用谷歌账号登录一个应用很常见；把”登录”和”动用链上资产”绑到一起，听着就让人手心冒汗。ERC-7522 尝试的正是这条路线：让 ERC-4337 智能账户接受 OIDC 身份验证的结果，用户不用在设备上签一段消息，也不用把某把长期私钥交给任何人——验证由链上合约对一个零知识证明做出裁决。这份规范标注为草案（Draft），下面拆开它的角色、接口和你真正该盯住的风险点。
它要接上的是哪两块拼图
OIDC（OpenID Connect）是目前最普及的登录协议之一，你点”用某某账号继续”时走的多半就是它；ERC-4337 则是智能账户的标准执行轨道（该协议已定稿，背景见 ERC-4337 是什么？智能账户怎么执行和付手续费）。难点在于：智能账户的默认验证器认的是密钥签名，而 OIDC 给用户的是一张身份提供方签名的 ID Token——通常是三段式的 JWT。直接让合约验 JWT 的 RSA 签名，代价高且暴露的信息多。ERC-7522 的解法是在中间加一层零知识证明：用户侧从 JWT 出发生成一份 ZK 证明，链上合约只验这份证明，从而确认”发起这个 UserOperation 的人，持有与被绑定身份对应、由登记的身份提供方签发、尚未过期的凭证”。
四个角色与三个函数
规范的术语表定义了四方：Identity Provider（签发 ID Token 的服务）、User（登录并生成证明的客户端）、ZK Aggregator（可选的链下聚合服务，把多人证明打包以摊薄验证成本）、OpenIdZkVerifier（链上验证合约）。接口上，getVerificationKeyOfIdp 返回身份提供方的验证公钥，getIdHash 按账户地址返回它绑定的身份哈希——同一个身份哈希可以挂在多个智能账户上；verify 接收一个 UserOperation、一组公开输入和证明本体，验证通过才放行；verifyAggregated 则批量处理多个操作与证明。公开输入的结构体带四个字段：JWT 头与负载段的哈希、用户身份哈希、过期时间戳、JWT 签名。读到这里你应该能看出来：链上核对的是”证明与这些公开输入的一致性”，具体的电路设计与信息隐藏程度属于实现细节，以各实现的审计文档为准。
和”谷歌拿着你的私钥”是两回事
这类方案最容易被误读成身份提供商掌握了账户钥匙。按规范的设定，ID Token 只是验证材料：平台签发的是”你是谁”的短期凭证，而不是资产控制权的私钥，任何一次操作仍要经智能账户的验证流程和 EntryPoint 上链。也正因此，它把信任重心从”某把密钥永远别丢”挪到了”这条身份链的完好性”上：账号密码、两步验证、邮箱本身，共同构成实际控制面。谷歌等大型身份提供商的授权记录怎么盘点和撤销，通用做法是回到身份提供方的授权管理页逐项检查，而不是只在钱包里找开关；至于钱包侧”连接过哪些站点”与”授出过哪些权限”是两本账，区别见 钱包连接过的网站清单怎么清：断开连接和撤销授权是两件事。
换机、找回与失效的三种剧本
顺着这个信任重心，三类场景值得预先想清楚。换设备：新设备上重新走一次 OIDC 登录即可继续操作账户，前提是你的身份账号本身能登录。身份账号被盗：攻击者若能拿到有效 ID Token 且通过两步验证，就可能通过验证器——所以开启两步验证、管好恢复码是这套模型下资产安全的前提，不是可选项。服务商宕机或取消某家 OIDC 接入：账户应留出备用验证器（如传统密钥或社交恢复）作为退路，单一验证路径在任何方案里都是单点。
现实核查
截至本文写作时，ERC-7522 在标准仓库中状态为 Draft，公开可用实现有限，具体电路、可信设置与审计情况差异很大；不要把”协议存在”理解为”任何钱包都能安全地用”。选钱包时该问的是：验证合约地址是谁部署的、源码是否经验证、身份提供方列表谁能改。
风险提示：智能账户验证方式的更换涉及资产在控状态，任何声称”登录即可管币”的产品请先核验其链上合约与审计报告，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。