钱包

在本节中，我们总结了用于构建用户友好，安全，和灵活的以太坊钱包的技术。

关于以太坊的一个常见误解是以太坊钱包包含ether或代币。实际上，钱包只包含密钥。ether或其他代币记录在以太坊区块链中。用户通过使用钱包中的密钥签署交易来控制网络上的代币。从某种意义上说，以太坊钱包是一个 钥匙串 keychain 。

有两种主要类型的钱包，通过它们包含的密钥是否彼此相关来区分。

第一种类型是 非确定性钱包 nondeterministic wallet ，其中每个密钥都是从随机数中独立生成的。密钥不相互关联。这种类型的钱包也被称为“Just a Bunch Of Keys”，JBOK钱包。

第二种类型的钱包是 确定性钱包 deterministic wallet ，其中所有密钥都来自单个主密钥，称为 种子 seed 。这种类型的钱包中的所有钥匙都是相互关联的，如果有原始种子，可以再次生成。确定性钱包中使用了许多不同的 *密钥推导方法。最常用的派生方法使用树状结构，称为 分层确定 hierarchical deterministic 或 HD 钱包。

确定性钱包是从种子初始化的。为了使这些更容易使用，种子被编码为一些英文单词（或其他语言的词），称为 mnemonic code 助记词，接下来的几节将从较高的层次介绍这些技术。

在第一个以太坊钱包（由Ethereum pre-sale创建）中，钱包文件存储一个随机生成的私钥。这些钱包正在被确定性的钱包取代，因为它们管理，备份和导入很麻烦。随机密钥的缺点是，如果你生成了许多密钥，你必须保留所有密钥的副本。每个密钥都必须备份，否则如果钱包变得不可访问，则其控制的资金将不可撤销地丢失。此外，以太坊地址重用可以通过将多个交易和地址相互关联来降低隐私。0型非确定性钱包是很少的选择，特别是如果你想避免地址重用，因为它意味着管理许多密钥，需要经常备份。

许多以太坊客户端（包括 go-ethereum 或 geth）使用 keystore 文件，这是一个JSON编码的文件，其中包含一个（随机生成的）私钥，由一个密码加密以提高安全性。JSON文件的内容如下所示：

{
    "address": "001d3f1ef827552ae1114027bd3ecf1f086ba0f9",
    "crypto": {
        "cipher": "aes-128-ctr",
        "ciphertext": "233a9f4d236ed0c13394b504b6da5df02587c8bf1ad8946f6f2b58f055507ece",
        "cipherparams": {
            "iv": "d10c6ec5bae81b6cb9144de81037fa15"
        },
        "kdf": "scrypt",
        "kdfparams": {
            "dklen": 32,
            "n": 262144,
            "p": 1,
            "r": 8,
            "salt": "99d37a47c7c9429c66976f643f386a61b78b97f3246adca89abe4245d2788407"
        },
        "mac": "594c8df1c8ee0ded8255a50caf07e8c12061fd859f4b7c76ab704b17c957e842"
    },
    "id": "4fcb2ba4-ccdb-424f-89d5-26cce304bf9c",
    "version": 3
}

keystore格式使用 Key 派生函数（KDF），也称为密码扩展算法，该算法可防止对密码加密的暴力破解，字典或彩虹表攻击。简而言之，私钥没有直接由密码短语加密。相反，通过反复对它进行哈希，密码被_拉长_ 。哈希函数重复执行262144轮，可以在keystore JSON中的参数 crypto.kdfparams.n 看到。试图暴力破解密码短语的攻击者必须对每个尝试的密码应用262144轮哈希，这足以减缓攻击行为，从而使破解足够复杂性和够长的密码短语是不可行的。

有许多软件库可以读写keystore格式，例如JavaScript库 keythereum：https://github.com/ethereumjs/keythereum

确定性或“种子”钱包是包含私钥的钱包，所有私钥都来源于共同的种子，使用单向哈希函数生成。种子是随机生成的数字，可以与其他数据（如索引编号或“链码”（请参阅HD 钱包 (BIP-32/BIP-44)））组合以导出私钥。在确定性钱包中，种子足以恢复所有派生的密钥，因此在创建时的单个备份就足够了。种子也足以用于钱包的导入和导出，允许在不同实现的钱包之间轻松迁移所有用户密钥。

确定性钱包的开发使得从单个”种子“中获得许多密钥变得容易。确定性钱包的最先进的形式是由比特币的BIP-32标准定义的HD钱包。HD钱包包含以树状结构导出的密钥，以便父密钥可以生成一系列的子密钥，每个子密钥可以派生一系列孙子密钥等等，可以达到无限深度。这个树状结构在 [hd_wallet] 中进行说明。

