ERC-7093 社交恢复接口：守护人验证和恢复策略为什么要拆开

社交恢复的老问题是这样：账户丢了钥匙，请若干守护人投票换新钥匙。但多数实现里，“谁能当守护人”和”怎么算投票通过”被硬编码进账户合约——想接受一个没有链上账户的亲友当守护人，做不到；想把规则从”三票里两票”改成”必须含一位机构守护人加两票”，就得升级合约。ERC-7093 的思路是把验证从流程里拆出来：账户合约只管恢复生命周期，谁来验证签名、规则如何判定，分别交给可替换的验证器合约。按照以太坊 ercs 仓库的记录，这份提案状态为 Draft（草稿），创建于 2023 年 5 月 29 日。

三层角色的分工

标准把体系拆成三块。IRecoveryAccount 是用户自己的智能账户，保管恢复生命周期：当前守护人配置、恢复状态、防重放的 getRecoveryNonce，以及 startRecovery、executeRecovery、cancelRecovery 等动作。IPermissionVerifier 回答”这个守护人出示的证明算不算数”——标准在身份定义里列举得很宽：外部账户、智能合约账户之外，WebAuthn 与 Passkey 密钥、邮件的 DKIM 签名、OpenID 令牌、零知识证明、NFT 与灵魂绑定的 SBT 都被视为可上链验证的身份形式。IRecoveryPolicyVerifier 回答”凑齐这些证明够不够格触发恢复”，阈值、分组、必须包含特定类别守护人等策略逻辑都住在这里。用户更换守护人用 updateGuardians，新类型的守护人上线时无须动账户合约，挂一个新验证器即可。

一条恢复请求的生命周期

流程以链上事件为节点。恢复启动时发出 RecoveryStarted，携带拟更换的新所有者 newOwners、nonce 和 uint48 的过期时间 expiryTime；期间由守护人提交签名或证明，经 PermissionVerifier 逐一核验；过期时间一到，任何人（标准场景里通常是 relayer）都可调用 executeRecovery(configIndex)，把账户所有权换成 newOwners、清理临时状态，发出 RecoveryExecuted。用户如果反悔或察觉异常，可在执行前 cancelRecovery 撤销，对应 RecoveryCanceled 事件。configIndex 的存在是为了让用户同时维护多套恢复配置，执行时指名用哪套判定。

过期窗口是安全设计不是缺陷

值得多说一句 expiryTime 的意图：从启动到生效之间留一段等待期，相当于给账户原持有人一个”恢复公告期”——若这次恢复是攻击者盗用守护人门槛发起的，用户还能赶在生效前链上撤销。等待期把”静默换钥匙”变成”有人能看见的换钥匙”，这是社交恢复类协议共同的防线结构。用户侧的配套习惯是：把 RecoveryStarted 事件配置成告警源，任何未经自己发起的启动事件都是最高优先级信号。

守护人配置的三种典型画像

把标准能力组合起来，能拼出几张有代表性的配置。第一种”亲友团”：三位朋友各是一个 EOA，由默认的链上签名验证器核验，策略定三选二——这是经典社交恢复的标准画像。第二种”混合团”：两位亲友走 EOA、一位走邮箱 DKIM 签名、一枚组织成员凭证 NFT 或灵魂绑定代币充当机构守护人，PermissionVerifier 各管各的验证逻辑，策略可以要求”至少一位机构类守护人”。第三种”时间换空间”：策略把过期窗口拉长到数天，任何恢复启动都会先在事件流里公示多日再可执行。三种画像的信任假设完全不同——第二种把邮箱服务商也引入了信任边界，配置者要清楚每个验证器背后站着谁能证伪。

边界：谁在替你看门

拆分验证器带来灵活，也转移了信任：PolicyVerifier 合约本身有部署者和升级逻辑，若它是可升级合约，掌握升级权的地址实际上能在幕后改写恢复门槛。因此评估一个 ERC-7093 风格的账户产品，除了数守护人人数，必须多查两个地址——当前挂接的验证器合约指向哪里、那个合约的升级权握在谁手里。账户合约再不可变，验证器若是代理模式，安全边界仍然在代理后面。按 ercs 仓库口径，ERC-7093 停留在 Draft，各产品实现差异大，投票规则与守护人类型都应逐项实测，不宜从一个产品的实现外推到标准承诺。本文为机制说明，不构成任何投资建议。