以太坊作为全球第二大区块链平台，其账户余额查询是用户与开发者最常接触的操作之一，无论是钱包应用、DeFi协议还是区块链浏览器，获取以太坊余额都是核心功能之一，看似简单的“查询余额”背后，涉及以太坊的账户模型、状态存储、节点通信等多层技术原理，本文将从底层机制出发,详细拆解以太坊余额获取的完整流程。

核心基础：以太坊的账户模型与状态存储

要理解余额获取原理，首先需明确以太坊的账户模型，与比特币的UTXO模型不同，以太坊采用账户模型（Account Model），每个账户分为两类：

  1. 外部账户（Externally Owned Account, EOA）：由用户私钥控制，用于发起交易、持有资产（如ETH和ERC-20代币）。
  2. 合约账户（Contract Account）：由代码控制，用于执行智能合约逻辑，不能主动发起交易。

两类账户的核心区别在于：EOA没有代码，仅通过nonce（交易序列号）、balance（余额）、storageRoot（合约存储根，仅合约账户有效）和codeHash（代码哈希，仅合约账户有效）四个字段存储状态；而合约账户在此基础上增加了代码执行能力。

余额（Balance）是EOA账户状态中最核心的字段之一，记录了该账户持有的ETH数量（以“wei”为单位，1 ETH = 10^18 wei），在以太坊区块链中，所有账户的状态共同构成了状态树（State Tree），而状态树又是更上层世界状态（World State）的一部分。

状态树的层级结构：余额如何“存”在链上

以太坊的状态数据通过Merkle Patricia Trie（MPT，梅克尔帕特里夏树）结构存储，这种设计既能高效查询，又能保证数据完整性，状态树的层级关系如下：

  1. 世界状态树（World State Tree）：以太坊的“顶层字典”，key是账户地址（20字节），value是该账户的状态根（即状态树的根哈希）。
  2. 账户状态树（Account State Tree）：每个账户对应一棵MPT，存储账户的四个字段（nonce、balance、storageRoot、codeHash）。balance作为叶子节点直接存储在账户状态树中。
  3. 存储树（Storage Tree）：仅合约账户使用，存储合约的变量状态；EOA账户的storageRoot为空。
  4. 合约代码树（Code Tree）：存储合约的字节码，codeHash是其根哈希。

一个EOA账户的余额存储路径为：世界状态树 → 账户状态树 → balance字段，当需要查询余额时，本质上是在这一层级的树状结构中定位目标地址的balance值。

余额获取的完整流程：从节点到用户

以太坊的余额获取并非直接“读取区块链”，而是通过节点间的数据同步与查询完成，完整流程可分为以下步骤：

节点同步最新状态

以太坊节点（全节点）会持续同步区块链数据，包括区块头、交易列表和状态数据，状态数据的同步通过“状态获取（State Retrieval）”实现：当节点收到新区块时，会根据区块中的stateRoot（世界状态树的根哈希）验证本地状态树的完整性，若缺失或过期，会从其他节点同步对应的账户状态、存储树等数据。

全节点本地存储了完整的最新世界状态树，可直接查询任意账户的余额，而轻节点（如钱包中的轻客户端）则通过状态尝试（State Trial）或状态通道（State Channels）从全节点获取特定数据,依赖MPT验证其真实性。

构建查询请求：明确目标地址

无论是钱包、浏览器还是应用，获取余额的第一步是提供目标账户地址（以“0x”开头的40位十六进制字符串，如0x742d35Cc6634C0532925a3b844Bc9e7595f8bE8c），这个地址是定位账户状态树的“钥匙”。

节点内部查询：从世界状态树到余额字段

当节点收到余额查询请求后，执行以下操作：

  • 定位账户状态树：以目标地址为key，从世界状态树中查找对应的stateRoot（即该账户状态树的根哈希）。
  • 遍历账户状态树：根据stateRoot在本地账户状态树中查找balance字段，由于MPT的特性，这一过程仅需O(log n)时间复杂度，效率极高。
    • 随机配图