ERC-1386：链下发、链上验的凭证，发行方合约怎么管撤销

“Alice 住在澳大利亚”“Alice 已满二十一岁”——这类由现实机构签署、却要在智能合约里被核验的陈述，行业里通常叫 attestation（凭证声明）。早在 2018 年 9 月 8 日，就有两份相邻提案试图把这件事标准化，其中 ERC-1386 管的是发行方那一侧：谁有资格签、密钥换没换、凭证怎么撤销。按 ercs 仓库的记录，这份提案状态是 Stagnant，也就是长期停滞、未被推进落地，但它留下的接口设计后来在很多凭证系统里都能看到影子。

三方各管一段的分工

ERC-1386 的正文把自己和两个兄弟提案绑在一起：ERC-1387 定义凭证本身的数据格式，ERC-1388 管发行方名录，而 1386 给发行方一个合约，作为对外应答“这份凭证还算不算数”的接线员。这个分工背后的假设很关键：凭证在链下签发，出于隐私考虑不上链；链上只放一个验证入口和撤销记录。凭证的效力因此拆成两层——签名本身对不对，以及发行方的合约有没有说它已作废。

接口里的那把密钥柜

草案接口以一个 Issuer 合约展开。addattestorKey 把一个签名地址登记为有效签发人，同时带上一个字符串形式的 capacity（能力描述）和到期时间；replaceKey 换掉某个签发密钥，原文注明这一步应当先做撤销；removeKey 注销单个密钥；validateKey 回答“这个密钥在这个能力范围内、且没被撤销或过期吗”。这套设计说明了一件事：发行方的可信不是地址一个维度，而是地址乘能力乘时间窗——同一个机构的密钥，签年龄和签地址可能不是同一条授权链。

合约里还有一个值得逐字段读的 Attestation 结构：merklePath 是默克尔路径，valid 是有效性标志，v、r、s 是签名的三段，attestor 和 recipient 分别是签发人和接收人，salt 用于加盐，key 和 val 放声明的键值。verify 函数被刻意留给各家自己实现，标准解释有两个原因：一是凭证格式不止默克尔树一种，二是有些凭证的有效性依赖只有发行方才知道的上下文，原文举的例子是用信用卡权益兑换出来的票证。

布隆过滤器撤销：隐私与批量的折中

接口里最特别的是 revokeAttestations：发行方不逐条公布被撤销凭证的内容，而是提交一个包含所有被撤销凭证哈希的布隆过滤器，一次性覆盖大批撤销。原文特意说明这样做的理由是保护隐私——链上旁观者看不出某一份具体凭证被作废，验证方只能问过滤器“这一份命中了吗”。这是典型的工程折中：布隆过滤器允许误命中，对验证方意味着偶尔要处理一次假阳性，对撤销方意味着公开成本被压到极低。

一场买酒的假想实验

为了把三份提案串起来，原文设计了一个场景：Alice 从当地车管机构拿到一份载明年龄、出生日期、居住国和驾驶资格的凭证，下单买酒时，她从默克尔树里只提交“年满二十一”这一片叶子，酒类销售合约调用发行方的 verify，合约检查签发合约合法、密钥在有效期内、能力等级够格——原文明确说驾照机构的签发够格，学生证的签发就不够。验证通过、付款到账，送货上门时不需要再证明一次年龄。这个假想实验其实就是今天零知识凭证产品反复讲的“最小披露”故事：证明一条属性，不交其他属性。停摆的提案把这层结构第一次写成了接口，读它的价值不在拿来即用，而在看清“链上验证、链下签发”这条路从设计之初就要同时回答格式、密钥、撤销三件事。

三份停摆提案的组合读法

把 1386、1387、1388 三份同日提案按顺序读一遍，会发现它们合起来是一份完整的最小系统：1387 管凭证长什么样，1386 管发行方怎么管好自己，1388 管信任从哪里来。任何今天的可验证凭证产品都能被这三层坐标系定位——它的格式是默克尔树、签名集合还是零知识承诺，它的撤销在发行方合约、公共注册表还是列表文件里，它的发行方名录由社区维护、政府维护还是平台内嵌。对普通读者，这套坐标系的实用价值在于识别宣传里省掉的层：只强调签名密码学、绝口不提名录与撤销机制的产品，等于把三份提案只做了第一份。剩下两份空白由谁填、按什么规则填，正是决定这份凭证能不能被陌生合约安全消费的最后一公里。

本文为机制说明，不构成任何投资建议。