状态树

什么是加密货币中的状态树？

状态树是一种加密数据结构，用于存储区块链当前状态，并可高效更新、验证，以及通过一个根哈希进行汇总。

在 Ethereum 风格的区块链中，状态树将账户地址映射至账户数据，例如余额、nonce、智能合约存储根和代码哈希。

官方Ethereum Merkle Patricia Trie 文档指出，Ethereum 拥有一个全局状态树，客户端每处理一个区块都会对其进行更新。

该全局状态树是 Ethereum 执行层最重要的组成部分之一，因为它表示交易应用后网络的实时状态。

状态树并不等同于历史交易列表。

交易描述已经发生的事件，而状态树描述这些交易改变余额、合约存储和账户数据后，区块链当前呈现的状态。

例如，用户将 ETH 从一个账户发送至另一个账户时，交易会被记录在区块中，但由于两个账户的余额得到更新，状态树也会发生变化。

如果用户调用智能合约，交易会被记录在区块中；但由于合约存储、余额和账户 nonce 可能被更新，状态树也可能发生变化。

简单来说，状态树是经过认证的区块链当前账户状态数据库。

状态树为何重要

状态树之所以重要，是因为区块链需要一种安全方式来证明当前状态。

区块链状态可包含数百万个账户、智能合约、余额、存储条目和其他数值。

节点必须就该状态达成一致，才能判断新交易是否有效。

如果发送方余额不足，交易应失败。

如果某个合约存储槽具有特定数值，智能合约调用的行为可能不同。

如果 nonce 已被使用，重放交易不应被接受。

状态树为客户端提供了确定性的结构，用于存储和检查这些数值。

它还会生成一个可写入区块头的状态根。

如果两个客户端处理同一区块并得到相同的状态根，这为它们对结果状态达成一致提供了有力证据。

因此，状态树是区块链共识、验证、轻客户端证明、节点同步、智能合约执行和数据完整性的核心。

状态树与状态根

状态根是区块中所有交易处理完毕后状态树的根哈希。

Ethereum 区块头包含 stateRoot，它承诺该区块的完整全局状态。

Ethereum Merkle Patricia Trie 文档说明，Ethereum 执行层区块头包含状态树、交易树和收据树的根。

状态根之所以重要，是因为它是对规模大得多的数据库作出的紧凑加密承诺。

若存在有效证明，用户无需下载每个账户和合约存储数值，即可验证特定声明。

相反，用户可以验证某个数值属于状态根所承诺的状态。

若任一账户余额、合约存储根、nonce 或代码哈希发生变化，通向根节点的哈希路径就会变化。

这意味着不同状态应产生不同状态根。

因此，状态根是特定区块完整区块链状态的指纹。

它将庞大的状态数据库转化为单一可验证数值。

状态树如何运作

Ethereum 状态树使用修改版 Merkle Patricia Trie。

Merkle Patricia Trie 结合了 Merkle 树、基数树和 Patricia 树的理念。

Trie 是一种树状键值结构，树中的路径由键决定。

Patricia 树会压缩路径，从而避免树在长串空节点上浪费空间。

Merkle 树添加加密哈希，使数据可通过哈希路径验证。

Ethereum 将这些特性结合起来，使客户端能够存储账户状态、高效更新状态，并通过根哈希和 Merkle 证明验证状态。

在 Ethereum 状态树中，路径基于账户地址的 Keccak-256 哈希。

该路径存储的值是经 RLP 编码的账户对象。

官方 Ethereum 文档指出，Ethereum 账户对象是包含 nonce、balance、storageRoot 和 codeHash 的四项数组。

这种设计使每个账户都可通过确定性的加密路径访问。

状态树中存储哪些数据？

状态树存储账户对象，而不是将所有合约存储值直接存入主全局树。

每个 Ethereum 账户对象都包含 nonce。

每个 Ethereum 账户对象都包含余额。

每个 Ethereum 账户对象都包含 storageRoot。

每个 Ethereum 账户对象都包含 codeHash。

nonce 有助于防止交易重放并追踪账户活动。

余额记录账户持有的原生货币数量。

storageRoot 指向另一棵树，该树存储该账户的智能合约存储。

