状态承诺

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

状态承诺是一种加密学摘要，用于承诺区块链在特定时间点的当前状态。

简单来说，它是庞大区块链数据集合的紧凑“指纹”。

根据区块链设计，这些数据可包括账户余额、智能合约存储、Nonce、验证者记录、代币余额、对象所有权、UTXO 或其他状态值。

状态承诺使节点、钱包、跨链桥、轻客户端、Rollup 和应用能够验证关于区块链状态的声明，而无需下载整个数据库或盲目信任它。

在 Ethereum 上，最常见的状态承诺是存储在区块头中的状态根。

官方 Ethereum Merkle Patricia Trie 文档说明，Ethereum 使用全局状态树；客户端处理区块时会更新该树，生成的状态根可通过加密学方式验证。

如果两个节点处理同一个有效区块并得出相同的状态承诺，这就有力证明它们对最终状态达成一致。

如果一个账户余额或合约存储值发生变化，状态承诺也应随之变化。

因此，状态承诺对于区块链共识、状态证明、欺诈证明、有效性证明、轻客户端验证和跨链消息传递至关重要。

在加密货币术语表中，State Commitment 指以紧凑且可验证的形式表示区块链当前状态的加密根或承诺。

状态承诺为何重要

状态承诺之所以重要，是因为区块链是由许多独立参与者共同维护的共享数据库。

任何用户都不应必须信任单个服务器来报告正确的余额、合约数值或账户状态。

状态承诺让网络能够就一个代表更大状态集合的紧凑数值达成一致。

这使状态可通过证明进行检查，而非依赖盲目信任。

例如，轻客户端可能不会存储完整 Ethereum 状态，但可根据可信状态根验证状态证明。

跨链桥可能需要证明消息或提现记录存在于另一条链的状态中。

Rollup 可发布状态根，以汇总大量链下或 Layer 2 交易的结果。

钱包可能依赖节点提供余额数据；更强的系统则可通过证明验证节点未提供虚假信息。

状态承诺还使区块链执行过程可审计。

每个区块都包含对最终状态的承诺，用户便可验证该链是否根据协议规则从一个有效状态转移至下一个有效状态。

状态承诺与区块链状态

区块链状态是处理新交易所需的全部实时数据集合。

状态承诺只是该状态的紧凑加密表示。

这一区别很重要，因为状态承诺并不直接包含每笔余额或每个存储槽位。

它仅通过加密数据结构承诺这些数值。

例如，Ethereum 的状态根不会在区块头中列出每个账户余额。

相反，它承诺存储账户对象并指向合约存储树的全局状态树。

如需证明某个具体数值，用户需提供一条将该数值连接至承诺的证明路径。

验证者会根据已知承诺检查该证明。

若证明有效，验证者即可相信该数值属于已承诺状态。

因此，状态承诺就像覆盖在实时区块链数据库上的防篡改封条。

状态承诺与状态根

状态根是状态承诺的常见类型。

在 Ethereum 中，状态根是区块执行后全局状态树的根哈希。

官方 Ethereum 区块文档指出，区块包含执行载荷信息，其中包括承诺重要执行层数据的根。

状态根是一个具体字段，而状态承诺则是更广泛的概念。

其他区块链系统可能使用 app hash、state hash、world state root、global root、ledger commitment、accumulator root 或 commitment root 等不同术语。

具体名称取决于协议。

核心理念相同。

庞大状态由一个小数值汇总；底层状态变化时，该数值也会变化。

对于 Ethereum 风格链，状态根是用户和开发者最常见的实际术语。

在区块链理论中，状态承诺则是更通用的概念。

状态承诺如何运作

状态承诺通常始于一个结构化的状态值数据库。

区块链会将这些值组织为 Merkle 树、Merkle Patricia Trie、稀疏 Merkle 树、向量承诺树或其他经认证的数据结构。

每个数值都会以确定性方式进行哈希或承诺。

这些哈希会逐层组合，直至生成一个顶层根。

该顶层根即为状态承诺。

若一个叶子节点数值变化，其路径上的哈希都会改变。

这一变化会向上传播，直至根发生变化。

这使篡改可被检测：除非攻击者能够破解底层密码学，否则伪造数值不应匹配原始承诺。

状态承诺的价值在于，它能通过一个小型根和证明来验证庞大数据库。

证明无需包含整个数据库，只需包含验证单项声明所需的路径和辅助数据。

Ethereum 中的状态承诺

Ethereum 使用改进版 Merkle Patricia Trie 来承诺其执行层状态。

官方 Ethereum Merkle Patricia Trie 文档称，Ethereum 拥有一个全局状态树，且每当处理区块时都会更新该树。

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

