在以太坊的底层架构中，有三种核心的数据结构被称为“树”（Tree），它们共同构成了区块链数据存储与验证的基石，这三种树分别是状态树（State Tree）、交易树（Transactions Tree）和收据树（Receipts Tree），它们共同确保了以太坊网络的数据完整性、可追溯性和状态一致性，下面，我们将逐一解析这三棵“树”的作用、结构及其在以太坊生态中的核心地位。

状态树（State Tree）：以太坊的“全球账本”

状态树是以太坊中最核心的数据结构，它记录了整个网络当前的全局状态，以太坊的“全局状态”就像一个分布式的“大账本”，记录了所有账户（外部账户或合约账户）的实时信息，包括账户余额、 nonce（交易次数）、合约代码、存储数据等。

结构：Merkle Patricia Trie（MPT）

状态树采用Merkle Patricia Trie（MPT，默克尔前缀树）结构，这是一种结合了Merkle树和Patricia Trie优化的数据结构：

• Patricia Trie：一种压缩前缀树，通过共享公共前缀减少存储空间，适合处理大规模键值对数据（如以太坊的账户地址）；
• Merkle树：通过哈希计算将子树根节点哈希值合并为父节点根值，最终生成一个唯一的“根哈希”（State Root），任何数据的修改都会导致根哈希变化，从而快速检测数据篡改。

作用：验证状态一致性

状态树的根哈希（State Root）会被打包到每个区块的头部，成为区块头的一部分，节点通过比较本地状态树的根哈希与网络中的最新根哈希，即可快速验证自身状态的完整性，当用户发起转账时，状态树会更新发送方和接收方的余额，生成新的根哈希，全网节点可通过该哈希同步最新状态。

示例

假设以太坊上有两个账户：

• 账户A（地址0x123…）：余额10 ETH，nonce=5；
• 账户B（地址0x456…）：余额20 ETH，nonce=3。
  这些信息会被组织成MPT结构，计算出一个唯一的State Root，若账户A向账户B转账1 ETH，状态树会更新账户A的余额（9 ETH，nonce=6）和账户B的余额（21 ETH，nonce=4），State Root随之改变。

交易树（Transactions Tree）：记录每一笔“操作指令”

交易树用于存储区块内包含的所有交易数据，是以太坊“可追溯性”的核心保障，每个区块中的交易都会被组织成一棵Merkle树，生成唯一的交易根哈希（Transactions Root），并记录在区块头中。

结构：Merkle Tree

交易树采用标准的Merkle树结构：

• 将区块内的每笔交易通过哈希函数生成唯一的交易哈希；
• 将交易哈希两两配对，计算子节点哈希，递归向上合并，最终得到交易树的根哈希（Transactions Root）。

作用：验证交易存在性与顺序

交易树的根哈希确保了区块内交易的不可篡改性和顺序性：

• 存在性证明：用户可以通过Merkle证明验证某笔交易是否属于某个区块（交易所或钱包用户可快速查询交易是否上链）；
• 顺序保障：交易树的构建顺序与区块中的交易顺序一致，任何交易顺序的篡改都会导致Transactions Root变化，从而被节点拒绝。

示例

假设一个区块包含3笔交易：

• 交易1：A→B转账1 ETH；
• 交易2：C→D转账2 ETH；
• 交易3：E→F转账3 ETH。
  交易树会先将这3笔交易的哈希值作为叶子节点，通过Merkle计算生成Transactions Root，矿工打包区块时，会将该Root写入区块头，全网节点通过验证Root确认交易的合法性。

收据树（Receipts Tree）：记录交易的“执行结果”

收据树存储了每笔交易的执行结果，即“收据”（Receipt），收据不是交易本身，而是交易被以太坊虚拟机（EVM）执行后产生的元数据，包括交易状态（成功/失败）、消耗的Gas、日志（Log）等。

结构：Merkle Tree

收据树同样采用Merkle树结构，其叶子节点是每笔交易的收据，最终生成收据根哈希（Receipts Root），记录在区块头中。

作用：轻量化查询与事件追踪

收据树的核心价值在于提供轻量级的交易执行结果查询，无需重新执行交易即可获取关键信息：

• 交易状态：用户可通过收据快速判断交易是否成功（因Gas不足导致的失败）；
• 日志（Log）：合约执行时产生的日志（如ERC20代币转账的“Transfer”事件）会被记录在收据中，是去中心化应用（DApp）事件监听（如The Graph索引
  
  ）的核心数据源；
• Gas消耗：帮助用户和开发者分析交易成本。

示例

假设一笔交易是调用ERC20代币合约的transfer函数：

• 交易执行成功，消耗了21000 Gas；
• 合约生成了Transfer事件，记录了“from: A, to: B, value: 1 ETH”。
  这些信息会被打包成收据，存入收据树，外部应用（如区块浏览器或DApp）无需重新运行transfer函数，只需查询收据即可获取交易结果和事件数据。

三棵树的关系：以太坊的“数据铁三角”

状态树、交易树和收据树并非独立存在，而是通过区块头紧密关联，共同构成以太坊的“数据铁三角”：

• 每个区块头包含三个关键哈希：State Root（状态树根）、Transactions Root（交易树根）、Receipts Root（收据树根）；
• 任何一笔交易的执行（如转账、合约调用）会同时影响三棵树：
  1. 交易被写入交易树；
  2. 交易执行结果（状态变更）更新状态树；
  3. 交易收据被写入收据树。

这种设计确保了以太坊的数据一致性：若任何一棵树的哈希不匹配（有人篡改历史交易），节点即可通过比对区块头中的三个Root快速发现异常，保障网络安全。

三棵树为何重要

状态树、交易树和收据树是以太坊作为“世界计算机”的底层基础设施：

• 状态树维护了网络的全局状态，确保所有账户数据的实时准确；
• 交易树记录了所有操作指令，保障了交易的不可篡改与可追溯；
• 收据树提供了轻量化的执行结果，支撑了DApp的事件交互与数据分析。

理解这三棵树，不仅有助于掌握以太坊的技术本质，更能为开发者构建安全、高效的区块链应用提供底层逻辑支撑，随着以太坊2.0的演进（如分片、Rollup），这三棵树的结构可能会优化，但其“保障数据完整性、可追溯性、一致性”的核心使命将始终不变。