一个智能账户今天可能用通行密钥验签、明天想用社交恢复、下个月给某个定时器开一条免确认通道——每次操作”该听谁的验证”，需要一个确定的答案。ERC-7582 给出的答案很取巧：把验证器的身份写进 ERC-4337 的 nonce 里。这份草案不要求账户合约新增任何接口函数，只规定了怎么复用既有字段。下面拆编码规则、转发流程、你怎么在链上查、以及由此产生的信任边界。
背景：一个函数的接口哲学
ERC-4337 的账户侧接口 IAccount 刻意只定义一个函数 validateUserOp：打包器把 UserOperation 交给账户，账户自己判断签名可不可信，返回一段验证数据。接口的极简是特性而非缺陷——所有扩展逻辑都留在账户合约内部。代价也明显：外部工具与用户很难不执行代码就看出”这个账户此刻用哪套规则在验证”，换插件、加模块往往要翻该账户的源码或文档。
nonce 高位的腾挪
ERC-4337 的半抽象 nonce 由两截组成：低位是账户内部顺序递增的序号，高 192 位是一个可以由账户自定义的 key，常用来区分多条独立的 nonce 序列。ERC-7582 的做法是：当这笔 UserOperation 的 nonce 高位不是常规顺序值、而是大于 type(uint64).max 的标识时，把它当作验证器指针——可以直接是验证器合约地址，也可以指向存储里的某个槽。账户在 validateUserOp 里 MUST 解出这个标识，并把 UserOperation 的 calldata（规范建议整包）转发给该验证器合约；验证器按 EntryPoint 约定完成校验后返回 validationData，账户原样转交。规范特意比较过另一种做法——把验证器信息塞进签名字段——选择 nonce 是为了省 calldata，并且能搭上 EntryPoint 的 getNonce 记账体系。
你能在链上查什么
这套编码给用户留了一个实用的观测点：EntryPoint 发出的 UserOperationEvent 事件带着完整 nonce，区块浏览器抓到这笔事件后，把高 192 位解出来，就知道这笔操作实际是谁替你的账户做的验证。核对路径因此成立：先在浏览器里看账户订阅的验证器列表与这笔操作用的是哪一个，再去验证器合约页面看它是否经过源码验证、最近一次更新是什么时候。一个只想批量转工资的账户，如果发现某笔操作的 nonce 指向了一个你不认识的验证器，这就是比”交易失败”更早的警报。
信任边界
验证器拿到的是整包 calldata 与验证否决权——它点头，操作才能进块。所以给账户挂验证器本质上是授权：它能判断某条规则的签名是否有效，规则本身却由它的合约代码写死。评估顺序与给钱包发通行证：ERC-7715 执行权限请求里讨论的权限请求类似：先看作用范围（这条通道允许它批准什么操作、有没有额度与有效期），再看合约实现，最后才看应用侧的说明。与它同属模块化账户题族的 ERC-7780 把验证器之外的模块类型补齐成六类，验证器之外的六种模块：ERC-7780 给智能账户补上策略与签名两类闸按类型拆过；而 ERC-7522 用登录身份加零知识证明做验证器用登录身份驱动智能账户：ERC-7522 的 OIDC 零知识验证怎么替你把关，可以和本篇的 nonce 指针法对照——同一个接口约束下，路由验证器的路不止一条。
换验证器的操作纪律
给账户增删验证器本身是一笔链上配置变更，纪律比开关本身更重要。三条顺序：其一，先增后删——新验证器登记并小额试跑通过之前，保留旧验证器在线，避免切换瞬间出现”两边都不认”的锁死窗口；其二，改配置那笔交易自己也要经过当时的验证规则，等于让旧规则批准新规则，任何一步的签名请求都要在钱包里看清是”变更配置”而不是普通操作；其三，删除即断后路，被移除的验证器所对应的那条通道（比如某把通行密钥）应立即视为退役，不要再往里充值或登记备用关系。
状态与使用提醒
ERC-7582 的官方状态是 Draft，接口约定以仓库当前文本为准。已经在使用模块化智能账户的用户，可以把”操作时账户用了哪个验证器”加入日常核对；还在用普通外部账户的用户，只需要知道一件事：将来钱包设置里出现”验证器""插件”这类开关时，它们决定的是谁来替你把关签名，加挂之前请逐项确认作用范围。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。