全局状态树将账户地址映射至这些账户对象。

每个智能合约账户还可拥有自己的存储树，其根存储在账户对象中。

这意味着 Ethereum 的状态承诺具有分层结构。

全局状态根承诺账户。

每个合约账户的 storageRoot 承诺该合约的持久化存储。

如果代币合约更新合约存储中的用户余额，该合约的存储根会变化，全局状态根也可能变化。

这使智能合约执行成为已承诺区块链状态的一部分。

状态承诺与 Merkle Patricia Trie

Merkle Patricia Trie 是 Ethereum 当前执行层使用的一种经认证键值数据结构。

它结合了 Trie 风格的键路径、Patricia 路径压缩和 Merkle 哈希。

Trie 部分可根据键，通过确定性路径查找数值。

Patricia 部分压缩长路径，以减少冗余结构。

Merkle 部分使该结构可通过加密学方式验证。

官方 Ethereum 文档指出，Merkle Patricia Trie 具有确定性且可加密验证，这意味着可通过比较根和证明路径来证明状态相同。

这正是状态承诺所需的特性。

它需要确定性构建方式，以便诚实节点计算出相同的根。

它需要加密完整性，以便被篡改的数据会改变承诺。

它需要证明支持，以便无需下载所有数据即可验证特定数值。

状态承诺与 Merkle 证明

Merkle 证明是某个特定数值属于根所承诺状态的证据。

EIP-1186 eth_getProof 规范描述了一种 JSON-RPC 方法，可返回账户和存储数值及 Merkle 证明数据。

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

若重建出的根与可信状态承诺匹配，该数值便得到验证。

这使验证者能够确认某账户在某一特定区块拥有特定余额，或合约存储槽位具有特定数值。

Merkle 证明很重要，因为它们可减少对 RPC 提供商、索引器和第三方 API 的信任。

简单的 RPC 响应只说明服务器声称的状态。

由证明支持的响应则可说明该声明为何与状态承诺相符。

这一差异对于钱包、跨链桥、审计、跨链系统和高价值应用非常重要。

状态承诺使这些证明具备意义，因为证明需要可信根进行验证。

状态承诺与区块头

许多区块链会在区块头中存储对更大区块数据的紧凑承诺。

Ethereum 区块头包括与状态、交易和回执相关的根。

状态根承诺最终世界状态。

交易根承诺区块内的交易列表。

回执根承诺交易回执和日志。

这些承诺具有不同用途。

状态承诺回答执行后区块链状态变为何种状态。

交易承诺回答包含了哪些交易。

回执承诺回答产生了哪些执行输出和日志。

这些根共同让客户端能够验证区块数据的重要部分，而无需将全部完整数据直接放入区块头。

状态承诺与交易承诺

状态承诺不同于交易承诺。

交易承诺承诺区块中包含的交易。

状态承诺承诺这些交易执行后的最终状态。

例如，一个区块可包含一笔将资产从一个账户转移到另一账户的交易。

交易承诺可证明该交易已被纳入区块。

若提供相关状态证明，状态承诺可证明最终余额变化。

这一区别对构建跨链桥或证明的开发者至关重要。

证明交易被包含不一定等于证明最终状态。

交易可能被包含但执行失败。

状态证明可展示执行后链上状态实际变成了什么。

状态承诺与回执承诺

回执承诺也不同于状态承诺。

回执可显示执行状态、已使用的 Gas、日志和事件。

状态承诺显示执行后的最终状态数据库。

事件可用于索引和应用逻辑，但事件不等同于合约存储。

合约可以在不改变状态的情况下发出事件。

合约也可改变状态而不发出有用事件。

因此，一些高安全性系统更倾向于使用存储证明，而非仅依赖事件。

回执很有价值，但它们回答的问题与状态承诺不同。

回执承诺有助于证明交易报告了什么。

状态承诺有助于证明区块链状态实际包含什么。

Rollup 中的状态承诺

Rollup 高度依赖状态承诺。

Rollup 在基础链外或独立执行环境中处理交易，随后将承诺、数据或证明发布回结算层。

Rollup 状态根汇总当前 Layer 2 状态。

用户可利用该承诺追踪 Rollup 内的余额、提现、消息和应用状态。

官方 Ethereum zk-rollup 文档说明，零知识 Rollup 会发布有效性证明，以证明状态转换正确。

在乐观 Rollup 中，如果有人认为状态转换无效，可在争议期内对状态承诺提出挑战。

在有效性 Rollup 中，证明用于展示已承诺的新状态符合规则。

在两种情况下，状态承诺都是关于 Rollup 状态的紧凑声明。