codeHash 承诺与合约账户关联的智能合约字节码。

外部拥有账户通常具有空代码和空合约存储。

智能合约账户可以拥有影响其执行方式的代码和存储。

状态树与存储树

状态树与存储树有关联，但二者不同。

状态树是将账户地址映射至账户对象的全局结构。

存储树是用于特定智能合约账户存储的独立 Trie。

Ethereum 文档说明，每个具有合约存储的账户都有一棵独立存储树。

状态树中的账户对象存储 storageRoot，即该账户存储树的根。

这意味着全局状态树并不直接包含每个合约的每个存储槽。

相反，它包含账户对象，每个合约账户均可指向其自身的存储树。

例如，代币合约可能会在自己的合约存储树中存储用户余额。

全局状态树存储该代币合约账户对象，而该对象指向代币合约的存储根。

这种分层设计有助于将账户级状态与合约级存储分开。

状态树与交易树

状态树不同于交易树。

状态树存储交易执行后的账户结果状态。

交易树存储特定区块中包含的交易。

每个区块都有自己的交易树。

交易树不会像全局状态树那样跨区块持续更新。

随着交易改变账户余额和合约存储，状态树会从一个区块演变至下一个区块。

交易可理解为一项指令。

状态树可理解为应用指令后的结果。

这一区别很重要，因为区块链不仅是有序交易日志。

它还是一台状态机，每笔有效交易都会将系统从一个状态转移至下一个状态。

状态树与收据树

状态树也不同于收据树。

收据树存储区块的交易收据。

收据记录状态、已用 Gas、日志和事件数据等执行结果。

状态树记录执行后的最终账户状态。

收据帮助应用了解交易执行期间发生了什么。

状态树帮助客户端验证执行后区块链状态变成了什么。

例如，智能合约交易可能发出记录在收据中的事件。

同一笔交易也可能改变通过状态树和存储树记录的合约存储。

两种结构都很重要，但它们回答的问题不同。

收据树回答交易产生了什么，状态树回答链当前状态是什么。

Merkle Patricia Trie 节点

Ethereum 的修改版 Merkle Patricia Trie 使用多种节点类型。

官方 Ethereum 文档描述了分支节点、叶节点、扩展节点和空节点。

分支节点最多可指向 16 条子路径，也可持有一个值。

叶节点存储最终的编码路径和值。

扩展节点压缩共享路径段，使 Trie 避免出现长串稀疏节点。

此设计很有用，因为 Ethereum 的键很长且稀疏。

若没有路径压缩，许多查找将在空路径或非分支路径上浪费步骤。

借助扩展节点和叶节点，Ethereum 使 Trie 比基础基数树更紧凑。

通过使用哈希，Ethereum 使 Trie 可进行加密验证。

这一组合正是该结构被称为修改版 Merkle Patricia Trie 的原因。

RLP 编码与哈希

Ethereum 使用递归长度前缀编码（Recursive Length Prefix），通常称为 RLP，对执行层中的许多数据结构进行序列化。

在状态树中，账户对象在作为值放入之前会经过 RLP 编码。

Trie 节点也会在被哈希或存储前进行编码。

Ethereum Merkle Patricia Trie 文档说明，当一个节点引用另一个节点时，视编码长度而定，该引用可能是经 RLP 编码节点的 Keccak-256 哈希。

这很重要，因为每个节点都必须以确定性方式编码。

如果两个客户端以不同方式编码相同状态，它们可能计算出不同根并无法达成一致。

因此，确定性编码是对共识至关重要的细节。

哈希也使篡改变得可见，因为数值变化会改变节点哈希及通向根的哈希路径。

结果是一个可验证的键值数据库，其中一个根哈希承诺所有包含的数值。

这正是状态证明背后的加密基础。

状态证明

状态证明是一种加密证明，用于证明某个账户或存储值存在于特定状态根所承诺的状态中。

EIP-1186 eth_getProof 提案说明，Ethereum 基于 Merkle 树的状态可通过 Merkle 证明验证账户和存储值。

证明通常包含从目标值重建至状态根路径所需的节点。

若重建后的哈希与可信状态根匹配，无需完全信任数据提供商即可验证该数值。

