ERC-5719 签名保鲜：合约钱包的旧签名怎么换新

一个普通地址对一段消息签的字，只要哈希不变就永远可验证。合约钱包不一样。2022 年 9 月 26 日创建的 ERC-5719 在动机部分列了四类原因，解释为什么一份当时有效的 ERC-1271 签名可能在未来某一天突然验不过：多签配置变了，当初参与签名的 signer 被移除；钱包用 Merkle 树记录 signer，新加入的成员改变了树根；签名本身按 Merkle 树存放，新增了叶节点；或者钱包整体升级到新实现，签名格式换了。对链下订单簿撮合、延迟结算这类业务来说，这意味着一笔交易可能因为签约方内部的行政变动而卡死在结算环节。这份状态为 Stagnant 的提案给出的答案是：让钱包合约自己挂一个换签入口。

一个函数与四步流程

接口的核心只有一个函数：getAlternativeSignature(bytes32 _digest)，返回一个 URI，指向一个 JSON，里面两个字段——一个区块哈希，声明替代签名在哪个区块高度上有效；一个替代签名本身。客户端的标准流程是四步。先按 ERC-1271 直接验证旧签名，通过就一切照旧；不通过再调用这个函数取新签名；取回后再次验证，通过则原位替换使用；如果 URI 拿不到、内容不合法，或者拿回来的还是同一份旧签名，则判定无效。提案特别要求客户端设置重试上限，防止在一个循环返回同一签名的源上无限打转。

URI 这个载体的好处是解法谱系宽：中心化服务器可以实时重算 Merkle 证明，IPFS 目录可以预先存好各种签名变体，链上链下都能接。代价也在这里——换签环节把一个原来纯数学的验证问题，变成部分依赖链下可用性的问题。签名替换声称不需要钱包在线配合，但源不可达时结果仍然只有失败一途。

值得多说一句的是失效的静默性。EOA 签名要么有效要么无效，判断即时且确定；合约钱包签名则带着一段隐形的寿命，边界由钱包内部的配置决定，而配置变更往往是几周前某个治理提案的结果，验证失败时表面上看到的只是一个普通的验签错误码。这也是提案为什么强调非交互式替换：结算发生的时刻，原签名钱包可能已经弃用、换域名甚至停止服务，能救这笔结算的只有当初留在链上的那个指针。

对藏家和交易者意味着什么

NFT 场景里这份提案照到的现实比机制本身更值得记。第一，用合约钱包参与链下签名类操作——订单签名、授权声明、白名单登记——要意识到签名的寿命和钱包配置绑在一起，换成员、升级实现之前先清点有哪些历史签名还挂着用。第二，验证方看到 1271 验签失败时，正确的动作不是直接判定作弊，而是先查对方钱包有没有公开的替代签名入口，排除配置演化的正常情况。第三，任何声称旧签名永远有效的中间件，要么只支持普通地址，要么在替你做隐性的重试，出了问题日志里看不到。还有一个容易被忽略的时间锚点：替代签名 JSON 里带的是区块哈希，意味着这份新签名只宣告在某个高度附近有效，跨多日结算的订单如果拖过了签名声明的参考高度，仍可能进入再一轮失效与再替换的循环。标准为这类故障设计了正门，但生态对门内接的是客服还是密码学，各自的选择并不相同。顺带一句实操提醒：多签钱包的治理动作如果涉及成员与实现变更，最好在低峰期执行并给链下系统留出同步时间，凡是把 1271 验签结果缓存过期的撮合引擎，也应该在钱包配置变更后主动失效对应地址的缓存，两侧各做一半，旧签名的复活与误杀才会都变少。本文为机制说明，不构成任何投资建议。