没有状态承诺，Rollup 将无法高效汇总和结算大量 Layer 2 执行。

这使状态承诺成为现代区块链扩容的关键。

状态承诺与欺诈证明

欺诈证明是一种证明已声明状态转换无效的挑战。

欺诈证明系统常见于乐观 Rollup 设计中。

Rollup 运营者可在执行交易后发布新的状态承诺。

若该承诺错误，其他参与者可通过证明从旧状态到新状态的转换无效来提出挑战。

争议流程需要明确承诺旧状态、交易数据和所声明的新状态。

因此，状态承诺构成欺诈证明证据结构的一部分。

欺诈证明不只是声称某事出错。

它必须将声明与已承诺的数据和执行规则关联起来。

这也是数据可用性对欺诈证明同样重要的原因。

如果重新计算状态转换所需的数据不可用，挑战者可能无法证明存在欺诈。

状态承诺与有效性证明

有效性证明是证明状态转换已正确执行的加密学证据。

有效性证明通常用于零知识 Rollup 和其他基于证明的系统。

证明者从旧状态承诺出发，按规则应用交易，并证明新状态承诺正确。

如果证明系统可靠且满足所需数据假设，验证者无需完整重新执行每笔交易。

这可使验证成本远低于执行成本。

状态承诺处于核心位置，因为证明需要清晰的起始承诺和结束承诺。

实际上，该证明表明系统已从一个已承诺状态有效地转移到另一个已承诺状态。

这使状态承诺成为可扩展验证的锚点。

有效性证明可支持 Rollup、跨链桥、隐私应用和压缩执行系统。

承诺定义了正在被证明的状态。

状态承诺与轻客户端

轻客户端利用承诺和证明验证区块链信息，而无需存储完整状态。

轻客户端可跟踪区块头，并针对其中的根验证证明。

对于状态值，轻客户端需要可信状态承诺和有效状态证明。

这使移动钱包、嵌入式设备和低资源系统可用更少存储空间和带宽验证特定事实。

因此，状态承诺是最小化信任钱包设计的重要组成部分。

没有状态承诺，轻客户端就需更大程度地信任远程服务器。

远程服务器可报告余额，但证明让客户端能够根据已承诺状态核验该余额。

轻客户端验证并非总是简单，因为客户端还需要可信区块头和终局性假设。

不过，状态承诺原则上使轻量级验证成为可能。

这是经认证状态最重要的面向用户优势之一。

状态承诺与跨链桥

跨链桥通常需要验证来自另一条区块链或 Layer 2 网络的状态。

跨链桥可能需要证明已发生充值、提现已完成终局确认，或某条消息存在于已承诺状态中。

状态承诺有助于跨链桥更安全地验证这些声明。

例如，跨链桥合约可针对另一系统的已知状态根验证证明。

如果证明有效，跨链桥可释放资金或传递消息。

但是，即便采用状态承诺，跨链桥仍然存在风险。

跨链桥还必须验证源链共识、终局性、数据可用性、证明格式和消息规则。

正确的状态证明只是跨链桥安全性的一部分。

设计不当的跨链桥仍可能因验证者薄弱、中继器问题、智能合约漏洞、重放攻击或错误终局性假设而失效。

状态承诺可减少信任，但不会自动使每座跨链桥都安全。

状态承诺与数据可用性

数据可用性是指验证或重建状态转换所需数据可公开获取。

单独的状态承诺无法保证用户能够检查状态是如何生成的。

恶意参与者可能发布新承诺，却隐藏验证转换所需的数据。

因此，数据可用性是 Rollup、分片和模块化区块链系统的重要问题。

官方 Ethereum 数据可用性文档说明，数据可用性关乎交易数据是否已发布，以便参与者验证或重建状态。

状态承诺与数据可用性相辅相成。

承诺表明所声明的状态是什么。

可用数据使其他人能够检查向该状态的转换是否有效。

没有数据的承诺可能成为黑箱。

可扩展区块链既需要紧凑承诺，也需要可访问数据。

状态承诺与无状态客户端

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

区块生产者或对等节点不再要求每个节点保存整个状态数据库，而是提供证明区块所触及状态值的见证。

官方 Ethereum 无状态化文档说明，无状态化旨在让节点使用见证而非庞大的本地状态数据库验证区块。

状态承诺是该设计的核心，因为见证必须针对承诺进行验证。

如果见证证明所有访问值匹配先前状态承诺，且最终数值生成新承诺，验证者便可用更少本地状态检查区块。

这可能随时间推移降低节点运行难度。

但当前 Merkle Patricia Trie 见证可能很大。

这是 Ethereum 研究重点转向 Verkle 树和更小见证结构的原因之一。