这对轻客户端、跨链桥、跨链应用、移动钱包、审计人员以及需要验证外部状态的智能合约系统很有用。

例如，证明可显示某账户在某一区块时具有特定余额。

证明也可显示合约存储槽在某一区块时具有特定值。

状态证明非常强大，因为它支持选择性验证，而无需下载整个状态数据库。

状态树使这些证明成为可能。

如果没有经过认证的状态结构，用户将需要更大程度地信任 RPC 提供商和索引器。

eth_getProof

eth_getProof 是一项 Ethereum JSON-RPC 方法，旨在返回账户和存储值及其 Merkle 证明。

EIP-1186 将 eth_getProof 定义为一种返回指定账户的账户值和存储值及证明数据的方法。

证明可包含沿状态根路径的 accountProof 数据。

证明也可包含沿合约存储根路径的 storageProof 数据。

当应用不仅需要原始 RPC 响应，还需要证据时，该方法十分有用。

例如，钱包或跨链桥可能希望根据区块状态根验证存储槽。

简单的余额查询只报告一个数值。

证明查询则报告该数值及检查它所需的加密数据。

这一区别很重要，因为 RPC 提供商可能出错、遭审查、存在漏洞或具有恶意。

Merkle 证明让用户可通过根据可信区块头检查证明，降低对提供商的信任需求。

状态树与全节点

全节点需要当前状态来验证新区块和新交易。

官方Ethereum 归档节点文档说明，每个账户和合约的全局数据都存储在称为 state 的 Trie 数据库中。

全节点跟踪网络最新状态，以验证传入区块和交易。

全节点通常不会永久保留每个历史状态。

它们可能保留最新状态以及足以处理链重组和正常网络运行的近期状态数据。

较旧的历史状态通常可被修剪，因为验证最新链尖端并不需要它们。

这就是为什么在普通全节点上查询旧余额或旧合约存储可能很困难。

当前状态是网络运行所必需的。

所有历史中间状态对分析和证明都有用，但存储成本高得多。

因此，状态树会影响节点硬件、同步、存储和去中心化。

状态树与归档节点

归档节点会存储历史状态，而非仅保留当前状态和近期状态。

Ethereum 归档节点文档说明，归档节点会存储每个区块后创建的全部历史状态，以更大的磁盘需求换取快速历史查询。

这对于区块链浏览器、审计人员、研究人员、安全团队、税务工具、分析提供商和 dApp 开发者很重要。

例如，用户可能想知道某账户数年前某个区块时的余额。

全节点可能需要重新执行历史交易以重建该状态。

归档节点通常可以直接从磁盘访问历史状态。

这种速度的代价是更大的存储需求。

因此，状态树历史很有价值，但成本高昂。

这也是许多用户依赖基础设施提供商查询历史状态的原因。

但是，依赖提供商可能增加信任、可用性和审查风险。

状态树与智能合约

智能合约高度依赖状态树和存储树。

合约的账户对象位于全局状态树中。

合约代码通过 codeHash 被承诺。

合约的持久化存储通过 storageRoot 被承诺。

智能合约执行时，可能读取和写入存储槽。

这些存储变更会更新合约的存储树。

合约新的 storageRoot 会更新全局状态树中的账户对象。

更新后的账户对象会改变全局状态根。

这意味着即使只是很小的合约存储更新，也可能改变一个区块的最终状态根。

因此，状态树是智能合约结果如何变得对共识可见的一部分。

状态树与代币余额

许多代币余额存储在智能合约存储中，而非直接存入全局状态树。

例如，同质化代币合约可存储从用户地址到代币余额的映射。

该映射存在于代币合约的存储树中。

全局状态树存储代币合约账户对象，包括该合约的 storageRoot。

这意味着原生币余额与代币余额的存储方式不同。

原生币余额属于全局状态树中账户对象的一部分。

代币余额通常是特定代币合约存储树中的存储值。

这一差异对证明和审计很重要。

要证明原生币余额，账户证明通常已足够。

要证明代币余额，证明可能同时需要代币合约的账户证明和相关余额槽的存储证明。

状态树与轻客户端

