ERC-7947 账户恢复接口：智能账户的找回服务长成一个可查询的样子

助记词丢了，在传统地址上几乎等于资产封存。智能账户给了另一条路：让某个服务或某组人有权在验证身份后帮你换掉控制密钥。问题是每家的找回流程都长得不一样，用户无法事前验证这家恢复商到底有没有能力、有没有被授权。ERC-7947 试图把恢复做成标准接口：账户这边登记恢复方、发起找回，服务方那边订阅和注销，两边都有事件可查。按照以太坊 ercs 仓库的记录，这份提案名为 Account Abstraction Recovery Interface，状态为 Draft，创建于 2025 年 5 月 7 日。

账户侧：登记、移除、找回三个动作

接口 IAccountRecovery 在账户这一侧的核心是：addRecoveryProvider(address provider, bytes memory recoveryData) 把一个恢复服务登记进来并附上该服务要求的凭证数据，removeRecoveryProvider(address provider) 移除，recoveryProviderAdded(address provider) 给任何工具做免 Gas 查询，getRecoveryData(address account) 读回登记时提交的凭证。找回动作有两个入口：账户还能正常操作时走 recoverAccess，密钥彻底丢失时走 recover(bytes memory object, bytes memory proof)——由恢复方提交一个对象和一份证明，合约验证通过后更新控制密钥并发出 AccessRecovered 事件。登记与移除分别触发 RecoveryProviderAdded 与 RecoveryProviderRemoved。这套设计的重点不是规定恢复的密码学方案，而是规定恢复关系必须写在链上。

服务侧：订阅制让恢复方也能被查

另一组接口服务恢复提供商自己：subscribe(bytes memory recoveryData) 让服务方带着自己要求的凭证数据注册为可用服务，unsubscribe() 退出，AccountSubscribed 与 AccountUnsubscribed 事件让任何人能重建哪些账户在订阅这家服务的名单。对用户这意味着选型阶段可以做两件事：数一数这家服务商名下有多少真实订阅账户（事件遍历），确认它当前的服务状态（最近有没有退出事件）。一个已经退订的恢复合约，就不该再被登记进你的账户。

和社交恢复、多签找回的关系

社交恢复把谁能替你决定换密钥定义为一组朋友地址；ERC-7947 不规定这个集合是什么——provider 可以是一个合约、一个多签、一个托管服务，接口只要求关系登记在链上、找回走标准函数并发标准事件。两者是互补层：社交恢复回答信任模型是什么，ERC-7947 回答不管信任模型是什么、接口长什么样。对普通用户最实用的推论是：任何自称提供账户恢复的服务，都应该能用 EIP-165 探到这套接口或在文档里给出等价查询路径；两头都给不出的，等于让你在没有验证手段的前提下信任找回流程。

使用前要核实的三件事

托管与自恢复之间的选择轴

配恢复方案本质上是在两条轴上做选择：信任轴上，从几个朋友到商业恢复商到多签机构；延迟轴上，从即时生效到几天强制冷静期。ERC-7947 的接口不预设这两条轴的答案，但让答案变得可比：登记了哪几家恢复商（addRecoveryProvider 事件时间线）、每家登记时约定的凭证形态是什么（getRecoveryData）、有没有装第二重延时（接口本身不规定，需要读合约实现）。用户最常见的误配是把信任轴拉得太满——单一恢复商、无延时、无到期——平时最顺滑，密钥泄露时也是最糟的配置：攻击者若能同时骗过恢复商的风控，找回速度比用户自己发现事故还快。接口化标准不能替你做选择，但至少让任何一种选择的后果第一次变得可以事前检查，而不是出事后从客服记录里考古。

一是恢复权与日常权的隔离：在能看源码的前提下翻 recover 的实现，确认恢复出的新密钥是否触发 AccessRecovered、旧配置是替换还是叠加，叠加式恢复会留下旧密钥仍然有效的隐患。二是凭证数据：recoveryData 里通常会写明恢复该账户需要提供的材料形式，对照自己实际拿得出的东西。三是撤销通道：确认 removeRecoveryProvider 由谁可调用——只允许账户自身调用才符合我能随时解雇恢复商的直觉。按 ercs 仓库口径该提案仍是 Draft，采用面有限，写合约前先确认目标产品确实实现，比在教程里假设它存在可靠。本文为机制说明，不构成任何投资建议。