无状态化不只是存储技巧。

它依赖支持高效证明的状态承诺。

状态承诺与 Verkle 树

Verkle 树是让 Ethereum 状态证明更小、更高效的一条拟议升级路径。

官方 Ethereum Verkle 树文档称，Verkle 树是一种可帮助 Ethereum 节点停止存储大量状态数据，同时保留验证区块能力的数据结构。

Verkle 树将树结构与向量承诺相结合。

Verkle 这一名称来自 vector commitment 和 Merkle tree。

与当前 Merkle Patricia Trie 证明相比，对于许多状态访问模式，Verkle 证明可以小得多。

更小的见证对无状态客户端和未来扩容十分重要。

Verkle 树不会消除状态承诺的需求。

它们改变了用于表示和证明状态的承诺结构。

这表明状态承诺是可通过不同加密数据结构实现的广泛概念。

承诺方法可以演进，但承诺状态的需求仍是基础性的。

状态承诺与向量承诺

向量承诺是对数值列表或向量作出的加密承诺，支持对单个位置进行高效证明。

向量承诺可用于区块链状态，因为与某些哈希树方案相比，它可缩小证明大小。

Verkle 树在树状结构中使用向量承诺。

这不同于传统 Merkle 树；后者使用兄弟哈希验证路径。

向量承诺可使证明更紧凑，但可能引入不同的密码学假设和实现复杂度。

对用户而言，重点不在数学细节。

重点是较新的状态承诺系统旨在降低状态证明成本。

更小证明可帮助轻客户端、无状态客户端、Rollup、跨链桥和隐私保护系统。

但是，在保护大型公共网络之前，新承诺方案必须经过谨慎测试。

状态承诺设计始终需要在证明大小、验证成本、更新成本、安全假设和实现风险之间权衡。

状态承诺与稀疏 Merkle 树

稀疏 Merkle 树是加密系统中另一种常见状态承诺结构。

当键位于极大且固定的键空间时，常会使用该结构。

每个可能的键在树中都有位置，但大多数位置可能为空。

根据实现方式，空分支可被压缩或高效表示。

稀疏 Merkle 树的价值在于支持清晰的包含证明和非包含证明。

一些 Layer 2 系统、跨链桥、钱包和应用专用区块链会使用稀疏 Merkle 树或其变体来进行状态承诺。

它们并不等同于 Ethereum 当前的 Merkle Patricia Trie。

它们是解决同一基本问题的另一种方式。

该问题是如何承诺庞大键值状态，并高效证明单个数值。

这种多样性表明，状态承诺是一个设计类别，而非单一数据结构。

状态承诺与 Bitcoin

Bitcoin 通常不会以 Ethereum 风格的全局账户状态承诺来描述。

Bitcoin 区块通过区块头中的 Merkle 根承诺交易。

Bitcoin 的实时可花费状态是 UTXO 集，由交易历史推导而来。

官方 Bitcoin 区块链开发者指南说明，区块头包含区块内交易的 Merkle 根。

这意味着 Bitcoin 具有强大的交易包含承诺。

但 Bitcoin 区块头不包含对完整当前 UTXO 集的直接承诺，不同于 Ethereum 为账户状态包含状态根的方式。

一些研究和提案曾探索 UTXO 承诺，因为对可花费状态的直接承诺可帮助轻客户端和验证模型。

这一比较很有意义，因为它表明不同区块链承诺不同的数据。

Ethereum 风格智能合约系统需要明确状态承诺，因为应用高度依赖当前账户和合约状态。

Bitcoin 的模型则更直接聚焦交易历史及由其推导的 UTXO 集。

状态承诺与账户型区块链

账户型区块链通常需要明确状态承诺，因为账户余额和合约存储是执行的核心。

交易执行时，可能更新账户余额、Nonce、智能合约存储、质押记录和应用数据。

必须承诺最终状态，以便其他节点验证准确结果。

这也是智能合约平台普遍使用状态根的原因。

状态根使网络对广泛状态数据库形成单一承诺。

没有可靠状态承诺，就更难证明合约存储数值正确。

构建依赖账户或存储证明的跨链桥、Rollup 和轻客户端也会更加困难。

账户型链的状态通常比简单支付系统复杂。

这种复杂性使状态承诺设计尤其重要。

链的可编程性越高，经认证状态的价值就越大。

状态承诺与对象型区块链

一些区块链使用对象型状态模型，而非简单的账户型状态。

在对象型系统中，资产、合约和数据可表示为具有所有者、字段和权限的对象。

这些系统同样需要状态承诺。

该承诺可汇总对象所有权、对象内容、版本号、包数据或执行结果。