轻客户端是在不存储完整状态的情况下验证区块链数据的客户端。

状态树有助于轻客户端，因为它支持与区块头关联的紧凑证明。

轻客户端可信任或验证区块头，然后使用 Merkle 证明检查特定状态值。

这比在本地存储完整状态便宜得多。

例如，移动钱包可能希望在不运行完整执行节点的情况下验证某合约存储值是否存在。

跨链桥可能希望验证某提币事件或账户状态是否包含在另一条链的状态中。

状态树提供这些工作流程所需的认证结构。

不过，证明大小和证明生成成本仍可能较高。

这也是 Ethereum 研究人员探索 Verkle 树等替代方案的原因之一。

目标是使状态验证随着时间推移变得更轻量、更具可扩展性。

状态树与无状态客户端

无状态客户端是一项长期区块链扩容理念，验证者或用户无需在本地存储完整状态即可验证区块。

并非每个验证者都存储全部状态，而是区块或交易会包含用于证明其所触及状态的见证数据。

状态树与此相关，因为当前 Merkle Patricia Trie 的见证数据可能很大。

大型见证数据可能使无状态验证效率较低。

Ethereum Foundation 的Verkle 树结构文章说明，Verkle 树的工作方式与 Merkle 树类似，但可通过向量承诺生成更小的见证数据。

因此，Verkle 树被研究为 Ethereum 当前状态承诺结构的可能替代方案。

当前状态树安全且久经考验，但其设计目标并非生成尽可能小的无状态见证数据。

无状态研究部分旨在减轻状态树为节点带来的负担。

对用户而言，实际要点是状态数据结构设计会影响未来的可扩展性。

对开发者而言，随着协议研究推进，状态访问模式和证明系统可能演变。

状态树与 Verkle 树

Verkle 树是一种拟议的状态承诺结构，使用向量承诺而非仅使用哈希链接。

Ethereum.org 表示，Ethereum 计划未来迁移至 Verkle Tree 结构，但协议时间表和实施细节可能发生变化。

Verkle 树旨在使证明比 Merkle Patricia Trie 证明更小。

Ethereum Foundation 文章说明，Verkle 树设计还会以不同布局合并账户树和存储树。

这将是一项重大变革，因为目前 Ethereum 使用一棵全局状态树加上每账户一棵存储树。

基于 Verkle 的状态模型可使无状态客户端更具可行性。

然而，从长期运行的状态树迁移至新的承诺结构非常复杂。

它会影响客户端、证明、钱包、节点、执行规则、存储布局和开发者假设。

因此，状态树既是当前基础，也是持续协议研究的重要领域。

理解状态树有助于用户理解 Verkle 研究为何重要。

状态树与状态膨胀

状态膨胀是指区块链活跃状态变得更大、更难维护。

随着更多账户、合约、存储槽和应用数据保持活跃，状态树会不断增长。

庞大的状态会增加磁盘使用量、同步时间、数据库工作负载和硬件要求。

如果节点运行成本过高，能够独立验证网络的用户就会减少。

这可能削弱去中心化。

状态膨胀不同于区块链历史增长，因为处理新交易需要活跃状态。

历史交易很重要，但旧的中间状态有时可被修剪或重新生成。

当前状态必须可用于验证。

这使状态增长成为智能合约区块链最棘手的扩容问题之一。

状态树是客户端可观察到这一增长的数据结构。

状态树与 Gas 成本

Gas 成本的设计部分是为了给计算和状态访问定价。

写入持久化存储成本较高，因为这会增加或改变节点必须维护的状态。

读取状态也可能产生成本，因为状态访问会影响执行性能。

当智能合约创建新的存储时，存储树和全局状态根可能需要更新。

当智能合约删除存储时，视当前协议规则而定，Gas 规则可能提供退款或激励。

这些 Gas 机制与状态树相关，因为持久化状态是共享网络资源。

如果存储写入过于便宜，应用可能用低价值数据膨胀状态树。

如果存储写入过于昂贵，有用的应用可能更难构建。

协议设计者必须平衡可用性、安全性和状态可持续性。

状态树位于这一经济权衡的中心。

状态树与 RPC 提供商

