在区块链技术中，数据结构的核心目标是高效验证数据的完整性与安全性，同时兼顾系统的可扩展性。比特币和以太坊作为两大主流公链，在区块结构设计上存在显著差异：比特币的区块头仅包含一棵交易默克尔树（Merkle Tree），而以太坊则引入了交易树、状态树和收据树三棵独立的数据结构。这种差异源于两者设计目标的不同——比特币专注于简单支付，而以太坊支持复杂的智能合约和状态管理。本文将从技术原理和应用场景出发，深入解析这一差异背后的逻辑。
一、比特币的默克尔树：简洁高效的支付验证
1.1 比特币的交易模型与UTXO
比特币的核心功能是点对点支付，其交易模型基于UTXO（未花费交易输出）。每个交易消耗之前的UTXO并生成新的UTXO，整个过程无需记录账户余额，只需验证交易的合法性。因此，比特币的区块设计只需关注交易的完整性验证。
1.2 默克尔树的角色
比特币的区块体包含所有交易，通过默克尔树将这些交易归纳为一个Merkle Root存入区块头。默克尔树的作用体现在三个方面：
- 快速验证：轻节点（如SPV钱包）仅需区块头和交易路径即可验证某笔交易是否被包含在区块中，复杂度仅为 (O(\log n))。
- 防篡改：任何交易的修改都会导致根哈希值变化，确保数据不可篡改。
- 零知识证明：无需透露交易细节即可证明交易存在性。
例如，当用户A向B转账时，全节点可向B的SPV钱包提供交易路径（如交易哈希、相邻节点哈希等），B通过本地计算验证Merkle Root是否与区块头一致，即可确认交易有效性。
二、以太坊的三棵树：为智能合约而生
2.1 智能合约的复杂性需求
以太坊的核心目标是支持智能合约，合约的执行涉及状态变更（如账户余额、合约存储变量等）。这种复杂性催生了以下需求：
- 状态管理：需全局记录所有账户的实时状态。
- 执行结果追溯：需存储交易执行后的收据（如日志、事件）。
- 高效查询：需支持复杂查询（如“过去十天与某合约相关的交易”）。
因此，以太坊设计了三种树结构：
- 交易树（Transaction Tree）：记录当前区块的交易。
- 状态树（State Tree）：存储所有账户的全局状态。
- 收据树（Receipt Tree）：保存交易执行后的结果。
2.2 全局状态树的设计逻辑
状态树是三者中最特殊的存在，其设计体现了以太坊与比特币的本质差异：
- 全局性：状态树包含所有账户（无论是否参与当前区块的交易），而交易树和收据树仅包含当前区块数据。
- 共享节点：多个区块的状态树共享未变更的节点，仅修改发生状态变化的账户分支。例如，若区块A修改了账户X的余额，则新区块B的状态树仅新建X的分支，其余节点沿用A的树结构。
- 高效查找：通过Merkle Patricia Trie（MPT）结构，状态树支持按账户地址快速定位状态，时间复杂度为 (O(\log n))。
为什么状态树必须是全局的？
假设状态树仅包含当前区块涉及的账户，则以下场景将无法处理：
- 跨区块状态依赖：若账户B在区块1中未参与任何交易，但在区块2中被账户A转账，此时需从全局状态树中获取B的历史状态。
- 新账户创建：若用户向一个从未参与交易的新地址转账，需在状态树中动态创建该账户。
三、数据结构差异的技术实现对比
3.1 比特币的默克尔树
- 结构：普通二叉树，叶子节点为交易哈希。
- 验证逻辑：仅需验证交易存在性，适合UTXO模型。
3.2 以太坊的MPT与Bloom Filter
- MPT（Merkle Patricia Trie）：结合默克尔树和前缀树的优点，支持键值查找。例如：
- 状态树的键为账户地址。
- 交易树和收据树的键为交易序号。
- Bloom Filter：用于快速过滤无关区块。每个交易的收据包含一个Bloom Filter摘要，区块头的总Bloom Filter是所有交易的并集。轻节点可先通过区块头过滤掉不相关区块，再深入验证候选区块。
四、设计差异的哲学思考
4.1 比特币：极简主义
比特币的设计哲学是“做减法”。通过UTXO模型和单一默克尔树，最大限度降低系统复杂度，确保安全性与去中心化。这一设计牺牲了功能扩展性，但换来了十多年的稳定运行。
4.2 以太坊：复杂性换灵活性
以太坊选择“做加法”，通过三棵树和全局状态管理支持智能合约。这种设计引入了更高复杂性（如状态爆炸问题），但也创造了DeFi、NFT等生态繁荣。状态树的共享节点机制和MPT结构，是其平衡效率与功能的关键。
五、总结：技术服务于场景
比特币和以太坊的区块结构差异，本质是应用场景驱动技术选型的体现：
- 比特币：专注支付，通过单一默克尔树实现高效验证。
- 以太坊：支持智能合约，需全局状态树保障状态一致性，收据树支持复杂查询，交易树维持区块独立性。
未来，随着区块链技术的发展，更多创新结构（如分片状态树、零知识证明树）可能进一步优化这一平衡。