具体结构与 Ethereum 的全局账户树不同。

但目标仍然是使当前状态可验证。

对象所有权变化时，状态承诺应反映该变化。

对象内容变化时，承诺也应反映这项更新。

这表明状态承诺并不限于 Ethereum 风格账户模型。

任何维护实时状态的区块链都需要某种安全承诺该状态的方式。

状态承诺与智能合约存储

智能合约存储是状态承诺复杂的主要原因之一。

智能合约可存储余额、授权、仓位、订单、投票、配置数值及许多其他记录。

这些数值可在每笔交易后发生变化。

状态承诺必须准确反映这些变化。

在 Ethereum 上，每个合约的存储树均有自己的根，合约账户会将该根存储在全局状态树中。

这支持针对具体合约存储槽位的证明。

例如，证明可表明某一代币余额映射在特定区块具有特定数值。

这对审计、跨链桥、治理、Rollup 和跨链验证很有用。

智能合约存储使状态承诺功能强大，但也使其负担更重，因为状态可能增长到很大规模。

因此，存储成本、状态膨胀和证明大小是重要的扩容问题。

状态承诺与代币余额

代币余额通常位于智能合约存储中，而非直接存于基础账户状态。

这意味着证明代币余额可能需要代币合约的存储证明。

原生币余额可通过账户对象证明。

代币余额可能需要证明代币合约账户，以及该合约存储根中相关的存储槽位。

这一区别对跨链桥和空投非常重要。

需要验证代币所有权的系统应了解该所有权存储在何处。

系统不应假设每笔余额都是同一状态字段的一部分。

状态承诺可支持原生资产证明和代币证明，但证明路径可能不同。

开发者在构建证明系统前应了解代币标准和存储布局。

只有验证者确切知道正在证明什么数值时，状态承诺才有用。

状态承诺与 NFT

NFT 所有权也可通过状态承诺表示。

NFT 合约通常为每个代币 ID 存储所有权数据。

NFT 所有权证明可能需要验证特定区块中相关合约存储数值。

这可用于跨链 NFT 桥、快照投票、门控访问、奖励和历史所有权检查。

但是，NFT 元数据并不一定完全由区块链状态承诺。

部分 NFT 元数据存储在链下，或通过外部链接引用。

状态承诺可证明链上所有权，但可能无法证明链下图像或元数据文件会永久可用。

这一区别对认为状态证明可证明 NFT 一切信息的用户很重要。

通常，它仅证明正在检查的链上状态值。

状态承诺功能强大，但不会自动验证链下数据的永久性。

状态承诺与历史状态

状态承诺与链历史中的特定区块或时间点相关联。

当前状态承诺可证明当前状态。

如验证者拥有旧区块头和正确证明，旧状态承诺可证明历史状态。

这对审计、快照、法律记录、治理和历史声明很有用。

但存储历史状态数据可能成本很高。

许多全节点保留当前和近期状态，但会修剪较早的中间状态。

归档节点保留更多历史状态，因此可更快回答历史查询。

官方 Ethereum 归档节点文档说明，归档节点存储所有历史状态，适合快速历史查询。

这意味着历史状态承诺可能存在于旧区块头中，但为旧状态生成证明可能需要访问历史状态数据库。

状态承诺保留可验证性，但仍需有人拥有构建证明所需的数据。

状态承诺与归档节点

归档节点很重要，因为状态承诺本身不存储完整状态数据。

区块头可能包含数年前的状态根。

要生成针对该旧根的证明，节点需访问相关历史树节点或状态数据。

标准全节点可能无法方便地获取旧状态。

归档节点旨在保留历史状态以便快速访问。

因此，区块链浏览器、分析公司、审计方和基础设施提供商通常依赖归档节点。

对用户而言，如果证明数据不易获得，验证旧状态可能比验证当前状态更困难。

对开发者而言，这意味着历史证明系统需要周密的数据存储规划。

状态承诺是紧凑锚点，但证明仍需辅助数据。

归档基础设施为历史验证弥合了这一缺口。

状态承诺与状态膨胀

状态膨胀是指实时区块链状态变得过大。

每个新账户、合约、存储槽位、代币余额、订单和仓位都可能增加需要承诺和维护的状态数量。

更大的状态会增加节点存储、同步时间、数据库工作负载和证明复杂度。

状态承诺并不能消除状态成本。

它们只是汇总并认证状态。

如果底层状态增长过大，节点仍需存储、更新或证明其中部分状态。

因此，状态承诺研究与状态过期、存储租金、修剪、无状态化和 Verkle 树密切相关。

区块链需要安全的承诺，也需要可持续的状态管理。