RPC 提供商提供各种方法，使钱包和应用可读取区块链状态。

常见状态方法包括余额查询、存储查询、代码查询、交易计数查询和合约调用。

官方Ethereum JSON-RPC 文档将状态方法描述为报告当前存储数据的方法，例如账户余额、合约数据和 Gas 估算。

钱包查询账户余额时，RPC 提供商会从节点读取状态数据。

dApp 查询合约值时，RPC 提供商可能读取存储槽，或针对当前状态模拟调用。

用户通常依赖 RPC 提供商，却不会考虑响应背后的状态树。

但正是状态树使这些数值成为可验证区块链状态的一部分。

对于高信任要求的应用，原始 RPC 响应可能不足够。

在获得支持并正确验证的情况下，状态证明可提供更强保障。

这对跨链桥、审计、合规工具和跨链系统很重要。

状态树与区块链浏览器

区块链浏览器使用状态数据来显示余额、代币持仓、合约存储、交易影响和历史账户信息。

浏览器通常依赖索引数据，而非仅直接查询状态树。

索引可加快搜索速度，并使用户界面更易构建。

不过，索引数据最终源自区块链状态、交易、日志、收据和执行结果。

若浏览器显示某账户在特定区块的余额，该信息与该区块的状态相关联。

若浏览器显示代币余额，通常会从合约存储变更和事件中推导这些数据。

归档节点可帮助浏览器快速回答历史状态问题。

如果没有历史状态访问，浏览器可能需要从交易历史重建旧状态。

普通浏览器用户通常看不到状态树。

但它仍是使浏览器数据能够在协议层面验证的核心结构之一。

状态树与跨链桥

跨链桥通常需要验证来自另一条区块链环境的状态或事件。

状态树和 Merkle 证明可支持此类验证。

例如，跨链桥可能需要证明消息、存储值或账户状态在某个特定区块中存在。

如果跨链桥能够信任区块头并验证证明，便可降低对中心化数据提供商的依赖。

这也是 EIP-1186 指出 Merkle 证明对 Layer 2 技术很重要的原因。

状态证明可帮助系统验证有关余额、存储槽和合约状态的声明。

但跨链桥安全性远不止取决于证明结构。

它还取决于区块头验证、最终性假设、欺诈证明、有效性证明、多签控制、智能合约安全和运营设计。

正确的状态树证明很强大，但只是跨链桥安全的一部分。

用户不应仅因跨链桥提及 Merkle 证明，就假设它是安全的。

状态树与 Layer 2 网络

Layer 2 网络通常使用状态根、证明和承诺结构来汇总链下或独立链执行。

Layer 2 可能将状态根发布到 Layer 1 链。

它可能使用欺诈证明、有效性证明或数据可用性机制，来证明状态转换有效。

具体设计取决于 Layer 2 架构。

Ethereum 状态树很重要，因为它展示了区块链如何通过紧凑根对庞大状态作出承诺。

Layer 2 系统可能使用不同数据结构，但概念相似。

庞大的执行状态由一个承诺进行汇总。

用户和合约随后根据该承诺验证声明。

因此，状态树不仅是底层客户端话题。

它还是扩容、Rollup 设计和跨链验证的一部分。

状态树与安全性

状态树通过使状态篡改可被检测来提高安全性。

若节点未遵循有效交易规则便更改账户余额，所得状态根将无法匹配已接受的区块头。

若提供商谎报存储值，有效 Merkle 证明应无法与可信状态根匹配。

若两个客户端对状态转换规则存在分歧，它们可能计算出不同状态根并拒绝彼此的区块。

这使状态树对共识至关重要。

状态树实施中的漏洞可能十分严重，因为它们可能造成客户端分歧或错误状态验证。

因此，执行客户端必须谨慎实现 Trie 逻辑、编码、哈希和状态更新。

状态树安全性还取决于加密哈希的抗碰撞性。

如果攻击者能创建具有相同根的两个不同状态，就可能破坏证明完整性。

现代区块链状态树依赖加密假设，在当前条件下这在实践中不可行。

状态树与客户端实现

不同 Ethereum 执行客户端实施相同状态规则，但可能使用不同内部数据库和优化方式。

