ERC-1388：谁签的凭证算数？一份公开的发行方名单怎么当信任中介

你收到一张“此人符合购买资格”的数字凭证，签名地址确实有效、格式也核验通过——但签发它的那家机构，你从没听过。凭证体系里最难的不是密码学，而是信任名录：到底该认哪些签发方。ERC-1388 在 2018 年 9 月 8 日给出过一个直白的答案：把名单本身做成合约，谁想验证就显式信任某一份名单，名单里所有签发方的签名自动算数。按 ercs 仓库记录，这份提案状态为 Stagnant，正文不长，但“名单即信任边界”的思路至今仍是各类认证体系的地基。

为什么不能逐家显式信任

原文的动机来自一个真实感很强的场景：一家房地产中介在合约里提供“意向登记”功能，要求参与者提交一份“我是新西兰或澳大利亚居民”的凭证，这是当地法规要求。麻烦在于，能合法签发居住凭证的机构太多了——治安法官、土地登记处、警方、护照机关，每家都有自己的签发合约。让业务合约逐一硬编码信任这些地址，既写不完，也没法随政策变化更新。原文因此提出把“管理合格发行方”这件事外包给一份名单：任何人都可以发布名单，但最终流行起来的只会是维护最认真、信誉最好的那几份。这句判断本身就是一份朴素的市场机制设计。

List 结构里的五件行李

草案实现把一个名单定义成 List 结构：name 和 description 说明这份名单是什么、覆盖什么范围；capacity 是一个字符串过滤器——如果业务合约指定了某份名单且名单的 capacity 非空，那么只有具备该能力标签的签发密钥签出的凭证才会被接受；issuerContracts 是名单里全部签发方合约的地址数组，注意原文特意说明这些条目是合约地址而不是签名密钥，密钥由各签发方合约自己管理；expiry 给整份名单一个到期时间。名单管理员（manager）是名单的看门人，只有他能用 addIssuer 与 removeIssuer 增删条目。

查询接口的代价与自曝的攻击面

业务侧的入口是 getIssuerCorrespondingToAttestationKey：给定一个签名密钥，合约会遍历名单里每个发行方合约、逐个调用其 validateKey，返回第一个命中的地址。这个“挨家敲门”的设计有一个明显的燃气代价——名单越长，验证越贵。更有意思的是原文的坦率：它在注释里直接写下一个攻击面，某个发行方可能谎称别人的密钥是自己的，并注明“由后续设计缓解”。2018 年的草案愿意把已知弱点写进正文而不是删掉，这种写法值得现在的作者学习。

用发送者当名单 ID 的取舍

草案为了简单，直接用创建者的地址当名单 ID，并主动列出两个后果：一个人想维护多份不同能力范围的名单，就得准备多个地址；如果管理人换掉了密钥，名单仍然记在最初的地址名下。这类“简单换代价”的条款在早期提案里常见，读者能把它们当作一面镜子：今天各类认证注册表在身份恢复、多名单管理上的复杂设计，都是沿着这些当年写明的小坑长出来的。三份同日提案的分工也至此齐整——1387 管凭证格式、1386 管发行方内部、1388 管谁有资格进入信任圈，链下签发链上验证的最后一块拼图是这份名单。

名单合约自身的信任悖论

顺着原文往下推，一个绕不开的问题浮出水面：名单合约解决了发行方的信任传递，可名单本身由谁担保？答案在设计里写得诚实——谁都可以发布名单，流行与否取决于信誉积累，也就是说名单层没有密码学保证，只有声誉与市场选择。这决定了读者对任何认证注册表的正确预期：名录的运营主体、更新频率、纠错机制，都是比接口函数更重要的事实。一家项目宣布接入某某信任名单时，值得查三件事：名单合约地址是多少、名单管理人是谁、名单里此刻躺着哪些发行方。这三个数都能在链上验证，缺一个，所谓认证生态的含金量就要重新估。信任外包是优雅的简化，但外包出去的信任仍然需要有人盯着，这是三份提案合并阅读时最贵的一课。

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