g>作用：这棵树记录了某个区块内包含的所有交易，以太坊的每个区块都有一笔或多笔交易，这些交易被打包进交易树。

结构：同样是一棵MPT，其键通常是交易索引（例如0, 1, 2...），值是每笔交易的RLP编码，通过交易树，可以高效地验证某笔交易是否属于某个特定区块，以及区块内交易的顺序和内容，其根哈希（Transactions Root）也存储在区块头中。

收据树 (Receipts Tree)

• 作用：这棵树记录了区块内每笔交易执行后的结果，即“收据”，收据包含了交易是否成功、消耗的Gas、日志条目（Log，常用于事件触发）等信息。
• 结构：同样是一棵MPT，键通常是交易索引，值是交易收据的RLP编码，收据树对于轻客户端和DApp开发者非常重要，因为它允许在不执行完整交易的情况下，验证交易的结果和事件的发生，其根哈希（Receipts Root）也存储在区块头中。

为什么会有“三种树”的说法？

看到这里,相信您已经明白，所谓的“三种树”，实际上都是Merkle Patricia Trie (MPT) 的不同应用实例，它们分别是：

• 状态树 (State Tree)
• 交易树 (Transactions Tree)
• 收据树 (Receipts Tree)

这三棵MPT共同构成了以太坊区块头中三个关键的根哈希,是以太坊数据完整性和可验证性的核心保障，当有人在知乎或 elsewhere 提到“以太坊有三种树”时，他们很可能指的就是这三种MPT，它们并非三种不同类型的“树”，而是同一种树结构（MPT）在不同数据维度上的体现。

有没有“第四种树”？—— 存储树 (Storage Tree)

还有一个常被提及的“树”是合约存储树 (Contract Storage Tree)，每个智能合约账户都拥有自己独立的存储树，用于记录合约的状态变量，当合约状态变量发生变化时，对应的存储树会更新，并产生新的存储根哈希（Storage Root），这个存储根会作为账户状态的一部分存储在状态树中。

如果从更广义的角度看,以太坊中存在大量的“树”——一个全局状态树，每个区块一棵交易树和一棵收据树，以及每个合约账户一棵存储树，但通常我们讨论以太坊的核心数据结构时，会聚焦于状态树、交易树和收据树这三种直接影响区块头和全局状态的MPT。

知乎上的常见误解与澄清

在知乎等社区,关于以太坊“树”的讨论中，常见的误区包括：

• 混淆MPT与其他树结构：比如将MPT与比特币中使用的Merkle Tree（普通默克尔树）混淆，比特币的默克尔树主要用于交易验证，而以太坊的MPT则更灵活，能适应键值对存储，并且支持更复杂的查询和更新。
• 将“三种MPT”误认为“三种不同类型的树”：如前所述，它们都是MPT，只是存储的数据不同。
• 忽略存储树：有时会忽略合约账户独立的存储树，只关注全局层面的三棵树。

回到最初的问题：“以太坊有三种树吗？” 基于以太坊的核心数据结构和知乎上常见的讨论语境，最贴切的回答是：以太坊主要依赖三种Merkle Patricia Trie (MPT) 实例来组织核心数据，它们分别是状态树、交易树和收据树，这“三种树”共同维护了以太坊网络的完整性、可验证性和高效性。 它们并非三种截然不同的树结构，而是MPT在不同数据维度上的具体应用，理解这三种MPT的作用，对于深入掌握以太坊的工作原理至关重要，下次在知乎看到类似问题时，您就可以清晰地解释这“三种树”的真相了。

---