---
title: "有效性证明"
description: "一份以核验为先的有效性证明指南，涵盖公开输入、见证、证明系统假设、汇总状态转换、数据可用性、最终性和操作故障模式。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 有效性证明
> 仅供教育参考，不构成投资或安全建议。有效性证明的可靠性取决于所证明的命题、公开输入绑定、证明系统、验证器、数据可用路径、合约、运营方、治理和结算链。
## 直接答案
有效性证明是一份密码学证据，用来表明某项计算满足一组精确定义的关系。验证器根据验证密钥和公开输入检查证明。在汇总协议中，这些输入通常绑定前状态根、拟议的新状态根以及交易批次承诺。验证成功后，结算合约可以接受新状态根，而无需重新执行每笔交易。
这项保证比“整个系统正确”更窄。它依赖可靠的密码学、预期程序或电路、正确的公开输入编码、真实的验证密钥，以及正确的验证器与状态更新合约。仅凭验证成功，无法证明用户能够取得底层数据、证明者会持续在线、结算区块已经最终确定、升级没有恶意，或提款路径确实可用。有效性证明可以使用零知识证明系统，但“有效性”本身不代表隐私。
## 工作原理
1. 锁定准确部署：L1 与 L2 链 ID、汇总协议版本、状态更新合约、验证器地址与字节码、验证密钥哈希、证明系统、电路或程序版本、数据可用模式、管理员权限、暂停状态和结算最终性政策。`validity proof` 不是跨系统的统一规范。
2. 解释结果之前，先定义被证明的关系。简写为：在证明系统可靠性假设成立时，`Verify(vk, x, proof) = 1` 应当意味着存在见证 `w`，使 `R(x, w) = 1`。其中 `vk` 是验证密钥，`x` 是完整公开输入，`R` 是编码后的规则集。证明只覆盖这项关系。
3. 独立重建公开输入。确认前状态根正是合约已接受的状态根；从规范数据派生批次或数据承诺、链与批次标识、后状态根、消息或提款根及协议参数。绑定到错误链、状态根、程序或批次的有效证明，只是对错误命题有效。
4. 核验证明和合约路径。运行兼容的独立验证器，再检查链上调用、收据、事件、已接受批次编号和存储变化。确认状态更新合约调用了预期验证器，且没有通过升级或特权分支绕过、模拟或替换验证结果。
5. 单独核验数据可用性。取得协议要求的交易数据、状态差异、blob sidecar 或委员会证明的数据；核对其承诺，并复现状态转换或退出见证。证明有效与数据不可用可以同时发生，尤其是 validium 或外部委员会把数据保存在链下时。
6. 分别跟踪生命周期状态：已生成、已提交、已纳入、证明已验证、状态已接受、结算安全、结算最终确定和提款完成。衡量证明积压与成本、排序器和证明者活跃性、L1 纳入、链重组、跨链桥延迟、强制纳入和逃生程序，不能把所有状态都称作“最终”。
7. 保存可复现证据：合约地址与代码哈希、验证密钥与程序哈希、完整公开输入、证明字节或持久引用、批次数据、验证命令与软件版本、交易收据、最终确定区块引用和成功退出测试。每次升级后都要重新核验。
## 算例
- **批次命题。** 某汇总协议处理 `8,192 transfers`。证明绑定旧状态根 `R0`、新状态根 `R1` 和批次承诺 `B7`。验证成功支持的命题是：“存在满足该电路、针对 `B7` 从 `R0` 转换到 `R1` 的见证。”它不能证明 `B7` 的字节可取、排序器纳入了每笔已提交交易，或 `R1` 已经最终确定。
- **递归聚合。** 聚合器在一个父电路内验证 `16 child proofs`，再提交一个父证明。父证明通过时，验证器接受聚合关系及其绑定的子证明承诺。审计者仍须确认父电路检查每个子证明、顺序和公开输入映射；证明数量本身不能建立这种绑定。
- **假设 Gas 账本。** 假设直接重新执行需要 `24,000,000 gas`，证明验证需要 `600,000 gas`，所需数据发布需要 `180,000 gas`。证明路径合计 `600,000 + 180,000 = 780,000 gas`，模型中的降幅为 `(24,000,000 - 780,000) / 24,000,000 = 96.75%`。这里不含证明硬件、聚合、失败提交、存储、跨链桥操作和数据留存成本。
## 风险
- 核验了错误的链、部署、批次、验证器、验证密钥或电路版本。
- 可靠的证明系统忠实证明了不完整或错误的电路。
- 公开输入遗漏或错误编码链 ID、状态根、批次、消息域或协议参数。
- 验证器、预编译合约、不安全库或不兼容实现存在缺陷。
- 初始化材料泄露或密码学假设失效。
- 可升级合约或治理替换验证器、密钥、程序或接受规则。
- 特权绕过、紧急模式、暂停或白名单削弱公开宣称的路径。
- 证明生成缺陷、非确定性或不同客户端派生出不同见证。
- 证明者中心化、审查、停机、积压或硬件故障使状态更新停滞。
- 交易数据、状态差异、blob、原像或归档历史缺失。
- 把委员会签名或数据承诺当成当前可取得数据的证明。
- 接受来自不安全、已重组或非规范结算区块的证明交易。
- 把证明获接受当成提款立即完成或经济最终性。
- 未能独立复现状态转换、余额、消息或退出见证。
- 低估验证 Gas、数据费用、证明延迟、跨链桥延迟或恢复成本。
- 假设一个汇总协议的证明、可用性和升级模型适用于另一部署。
## 常见误区
- 有效性证明通过验证，就证明所有实现细节和用户可见余额均正确。
- 每份有效性证明都是零知识证明，都会隐藏交易数据。
- 有效性证明消除了数据可用性、排序器活跃性和审查风险。
- 证明通过验证后，结算交易立即最终确定并可提款。
- 证明更小或验证器更快，就一定代表系统更安全或更便宜。
## 相关主题
- [数据可用性](/zh-cn/crypto/data-availability/)
- [故障证明](/zh-cn/crypto/fraud-proof/)
- [汇总协议](/zh-cn/crypto/rollup/)
- [零知识证明](/zh-cn/crypto/zero-knowledge-proof/)
- [ZK Rollup](/zh-cn/crypto/zk-rollup/)
## 来源
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org（查阅日期：2026-08-22）
- [Zero-knowledge proofs](https://ethereum.org/zero-knowledge-proofs/) - Ethereum.org（查阅日期：2026-08-22）
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals（查阅日期：2026-08-22）
- [Sequencing and verification flows](https://docs.polygon.technology/tools/zkevm/architecture/unified-LxLy/ulxly-sequence-verify) - Polygon Documentation（查阅日期：2026-08-22）
- [Data availability](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation（查阅日期：2026-08-22）
Source: https://wiki.fcontext.com/zh-cn/crypto/validity-proof/index.mdx