Substrate BIP39

这是一个用于从 BIP39 短语中派生 Ristretto 压缩 Ed25519（应与 Ed25519 兼容）密钥的crate。

为什么？

在这里，自然的方法是使用从 BIP39 短语生成的 64 字节种子，并使用它来构建密钥。这种方法虽然合理且易于实现，但也意味着我们必须继承种子生成的一切特性。由于我们无论如何都要与 BIP32 和 BIP44 兼容性断裂（我们之所以可以这样做，是因为我们不再使用 Secp256k1 曲线），因此也没有理由我们必须遵守从助记符生成种子。

BIP39种子生成旨在与用户提供的脑钱包短语兼容，同时也可扩展到提供自己的字典和校验机制的钱包。关于这两点存在的问题

1. 脑钱包是一个糟糕的想法，因为人类是糟糕的熵生成者。教育用户以安全方式使用该功能几乎是不可能的。2048轮PBKDF2只是一个不便，对于拥有现代消费级硬件的人来说，并不能真正提供对字典攻击的保护。脑钱包给用户带来了虚假的安全感。人们因此损失了钱财，而现在的钱包提供商通常坚持使用CSPRNG提供的字典短语。

2. 提供自己的字典从第一天开始就陷入了你不需要它的反模式。钱包提供商（无论是硬件还是软件）通常希望他们的产品与其他钱包兼容，这样用户就可以在不迁移所有资产的情况下迁移到他们的产品。

为了实现上述功能，短语必须精确地编码在唯一真正的规范编码中，因此选择了UTF-8 NFKD。这对于英文短语来说在很大程度上是不相关的（甚至被忽略），因为它们在几乎所有的字符编码中都编码为基本的ASCII，但对于使用非ASCII字符的字典来说，立即成为一个问题。即使使用正确的编码并正确实现，仍然存在其他一些非英语字典的注意事项，例如将空格规范化为规范形式，或者使某些基于拉丁字母的字符在字典查找中等同于其基字符（例如，西班牙语中的ñ和n应该可以互换）。思考所有这些让我头疼，并且为有缺陷的实现之间的不一致打开了大门，破坏了兼容性。

BIP39已经提供了一种无任何这些问题的助记符形式：熵字节数组。由于验证校验和需要从生成短语中恢复熵，所以这里实际上不需要做额外的工作。钱包实现者可以将字典编码为他们认为方便的任何编码（只要它们是标准的BIP39字典），使用Java和JavaScript提供的UTF-16字符串原语没有问题。由于字典是固定的并且是已知的，校验和是在熵本身上进行的，所以确切的字符编码变得无关紧要，精确的码点和单词周围的空白数量也是如此。因此，创建有缺陷的实现变得更加困难。

保留了PBKDF2和密码。使用24个单词（其熵为256位）使得额外的散列是多余的（如果你能强行破解256位熵，你也可以直接强行破解秘密密钥），然而一些用户可能仍在使用其他应用程序中的12个单词短语。在我看来，没有理由禁止用户使用12个单词恢复他们的旧钱包，在这种情况下，额外的散列确实提供了一些保护。密码也是一些高级用户认为有用的功能——特别是用于创建一个带有少量余额且密码为空的诱饵地址，而实际资金存储在一个需要输入密码的地址上。

为什么不完全放弃BIP39呢？

因为有一些硬件钱包使用一个短语来覆盖整个设备，并在多个网络上使用该短语操作多个账户。一个完全不同的单词列表会让它们在提供未来Substrate支持时困难得多。