对共识至关重要的结果必须是相同状态根。

客户端在磁盘上存储 Trie 节点的方式可能不同。

客户端缓存状态的方式可能不同。

客户端修剪旧状态的方式可能不同。

客户端提供历史查询的方式可能不同。

这意味着状态树既是协议概念，也是实施挑战。

在协议层面，客户端必须就根和状态转换规则达成一致。

在数据库层面，客户端团队可优化存储布局、访问速度、修剪、快照和同步行为。

用户通常会通过节点性能、磁盘使用量、同步时间和 RPC 可靠性感受到这些差异。

状态树与开发者调试

开发者常通过存储槽、账户证明和历史状态查询间接接触状态树。

智能合约开发者可能需要了解映射如何存储在合约存储中。

安全研究人员可能需要证明某个存储槽在某区块中具有特定值。

跨链桥开发者可能需要验证另一环境中的合约状态值。

钱包开发者可能需要解释为何余额查询取决于 latest 或 finalized 等区块标签。

dApp 开发者在调试旧合约状态时可能需要归档节点。

理解状态树有助于开发者正确解读这些问题。

这也有助于开发者避免将交易历史与当前状态混淆。

许多漏洞源于假设事件、存储、余额和账户状态是同一事物。

状态树可澄清每类数据的存放位置。

状态树与常见用户体验

大多数加密货币用户从不直接与状态树交互。

他们使用钱包、dApp、浏览器和 RPC 提供商。

钱包显示余额时，实际上是在读取状态。

dApp 检查用户是否已批准代币时，实际上是在读取合约存储状态。

智能合约调用成功或失败取决于当前状态。

浏览器显示某区块的合约值时，取决于状态访问或源自状态的索引数据。

状态树是隐藏基础设施，但每天都会影响普通用户活动。

若状态访问缓慢，dApp 可能感觉很慢。

若 RPC 提供商提供错误状态，用户可能看到错误余额或交易失败。

若历史状态不可用，用户可能难以审计旧活动。

状态树的常见误解

一种常见误解是状态树存储每笔交易。

状态树存储当前账户状态，而交易则独立存储在区块和交易树中。

另一种误解是智能合约存储直接保存在全局状态树中。

全局状态树存储账户对象，合约存储则保存在由 storageRoot 值引用的独立存储树中。

第三种误解是全节点总会存储全部历史状态。

许多全节点保留当前和近期状态，同时修剪较旧中间状态。

第四种误解是状态根就是状态本身。

状态根是对状态的紧凑加密承诺，而非完整状态数据库。

第五种误解是 Merkle 证明可以证明有关合约的所有事实。

Merkle 证明仅能根据特定根证明特定账户或存储值，不能证明该数值完整的业务含义。

状态树的优势

状态树的第一项优势是可验证性。

用户和客户端可通过与状态根关联的证明验证状态值。

第二项优势是确定性。

处理相同有效区块的客户端应获得相同状态根。

第三项优势是高效查找。

Trie 路径使客户端可通过确定性键查找账户和存储数据。

第四项优势是篡改可见性。

一个数值的变化会改变哈希路径和最终根。

第五项优势是支持轻客户端。

选择性证明可在不下载完整状态的情况下验证数据。

第六项优势是清晰的状态转换结构。

每个区块都会将先前状态变为具有新根的新状态。

这些优势使状态树成为基于账户的智能合约区块链的基础。

状态树的局限性

第一项局限是存储增长。

随着账户和合约存储值不断累积，节点维护状态的负担会加重。

第二项局限是证明大小。

对于无状态客户端和大规模验证而言，Merkle Patricia Trie 证明可能大于理想水平。

第三项局限是实现复杂度。

Trie 编码、哈希、修剪、缓存和数据库存储很难正确实施。

第四项局限是历史状态成本。

保留全部历史状态需要的磁盘空间远大于普通全节点运行所需空间。

第五项局限是开发者困惑。

许多开发者误解状态、存储、交易、收据、日志和索引数据之间的区别。

这些局限说明状态管理仍是活跃的研究和工程领域。

状态树能够运作，但也带来实际的扩容和可用性挑战。

开发者最佳实践

