以太坊账号余额查询,从用户操作到底层实现的深度解析

>区块浏览器：如Etherscan、Etherscan (测试网)等,输入任意以太坊地址即可查看其交易历史和实时余额。

Web3.js/Ethers.js等库：开发者通过调用这些库提供的方法，如eth_getBalance,可以轻松获取指定地址的余额。

这些便捷的体验背后，是对以太坊底层节点、数据结构和通信协议的复杂调用，从用户输入查询指令到看到余额结果,底层究竟发生了什么？

以太坊账户模型：余额存储的基础

理解余额查询，首先需要理解以太坊的账户模型，以太坊采用账户余额模型 (Account Balance Model)，这与比特币的UTXO模型不同,以太坊上的账户分为两类：

1. 外部账户 (Externally Owned Accounts, EOA)：
   • 由用户通过私钥控制。
   • 没有关联代码。
   • 存储ETH和代币余额,发起交易。
2. 合约账户 (Contract Accounts)：
   • 由代码控制（智能合约）。
   • 在被交易触发时执行代码。
   • 同样可以存储ETH和代币余额。

无论是EOA还是合约账户，其ETH余额都直接存储在账户的一个特定字段中，对于ERC-20等代币，其余额记录在代币智能合约内部维护的映射表中（mapping(address => uint256)）。

查询ETH余额，本质上是读取某个账户地址对应的ETH余额字段；查询ERC-20代币余额,则是读取代币合约账户中对应地址的映射值。

核心数据结构：状态树 (State Trie)

以太坊的状态（包括所有账户的余额、nonce、代码、存储等）信息存储在一个被称为状态树 (State Trie) 的Merkle Patricia Trie (MPT) 数据结构中。

• 状态树：以所有账户地址为键，账户状态（包括余额）为值的Merkle树,每个账户都有一个唯一的地址。
• 账户状态 (Account State)：包含以下字段：
  • nonce：账户发起的交易数量或合约创建数量。
  • balance：账户的ETH余额，以“wei”为单位（1 ETH = 10^18 wei）。
  • storageRoot：该账户的存储树的根哈希,存储合约的持久化数据。
  • codeHash：账户关联代码的哈希值（EOA此字段为空哈希）。

查询一个地址的ETH余额，就是在状态树中查找该地址对应的账户状态，然后读取其中的balance字段。

余额查询的核心流程：从节点到客户端

当用户通过钱包或应用发起一个余额查询请求时（例如调用eth_getBalance JSON-RPC方法）,底层流程大致如下：

1. 客户端发起请求：

   • 用户的钱包应用或DApp通过Web3.js、Ethers.js等库，构建一个eth_getBalance的JSON-RPC请求。
   • 请求中包含目标地址（通常格式化为十六进制字符串，如0x...）和区块号（可选，默认为最新区块latest）。

2. 连接以太坊节点：

   该请求被发送到用户连接的以太坊节点，节点可以是全节点、归档节点或轻节点,全节点拥有最完整的状态数据。

3. 节点处理请求 (核心步骤)：

   • 接收并解析请求：节点的JSON-RPC服务模块接收请求，解析出方法名eth_getBalance、参数（地址、区块号）。
   • 区块状态确定：如果指定了latest或特定区块号，节点需要确定要查询哪个区块的状态，每个区块头都包含一个stateRoot字段,指向该区块被确认时的状态树的根哈希。
   • 访问状态数据库：节点维护一个状态数据库（通常是LevelDB或类似的KV数据库）,用于存储当前或历史状态树的数据。
   • 状态树查找：
     • 节点根据stateRoot找到对应的状态树。
     • 使用目标地址作为键，在状态树中进行Merkle Patricia Trie查找，这个过程从树的根节点开始，根据地址的路径逐步向下遍历,直到找到对应的账户节点。
     • 在账户节点中，读取balance字段的值。
   • 处理代币余额（针对ERC-20等）：
     • 如果查询的是ERC-20代币余额，流程略有不同，节点需要：
       • 知道代币合约地址。
       • 从状态树中读取代币合约账户的状态,获取其代码。
       • 或者，更常见的是，节点（如果是全节点）会维护一个缓存或索引，或者直接执行合约代码中的balanceOf(address)方法（这涉及到EVM执行，对于简单查询可能效率不高，实际中节点可能优化或依赖预计算的数据）。
       • 节点会构造一个对代币合约balanceOf方法的调用，传入查询地址，然后执行这个调用（可能通过EVM），返回结果，这比查询ETH余额要复杂得多,因为它涉及合约代码的执行。
   • 格式化结果：查找到的ETH余额是以wei为单位的整数，节点会将其格式化为十六进制字符串（如0x1a05...）。

4. 返回响应：

   节点将格式化后的余额十六进制字符串封装在JSON-RPC响应中,返回给客户端。

5. 客户端展示：

   • 客户端（钱包或DApp）接收到响应，解析出余额值，可能进行单位转换（如从wei转换为ETH）,并最终展示给用户。

底层关键技术点

• Merkle Patricia Trie (MPT)：确保了状态数据的完整性、高效验证和轻客户端支持，通过Merkle证明，轻客户端可以验证某个余额是否属于某个状态根,而无需下载整个状态树。
• 状态数据库：通常使用Google的LevelDB,高效存储和检索MPT节点数据。
• JSON-RPC API：定义了客户端与以太坊节点进行通信的标准接口，eth_getBalance是其中用于查询ETH余额的核心方法。
• 区块状态与状态根：每个区块的状态快照通过stateRoot锚定在区块头中，使得历史状态的查询成为可能（归档节点尤其重要）。
• EVM (Ethereum Virtual Machine)：对于代币余额等需要合约交互的场景,EVM负责执行合约代码并返回结果。

以太坊账号余额的查询流程，是从用户友好的界面操作出发，经过客户端封装、网络传输，最终到达以太坊节点，节点则通过其核心的状态数据库（基于MPT结构），高效地定位并读取特定账户地址的余额信息，再返回给客户端，对于ETH余额，这主要是状态树的直接查找；而对于代币余额，则可能涉及对智能合约代码的调用与执行，这一系列底层机制共同保证了以太坊网络中余额数据的准确性、一致性和可查询性，为整个以太坊生态系统的稳定运行奠定了坚实的基础，理解这一流程，有助于开发者更好地与以太坊交互,也使用户对钱包和区块浏览器的工作原理有更深刻的认识。