文章指出以太坊在正确性（ZK证明）和数据可用性（DAS等）方面取得了进展，但验证仍依赖于特定系统。为解决此问题，提出“可移植验证边界”概念，即通过简单的哈希承诺（Observation Commitment Protocol, OCP）实现系统无关的验证：只需重新计算哈希并与链上承诺比对，任何字节变化都导致验证失败。文章认为这可能是以太坊缺失的第三个原语，并探讨了标准化和与现有层组合的开放问题。
走向以太坊的可移植验证边界
以太坊在两个方向上取得了重大进展：
- 正确性（例如 ZK 证明）：证明计算被正确执行
- 数据可用性（例如 DAS、数据块）：证明数据可以被检索
但还有一个缺口：
验证仍然依赖于系统。
大多数现实世界的验证工作流仍然依赖于：
- 特定的执行环境
- 特定 Rollup 的证明器
- 索引器或 API
- 应用层语义
这意味着验证无法脱离产生结果的系统而独立存在。
缺失的层级
随着 AI 系统开始生成：
……需求发生了变化。
问题不再是：
“这个计算是否正确？”
而是：
“任何第三方能否独立验证实际存在的内容——而不必信任源系统？”
最小模型
observation ∈ {0,1}*
H = hash(observation)
commitment = inclusion of H in a public ledger
验证简化为：
- 重新计算 H′ = hash(observation′)
- 检查 H′ == H
- 确认 H 包含在一笔交易中
这产生了一个可移植的验证不变量：
只要有一个字节改变，验证就会失败。
观察承诺协议 (OCP)
观察承诺协议仅定义了这一边界。
它没有定义：
它定义了：
一个与系统无关的验证边界
一个可移植的验证构件：(摘要 + 交易引用)
为何重要
当前：
但两者单独都无法提供：
一个允许独立第三方验证实际存在内容的可移植构件
没有这一点，验证仍然：
- 绑定在特定系统中
- 依赖于基础设施假设
- 在不同上下文之间不可移植
提议框架
以太坊可能缺少第三个原语：
- 正确性 → “计算是否正确？”
- 可用性 → “数据能否被检索？”
- 验证边界 → “这个确切的构件能否在之后被独立验证？”
开放问题
- 这个边界应该在协议层标准化吗？
- 是否需要规范化的承诺/提取接口？
- 如何与 Rollup、ZK 系统和 DA 层组合？
- 能否减少对索引器和特定应用验证逻辑的依赖？
参考实现
npx ocp-commit file.txt
npx ocp-verify file.txt
只要有一个字节改变，验证就会失败。
仓库：
结语
以太坊已从一个结算层演变为一个协调层。
下一步可能是：
一个验证层——其中真理不是从系统中推断出来的，
而是独立地重新计算和确认的。