在构建基于证明的系统前，先理解账户状态与合约存储之间的区别。

学习 Merkle Patricia Trie 机制时应使用官方 Ethereum 文档。

构建需要账户或存储证明的系统时，谨慎使用 eth_getProof。

应根据可信区块头验证证明，而非盲目信任 RPC 响应。

请记住，代币余额通常存在合约存储中，而非直接存在全局状态树中。

需要快速访问旧历史状态时，可使用归档节点或归档数据提供商。

设计智能合约时应尽量减少不必要的持久化存储。

写入存储时应考虑 Gas 成本，因为持久化状态成本较高。

若系统高度依赖状态证明，请关注 Verkle 树等协议研究。

不要假设当前证明格式会在未来所有协议升级中永久保持不变。

用户最佳实践

使用可信钱包和浏览器，但请记住其显示内容来自状态查询和索引数据。

在不同工具间比较余额或合约值时，请检查区块号。

应了解当前余额和历史余额可能需要不同的数据访问方式。

在需要高保障且工具支持时，可使用基于证明的验证。

不要认为简单 RPC 响应等同于加密证明。

使用声称验证另一条链状态的跨链桥或应用时应保持谨慎。

查看应用使用的是当前状态、历史状态、日志还是链下索引。

应了解，即使代币转账不明显，智能合约存储变更也可能影响应用行为。

请记住，区块链透明性依赖状态树等数据结构。

状态树对大多数用户不可见，但它有助于使公链数据可验证。

FAQ

状态树是什么意思？

状态树是一种加密键值树，用于存储当前区块链状态，并生成承诺该状态的根哈希。

什么是 Ethereum 状态树？

Ethereum 状态树是全局修改版 Merkle Patricia Trie，用于将哈希后的账户地址映射至经 RLP 编码的账户对象。

Ethereum 账户对象中存储什么？

Ethereum 账户对象包含 nonce、balance、storageRoot 和 codeHash。

什么是状态根？

状态根是区块交易执行后的状态树根哈希。

状态树与存储树相同吗？

不同。状态树存储账户对象，存储树则存储各个合约账户的合约存储。

状态树等同于交易历史吗？

不同。状态树存储当前账户状态，而交易历史记录包含在区块中的有序交易。

什么是 Merkle 证明？

Merkle 证明是一组 Trie 节点，可证明特定值包含在根哈希所承诺的状态中。

什么是 eth_getProof？

eth_getProof 是一项 Ethereum JSON-RPC 方法，返回账户和存储值及 Merkle 证明数据。

归档节点为何对状态树重要？

归档节点很重要，因为它们存储历史状态，并可比普通全节点更快地回答旧状态查询。

Ethereum 会一直使用当前状态树吗？

Ethereum 当前在执行层使用 Merkle Patricia Trie，但 Ethereum 研究已探索将 Verkle 树作为未来状态承诺结构。

结语

状态树是基于账户的智能合约区块链背后的核心数据结构之一。

它存储账户当前状态，并让客户端通过单一加密根汇总该状态。

在 Ethereum 中，全局状态树将哈希后的账户地址映射至包含 nonce、balance、storageRoot 和 codeHash 的账户对象。

每份合约都可拥有自己的存储树，其根存储于合约账户对象中。

每个区块头中的状态根承诺该区块所有交易处理后的完整结果状态。

这使状态树对共识、验证、轻客户端、证明、节点同步、智能合约执行和区块链数据完整性至关重要。

状态树也带来挑战，因为活跃状态增长会增加节点存储、证明大小、同步复杂性和历史数据成本。

这些挑战说明归档节点、状态修剪、Gas 成本、存储设计、eth_getProof 和 Verkle 树研究都与同一主题相关。

对用户而言，状态树大多隐藏在钱包、浏览器和 dApp 背后。

对开发者和基础设施团队而言，状态树是理解余额、合约存储、证明、历史查询和扩容限制的关键概念。

在加密货币术语表中，State Trie 指记录当前账户状态并生成用于验证该状态的状态根的、经过认证的区块链状态数据库。

核心要点是，状态树通过加密根和证明，将庞大且不断变化的区块链状态转化为节点、应用和用户可以信任的可验证结构。