ERC-1387：默克尔树凭证——一份证明，为什么只用露出其中一行

把一份身份凭证原样放上公开账本，等于把姓名、住址、出生日期广播给所有陌生人；完全不上链，智能合约又没法核验。ERC-1387 给出的答案是第三种：凭证整棵默克尔树在链下由发行方签名，用户每次只在链上“掀开一角”。这份提案与 ERC-1386 在 2018 年 9 月 8 日同日创建，按 ercs 仓库记录状态同为 Stagnant，正文很短，把结构定清楚就收笔了，但“只露一行”的思路值得完整展开。

一份声明，一棵树

原文的设定是：签发者（比如一位治安法官）为 Alice 出具一份居住声明，内容被组织成一棵默克尔树，多个声明条目作为叶子散落在树上，每个叶子前加盐。树根由发行方签名，签名本身不告诉任何人树里写了什么，只承诺这棵树的内容没有被改过。用户在链上要做的，是把其中一片叶子连同它的 merklePath（从叶子到树根一路的兄弟节点哈希）交给合约；合约用叶子和路径逐层重算哈希，推出一个候选树根，再确认它出自可信签发方的签名。验证通过，说明这一条声明确实在发行方签过名的凭证里，而其余叶子对链上所有人依然不可见。

结构体十个字段各管什么

草案接口只给出一个 MerkleTreeAttestationInterface，核心是 Attestation 结构体和 validate 函数。结构体里 merklePath 承载路径哈希，valid 是验证过程写入的标志位，v、r、s 是发行方对树根的签名三段，attester 与 recipient 记录谁签给谁，salt 让同样的内容在不同树里长成不同的叶子哈希，key 和 val 则是要披露的那一行声明本身，例如“居住在澳大利亚新南威尔士州”。十个字段合起来讲了一个完整故事：这份声明、由这位签发人、给这位接收人、签在这棵树上、这一次选择让链上看见的是这一格。

多棵树：防止把两次使用连起来

原文还有一层容易被略过的设计：同一条事实可以为 Alice 生成多棵不同的签名默克尔树。为什么？如果所有场合都提交同一棵树的同一片叶子，两个本来互不相干的合约就能凭相同的树根或路径把她两次交易连起来。为同一声明准备多棵树，等于给每次使用换一个可公开的身份投影。加盐和多树这两招叠在一起，说明这份 2018 年的提案已经意识到：隐私泄露往往不是内容泄露，而是重复使用同一可关联标识造成的模式泄露。

它没有回答什么

把边界说清楚同样重要。ERC-1387 只定义凭证长什么样、怎么验证，不管签发方是谁、地址可不可信——那是 ERC-1386 发行方合约和 ERC-1388 名录要管的事；也不管密钥被泄露之后怎么办，撤销依然要靠发行方侧的机制。同时，作为状态 Stagnant 的提案，它没有经过完整评审与多套实现的反复锤炼，结构里的 valid 标志位这类设计在今天的实现者看来未必干净。把它当作理解“最小披露”的入门读物正合适：原来在零知识证明被广泛讨论之前，默克尔树加盐加多树这套朴素组合，就已经能把“证明一条、不交全部”做出来大半。

与今天凭证产品的对照

把这份 2018 年的接口与后来的可验证凭证生态并排看，概念几乎一一对应：salt 与多树设计近似今天凭证里防关联的随机数与多次签发思路，merklePath 披露近似选择性披露，发行方信任则整体交给了后来的注册表与模式体系。差异在工程成熟度：今天的实现普遍引入标准化签名编码、机器可读的模式定义与链上撤销登记，把当年留给各家自便的部分尽量收口。读者从中得到的迁移经验是，任何某某机构给你签了名的宣传都可以按三层追问——签名格式能否被第三方独立验证、签发密钥在不在可查的名录里、撤销状态靠什么机制维护。三层都答得出，凭证才具备机器可验的最小可信；任何一层靠品牌背书，信任就还停在现实世界那半截，链上部分只是装饰。默克尔树凭证虽然停摆，它把隐私拆成结构这件事，一直活在后来者的设计图纸里。

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