Figure 1. HD wallet: a tree of keys generated from a single seed

与随机（非确定性）密钥相比，HD钱包具有两大优势。首先，树状结构可以用来表达额外的组织含义，例如，使用特定分支的子密钥来接收传入的支付，使用不同分支的子秘钥来接收支付时产生的零钱。密钥的分支也可用于公司设置，将不同分支分配给部门，子公司，特定职能或会计类别。

HD钱包的第二个优点是用户可以创建一系列公钥而无需访问相应的私钥。这允许HD钱包用于不安全的服务器上，或者仅用于只查看或只接收的地方，其中钱包没有可以花费资金的私钥。

HD钱包是管理许多密钥和地址的非常强大的机制。如果将它们与一系列英文单词（或另一种语言的单词）相结合，更易于转录，和跨钱包的导出导入。这被称为 mnemonic ，标准由BIP-39定义。今天，许多以太坊钱包（以及用于其他加密货币的钱包）都使用此标准，并且可以使用可互操作的助记词导入和导出种子以进行备份和恢复。

我们从实际的角度来看一下。下列哪种种子更容易转录，在纸上记录，无误地读取，导出并导入另一个钱包？

随着加密货币钱包技术的成熟，某些常见行业标准使钱包广泛地互操作，易于使用，安全和灵活。这些标准还允许钱包从多个不同的加密货币中获取密钥，所有这些都来自助记词。这些通用标准是：

这些标准可能会改变，或者可能会因未来的发展而过时，但现在它们形成了一套互联技术，已成为大多数加密货币的事实上的钱包标准。

这些标准已广泛的被软件和硬件钱包采用，使所有这些钱包可以互操作。用户可以导出其中一个钱包上生成的助记词并将其导入另一个钱包，恢复所有交易，密钥和地址。

支持这些标准的软件钱包有 Jaxx，MetaMask，MyEtherWallet（MEW），硬件钱包有：Keepkey，Ledger和Trezor。

助记词是表示（编码）派生确定性钱包的种子的随机数的单词序列。单词序列足以重新创建种子，从而重新创建钱包和所有派生的密钥。使用助记词实现的确定性钱包会在首次创建钱包时向用户展示12至24个字的序列。该单字序列是钱包的备份，可用于在相同或任何兼容的钱包应用程序中恢复和重新创建所有密钥。

助记词在BIP-39中定义。请注意，BIP-39是助记词编码标准的一个实现。有一个不同的标准，带有一组不同的单词，在BIP-39之前用于Electrum比特币钱包。BIP-39由Trezor硬件钱包背后的公司提出，与Electrum的实现不兼容。但是，BIP-39现在已经在数十种可互操作实现方面取得了广泛的行业支持，应该被视为事实上的行业标准。此外，BIP-39可用于生产支持以太坊的多币种钱包，而Electrum种子不能。

BIP-39定义了助记词和种子的创建，我们在这里通过九个步骤来描述它。为了清楚起见，该过程分为两部分：步骤1至6展示在[generate mnemonic words] 中，步骤7至9展示在 从助记词到种子 中。

助记词是由钱包使用BIP-39中定义的标准化流程自动生成的。钱包从熵源开始，添加校验和，然后将熵映射到单词列表：

Generating entropy and encoding as mnemonic words 展示了如何使用熵来生成助记词。

Figure 2. Generating entropy and encoding as mnemonic words

Mnemonic codes: entropy and word length 展示熵数据的大小和助记词的长度关系。

Table 1. Mnemonic codes: entropy and word length

助记符字表示长度为128到256位的熵。然后使用使用密钥扩展函数PBKDF2将熵导出成更长的（512位）种子。然后使用生成的种子构建确定性钱包并派生其密钥。

密钥扩展函数有两个参数：助记词和 salt 。在密钥扩展函数中使用盐的目的是使得构建能够进行暴力攻击的查找表不可行。在BIP-39标准中，盐有另一个目的 —— 它允许引入密码，作为保护种子的附加安全因素，我们将在 BIP-39中的可选密码短语 中详细描述。

步骤7到9中从 生成助记词 描述的过程后继续：

[fig 5 7] 展示如何使用助记词来生成种子。

Figure 3. From mnemonic to seed

表格 #mnemonic_128_no_pass, #mnemonic_128_w_pass, 和 #mnemonic_256_no_pass 展示了一些助记词和它们生成的种子的例子（没有密码）。

Table 2. 128-bit entropy mnemonic code, no passphrase, resulting seed

Table 3. 128-bit entropy mnemonic code, with passphrase, resulting seed

Table 4. 256-bit entropy mnemonic code, no passphrase, resulting seed

