文章指出以太坊目前仅标准化了链上存证（Commitment），却缺乏通用的验证原语（Verification Primitive）。这导致外部数据与链上哈希的验证过程高度依赖特定应用的逻辑或SDK，使得验证碎片化且无法跨系统通用。作者呼吁建立一种标准化的、系统无关的验证层，以实现外部工件与链上承诺的直接验证。
以太坊中缺失的验证原语
摘要
以太坊常被描述为一个去中心化的“世界计算机”——一个具有全局复制状态的共享执行环境。
虽然以太坊提供了将数据提交到链上的强健机制，但并不存在一种标准的、可移植的方式，让独立第三方在不依赖应用特定验证系统的情况下验证外部工件是否与这种提交相对应。
在实践中，这意味着：
验证并不是全局自足的——它依赖于系统特定的环境。
本文认为，以太坊并未标准化一种系统无关的验证原语，而这一缺口引入了一个微妙但重要的张力：
即使在共享的全局执行环境中，验证仍然依赖碎片化的、应用层的系统。
这凸显了一个缺口：以太坊标准化了提交（commitment），但没有标准化独立验证这些提交的接口。
随着越来越多的系统依赖链下工件——媒体、AI 输出、日志和文档——这一缺口变得越来越明显。
以太坊做对了什么
以太坊成功提供了：
- 提交 — 任何数据都可以被哈希并锚定到链上
- 共识与最终性 — 提交在全局范围内被排序并带有时间戳
- 共享执行层 — 合约定义确定性计算
这支持了被广泛接受的模式：
“把它哈希后，把哈希值存到链上。”
这是正确的，但并不完整。
模型在哪里失效
问题并不出现在提交阶段，而是出现在验证阶段。
第三方会问：
“这个工件是否对应那条链上提交？”
以太坊并没有定义一种标准方式来回答这个问题。
相反，验证被委托给：
被隐藏的依赖层
尽管存在去中心化共识和共享执行，今天的验证仍然需要：
通过一个特定系统来运行，该系统定义了验证如何工作。
这带来了一种依赖关系：
- 必须正确解释工件
- 必须正确重建哈希
- 必须正确引用交易
- 逻辑必须与原始系统匹配
结果：
验证只有在产生它的系统语境中才有效。
后果：验证不是系统无关的
这引出一个关键观察：
即使在一个全局共享的执行系统内，验证仍然是局部化的。
在实践中：
- 验证逻辑是碎片化的
- 证明格式不一致
- 系统之间不可互操作
这意味着：
相反：
验证被应用特定环境所门控。
核心问题
今天存在的是：
并没有一种标准方式，让独立第三方在不依赖系统特定假设的情况下，基于链上提交去验证任意工件。
每个系统都定义自己的：
结果：
证明天然绑定于产生它们的系统。
这引入了对原始系统持续可用性和正确性的依赖，才能完成验证——这是验证层面上一种软性的中心化形式。
可观察到的失败案例
两个系统：
然而：
- 证明不可互换
- 验证逻辑不可复用
- 第三方验证需要自定义集成
例如，一个系统生成的证明通常需要该系统的 SDK 或特定的重建逻辑才能验证。没有这些逻辑的第三方无法独立验证该工件，即使底层提交已经在链上。
缺失的层：一种验证原语
缺失的不是提交。
缺失的是一种标准化的验证边界。
定义
一个验证原语提供：
一个最小的、可移植的工件，使任何独立验证者都能确认某个特定字节序列已经被提交到链上，而无需依赖产生该工件的系统。
这意味着需要一种标准化的验证工件——一个可移植对象，将链下观察绑定到链上提交。
最小验证不变量
其核心是：
H' = hash(o)
检查：
- H’ == H
- H 被包含在交易 T 中（例如，calldata 或发出的 logs）
重新计算 → 比较 → 确认包含性
这能带来什么
一个共享的验证层能够实现：
- 系统无关的验证
- 可移植证明
- 跨应用互操作性
- 长期可审计性
最重要的是：
验证不再依赖产生它的系统。
与 Attestation 系统的关系
这并不取代像 EAS 这样的系统。
-
EAS — 声明、schema、身份
-
验证层 — 工件 ↔ 提交对应关系
-
非目标
这一层明确不包括：
它只关注：
对应关系的机械验证
证伪框架
主张：
如果任意一个字节发生变化，验证必须失败。
o ≠ o' → hash(o') ≠ hash(o)
→ verification fails
如果某个系统能够把被修改的工件验证为有效，那么这个模型就是错误的。
核心张力
以太坊提供：
一个具有全局复制状态的共享执行环境
但在实践中：
验证依赖于应用特定系统。
张力：
一个全局执行模型与局部化的验证依赖并存。
核心主张
以太坊提供了一种提交原语，但没有标准化一种系统无关的验证原语。
开放问题
验证应当继续保持：
还是以太坊应当定义：
一个最小的、可移植的验证层，使验证本身系统无关？
结语
“只要哈希一下”解决的是提交问题。
它并没有解决验证问题。
而如果没有系统无关的验证：
这个世界计算机在验证外部工件时，仍然依赖本地系统。