状态膨胀是智能合约平台最难解决的长期问题之一。

更好的状态承诺可提供帮助，但不是唯一解决方案。

状态承诺与存储租金

存储租金是一种针对在区块链状态中保留数据而收费或预留价值的经济工具。

它与状态承诺有关，因为每项持久化数据最终都必须纳入已承诺状态。

若存储数据成本过低，用户和应用可能创建低价值状态，长期给网络带来负担。

若存储成本过高，有用应用可能更难构建。

状态承诺使状态可验证，但不决定谁应为存储该状态付费。

存储租金、保证金、Gas 成本和返还机制有助于解决状态增长的经济问题。

状态承诺解决加密学问题。

可持续的区块链设计需要两者。

区块链即使拥有强大的状态根，若状态无限增长，仍可能面临问题。

因此，应将状态承诺与状态经济学结合研究。

状态承诺与终局性

当状态承诺关联已终局确定或已获得强确认的区块时，它会更有价值。

如果区块可能发生重组，其状态承诺可能被另一条链分支的状态承诺取代。

这对跨链桥、提现、审计和跨链消息很重要。

跨链桥不应依赖容易被逆转区块中的状态承诺。

轻客户端应了解其所验证状态所在链的终局性模型。

部分链具有概率终局性，可信度会随时间增加。

部分链具有明确的经济终局性或 BFT 风格终局性。

承诺证明相对于某一区块的状态。

终局性则告诉用户该区块保持规范链状态的可信程度。

当底层区块承诺也依照相关共识规则达到终局性时，状态证明最为有力。

状态承诺与共识

共识与状态承诺协同运作，但二者并不相同。

共识决定接受哪些区块及其顺序。

状态转换函数执行这些区块并生成新状态。

状态承诺汇总该新状态。

若共识接受了状态根错误的区块，诚实节点应在执行验证期间拒绝该区块。

如果节点对执行规则存在分歧，可能计算出不同状态承诺并发生分裂。

因此，客户端实现必须严格依照协议规则计算状态承诺。

状态承诺对共识至关重要，因为它们代表已达成共识的执行结果。

它们不只是数据库索引或可选元数据。

错误的状态承诺可导致区块无效。

状态承诺与 RPC 提供商

RPC 提供商是钱包和 dApp 用于读取和提交区块链数据的服务。

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

dApp 检查合约数值时，提供商可能读取合约存储，或根据当前状态模拟执行。

但普通 RPC 响应并不总是加密证明。

它可能只是提供商报告的数值。

当提供商同时提供证明数据时，状态承诺可支持更强验证。

对于 Ethereum，EIP-1186 定义了用于账户和存储证明的 eth_getProof。

这意味着需要更高保证的应用可请求证明数据，而非信任普通响应。

大多数普通用户不会手动验证这些证明。

但状态承诺为可降低对基础设施提供商信任的工具奠定基础。

状态承诺与索引器

索引器会整理区块链数据，以便应用快速搜索。

它们可追踪代币转账、NFT 所有权、DeFi 仓位、治理投票或账户活动。

索引器很有用，因为直接查询原始状态和日志可能较为困难。

但索引数据不等于状态承诺。

索引器可能出错、落后于链，或采用自身的解释规则。

状态承诺是协议加密验证系统的一部分。

对于高价值或安全敏感型应用，可能需要根据已承诺状态或回执检查索引数据。

当索引器输出触发金融操作时，这一点尤其重要。

索引器提升易用性，状态承诺提升可验证性。

可靠的加密应用应理解二者区别。

状态承诺与隐私

状态承诺可支持隐私保护系统，但并非天然具备隐私性。

在公链上，状态承诺通常汇总公开或可公开推导的状态。

视链和工具而定，任何人都可能查看余额、合约存储和交易历史。

隐私保护系统可能以不同方式使用承诺。

例如，协议可承诺隐藏数值，并使用零知识证明展示状态转换有效，而无需披露全部细节。

在这些系统中，承诺可隐藏数据，同时仍支持验证。

因此，commitment 一词的范围比公开状态根更广。

状态承诺可以是透明、私密或部分私密的，具体取决于设计。

除非协议明确提供隐私功能，用户不应假设状态承诺会隐藏数据。

大多数公链状态承诺更关注完整性而非保密性。

状态承诺与零知识证明

零知识证明通常使用承诺表示执行前后的状态。

证明者可证明从一个状态承诺到另一个状态承诺的转换有效，而无需让验证者重新执行全部内容。

这在有效性 Rollup、隐私系统和压缩执行模型中很常见。

证明可表明，新状态承诺源自旧状态承诺和一组有效操作。