BIP-39标准允许在派生种子时使用可选的密码短语。如果没有使用密码短语，助记词将被一个由常量字符串+"mnemonic"+ 组成的盐扩展，从任何给定的助记词中产生一个特定的512位种子。如果使用密码短语，则扩展函数会从同一助记词中生成一个 不同的 种子。事实上，对于一个助记符，每个可能的密码都会生成不同的种子。本质上，没有“错误的”密码。所有密码都是有效的，它们都会生成不同的种子，形成一大批可能未初始化的钱包。可能的钱包的集合非常大（ \( 2^{512} \) ），因此没有暴力或意外猜测正在使用的钱包的可能。

可选的密码短语创造了两个重要的特性：

但是，重要的是要注意使用密码也会导致丢失的风险。

虽然密码短语非常有用，但只能结合精心策划的备份和恢复过程，考虑到主人存活的可能性，并允许其家人恢复加密货币资产。

BIP-39 以许多不同的编程语言实现为库：

在独立网页中还有一个BIP-39生成器，对于测试和实验非常有用。A BIP-39 generator as a standalone web page 展示了生成助记词，种子和扩展私钥的独立网页。

Figure 4. A BIP-39 generator as a standalone Web page

页面（https://iancoleman.github.io/bip39/）可以在浏览器中离线使用，也可以在线访问。

HD钱包是由单个 根种子 创建的，该 种子 是128,256或512位随机数。最常见的情况是，这个种子是从 助记词 生成的，详见前一节。

HD钱包中的每个密钥都是从这个根种子确定性地派生出来的，这使得可以在任何兼容的HD钱包中从该种子重新创建整个HD钱包。这使得备份，恢复，导出和导入包含数千乃至数百万个密钥的HD钱包变得很容易，只需传输根种子的助记词即可。

[[bip32_bip43/44]] ==== 分层确定性钱包（BIP-32）和路径（BIP-43/44）

大多数HD钱包遵循BIP-32标准，这已成为确定性密钥事实上的行业标准代。你可以在以下网址阅读详细说明：https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

我们不会在这里讨论BIP-32的细节，只是了解如何在钱包中使用BIP-32。在许多软件库中提供了许多可互操作的BIP-32实现：Consensys/eth-lightwallet轻量级JS Ethereum节点和浏览器钱包（使用BIP-32）

还有一个BIP-32独立的网页生成器，对BIP-32的测试和实验非常有用：http://bip32.org/

HD钱包的一个非常有用的特点是能够从公开的父公钥中派生子公钥，而不需要拥有私钥。这为我们提供了两种派生子公钥的方法：从子私钥派生，或直接从父公钥派生。

因此，可以使用扩展公钥导出HD钱包结构分支中的所有 公钥 （只有公钥）。

此快捷方式可用于创建非常安全的公钥 - 部署中的服务器或应用程序只有扩展公钥的副本，没有任何私钥。这种部署可以产生无限数量的公钥和以太坊地址，但无法花费发送到这些地址的任何资金。与此同时，在另一个更安全的服务器上，扩展私钥可以导出所有相应的私钥来签署交易并花费金钱。

此解决方案的一个常见应用是在为电子商务应用程序提供服务的Web服务器上安装扩展公钥。网络服务器可以使用公钥派生函数为每个交易（例如，针对客户购物车）创建新的以太坊地址。Web服务器将不会有任何易被盗的私钥。如果没有HD钱包，唯一的方法就是在单独的安全服务器上生成数千个以太坊地址，然后将其预先加载到电子商务服务器上。这种方法很麻烦，需要不断的维护以确保电子商务服务器不会“用完”密钥。

此解决方案的另一个常见应用是冷钱包或硬件钱包。在这种情况下，扩展私钥可以存储在硬件钱包中，而扩展公钥可以保持在线。用户可以随意创建“接收”地址，而私钥可以安全地在离线状态下存储。要花费资金，用户可以在离线签署的以太坊客户端上使用扩展私钥或在硬件钱包设备上签署交易。

从xpub派生公钥的分支是非常有用的，但它带有潜在风险。访问xpub不能访问子私钥。但是，因为xpub包含链码，所以如果某个子私钥已知，或者以某种方式泄漏，则可以与链码一起使用，以派生所有其他子私钥。一个泄露的子私钥和一个父链码一起揭示了所有子私钥。更糟的是，可以使用子私钥和父链码来推导父私钥。

为了应对这种风险，HD钱包使用一种称为 强化派生 hardened derivation 的替代派生函数，该函数“破坏”父公钥和子链码之间的关系。强化派生函数使用父私钥来派生子链码，而不是父公钥。这会在父/子序列中创建一个“防火墙”，链码不能用于危害父代或同级私钥。

