模块化智能账户的词汇表里，validator（验证器）、executor（执行器）、fallback（回退处理器）你已经见过了。ERC-7780 在这三种之外又登记了六种新模块类型——策略模块、签名模块、无状态验证器，外加两个预验证钩子和一个变体。这份草案（Draft）不要求账户必须支持，但对准备给钱包装模块、或者正在评估某款模块化账户配置的用户来说，它是把”装进去的东西到底在干什么”说清楚的坐标尺。
先补一层 ERC-7579 的地基
一次确认办完一串操作：ERC-7638 智能账户批量调用的编码与原子性 里解释过批量调用，其底层 ERC-7579 给模块化智能账户定了规矩：模块是功能自成一体的合约，账户按类型调用它们；验证阶段判断操作是否放行，执行阶段代表账户办事。ERC-7780 完全叠加在这套体系上，它的规范文本明确说：这些新类型没有任何一种是账户必须实现的，装了才有效果，不装也不违反 7579。
六个类型编号，各管一段流程
规范给出的类型编号很直白：编号 5 是 Policy（策略模块），职责是在操作落地前检查这个 UserOperation 想干什么、允不允许干，接口里对应 checkUserOpPolicy 与 checkSignaturePolicy 两个检查函数——额度上限、白名单、频率限制都属于这一类逻辑。编号 6 是 Signer（签名模块），专管”签名对不对”，比如把验签外包给一套特殊的密钥体系。编号 7 是 StatelessValidator（无状态验证器），它同时验签名并和调用数据里附带的一段数据做比对——规范举的例子是核对签名者是否在一串 owners 列表里；正因为比对数据随请求传入而不是存在模块自己身上，才叫”无状态”，规范还建议常规验证器（类型编号 1）也顺手实现这个接口以便组合。编号 8 和 9 分别是 ERC-1271 与 ERC-4337 场景的 PreValidationHook（预验证钩子），在正式验证前先跑一段公共逻辑。编号 10 是无状态验证器的带发送方变体，接口名多了一个 WithSender 尾巴。
用户视角：模块清单就是权限清单
如果你用支持这些类型的钱包（不少智能账户产品的”插件”就是这类模块），值得建立一个习惯：把已安装模块按类型编号分组看。策略模块决定哪些操作会被拒——你发现某笔本意的转账被莫名拦下，多半是某个 policy 的条件没过；验证器和无状态验证器决定”谁算你”，被替换或被追加意味着账户的授权面变了；预验证钩子最少被注意、却排在验证链最前面。模块装了哪些、能不能被远程换地址，用注册表类标准查的思路见 给插件装安检门：ERC-7484 模块注册表，原则是一样的：链上记录比钱包界面诚实。
省钱与减权的取舍
规范在动机部分给了一个坦率的权衡：把权限判断和签名验证做成账户直属模块，路径短、gas 便宜，但灵活性也更低；外部组合式的模块反之。对用户翻译过来就是——同一款钱包，“精简模式”少装模块、行为可预期，“扩展模式”能玩会话密钥、自动化，但每一次安装都是在给自己的资产加一条新的信任边。给日常零花账户和多签金库配置同样的模块清单，是最常见的错误之一。
一个具体到函数名的核对示范
想验证某款账户的模块生态是否名副其实，可以做一组零成本实验：在浏览器已验证源码页找到账户合约，查它对 ERC-165 的应答与 isModuleType 类接口的实现，逐个问编号 5 到 10 支不支持；再进模块地址的合约页看它是否实现了对应接口——策略模块看 checkUserOpPolicy，无状态验证器看 validateSignatureWithData。两类合约的部署者与升级方式也要分开看：模块若是可升级代理，今天核过的逻辑明天可能被换，这条纪律和 区块浏览器显示“源码已验证”意味着什么？合约验证状态核对指南 的源码验证状态核对属于同一套基本功。查不到的字段不要猜，问项目方要接口文档。
边界说明
ERC-7780 与它叠加的 ERC-7579 一样处于草案状态，模块类型编号在各实现中的一致性以实际合约的 isModuleType 应答为准；本文对函数名的引用均出自规范接口定义，具体链上合约可能未实现或部分实现。
风险提示：为智能账户安装或更换模块会直接改变资产的控制与放行规则，请先在小额账户演练，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。