根据系统不同，部分数据可公开，部分数据可保持隐藏。

这使承诺成为紧凑验证与复杂计算之间的桥梁。

状态承诺定义正在证明什么。

零知识证明定义状态转换为何应被接受。

二者结合，使系统能够在保持可验证正确性的同时实现扩容或保护隐私。

这是现代加密基础设施中状态承诺最重要的高级应用之一。

状态承诺与非包含证明

非包含证明用于表明某个键或数值不存在于已承诺状态中。

包含证明表明某项内容存在。

非包含证明表明某项内容不存在。

这对账户创建、Nullifier 检查、稀疏 Merkle 树、身份系统和空投领取很重要。

例如，隐私系统可能需要证明某个 Nullifier 尚未被使用。

跨链桥可能需要证明某条消息此前未被消费。

注册表可能需要证明名称或键仍未分配。

某些承诺结构比其他结构更容易支持非包含证明。

这正是状态承诺设计的重要性超越简单余额证明的原因之一。

良好的状态承诺系统应支持协议实际所需的证明类型。

状态承诺与安全假设

状态承诺依赖密码学假设。

基于哈希的承诺依赖哈希函数的抗碰撞性和抗原像性。

向量承诺可能根据方案依赖不同数学假设。

若底层密码学被攻破，承诺可能不再可信。

实现安全性同样重要。

即使承诺方案正确，若客户端软件错误编码数值或错误验证证明，系统仍可能危险。

共识关键代码必须严格处理边界情况。

不同客户端必须从相同状态计算出相同承诺。

因此，大型区块链升级会谨慎对待状态承诺的变更。

改变承诺结构会改变链安全模型的深层部分。

状态承诺与开发者工具

开发者会通过 RPC 方法、证明系统、区块头、Rollup 状态根、存储证明和客户端数据库接触状态承诺。

智能合约开发者可能需要了解代币余额的存储方式，以便生成证明。

跨链桥开发者可能需要针对已终局确定的根验证存储证明。

Rollup 开发者可能需要在批次处理后计算并发布状态根。

钱包开发者可能需要决定信任 RPC 数值还是验证证明。

索引器开发者可能需要使已索引事件与已承诺状态保持一致。

协议研究人员可能比较 Merkle Patricia Trie、稀疏 Merkle 树、Verkle 树和其他累加器。

这些都是不同形式的状态承诺问题。

理解这一概念有助于开发者避免混淆交易包含、事件日志、回执和实际状态。

最安全的系统会清晰说明正在验证哪个承诺，以及正在证明哪个状态值。

关于状态承诺的常见误解

一个常见误解是，状态承诺包含完整状态。

它不包含完整状态，因为它只是状态的紧凑加密摘要。

另一个误解是，交易证明等同于状态证明。

交易证明可表明交易被包含，状态证明可表明最终状态值。

第三个误解是，状态承诺使数据可用。

承诺可证明完整性，但数据可用性是独立要求。

第四个误解是，每条区块链均以相同方式承诺状态。

不同链采用不同状态模型和承诺结构。

第五个误解是，状态承诺自动意味着隐私。

多数公开状态承诺提供完整性和可验证性，而非保密性。

状态承诺的优势

状态承诺的首项优势是紧凑验证。

一个小型根可代表极大的状态数据库。

第二项优势是篡改可发现性。

改变底层状态会改变承诺。

第三项优势是证明支持。

用户可通过包含证明或非包含证明验证特定数值。

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

轻客户端无需存储完整状态即可检查选定状态值。

第五项优势是扩容支持。

Rollup 和证明系统使用状态承诺汇总大规模执行批次。

第六项优势是跨链验证。

跨链桥和消息系统可根据其他链或层的承诺验证声明。

第七项优势是可审计性。

状态承诺有助于表明每个区块都产生了一个已达成一致的特定状态。

状态承诺的局限性

第一项局限是，承诺本身不提供底层数据。

用户仍需数据可用性和证明数据来验证声明。

第二项局限是证明大小。

某些承诺结构生成的证明过大，无法高效用于轻客户端或无状态验证。

第三项局限是更新成本。

许多状态值变化后更新承诺，计算成本可能很高。

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

编码、哈希、证明生成和证明验证必须准确无误。

第五项局限是历史访问。

旧承诺可能存在于区块头中，但生成证明可能需要归档节点保存的旧状态数据。

第六项局限是安全假设。

不同承诺方案依赖不同加密保证。

第七项局限是对用户不可见。

大多数用户不会直接看到状态承诺，因此钱包和应用必须清晰解释基于证明的安全机制。

如何评估状态承诺系统

首先确定承诺的状态是什么。

