当前位置：首页 > news >正文

区块链技术原理(14)-以太坊数据结构

news 2025/8/17 8:35:58

文章目录

前言
一、区块结构（Block Structure）和交易
二、核心索引：Merkle Patricia Trie（MPT）树
- 统一编码：RLP（Recursive Length Prefix）
- 为什么要设计三棵树
三、与比特币数据结构对比
总结

前言

以太坊的数据结构是其实现 “去中心化世界计算机” 功能的核心支撑，围绕账户状态管理、交易完整性验证、合约执行追溯三大需求设计，形成了 “区块容器 + Merkle Patricia Trie（MPT）树 + 账户 / 交易 / 收据结构化数据” 的分层体系。这些数据结构不仅确保了全网状态一致性和数据不可篡改，还为智能合约的复杂逻辑、轻节点高效验证提供了技术基础。

以太坊设计状态树、交易树和收据树这三棵树，主要是为了满足其支持智能合约、账户模型以及高效验证等多方面的需求，具体如下：

一、区块结构（Block Structure）和交易

这部分我们前面的章节已经讲解过，可以移步以太坊区块和以太坊交易

二、核心索引：Merkle Patricia Trie（MPT）树

以太坊的 “三棵树”（状态树、交易树、收据树）均基于MPT实现 —— 这是一种结合了 “Patricia Trie（前缀树）路径压缩” 和 “Merkle 树哈希验证” 的混合数据结构，专门解决 “稀疏键值对存储” 和 “快速哈希验证” 的矛盾（以太坊账户地址是 160 位，普通 Merkle 树会因键值稀疏导致存储爆炸）。

MPT 的核心设计：为什么不用普通 Merkle 树？

普通 Merkle 树的痛点：需将所有叶子节点按顺序排列，若键值（如账户地址）稀疏（大部分地址无对应状态），会产生大量 “空叶子节点”，存储效率极低。
MPT 的优化：
- 路径压缩：合并连续的 “单一子节点” 路径（如键0x1234和0x1235的共同前缀0x123可合并为一个中间节点），大幅减少稀疏键值对的存储开销。
- Merkle 哈希验证：每个节点（叶子 / 中间 / 根）均有唯一哈希，根哈希由所有子节点哈希递归计算得出，任一子节点篡改都会导致根哈希变化，确保数据不可篡改。
- 支持部分验证：轻节点无需存储整棵树，只需获取 “目标键到根节点的路径节点”，即可验证该键值的真实性（Merkle 证明）。

三棵 MPT 树的分工：数据索引的 “三驾马车”
以太坊通过三棵独立的 MPT 树，分别管理 “账户状态”“交易记录”“执行结果”，实现数据的分类存储和高效查询：

树类型	叶子节点数据	键（Key）类型	核心作用
状态树	账户状态（RLP 编码）	账户地址（160 位哈希）	实时存储全网所有账户的状态（余额、nonce、合约代码 / 存储），支持按地址快速查询状态。
交易树	交易数据（RLP 编码）	交易在区块内的索引（uint256）	记录区块内所有交易的完整信息，验证交易是否被篡改或遗漏。
收据树	交易收据（RLP 编码）	交易在区块内的索引（uint256）	记录每笔交易的执行结果（如 Gas 消耗、事件日志），支持快速追溯交易影响。

关键共性：三棵树的根哈希均存储在区块头中 —— 全网节点只需对比区块头的根哈希，即可确认 “账户状态、交易、执行结果” 是否一致，无需传输完整数据，大幅提升同步效率。

统一编码：RLP（Recursive Length Prefix）

以太坊的所有结构化数据（账户、交易、收据、MPT 节点）均采用 RLP 编码，这是一种 “无类型、紧凑、递归” 的编码格式，核心目标是：

统一哈希计算：确保相同数据在不同节点上生成相同的哈希（避免因数据格式差异导致哈希不一致）；
减少存储 / 传输开销：通过 “长度前缀” 直接标识数据长度，无需分隔符（如 JSON 的{}或 XML 的标签）；
支持递归结构：天然适配 MPT 节点、交易数组等嵌套数据（如 MPT 的中间节点包含多个子节点哈希，RLP 可递归编码）。

示例：对字符串"eth"进行 RLP 编码：

字符串长度 3 ≤ 55，前缀为0x80 + 3 = 0x83；
编码结果：0x83657468（65是e的 ASCII 码，74是t，68是h）。

为什么要设计三棵树

以太坊设计状态树、交易树和收据树这三棵树，主要是为了满足其支持智能合约、账户模型以及高效验证等多方面的需求，具体如下：

