ERC-6327 弹性签名：用一段可改的口令在链上证明“我知道它”

私钥体系的劝退感很强：一长串随机字符、丢了就没了、丢了也改不了。2023 年 1 月 13 日创建、状态为 Draft 的 ERC-6327 提出了一个叫弹性签名（Elastic Signature）的构想：用户保管的是一段像密码一样可以频繁更换的口令，口令不存放在任何地方，验证完全在链上完成。听起来像魔法，拆开看是零知识证明在账户方向的又一次落地。本文按原文拆它的机制与边界。

口令不进链，进链的只有证明

抽象层的设计是这样的：用户口令先被哈希成一个链上可存储的摘要，合约里只保存这个摘要。用户执行操作时，不是把口令交出去，而是在本地生成一段“我知道对应口令”的证明，合约用 verifyProof 验证证明与摘要是否匹配。口令本身既不上链也不需要发给任何人。更换口令走 resetPassword，从原文的函数签名看，这个函数要带两组证明、两组过期时间和新旧口令摘要——旧证明证明你曾经有权改，新证明绑定新口令，两道都过了，链上摘要才被替换。这种设计让改密动作本身也需要授权，避免任何人拿到账户入口就能悄悄换锁。摘要查询函数是 pwdhashOf，按地址返回当前生效的口令摘要。

它是私钥的补充，不是替代

原文在用途部分把定位写得很克制：弹性签名是一种替代性的签名算法思路，但它不是私钥方案的非此即彼选项，设计上是在私钥签名之上再叠一层签名机制。举的例子有两个。一个是理财类应用可以在转账流程里额外要求用户提供口令证明，这样即使私钥被钓走，攻击者过不了第二道闸。另一个是把它作为 ERC-4337 这类智能合约钱包的插件，用去中心化挑选的口令代替私钥来做入门验证，降低新用户的第一道门槛。换句话说，标准给出的是一种可组合的认证件，安全强度取决于它挂在哪、怎么挂。

三个查询函数透露的细节

接口里还有一处值得从产品视角看的设计：摘要查询按地址返回，意味着任何前端都能告知用户“这个账户还没设口令”或者“口令摘要刚刚变过”，把配置状态从猜测变成可显示的信号。resetPassword 与 verify 参数中两组过期时间说明证明自带有效期，防止一劳永逸的凭证被无限重放，也暗示实现时 clock 参数配置要格外谨慎。合约端执行零知识证明验证，则意味着弹性签名的每次使用都要多付一笔链上验证成本，这份标准停在草稿、迟迟没有公开部署，成本曲线是绕不开的现实原因之一。接口面很小，取舍却都写在了明面上。

Draft 状态下的冷思考

按 ercs 仓库的记录，这份标准从创建起一直停在 Draft，没有进入更靠后的评审阶段，公开实现稀少，读者应当把它当作一份机制样本而非可用产品。机制层面有几个值得记住的边界。第一，口令的安全上限受抗爆破能力约束：链上验证意味着验证合约会诚实地拒绝错误证明，但也意味着攻击者可以无限次在链下拿字典去试，口令熵不够高时与把锁摆在马路上无异。第二，原文给摘要配了过期时间字段，说明设计者预期证明有有效期，配置不当会让旧证明在改密后仍被接受的窗口出现，这正是接口要求两组证明的原因所在。第三，零知识电路本身的正确性不在标准管辖内，合约验证通过只说明证明符合电路约束。把这三条放在一起，弹性签名描述的其实是一个朴素的愿望：让“忘记密码可以改”这种 web2 习惯搬进链上，同时不把口令托付给任何平台。愿望与落地之间的距离，恰好是这份标准停在草稿箱里的原因。

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