73万条链上认证被撤销：签名记录为何只有单方纠错权

有人曾礼貌而准确地告诉我：一个签名并不能让一个声明变成真的。我没有好的回答，于是去查了一遍——当一个签名声明不再成立时，整个生态到底会发生什么。

我数的是数据，依据三个 EAS 索引器，而非估算：

Base：3,651,900 条认证中有 678,895 条被撤销
Optimism：1,319,189 条中有 54,213 条被撤销
以太坊主网：14,956 条中有 95 条被撤销

合计 4,986,045 条中有 733,203 条被撤销，接近 15%。这个总数其实是最没用的部分。

来源截图

撤销权的分布：一家交易所占了绝大多数

在 Base 上，三个 schema 承载了全部撤销量的 97%，而且都属于同一个发行方：verifiedAccount（发行 723,600，撤销 409,490）、verifiedCountry（发行 307,123，撤销 144,207）、verifiedCoinbaseOne（发行 189,434，撤销 103,295）。一家交易所在持续撤销自己约一半的验证记录。

任何人都可以复现这个结果：

curl -s https://base.easscan.org/graphql -H "Content-Type: application/json" \
  -d '{"query":"{ aggregateAttestation(where: {revoked: {equals: true}}) { _count { id } } }"}'

再用 groupByAttestation(by: [schemaId], where: {revoked: {equals: true}}) 获取拆分数据。一个提醒：我跑的时候 Base 端点对一个合法查询返回了 200 状态的维护页。如果你不看响应体，会把它读成零。

EAS（Ethereum Attestation Service） 是一套运行在 EVM 链上的通用认证协议：任何地址都可以对任意数据（由 schema 定义结构）发起一条链上声明，声明会被记录为一条 attestation，包含发行方、接收方、schema、时间戳以及是否已撤销等字段。它的关键设计是「单方主权」——认证只能由发行方自己撤销，接收方或第三方无法单方面修改。EAS 在 Base、Optimism 主网都有官方部署，并衍生出 easscan.org 这类索引器，把链上日志聚合成可查询的 GraphQL 接口，本文中的统计数字正是通过这些索引器拿到的。理解这一点，才能看懂后文所说的「交易对手方没有任何动作可用」——这不是实现偷懒，而是协议层面的结构性事实。

我原本预期看到争议，结果一条都没有

我本以为会找到争议。一个装满签名声明的注册表，有些是错的，还有各方互相质疑的痕迹。

没有争议，因为根本没有这种操作。一次撤销，是发行方撤回自己的声明。这 733,203 条全部如此。交易对手方没有任何动作可用。

这重新定义了整幅图景。修改一条已签名的记录，不是理论问题，也不罕见：它是数十万量级的日常运营工作。而唯一可用的工具，是自我纠错。

自我纠错在哪里有效，在哪里完全失灵

当作者对声明为假这件事没有利害关系时，自我纠错运行得非常漂亮。一家不再验证某用户的交易所，没有理由继续声称它在验证。撤销只是记账，上面那些数字大体就是如此：一个庞大而诚实的系统在保持自己的记录是最新的。

当作者本身就是利益相关方时，它什么也做不了。

想想 agent 与 agent 之间的支付会产生什么。卖方声明自己已交付，买方声明自己收到了什么。双方说的都是自己的履约情况，或自己的应得权益，而这份记录日后可能用来决定谁是对的。要求任何一方去撤销对自己有利的声明，这不是机制，这是指望。

所以缺口不在于签名太弱。缺口在于：注册表把修改记录的权利只交给了一方，而且把这项权利交给了作者，而不是事件另一侧的那个人。