状态树
- 实现账户状态管理：以太坊采用账户模型，需要全局记录所有账户的实时状态，包括余额、交易次数、合约账户的代码和存储等信息。状态树通过 MPT（Merkle Patricia Trie）结构，能够高效地实现地址到状态的映射，支持按账户地址快速定位状态，并且在账户状态发生变化时，只需新建部分分支，保留原本状态，减少了计算量和存储开销。
- 保证节点状态一致性：以太坊的全节点需要维护一致的账户状态信息。状态树通过生成唯一的根哈希值存储在区块头中，使得所有节点可以通过验证根哈希来确保状态的一致性，避免了因账户顺序不同导致的根哈希不一致问题。
- 支持智能合约执行：智能合约的执行会涉及账户状态的变更，状态树能够记录合约执行前后的状态变化，并且由于智能合约执行复杂，难以反推执行前的状态，状态树保留历史状态便于在需要时进行回滚操作。
交易树
- 验证交易完整性：交易树用于记录当前区块中的所有交易，通过 Merkle 树结构，将交易组织成树状，生成交易树根哈希存储在区块头中。这使得节点可以通过验证交易树的根哈希来快速确认区块内的交易是否被篡改，保证了交易的完整性和真实性。
- 提供 Merkle 证明：交易树可以为轻节点提供 Merkle 证明，轻节点只需下载区块头和相关的 Merkle 证明，就能够验证某个交易是否存在于区块链上，而无需下载完整的交易数据，提高了轻节点的验证效率。
- 统一管理交易数据：以太坊的交易类型多样，包括转账、合约调用、部署等，交易树能够将这些不同类型的交易统一管理，方便节点对交易进行排序、打包和验证，确保交易按照正确的顺序执行。
收据树
- 记录交易执行结果：以太坊的智能合约执行过程复杂，交易执行后可能成功或失败，还会产生日志等信息。收据树用于保存每笔交易执行后的收据信息，包括交易是否成功、消耗的 Gas 量、日志 Bloom 过滤器以及交易产生的日志等，方便对交易执行结果进行追溯和验证。
- 提高查询效率：收据树通过与交易树节点一一对应，以及结合 Bloom filter 数据结构，能够支持高效的查询操作。例如，在查询某笔交易的执行情况或获取交易产生的事件日志时，可以通过收据树快速定位和获取相关信息，避免了遍历整个区块数据。
- 辅助轻节点验证：收据树也可以为轻节点提供证明，帮助轻节点验证交易执行结果的有效性，进一步增强了轻节点对区块链状态的验证能力。

三、与比特币数据结构对比

以太坊数据结构与比特币数据结构在多个方面存在差异，具体如下：

账户模型：
- 以太坊：采用基于账户的模型，直接存储和更新用户的账户余额等信息。以太坊区块链中的状态是底层协议的一部分，账户余额等数据存储在状态树中，每当有与该账户相关的交易发生时，账户余额就会发生变化。
- 比特币：使用 UTXO（未花费交易输出）模型，区块链并不直接存储和更新账户余额，用户的余额通过钱包持有 UTXO 对应的私钥，并通过扫描区块链数据库中与该地址相关的所有 UTXO 来计算。
区块结构：
- 以太坊：区块头包含父块哈希、叔块列表哈希、矿工地址、状态树根哈希、交易树根哈希、收据树根哈希、难度值、区块号、Gas 限制、Gas 使用量、时间戳、额外数据、mixHash 和 nonce 等字段。区块体包含交易序列和叔区块头列表。
- 比特币：区块头包含时间戳、用于 PoW 算法的计数器 nonce、父区块哈希、Merkle 根。区块体包含交易序列。
数据存储树结构：
- 以太坊：有三棵树，即状态树、交易树和收据树，均采用 Merkle Patricia Trie（MPT）结构。状态树的键为账户地址，用于存储以太坊网络中所有账户的实时状态；交易树的键为交易序号，用于记录当前区块中的所有交易；收据树的键为交易序号，用于保存每笔交易执行后的收据信息。
- 比特币：只使用一棵普通的 Merkle 树，叶子节点为交易哈希，主要用于验证交易的存在性，适合 UTXO 模型。
数据编码：
- 以太坊：使用 RLP（Recursive Length Prefix）编码，将数据转换为字节数组，支持嵌套结构，适合存储复杂数据，如账户状态、交易等。
- 比特币：没有明确提及使用类似 RLP 这样的统一编码方式来处理数据结构。
轻节点验证支持：
- 以太坊：收据树中每个交易的收据包含一个 Bloom Filter 摘要，区块头的总 Bloom Filter 是所有交易的并集，轻节点可先通过区块头过滤掉不相关区块，再深入验证候选区块。
- 比特币：轻节点（SPV 节点）使用 Bloom Filter 数据结构过滤不属于钱包的状态数据，但整体验证机制相对以太坊较为简单。