然后检查用于生成承诺的数据结构。

评估该承诺是否支持包含证明。

如果应用需要，也应评估其是否支持非包含证明。

检查证明大小和验证成本。

检查大量状态值变化时的更新成本。

评估承诺方案背后的密码学假设。

检查当前和历史状态的证明数据是否易于获取。

评估承诺是否被纳入已终局确定的区块、Rollup 批次或其他可信锚点。

确认数据可用性是否在承诺本身之外得到单独解决。

开发者最佳实践

在实现证明验证前，先使用官方协议文档。

在设计中区分交易包含证明与状态证明。

尽可能针对可信且已终局确定的承诺验证证明。

不要假设事件和日志等同于已承诺的存储数值。

在证明代币余额、NFT 所有权或治理权之前，应了解合约存储布局。

如果应用需要旧状态快照，应规划历史证明生成方案。

除验证状态承诺外，还应考虑数据可用性。

仔细审计证明验证代码，因为微小编码错误可能成为严重漏洞。

如系统深度依赖 Ethereum 状态证明，应跟踪 Verkle 树研究等路线图变更。

记录应用证明什么、使用哪种承诺及仍存在哪些假设。

用户最佳实践

应了解，显示的余额可能来自 RPC 提供商或索引器，而非您亲自验证的证明。

使用可信钱包和区块链浏览器，但请记住，高价值系统可能需要更强的基于证明验证。

对声称验证另一条链状态的跨链桥保持谨慎。

检查跨链桥依赖原生证明、验证者、中继器、多签还是外部委员会。

应了解状态承诺并不保证所有数据都易于访问。

请记住，旧状态可能需要归档基础设施才能高效证明。

不要假设交易被包含就意味着最终状态变更已成功发生。

在依赖状态承诺执行高价值操作前，应等待足够的终局性。

与依赖跨链状态证明的系统交互时，应先使用小额测试交易。

只有在证明实际针对正确承诺完成验证时，才应将基于证明的声明视为强于普通声明。

常见问题

加密货币中的状态承诺是什么意思？

状态承诺是一种加密根或承诺，以紧凑且可验证的方式表示区块链当前状态。

状态承诺是否等同于状态根？

状态根是状态承诺的常见类型，尤其常见于 Ethereum 风格区块链。

状态承诺能证明什么？

状态承诺本身不能证明某个数值，但与有效状态证明结合时，可让用户验证该数值。

为什么 Ethereum 使用状态根？

Ethereum 使用状态根承诺每个区块执行后的全局世界状态。

状态承诺与交易根有何区别？

状态承诺表示最终区块链状态，而交易根承诺区块中包含的交易。

什么是 Merkle 证明？

Merkle 证明是辅助数据，使验证者能够检查某个数值是否属于根所承诺的状态。

Rollup 如何使用状态承诺？

Rollup 在执行交易批次后，使用状态承诺汇总其 Layer 2 状态。

状态承诺能解决数据可用性问题吗？

不能。状态承诺证明完整性，而数据可用性确保验证或重建状态转换所需数据可访问。

什么是 Verkle 树？

Verkle 树是一种拟议状态承诺结构，使用向量承诺支持更小见证和更高效的无状态验证。

状态承诺是否具有隐私性？

不一定。多数公链状态承诺提供可验证性而非保密性，除非与隐私保护密码学结合。

结论

状态承诺是在特定时间点对区块链实时状态作出的紧凑加密承诺。

它使庞大的余额、账户、合约存储和应用数据集合可由一个小型根或承诺数值表示。

在 Ethereum 中，状态根是全局执行层状态的主要状态承诺。

该根由 Merkle Patricia Trie 生成，并会在底层状态变化时改变。

状态承诺对共识、轻客户端、Merkle 证明、Rollup、跨链桥、审计和无状态客户端研究至关重要。

它们帮助用户验证有关状态的声明，无需盲目信任数据库提供商。

它们还支持欺诈证明、有效性证明和跨链消息传递等高级系统。

但是，状态承诺不同于完整数据可用性、交易包含、回执日志或隐私。

它必须与正确的证明、正确的数据和正确的终局性假设结合。

随着区块链寻求更小证明、更快更新和更低节点要求，状态承诺设计仍在不断演进。

Verkle 树和无状态化研究表明，状态承诺的未来仍是活跃的工程和密码学议题。

在加密货币术语表中，State Commitment 指让区块链证明自身状态的加密锚点，而无需将完整状态放入每个区块头。

关键要点是，状态承诺将庞大的区块链状态转化为可验证的根，从而使节点、钱包、Rollup、跨链桥和应用能够进行最小化信任验证。