链上证书的第一版：ERC-5851 可验证声明的写法

“证明这个地址年满十八”“证明这个账户通过了机构认证”——这类需求在链上有一个共同结构：可验证声明（Verifiable Credential）。ERC-5851 是最早把它搬上以太坊的尝试之一：发行方把声明做成灵魂绑定代币（SBT）发给持有者，验证方通过链上元数据核对声明是否成立。提案在 ercs 仓库的状态是 Stagnant（停滞），创建于 2022 年 10 月 18 日，依赖 ERC-721、ERC-1155、ERC-1167、ERC-1967 和 ERC-3475。

角色与数据三层结构

规范先摆正角色链：Issuer（发行方）把关于主体（Holder 所代表的实体）的一组 Claim（声明条件）铸成凭证；Verifier（验证方）核对声明；零知识证明被列为可选工具——不透露全部输入就能让验证方相信断言成立。数据侧分三层：Metadata 结构描述每个条件——title 字段名、_type 数据类型、description 说明；Values 结构与 ERC-3475 一致，四选一装值（字符串、整数、地址、布尔）；Claim 结构把条件式连同值写清楚，比如 age >= 18。规范还建议实现者用 TLV 或 base64 之类方案压缩这些字段，别把证书写得太大。

签发与作废的动作

接口核心是两个动作：certify 把一枚 SBT 证书连同声明数据签发给地址，revoke 作废它；standardClaim 与 changeStandardClaim 维护标准条件集，ifVerified 给验证方一个入口查询某主体对某条件的满足状态。三个事件对应三条变化：Certified、Revoked、StandardChanged。因为证书走 SBT 路线——不可转让的 ERC-721 或 ERC-1155——声明跟着地址走而不是跟着市场走：证书进不了交易市场，验证方核对的身份锚点始终是那个钱包地址本身。

怎么读这份停滞的提案

和现代方案的衔接

把 ERC-5851 放到今天的坐标系里看，它的问题意识仍在，解法被替换了。元数据层的思路被 ERC-7160 式的多档案与钉选机制接走；作废层如今更多依赖 EAS 的可撤销证明或专用销毁标准，SBT 证书路线则常见于凭证与徽章类项目。规范里对零知识证明的引用也预示了后来的走向：验证“满足条件”而不泄露“条件值”成了隐私凭证的主流诉求。因此读 ERC-5851 的正确姿势是当作一张分层对照表：条件元数据在哪、值在哪、验证查询走哪、吊销走哪。任何新一代凭证方案——无论是链下签发链上验证的混合模型，还是完全链上的证明登记——都可以拿这张表逐层核对，哪一层落在链上、哪一层落在发行方服务器，信任成本就藏在那一层。

另外注意事件与链下记录的衔接：Certified 与 Revoked 只证明发生过动作，声明内容是否仍然成立，取决于验证时点的实际条件，两者间隔越久越要重新验证。

再补一个实操细节：standardClaim 定义的条件集会随 changeStandardClaim 版本化演进，核验旧证书时要看事件里条件集当时是哪一版，拿新版条件套旧证书会得出错误结论。

顺带提醒读者留意提案谱系：从 ERC-5851 到 EAS 与 W3C 模型的映射提案，链上凭证的公共件在持续迭代，读到任何一版都不要把它当作终点。

Stagnant 不是“错误”，是“不再推进”：它把链上 VC 的骨架摆了出来，但没有形成活跃生态，公开实现与工具支持都稀薄。读它现在更像读一份设计标本——它的价值在概念分工：条件描述与值分离、发行方权限与代币标准复用、验证走查询而非出示文件。今天真要在链上发可撤销证书，社区更多讨论 EAS 证明服务或 ERC-8004、W3C VC 的链上映射等路线。评估任何声称“符合链上 VC 标准”的项目时，用 ERC-5851 的分层做体检仍然有效：条件是怎么声明的（有没有元数据）、值存在哪（链上字段还是链下哈希）、作废怎么查（有没有 revoke 与事件）、以及发行方地址是不是你认识的那家。四层里最后一条最朴素也最关键——证书的可信度首先来自 Issuer 地址的可信度，代币和标准都替代不了这一步。本文为机制说明，不构成任何投资建议。