链上签名验证器：ERC-7913 如何验一把“没有地址的钥匙”

链上“证明你是谁”的主流答案很统一：签个名，合约按签名恢复出地址。但这套答案预设了签名密钥必须长着以太坊的样子。可现实里的密钥越来越杂——Passkey 用的 secp256r1 曲线、邮箱验证体系、手机安全芯片，它们没有一个自己的以太坊地址。ERC-7913 处理的就是“这些没有地址的钥匙怎么在链上算数”：它在 ethereum/ERCs 仓库标注为 Final，2025 年 3 月 21 日创建，思路是给每类密钥配一个公共验证器合约，把验签变成一次标准化调用。

与 ERC-1271 的分水岭

以太坊早有关于“非普通地址签名”的先例：ERC-1271 允许智能合约账户（比如多签钱包）通过实现 isValidSignature 来证明签名有效——那个签名背后是一个地址，只是验证逻辑住在合约里。ERC-7913 走得更远：签名者根本没有以太坊身份。标准定义的接口只有一个函数：verify(key, hash, signature)，传入密钥、消息哈希和签名，返回标准的验证成功魔数或表示失败的数值。密钥格式、算法约定全部编码进 key 参数本身，验证器合约只负责“按这把钥匙的规矩验这个签”。

标准对验证器提了一条硬约束式的建议：verify 应当是无状态的纯函数，不得依赖部署后可变的状态，参与验证的参数要么装进 key，要么写进不可变代码。这条约束有两个现实理由：一是 Gas——验证器是全链公共基础设施，一个热门验证器每天被成千上万合约调用，无状态意味着可以放到预编译友好的执行路径上；二是可组合性安全——按 ERC-7562 的范围规则，无状态验证器不会在交易模拟中引入意外存储访问，钱包和基础设施才能放心调用。它还带来一个容易被忽略的工程事实：验证器是公共品。一把 Passkey 曲线可能只需要一个全网共享的验证器，任何人部署、所有人复用；验证器代码有 bug 时影响面是全网级的，这也是标准强调无状态与最小接口的原因——攻击面越小，公共品越稳。

与 NFT 用户有什么关系

它离普通用户最近的位置是社交恢复。智能账户的恢复流程常设计成“若干监护人签名同意即可换掉丢失的密钥”，而监护人完全可能是不用以太坊的人——他们的确证签名可以来自 Passkey 或既有身份体系，通过验证器在链上被承认。对保管 NFT 的用户，这条路径的真实含义是：恢复机制的信任从“你备份的那 12 个词”部分转移到“你选择的监护人体系”，攻击面也随之改变：钓鱼目标从你的助记词转向你的监护人。评估新钱包时，应当把“恢复走哪些密钥、经哪些验证器”当成与“支持哪些 NFT”同级的问题来问。

另一个直接场景是验证链上凭证：一份签发时带外部体系签名的证书，验证动作可以委派给标准验证器，而不要求验证方原生理解每种算法。

使用注意

第一，key 的格式约定是信任的一部分：同样写着“邮箱密钥”，不同验证器对格式与签发源的解析不同，不要跨体系猜测等价。第二，验证器地址应当从可信清单获取——恶意部署一个同名验证器再骗工具去调用，是标准的授权类钓鱼路径。第三，Final 状态说明协议本身收口，但具体算法验证器的审计要逐个看，标准统一的是接口不是实现质量。第四，对普通用户，助记词仍是第一因：验证器和社交恢复解决“丢钥匙怎么办”，不解决“钥匙还在但被诱导签名”——后者永远靠签名前读内容。本文不构成投资建议。