以太坊源码分析：账户

本文分析的源码地址为：

部门：师傅

提交 ID：257bfff316e4efb8952fbeb67c91f86af579cb0a

介绍

在以太坊中，当你想要挖矿或发送交易时，你需要一个账号和私钥。 众所周知，不同于普通应用的账户密码，一旦区块链中的私钥丢失，就没有“忘记密码”按钮； 如果它被盗，你不能“更改密码”。 所以私钥在安全上是非常重要的。

accounts模块是以太坊的一个账户管理模块，其实就是一个命令行钱包。 可以使用本地文件存储加密的私钥信息； 它还可以连接到硬件钱包以创建和管理私钥。 在本文中，我们将对实现这些功能的源码进行介绍和分析。

账户支持的钱包类型

账户中，两类共支持4种钱包。 这两个类别包括keystore和usbwallet； keystore中私钥存储分为加密和未加密； usbwallet 支持 ledger 和 trenzer 两种硬件钱包。 如下所示：

下面我们依次对其进行介绍。

密钥库：本地文件夹

keystore类型的钱包其实就是一个本地的文件夹目录。 该目录下可以存放多个文件，每个文件存放一个私钥信息。 这些文件都是json格式，私钥可以是加密的也可以是未加密的明文。 但非加密格式已被弃用（没有人愿意将他们的私钥以明文形式存储在文件中）。

keystore的目录路径可以在配置文件中指定，默认路径为/keystore。 每个文件的文件名格式为：UTC----。 例如 UTC--2016-03-22T12-57-55--7ef5a6135f1fd6a02593eedc869c6d41d934aef8。

keystore目录和目录下的文件可以直接复制。 也就是说，如果你想将某个私钥转移到另一台电脑上，直接将文件复制到另一台电脑的keystore目录下即可。 复制整个keystore目录也是如此。

HD：分层确定性钱包

先解释一下HD（Hierarchical Deterministic）的概念。 这个概念的中文名称叫做“层次确定性”。 我的理解是这是一种密钥推导方式，只能使用一个公钥（我们称这个公钥为主公钥，其对应的私钥为主私钥），任意多个子公钥可以生成密钥，这些子公钥可以由主私钥控制。 HD的概念最早是从比特币的BIP-32提案中提出来的。

每个密钥都有自己的路径，即它是派生密钥，与密钥库类型相同。 我们先来看看HD账号的路径格式：

m /purpose'/coin_type'/account'/change/address_index

这个路径规范不是一下子形成的。 BIP-32虽然提出了HD的概念，但是实现者的自由度比较大，导致相互之间的兼容性较差。 因此，在BIP-43中增加了purpose字段； 并且对BIP-44中的路径规范进行了大量的扩展，使其可以在不同的币种中使用。

在BIP-43中，purpose的推荐值为44'（0x8000002C）； 而在 BIPSLIP-44 中以太坊私钥格式，以太坊类型的 coin_type 的值为 60' (0x8000003c)。 所以我们可能会在以太坊中看到类似 m/44'/60'/0'/0 的路径。

账户模块支持两种类型的 HD 钱包：Ledger 和 Trenzer。 都是非常有名的硬件钱包，有兴趣的朋友可以自行搜索，就不过多介绍了。

目录结构

accounts模块下的源文件很多，这里就不一一解释了以太坊私钥格式，只挑一些比较重要的说一下。

优盘钱包

这是一个子目录。 该目录下的代码实现了通过usb连接的硬件钱包的访问，但只支持ledger和trezor两种硬件钱包。

实施框架

accounts模块中的代码虽然不多，但还是有点复杂。 它的复杂性主要来自于多个接口的使用，以及不同层次的概念。 先看一个框架图，再解释一下不明白的地方。

从图中可以看出，钱包有两种类型：keystore和usbwallet，两者都是由Manager对象作为Backend接口进行管理。 在不同的 Backends 内部，Wallet 接口有不同的实现。 调用者生成不同的Backend对象后，使用Manager进行统一管理。

这里要强调一下Wallet接口的含义和具体实现，因为我自己理解错了。 我误以为一个Wallet对象是用来管理多个账户的。 但是在accounts模块中，一个Wallet对象（比如keyStoreWallet）只代表一个账户，不能代表多个。 以keyStoreWallet为例，它只代表一个账户和一个文件。

上面一一解释。 在usbwallet类型的Backend中，Hub结构代表了该类后端钱包，主要由函数NewLedgerHub或NewTrezorHub创建，根据不同的驱动可以代表不同的硬件钱包。 这也是图中makeDriver字段想要表达的意思。 在ledger.go和trezor.go中，有各自的驱动实现，使用不同的协议，通过device.Write和io.ReadAll来读写设备，实现通信。

在keystore类型Backend中，KeyStore结构代表了这种后端钱包，主要是通过函数NewKeyStore或者NewPlaintextKeyStore创建的。 根据不同的keyStore，可以代表一个加密或非加密的keystore类型钱包。 这就是图中storager的意思。 非加密存储更简单且已弃用，因此我们不再多说。 加密存储是通过keyStorePassphrase结构实现的。 它通过AES算法对私钥进行加密，写入文件。

accountCache 和 fileCache 用于缓存账户信息。 fileCache 每次扫描keystore 目录时，都会与内存中当前存储的文件信息进行比较，以查找新创建、删除和修改的文件； accountCache 使用这些信息来更新内存中的帐户信息。

总结

本文主要介绍以太坊账户模块的实现架构。 accounts模块是以太坊项目中的账户和私钥管理模块。 它不仅存储私钥和账户信息，还对数据进行加密。

accounts模块的第一个概念是Backend，代表不同的钱包类型。 Backend inside accounts有两种类型：本地目录（keystore）和硬件钱包（usbwallet）。 本地目录方式支持将私钥加密后存放在本地目录； 硬件钱包同时支持 ledger 和 trezor。

帐户的第二个概念是钱包。 其内部的Wallet接口代表了一个账户和私钥的管理，而不是“钱包”的概念。 我觉得这有点模棱两可，还是改成“KeyPair”比较好。

以上是我对以太坊账户模块的分析，如有错误，欢迎指正。

笔记：

[1]参考：源码阅读笔记-accounts-2-hierarchical deterministic wallet