简而言之，如果你想使用xpub的便利来派生公钥的分支，而不会让自己面临泄漏链码的风险，所以应该从强化父项而不是普通父项派生。作为最佳做法，主密钥的1级子密钥级始终通过强化派生派生，以防止主密钥受到破坏。

BIP-32派生函数中使用的索引号是一个32位整数。为了便于区分通过常规派生函数派生的密钥与通过强化派生函数派生的密钥，该索引号分为两个部分。0到 \( 2^{31} -1 \)（0x0到0x7FFFFFFF）之间的索引号仅用于常规派生。 \( 2^{31} \) 和 \( 2^{32} -1 \)（0x80000000至0xFFFFFFFF）之间的索引号仅用于强化派生。因此，如果索引号小于 \( 2^{31} \) ，则子项是常规的，如果索引号等于或大于 \( 2^{31} \) ，则子项是强化的。

为了使索引号更容易阅读和展示，强化子项的索引号从零开始展示，但带有一个主要符号。第一个正常子密钥展示为0，而第一个强化子密钥（索引0x80000000）展示为0。然后，按顺序，第二个强化子密钥将具有索引0x80000001，并将展示为 1，依此类推。当你看到HD钱包索引i'时，表示 \( 2^{31} +i \)。

HD钱包中的密钥使用“路径”命名约定来标识，树的每个级别都用斜杠（/）字符分隔（参见 HD wallet path examples）。从主密钥派生的私钥以“m”开头。从主公钥派生的公钥以“M”开始。因此，主私钥的第一个子私钥为m/0。第一个子公钥是M/0。第一个孩子的第二个孩子是m/0/1，依此类推。

从右向左读取一个密钥的“祖先”，直到你到达从派生出它的主密钥。例如，标识符 m/x/y/z 描述了密钥 m/x/y 的第z个子密钥，密钥 m/x/y 是密钥 m/x 的第y个子密钥，密钥 m/x 是 m 的第 x 个子密钥。

Table 5. HD wallet path examples| HD path

HD钱包树结构提供了巨大的灵活性。每个父扩展密钥可以有40亿子密钥：20亿正常子密钥和20亿强化子密钥。这些子密钥中的每一个又可以有另外40亿子密钥，以此类推。这棵树可以像你想要的一样深，无限的世代。然而，这些灵活性，使得在这个无限树中导航变得非常困难。在实现之间转移HD钱包尤其困难，因为内部组织分支和子分支的可能性是无穷无尽的。

通过为HD钱包的树状结构创建一些标准，两个BIP为这种复杂性提供了解决方案。BIP-43建议使用第一个强化子密钥作为表示树结构“目的”的特殊标识符。基于BIP-43，HD钱包应该只使用树的一个1级分支，索引号通过定义其目的来标识树的其余部分的结构和名称空间。例如，仅使用分支m/i'/的HD钱包表示特定目的，而该目的由索引号“i”标识。

扩展该规范，BIP-44提出了一个多币种多帐户结构作为BIP-43下的“目的”号码+44'+。遵循BIP-44的HD钱包通过仅使用树的一个分支的事实来标识：m / 44'/。

BIP-44指定了包含五个预定义层级的结构：m / purpose' / coin_type' / account' / change / address_index

第一级“purpose”始终设置为+44'+。第二级“coin_type”指定加密货币类型，允许多货币HD钱包，其中每种货币在第二级下具有其自己的子树。标准文件中定义了几种货币，称为SLIP0044：https://github.com/satoshilabs/slips/blob/master/slip-0044.md

一些例子: Ethereum 是 m/44'/60', Ethereum Classic is m/44'/61', Bitcoin 是 m/44'/0', 所有货币的 Testnet 是 m/44'/1'.

树的第三层“account”, 允许用户将他们的钱包分割成逻辑上的子账户，用于会计或组织管理目的。例如HD钱包可能包含两个以太坊“账户”： m/44'/60'/0' 和 m/44'/60'/1'. 每个账户都是自己的子树的根。

由于BIP-44最初是为比特币创建的，因此它包含一个在以太坊世界中不相关的“怪癖”。在路径的第四层“change”时，HD钱包有两个子树，一个用于创建接收地址，另一个用于创建零钱地址。以太坊只使用“接收”路径，因为没有零钱地址这样的东西。请注意，虽然以前的层级使用强化派生，但此层级使用正常派生。这是为了允许树的这个层级导出扩展公钥在非安全环境中使用。可用地址由HD钱包作为第四级的孩子派生，使树的第五级成为“address_index”。例如，在主账户中以太坊付款的第三个接收地址为M/44'/60'/0'/0/2。BIP-44 HD wallet structure examples 展示了几个例子。

Table 6. BIP-44 HD wallet structure examples| HD path