帧交易的审批分四档：ERC-8286 让 7579 模块直通 EIP-8141

2026 年 1 月，以太坊核心层出现了一份受关注的新提案 EIP-8141”帧交易”：一笔交易被拆成一串叫 frame 的片段，验证、gas 支付、执行各自成帧，账户逻辑从此可以由协议原生承载。而 7 月登记的 ERC-8286 回答了一个紧跟其后的问题——已经按验证器之外的六种模块：ERC-7780 给智能账户补上策略与签名两类闸里那套 ERC-7579 模块化标准装好插件的账户，切换到帧交易时要不要重写模块？它的答案是”不用重写”，代价是给验证结果定义了一张四格审批表。两份文件目前都标注为草案（Draft），下面讲清这张表和它对钱包用户意味着什么。

一张四格的审批表

ERC-8286 把”验证结论”标准化为一个 uint8 的 approval mode（审批模式），它的取值直接复用 EIP-8141 里 APPROVE 指令的 scope 操作数：0x0 是 APPROVE_NONE，什么都不批；0x1 是 APPROVE_PAYMENT，只批准这笔交易的手续费支付；0x2 是 APPROVE_EXECUTION，只批准执行动作；0x3 是 APPROVE_EXECUTION_AND_PAYMENT，两者都批。掩码 APPROVE_SCOPE_MASK 为 0x3，一个帧允许的最宽范围由帧标志位与掩码相与得出。场景化的读法：你给某个自动化服务开了”只能代付、不能动钱”的权限，它对应的就是 0x1 这一格——验证器认出请求来自合法会话，但把执行大门留着。

验证怎么发生：VERIFY 帧里的问答

流程上，当账户代码在 VERIFY 帧中执行时，账户挑选一个帧验证器（frame validator）发起质询；验证器返回审批模式，账户据此执行 APPROVE。规范写死了三条硬规则：其一，账户不得批准超出当前 VERIFY 帧允许范围的模式；其二，APPROVE_EXECUTION 只在帧的解析目标恰好是交易发送方自身时有效——想去驱动另一个地址的资产，这一格不该亮；其三，验证不通过时账户不得调用 APPROVE，模式停在 APPROVE_NONE，整笔交易作废。此外账户必须通过 supportsApprovalMode 对外声明自己支持哪些模式，且不得批准自己声明不支持的模式。

从”验没验过”到”验到了哪一档”

对用户，这套表格带来的实质变化是：智能账户的验证从二值判断变成有刻度的结论。过去问”这次操作合法吗”，现在问”这次操作合法到哪一档”——一个只验证了会话密钥有效性的模块，和一个确认了完整转账指令的模块，给出的是不同的格。这给钱包界面提供了更细的展示空间：弹窗若能标注本次动用的是哪一档，你核对的就不再是”要不要签名”，而是”这一档和我的本意是否相配”。批量与自动场景里，这个刻度也解释了为什么有些操作只需确认一次支付、有些必须逐笔确认执行，与 ERC-7579 模块生态的关系见一次确认办完一串操作：ERC-7638 智能账户批量调用的编码与原子性。

怎么查一款账户支持到哪

规范给了直接入口：对合约调用 supportsApprovalMode，问某档支持不支持；结合模块安装清单看它挂了哪些帧验证器。要注意的是，这四档说的是”支付与执行”两个维度的组合，不等于安全强度分级——0x3 全批的交易并不自动比 0x1 危险，关键还是验证器凭什么给出这一档。

为什么要拆成帧：一句话背景

没有帧交易之前，智能账户的验证逻辑要塞进 validateUserOp 这类固定钩子里，签名算法、gas 支付方式都被 4337 的框架约束。EIP-8141 的思路是把一笔交易拆成若干帧——每帧是一次合约调用，先验证、再批准支付、最后执行，于是验证可以用任意算法（包括抗量子的新体系），账户也不再有固定的密钥形状，密钥轮换成为协议原生能力。这套设计还顺带批量处理、替代中心化转发人付费等目标。理解了这个背景，才会明白 ERC-8286 为什么必须存在：帧与帧之间，“验证通过”不再是布尔值，而是一个必须精确到”批准哪几帧动什么”的结论——四格审批表就是为这个接缝准备的。