以太坊作为全球第二大公链,其账户模型和余额机制是区块链生态运行的基础，无论是普通用户查看钱包资产、开发者构建DApp，还是矿工/验证者处理交易，都离不开对“以太坊余额计算”的理解，本文将从账户模型入手，拆解以太坊余额的核心计算逻辑，并探讨影响余额的关键因素与实际应用场景。

以太坊账户模型：余额计算的基础

以太坊采用“账户模型”（Account Model），而非比特币的“UTXO模型”，每个账户在以太坊中都是一个独立的实体，分为外部账户（EOA，Externally Owned Account）和合约账户（Contract Account）两类，两类账户均存储“余额”（Balance），但计算逻辑略有差异。

  • 外部账户：由用户通过私钥控制，如MetaMask钱包中的账户，其余额计算相对简单，直接对应账户地址持有的以太币（ETH）数量。
  • 合约账户：由代码控制，其余额不仅包括接收的ETH，还可能涉及内部调用（如fallback函数）或代币交互，但无论哪种账户，余额的底层存储逻辑均一致。

在以太坊的Merkle Patricia Trie（MPT）状态树中，每个账户的状态由以下字段构成，其中balance字段存储的就是账户余额： 

{
  nonce: uint,          // 账户交易次数（外部账户）或合约创建次数（合约账户）
  balance: uint,        // 以太坊余额（单位：wei，1 ETH = 10^18 wei）
  storageRoot: bytes32, // 合约账户的存储根哈希
  codeHash: bytes32     // 账户代码的哈希（外部账户为空哈希）
}

以太坊余额计算的本质，就是读取账户状态树中balance字段的值。

余额计算的核心逻辑：从交易到状态更新

以太坊的余额并非静态值,而是随着交易和区块打包动态变化的，其计算逻辑可拆解为“初始余额+交易变动-手续费”的过程，具体如下：

初始余额：状态树中的当前值

每个账户的初始余额是当前区块状态树中balance字段的值，当用户查询余额时，客户端（如以太坊节点、钱包）会通过以下步骤获取：

  • 节点查询：全节点通过账户地址访问状态树，定位到对应的账户状态节点，读取balance字段。
  • 轻节点/钱包：通过JSON-RPC接口（如eth_getBalance）向节点发起请求，节点返回指定地址的当前余额（默认单位为wei，可转换为ETH）。

交易中的余额变动：转账与手续费

交易是影响余额的核心操作,以太坊的交易类型多样（如普通转账、合约调用、ERC-20代币转账等），但余额变动均遵循“输入=输出+手续费”的原则。

  • 普通转账交易（如Transfer）：
    假设账户A向账户B转账10 ETH，当前账户A余额为100 ETH，账户B为50 ETH，交易流程如下：

    1. 交易发起：账户A签名交易，指定接收方B和转账金额10 ETH（10^18 wei）。
    2. 手续费扣除随机配图