agent-to-agent 支付指的是由软件代理（而非人类）代表各自主体，在无需人工介入的情况下完成的机器间结算。典型场景是：一个 agent 购买另一个 agent 提供的数据、算力或 API 调用，双方各自动生成一份关于本次交易的记录。这类场景对「可验证的履约凭证」需求极高，因为它没有传统金融里的对账窗口、客服申诉或人工裁决；争议一旦发生，唯一能依赖的就是双方各自签名的记录是否一致。当这些记录同样托管在单方撤销的注册表里时，履约方完全可以事后撤回对自己不利的声明，于是「可验证」这一前提就被抽空了。这正是本文所说缺口最尖锐的落点。

另一半应该长什么样

对同一事件的两份签名账目，来自利益方向相反的两方，并且两份凭证被绑定在一起，使矛盾可以被计算出来。

具体来说，在我采用的格式中：买方的声明包含卖方签名收据的哈希，针对该收据传输时的精确字节计算。这样一来，该声明不可能指向另一次交付，也不可能悄悄偏离卖方的版本。如果买方说一套、收据说另一套，验证者重新计算摘要、比较双方都描述的字段，就能从算术里算出不一致，而不是靠人去阅读判断。

这个设计是刻意收窄的。它不判定谁对谁错。判定属于治理，不应该由某个库来接管。它消除的是这样一种状态：两方各自悄悄持有着互不兼容的记录，而系统里没有任何东西会注意到。

哈希绑定（hash binding）是这里的关键密码学手法：买方声明中不直接复述卖方收据的内容，而是嵌入卖方收据字节的密码学摘要（如 SHA-256）。由于摘要对输入的任意改动极其敏感，买方无法在事后替换成另一份收据的摘要而不被发现。验证者只需重新计算收据的摘要，与买方声明中嵌入的值比对，就能判断两份记录是否指向同一次交付。这样，矛盾从「两份文本谁在说谎」变成了「两个数字是否相等」——可被程序直接判定，而无需任何一方的配合，也不需要信任任何中心化仲裁者。这正是作者所说「从算术里算出不一致」的含义。

诚实的边界：检测矛盾不等于让不诚实变贵

检测到矛盾，不等于让一个不诚实的声明变得代价高昂。我所构建的东西，没有任何一种能给错误施加成本。能做到这件事的三种机制是：质押、争议流程、可验证执行——我一个都没有。

这次数数给我带来的，是去构建最便宜那一个的论据。不是关于“缺口存在”的观点，而是测量结果：一个被行使了 733,203 次的需求，而对其采取行动的权利，恰好只握在一方手里。

还有一个从反方向得到的数字。对某个 facilitator 的发现索引中 20,462 个活跃 x402 资源进行抽样，在六个分散偏移点各取一百个，没有任何一个声明了会发出交易对手收据的扩展。我试过的八个 facilitator 端点里有七个在该路径上没有返回可用的 JSON，所以它们属于“未测量”而非“零”，其中就包括最大的那个索引。这是一个强有力的迹象，不是证明。

我后来自己搭了一个，所以这个计数不再为零。我宁愿把这句话说出来，也不愿让我发布过的数字继续暗示一件它已经不再代表的事情。它仍然是“一”，而且它的两边都是我。

这是一个奇怪而不错的位置，因为它意味着最难的部分不是发明。

代码与测量脚本：github.com/holistis/tokenizen

质押（staking）、争议流程（dispute process）、可验证执行（verifiable execution） 是给不诚实声明「加价」的三类主流机制。质押要求声明方锁定资产，若被证明说谎则罚没，使说谎有了明确成本；争议流程引入一个可被挑战、可被裁决的环节，通常配合经济激励让第三方充当裁决者；可验证执行则把声明本身变成可被机器验证的确定性计算，让「说谎」在数学上不可能，而非仅仅是昂贵。三者的共同点是都为「违约」引入了外部成本，因此能改变博弈均衡。而纯粹的检测只能改变信息分布，不改变收益结构——说谎者依旧可能选择说谎，只是更早被看穿。作者明确承认自己没有实现这三者中的任何一个，是为了划清「已做」和「未做」的边界，而非淡化局限。