普通地址（EOA）想批量办事、想让别人代付手续费，过去只有两条路：换成 ERC-4337 那类合约账户，或者忍受各自为政的私有能力。ERC-7806 给出第三条：地址还是你的地址，但通过 EIP-7702 把一个”意图处理器”的代码挂到自己名下，钱包签名从”逐笔交易”升级为”一份意图”。这份提案 2024 年 11 月 2 日提交，官方仓库状态是 Draft（草案），依赖的 EIP-7702（给外部拥有账户设置代码）状态为 Final。下面按它的字段表讲清楚你签出去的到底是什么。
它想解决什么问题
ERC-4337 把账户抽象做成了完整的组件堆：账户合约、EntryPoint、打包器、付款方，一个都不能少。提案文档对这条路的批评很直白：组件多、升级要联动、跑打包器有运维门槛，而且 UserOperation 本身处理起来就费 Gas。ERC-7806 的思路是轻量化——普通地址不需要搬家，只需要临时”雇”一段合约代码替自己解析和执行意图。批量执行、代付手续费、访问控制这些能力，都塞进意图的编码格式里，由被挂载的标准合约解释。
UserIntent 只有五个字段
规范的意图结构是一张五行表：sender 是发起意图的账户地址；standard 指向负责验证和解析这份意图的标准合约；header 是给 standard 解读的元数据，用可变字节装着；instructions 是真正要执行的操作清单，同样以字节数组形式存放；signatures 是执行时需要核验的签名列表。换句话说，签名对象里没有一个字段的语义是协议层钉死的——地址以外的全部含义都委托给 standard 那一栏指向的代码。这与一次确认办完一串操作：ERC-7638 智能账户批量调用的编码与原子性讲的批量调用编码是同一类问题：一次确认办多件事，风险也从”核对一笔转账”变成”核对一份编码后的说明书”。
谁来执行：解算者与中继
意图签好之后不必自己广播。执行者（提案里叫 solver 或 relayer）收集公开的意图，替账户把执行交易发上链，账户全程不需要先发一笔交易、也不需要预存 Gas。这就是”意图中心”的完整闭环：你签名表达要什么，别人替你办并结算。执行者靠什么赚钱、报价怎么形成，规范刻意不管，这部分与跨链信箱场景里”快递员不属于标准”的分工逻辑一致，可以对照链与链之间递话的信封长什么样：ERC-7841 信箱与消息格式。
委托代码的安全边界
提案的安全章节把最重要的风险写在”存储”上：如果挂载的账户实现自己往链上写状态，它可能与同一地址上其他被委托的合约互相踩踏，也可能因为保护不严被越权改动；因此规范强烈建议实现走无状态路线。对用户的翻译是：地址背后挂了谁，决定了地址的安全水位——这段代码是可以被再次改写指向的，改一次指向，解释你签名的规则就换了一家人。这类”地址背后代码可换”的信任问题，密钥委托方向的 EIP-8164 有同款讨论，见给普通地址永久换上抗量子钥匙：EIP-8164 原生密钥委托。
签名环节的一次演练
把镜头拉回弹窗那一刻：传统转账确认里你能读到”给谁、多少、哪条链”，意图签名则常常只剩一串编码后的字节。可行的自保动作是把 instructions 当成一份待验收的清单：先让钱包或第三方解码器把字节数组展开成目标合约与函数选择器的列表，逐条比对官方文档；对拿不准的目标合约，先到浏览器查它有没有验证过的源码、创建交易是否体面，方法在交易的 Input Data 怎么读？方法选择器与参数解码里已经写过。解码器与钱包不是一家，本身就是一道防自说自话的交叉核验。
现状与核对清单
ERC-7806 仍是草案，IStandard 与 IAccount 的具体实现鱼龙混杂，任何声称”意图账户”的产品都值得按这张清单反问：代码是否公开可审计、实现有没有第三方审计、解算者执行失败或未执行时你的签名是否会被滥用、意图里 instructions 的字节能否解码成人话。草案身份意味着现网不存在”标准答案”，字段名与接口以官方提案文本为准。本文为机制科普，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。