EIP-7701 原生账户抽象协议详解新交易类型与 CURRENT_ROLE / ACCEPT_ROLE / TXPARAM 操作码家族【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7701Native Account Abstraction提出将一笔以太坊交易的执行过程拆分为验证validation与执行execution等多个步骤frame并引入一种新的 EIP-2718 类型交易AA 交易以及CURRENT_ROLE、ACCEPT_ROLE、TXPARAM*三组新操作码让智能合约账户可以自定义交易的合法性校验与 gas 支付逻辑从而原生实现账户抽象。读完本文你将掌握 EIP-7701 的交易载荷编码格式、五类角色Role的生命周期、新操作码的语义与限制、完整的交易处理伪代码流程以及它作为设计原型与后续 EIP-8141Frame Transaction之间的演进关系。本文基于当前仓库中的 EIPS/eip-7701.md 与 assets/eip-7701/README.md 展开。该 EIP 目前状态为Withdrawn已撤回撤回原因是已被 EIP-8141 取代见 EIPS/eip-8141.md因此本文重点在于还原其完整的技术设计而非描述当前主网状态。一、协议概述把交易拆成验证 执行 后置操作EIP-7701 的核心思想可以用一句话概括把传统交易隐含的签名即授权流程替换为可编程的合约验证流程。提案的摘要明确指出将以太坊交易的执行范围拆分为多个步骤验证validations、执行execution与后置操作post-operation交易的有效性由交易的验证步骤结果决定——只有所有验证 frame 都成功交易才能被打包进区块进一步将授权authorization与gas 费用支付两件事分离允许一个合约Paymaster为一笔由另一个合约Sender执行的交易支付 gas。这样做的动机很直接原生账户抽象允许自定义交易验证逻辑与自定义 gas 支付逻辑为钱包与 dApp 打开新的用例——例如无 ECDSA 密钥的签名方案、社交恢复、批量操作、代付 gasSponsorship等。提案作者包括 Vitalik Buterin、Yoav Weiss、Alex Forshtat、Dror Tirosh、Shahaf Nacson创建于 2024-05-01。二、核心术语与角色定义在深入规范之前先明确 EIP-7701 使用的一套术语完整定义见 assets/eip-7701/README.md术语含义Smart Contract Account智能合约账户作为用户账户与链上身份的智能合约负责持有资产、验证用户请求并代表用户执行操作Sender发起当前 AA 交易的智能合约账户Paymaster被请求代表 Sender 为当前 AA 交易支付 gas 费用的智能合约Deployer在当前 AA 交易上下文中负责为新 Sender 合约执行部署如CREATE2的智能合约Entity上述 Sender / Paymaster / Deployer 的统称Transaction Validity交易有效性一笔交易能否在不违反执行与共识规则的前提下被打包进区块的性质它同时取决于交易输入与当前链上状态因此会随时间变化EIP-7701 Transaction由 Sender 发起、以 EIP-2718 兼容信封对象表示的一整笔交易Call Frame调用帧合约执行期间某次具体函数调用的上下文与状态包括入参、局部变量与执行环境Top-Level Call Frame交易访问合约时的初始执行上下文即 EVM 代码的入口点EIP-7701 Call FrameEVM 代码执行的单个原子元素即对某地址、以给定数据发起的一次顶层调用其内部还可能包含内层调用帧但内层帧不称为EIP-7701 Call Frame每个帧要么成功要么回滚Frames Role帧角色当前调用帧中被调用合约被要求执行的动作标识符一个 Entity 在交易流程中可能承担一个或多个角色Transaction Phase交易阶段一组 EIP-7701 Call Frame 构成交易流程中的单个步骤AA 交易包含**验证validation与执行execution**两个阶段Validation phase验证阶段通过执行验证 EVM 代码来定义当前交易有效性的帧集合Execution phase执行阶段根据 Sender 与 Paymaster 对用户输入的解释来执行动作的帧集合这些帧不决定交易的有效性其中Transaction Validity 随时间变化这一点非常重要同样一笔 AA 交易在当前状态下可能有效、在下一个区块状态变化后可能失效例如验证依赖的余额或授权状态发生改变这与传统基于 ECDSA 签名的静态有效性有本质区别。五类角色常量规范定义了一组与交易生命周期各步骤对应的角色常量名称值用途ROLE_SENDER_DEPLOYMENT0xA0Sender 部署帧可选每个账户只发生一次ROLE_SENDER_VALIDATION0xA1Sender 验证帧必需ROLE_PAYMASTER_VALIDATION0xA2Paymaster 验证帧可选ROLE_SENDER_EXECUTION0xA3Sender 执行帧必需ROLE_PAYMASTER_POST_OP0xA4Paymaster 后置操作帧可选三、新交易类型AA 交易AA_TX_TYPEEIP-7701 引入一种新的 EIP-2718 类型交易类型号为AA_TX_TYPE规范中标记为 TBD即尚未最终确定。按照 EIP-2718 的约定交易格式为TransactionType || TransactionPayload其中TransactionType是 0x00–0x7f 范围内的单字节类型标识payload 的解释权归该类型定义者所有。AA 交易的 payload 按如下结构 RLP 编码AA_TX_TYPE || rlp([ chain_id, nonce, sender, sender_validation_data, deployer, deployer_data, paymaster, paymaster_data, sender_execution_data, max_priority_fee_per_gas, max_fee_per_gas, sender_validation_gas, paymaster_validation_gas, sender_execution_gas, paymaster_post_op_gas, access_list, authorization_list ])逐字段解读chain_id链 ID用于防止跨链重放nonce与 EIP-1559 类型交易类似的重放保护计数sender/sender_validation_dataSender 地址及其自定义验证数据由 Sender 在验证帧中解释deployer/deployer_data可选的部署器地址与部署数据——当 Sender 尚不存在无代码时用于先部署账户paymaster/paymaster_data可选的代付方地址及其验证数据用于实现 gas 抽象Gas Abstractionsender_execution_data真正要执行的业务数据相当于传统交易的datamax_priority_fee_per_gas、max_fee_per_gas沿用 EIP-1559 的费用字段sender_validation_gas、paymaster_validation_gas、sender_execution_gas、paymaster_post_op_gas四个帧各自的 gas 上限access_listEIP-2930 风格的访问列表authorization_list授权列表可类比 EIP-7702 中的授权条目概念。可以看出这笔交易把谁是发送者、谁付钱、怎么验证、执行什么全部显式地编码在交易载荷中由协议层按固定流程驱动。四、CURRENT_ROLE与ACCEPT_ROLE操作码显式的角色生命周期上下文变量current_context_role规范引入一个上下文变量current_context_role由 AA 交易在执行时设置在 AA 交易期间对于每个顶层调用它被设置为该交易生命周期中当前所处的角色在非 AA 交易期间它始终为ROLE_SENDER_EXECUTION它在DELEGATECALL时保持不变但在CALL/STATICCALL/CALLCODE时被重置为ROLE_SENDER_EXECUTION——这个传播行为与msg.sender类似见 EIPS/eip-7701.md。配套文档进一步说明该角色值只对顶层帧以及通过不间断DELEGATECALL链建立的 Entity 上下文内层帧保持用其他操作码发起的调用帧一律以ROLE_SENDER_EXECUTION运行。CURRENT_ROLE操作码CURRENT_ROLE返回当前的current_context_role值供合约查询我正在以什么角色被调用。这是TXPARAM*之外另一条与交易类型相关的自省通道。ACCEPT_ROLE操作码授权与有效性闸门ACCEPT_ROLE在语义上等价于RETURN——它复制一段内存切片、结束当前执行并把该切片粘贴到父调用的 returndata 中——但有一处关键修改它额外接受一个输入参数frame_role如果该参数与current_context_role不一致则直接回滚。换句话说ACCEPT_ROLE是一个带角色校验的 RETURN合约只有在正确的角色上下文中显式声明我接受当前角色才能正常返回。交易生命周期中的每个角色都必须有一次成功的ACCEPT_ROLE其frame_role 当前角色只要任何一个验证帧没有执行与自身角色匹配的ACCEPT_ROLE交易就通不过有效性检查无法被打包。配套文档还给出了一条重要规则如果 Entity 代码执行结束时current_context_role尚未通过ACCEPT_ROLE显式接受则该 EIP-7701 Call Frame 回滚。因此一笔 AA 交易有效当且仅当对role_sender_deployment、role_sender_validation、role_paymaster_validation中的每一个角色同时满足顶层调用帧没有回滚在某个未回滚的帧中ACCEPT_ROLE至少被调用一次且传入的角色参数等于current_context_role。这套机制把交易是否被授权从静态签名校验变成了 EVM 内可编程、可审计的显式断言。五、TXPARAM*操作码家族交易参数的自省接口指令形态与参数标识符为了让验证合约能基于交易细节做出接受或拒绝的知情决策EIP-7701 新增TXPARAMDLOAD、TXPARAMSIZE、TXPARAMCOPY三个操作码它们遵循CALLDATA*/RETURNDATA*操作码家族的既有模式但每个指令都额外接受一个栈输入作为第一个参数参数标识符txparam_idn。参数标识符取值表n返回值数据大小默认值说明0x00当前交易类型320x01nonce320x02sender320x03sender_validation_data动态0x04deployer0 或 32address(0)0x05deployer_data动态空数组0x06paymaster0 或 32address(0)0x07paymaster_data动态空数组0x08sender_execution_data动态0x0Bmax_priority_fee_per_gas320x0Cmax_fee_per_gas320x0Dsender_validation_gas320x0Epaymaster_validation_gas3200x0Fsender_execution_gas320x10paymaster_post_op_gas3200x11access_list哈希320x12authorization_list哈希320xf1execution_status32交易作用域变量见处理流程0xf2execution_gas_used32交易作用域变量见处理流程0xfftx_hash_for_signature32不含签名的交易哈希可见验证合约可以读到交易的几乎所有关键字段Sender、Paymaster、四段 gas 上限、费用参数、访问列表与授权列表的哈希等其中deployer/paymaster在未提供时返回address(0)动态数据字段返回空数组gas 相关字段在未提供时返回0。0xff提供的不含签名的交易哈希可用于在 EVM 内实现自定义签名/授权方案例如验证基于非 ECDSA 曲线的签名。使用限制TXPARAM*操作码有严格的使用边界见 assets/eip-7701/README.md只在所有角色的顶层帧中可用在其他上下文调用时返回零值与零长度请求execution_status0xf1与execution_gas_used0xf2参数时只有role_paymaster_post_op角色的帧内才能读到有效值其余上下文返回零值合约可以通过CURRENT_ROLE来判断当前帧角色进而决定能否安全使用这些参数。六、受影响的全局变量与冷地址访问成本顶层帧中的全局变量语义在 AA 交易的所有顶层帧中传统全局变量的含义被重新定义操作码Solidity 对应值CALLERmsg.senderAA_ENTRY_POINT地址address(0x7701)ORIGINtx.origin交易的sender地址CALLDATA*msg.data除 Sender 执行帧外所有调用帧均为空Sender 执行帧中为sender_execution_data也就是说所有 Entity 帧看到的调用者都是固定的协议入口address(0x7701)而tx.origin始终指向 Sender 账户业务数据只在执行帧通过msg.data暴露。这与传统交易中ORIGIN CALLER 签名地址的行为形成鲜明对比配套文档对此有专门说明传统交易中两者都等于由 ECDSA 签名(yParity, r, s)确定的地址。冷地址预热与 2400 gas 附加成本Sender地址作为AA_BASE_GAS_COST15000的一部分被预预热pre-warmed避免重复支付冷访问成本当为Paymaster或Deployer提供非零且不等于 Sender 地址的地址时额外收取一次 EIP-2930 的ACCESS_LIST_ADDRESS_COST即2400 gas并将该地址加入accessed_addresses。其余协议常量汇总见 EIPS/eip-7701.md常量值AA_TX_TYPETBDAA_ENTRY_POINTaddress(0x7701)AA_BASE_GAS_COST15000七、AA 交易处理流程规范给出了完整的state_transition_function伪代码这是理解整套协议最直观的入口def state_transition_function(tx, block, state): # Empty refunds, warm list, execution status and gas used (new), etc state.transaction_scoped_vars {} max_gas tx.sender_validation_gas tx.paymaster_validation_gas tx.sender_execution_gas tx.paymaster_post_op_gas gas_price min(tx.max_fee_per_gas, block.base_fee_per_gas tx.max_priority_fee_per_gas) payer tx.sender if tx.paymaster is None else tx.paymaster total_max_cost max_gas * gas_price balances[payer] - total_max_cost gas_used 0 if get_code(tx.sender) is None: deployer_result call(tx.deployer, [], tx.sender_validation_gas_limit, ROLE_SENDER_DEPLOYMENT) assert deployer_result.accepted_role ROLE_SENDER_DEPLOYMENT gas_used deployer_result.gas_used sender_result call(tx.sender, [], tx.sender_validation_gas_limit - gas_used, ROLE_SENDER_VALIDATION) assert sender_result.accepted_role ROLE_SENDER_VALIDATION gas_used sender_result.gas_used if tx.paymaster: paymaster_result call(tx.paymaster, [], tx.paymaster_validation_gas, ROLE_PAYMASTER_VALIDATION) assert paymaster_result.accepted_role ROLE_PAYMASTER_VALIDATION gas_used paymaster_result.gas_used checkpoint state.take_snapshot() sender_execution_result call(tx.sender, [], tx.sender_execution_gas, ROLE_SENDER_EXECUTION) gas_used sender_execution_result.gas_used state.transaction_scoped_vars[execution_status] sender_execution_result.output_code state.transaction_scoped_vars[execution_gas_used] gas_used if tx.paymaster: postop_result call(tx.paymaster, [], tx.paymaster_post_op_gas, ROLE_PAYMASTER_POST_OP) gas_used postop_result.gas_used if postop_result.accepted_role ! ROLE_PAYMASTER_POST_OP: state.revert_snapshot(checkpoint) balances[payer] gas_price * (max_gas - gas_used)流程逐步拆解初始化清空退款、热地址列表、执行状态与已用 gas 等交易作用域变量。费用预扣max_gas是四段 gas 上限之和gas_price按 EIP-1559 规则取max_fee_per_gas与base_fee_per_gas max_priority_fee_per_gas的较小值付款方payer在有 Paymaster 时是 Paymaster否则是 Sender先从 payer 余额中预扣total_max_cost max_gas * gas_price。Sender 部署帧可选若get_code(tx.sender)为空账户尚不存在先以ROLE_SENDER_DEPLOYMENT角色调用 Deployer只有其accepted_role ROLE_SENDER_DEPLOYMENT断言通过才继续。Sender 验证帧必需以ROLE_SENDER_VALIDATION调用 Sender断言其接受了对应角色。注意 gas 上限用的是sender_validation_gas_limit - gas_used即扣除部署帧消耗后的剩余量。Paymaster 验证帧可选以ROLE_PAYMASTER_VALIDATION调用 Paymaster同样断言角色接受。快照与执行take_snapshot()建立检查点后以ROLE_SENDER_EXECUTION执行 Sender随后把execution_status执行帧的 output code与execution_gas_used写入交易作用域变量——这两个值正是TXPARAMLOAD0xf1 / 0xf2 的数据来源。Paymaster 后置操作帧可选以ROLE_PAYMASTER_POST_OP调用 Paymaster若该帧没有接受角色则revert_snapshot(checkpoint)连同 Sender 执行的改动一起回滚。结算退款最后把gas_price * (max_gas - gas_used)退回给 payer。完整的帧清单与两阶段划分综合规范与配套文档一笔 AA 交易可能产生的全部顶层帧为验证阶段Validation PhaseSender 部署帧可选每账户一次——role_sender_deployment0xA0Sender 验证帧必需——role_sender_validation0xA1Paymaster 验证帧可选——role_paymaster_validation0xA2执行阶段Execution PhaseSender 执行帧必需——role_sender_execution0xA3Paymaster 后置操作帧可选——role_paymaster_post_op0xA4验证阶段的所有帧必须全部成功且不回滚交易才被认为在区块的某个位置有效执行阶段含 postOp不参与有效性判定。Paymaster 后置操作帧的设计意图postOp 帧属于执行阶段而非验证阶段它为 Paymaster 提供三个能力详见配套文档 Rationale在 Sender 执行结果已知后完成自身的记账/退款结算强制执行后置条件确保 Sender 做了 Paymaster 预期的事如果 postOp 回滚Sender 执行的状态改动一并回滚用户得不到交易价值消除了利用 Paymaster 的动机Paymaster 虽然仍支付 gas 但阻止了不合规操作完成并能识别出违规 Sender、拒绝其后续交易。典型触发 postOp 回滚的场景包括用户没有完成 Paymaster 打算付费的特定动作用户在验证时提供的信息在 postOp 检查时被证实为虚假求解器solver未在 postOp 校验中正确履行某个意图intent。八、交易执行上下文跨帧的状态一致性将交易拆成多个帧并不意味着破坏 EVM 的交易作用域语义。配套文档明确指出以下依赖交易上下文的特性不受多帧拆分影响SSTORE (0x55)的 gas 成本按 EIP-2200冷地址与冷槽位的访问成本按 EIP-2929瞬态存储transient storage中可用的值按 EIP-1153执行后分配的最大 gas 退款额按 EIP-3529。例如某个帧中用TSTORE (0x5D)写入的值在下一个帧中依然可读。这一点保证了 Sender 验证帧与执行帧之间、以及 postOp 帧与执行帧之间可以共享状态是实现先验证后执行且整体记账一致性的基础。九、交易流程示意图以下两张示意图直接取自本仓库的配套文档 assets/eip-7701/README.md分别展示了最简流程与完整流程中AA_ENTRY_POINT与各 Entity 之间的调用与角色接受关系。简单流程中验证阶段仅包含 Sender 验证帧ACCEPT_ROLE 0xA1执行阶段包含 Sender 执行帧ACCEPT_ROLE 0xA3执行帧内部再向 Target Contract 发起业务调用。完整流程在此基础上叠加了可选的 Sender 部署Deployer 通过CREATE2部署 SenderACCEPT_ROLE 0xA0、Paymaster 验证ACCEPT_ROLE 0xA2与 Paymaster PostOpACCEPT_ROLE 0xA4。两张图的原始 PlantUML 源码分别位于 assets/eip-7701/simple_flow.md 与 assets/eip-7701/complete_flow.md。十、设计取舍Rationale为什么引入TXPARAM*而不是为每个字段单独造操作码智能合约账户的验证代码需要访问绝大多数交易细节才能做出接受/拒绝的知情决策。虽然CALLER (0x33)、GASPRICE (0x3A)等现有操作码能提供一小部分数据但为每个交易参数单独创建操作码既不现实也不可取。TXPARAM*家族以统一的txparam_id索引方式解决了这个问题。同时这些值不向交易的执行帧或传统交易类型开放。这一限制防止TXPARAM*成为新的全局可观测状态globally observable state来源从而避免未来出现向后兼容问题——执行代码不应能根据只读的交易参数产生分支依赖否则会增加重放与兼容风险。为什么 postOp 回滚要连带回滚主执行如第七节所述postOp 帧回滚时回滚 Sender 执行的整体改动本质上是让 Paymaster 的后置条件成为用户操作生效的硬约束用户无法在未满足条件的情况下白嫖交易结果Paymaster 也不会为不合规操作买单虽然仍承担 gas并能借此识别与封锁恶意 Sender。十一、向后兼容与安全考虑向后兼容EIP-7701 以全新的 EIP-2718 交易类型引入与传统交易legacy、EIP-1559 等在编码层天然隔离——类型字节落在[0x00, 0x7f]区间不会与以 0xc0开头的 RLP 传统交易冲突这是 EIP-2718 信封设计本身提供的保证见 EIPS/eip-2718.md。规范正文中该小节未展开额外细节。安全考虑ACCEPT_ROLE是一个通用的、代表合约授权任何操作的机制因此其实现正确性与安全性至关重要规范期望面向 EVM 的编译器在启用与保障智能合约账户安全性方面发挥主要作用——由编译器生成并约束ACCEPT_ROLE的使用降低手写汇编出错的可能对于智能合约安全审计人员与安全导向的开发工具关键是确保不打算在 AA 交易中扮演角色的合约不会意外包含ACCEPT_ROLE操作码否则这些合约可能构成直接的安全威胁——例如一个普通合约若在错误上下文里接受了角色可能被攻击者利用来放行未经授权的操作作为示例区块浏览器应当在合约源码中检测到ACCEPT_ROLE时将其标记为用户账户user account或paymaster帮助用户识别其语义。十二、协议演进从 EIP-7701 到 EIP-8141需要特别说明的是EIP-7701 的 front matter 明确标注status: Withdrawnwithdrawal-reason为 Superseded by EIP-8141。也就是说这份规范在当前仓库中是以历史提案的形式存在的。它的后继者 EIPS/eip-8141.mdFrame TransactionDraft 状态继承了把交易分解为验证、批准 gas 支付与执行标准用户操作的帧序列的核心理念并做了大量演进引入FRAME_TX_TYPE0x06、ENTRY_POINT address(0xaa)、FRAME_TX_INTRINSIC_COST 12000、FRAME_TX_PER_FRAME_COST 475等具体常量将帧的定义、签名方案含后量子方案与费用结构系统化。因此阅读 EIP-7701 的最佳方式是把它看作原生账户抽象这一设计方向的重要早期蓝图——它的角色模型、ACCEPT_ROLE授权机制与TXPARAM*自省接口为后续 frame 交易的设计奠定了概念基础。十三、总结EIP-7701 以一份交易类型 一族操作码的方式把账户抽象的三大诉求落到了协议层可编程验证通过ROLE_*角色 ACCEPT_ROLE显式授权替代固定 ECDSA 签名校验可编程付费通过可选的 Paymaster 角色帧实现他人代付 gas且 postOp 帧让代付方可执行后置约束可编程执行通过TXPARAM*让验证代码基于完整交易上下文做决策同时限制其在执行帧的可见性以规避可观测状态问题。对于钱包、dApp 与 Layer2 研究者而言EIPS/eip-7701.md 与 assets/eip-7701/README.md 是理解原生账户抽象设计空间的第一手资料而 EIPS/eip-8141.md 则展示了这一设计后续的成熟形态。文中涉及的伪代码、常量表与参数表均可直接对照规范原文验证未做任何推测性改写。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
EIP-7701 原生账户抽象协议详解：新交易类型与 CURRENT_ROLE / ACCEPT_ROLE / TXPARAM 操作码家族
EIP-7701 原生账户抽象协议详解新交易类型与 CURRENT_ROLE / ACCEPT_ROLE / TXPARAM 操作码家族【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7701Native Account Abstraction提出将一笔以太坊交易的执行过程拆分为验证validation与执行execution等多个步骤frame并引入一种新的 EIP-2718 类型交易AA 交易以及CURRENT_ROLE、ACCEPT_ROLE、TXPARAM*三组新操作码让智能合约账户可以自定义交易的合法性校验与 gas 支付逻辑从而原生实现账户抽象。读完本文你将掌握 EIP-7701 的交易载荷编码格式、五类角色Role的生命周期、新操作码的语义与限制、完整的交易处理伪代码流程以及它作为设计原型与后续 EIP-8141Frame Transaction之间的演进关系。本文基于当前仓库中的 EIPS/eip-7701.md 与 assets/eip-7701/README.md 展开。该 EIP 目前状态为Withdrawn已撤回撤回原因是已被 EIP-8141 取代见 EIPS/eip-8141.md因此本文重点在于还原其完整的技术设计而非描述当前主网状态。一、协议概述把交易拆成验证 执行 后置操作EIP-7701 的核心思想可以用一句话概括把传统交易隐含的签名即授权流程替换为可编程的合约验证流程。提案的摘要明确指出将以太坊交易的执行范围拆分为多个步骤验证validations、执行execution与后置操作post-operation交易的有效性由交易的验证步骤结果决定——只有所有验证 frame 都成功交易才能被打包进区块进一步将授权authorization与gas 费用支付两件事分离允许一个合约Paymaster为一笔由另一个合约Sender执行的交易支付 gas。这样做的动机很直接原生账户抽象允许自定义交易验证逻辑与自定义 gas 支付逻辑为钱包与 dApp 打开新的用例——例如无 ECDSA 密钥的签名方案、社交恢复、批量操作、代付 gasSponsorship等。提案作者包括 Vitalik Buterin、Yoav Weiss、Alex Forshtat、Dror Tirosh、Shahaf Nacson创建于 2024-05-01。二、核心术语与角色定义在深入规范之前先明确 EIP-7701 使用的一套术语完整定义见 assets/eip-7701/README.md术语含义Smart Contract Account智能合约账户作为用户账户与链上身份的智能合约负责持有资产、验证用户请求并代表用户执行操作Sender发起当前 AA 交易的智能合约账户Paymaster被请求代表 Sender 为当前 AA 交易支付 gas 费用的智能合约Deployer在当前 AA 交易上下文中负责为新 Sender 合约执行部署如CREATE2的智能合约Entity上述 Sender / Paymaster / Deployer 的统称Transaction Validity交易有效性一笔交易能否在不违反执行与共识规则的前提下被打包进区块的性质它同时取决于交易输入与当前链上状态因此会随时间变化EIP-7701 Transaction由 Sender 发起、以 EIP-2718 兼容信封对象表示的一整笔交易Call Frame调用帧合约执行期间某次具体函数调用的上下文与状态包括入参、局部变量与执行环境Top-Level Call Frame交易访问合约时的初始执行上下文即 EVM 代码的入口点EIP-7701 Call FrameEVM 代码执行的单个原子元素即对某地址、以给定数据发起的一次顶层调用其内部还可能包含内层调用帧但内层帧不称为EIP-7701 Call Frame每个帧要么成功要么回滚Frames Role帧角色当前调用帧中被调用合约被要求执行的动作标识符一个 Entity 在交易流程中可能承担一个或多个角色Transaction Phase交易阶段一组 EIP-7701 Call Frame 构成交易流程中的单个步骤AA 交易包含**验证validation与执行execution**两个阶段Validation phase验证阶段通过执行验证 EVM 代码来定义当前交易有效性的帧集合Execution phase执行阶段根据 Sender 与 Paymaster 对用户输入的解释来执行动作的帧集合这些帧不决定交易的有效性其中Transaction Validity 随时间变化这一点非常重要同样一笔 AA 交易在当前状态下可能有效、在下一个区块状态变化后可能失效例如验证依赖的余额或授权状态发生改变这与传统基于 ECDSA 签名的静态有效性有本质区别。五类角色常量规范定义了一组与交易生命周期各步骤对应的角色常量名称值用途ROLE_SENDER_DEPLOYMENT0xA0Sender 部署帧可选每个账户只发生一次ROLE_SENDER_VALIDATION0xA1Sender 验证帧必需ROLE_PAYMASTER_VALIDATION0xA2Paymaster 验证帧可选ROLE_SENDER_EXECUTION0xA3Sender 执行帧必需ROLE_PAYMASTER_POST_OP0xA4Paymaster 后置操作帧可选三、新交易类型AA 交易AA_TX_TYPEEIP-7701 引入一种新的 EIP-2718 类型交易类型号为AA_TX_TYPE规范中标记为 TBD即尚未最终确定。按照 EIP-2718 的约定交易格式为TransactionType || TransactionPayload其中TransactionType是 0x00–0x7f 范围内的单字节类型标识payload 的解释权归该类型定义者所有。AA 交易的 payload 按如下结构 RLP 编码AA_TX_TYPE || rlp([ chain_id, nonce, sender, sender_validation_data, deployer, deployer_data, paymaster, paymaster_data, sender_execution_data, max_priority_fee_per_gas, max_fee_per_gas, sender_validation_gas, paymaster_validation_gas, sender_execution_gas, paymaster_post_op_gas, access_list, authorization_list ])逐字段解读chain_id链 ID用于防止跨链重放nonce与 EIP-1559 类型交易类似的重放保护计数sender/sender_validation_dataSender 地址及其自定义验证数据由 Sender 在验证帧中解释deployer/deployer_data可选的部署器地址与部署数据——当 Sender 尚不存在无代码时用于先部署账户paymaster/paymaster_data可选的代付方地址及其验证数据用于实现 gas 抽象Gas Abstractionsender_execution_data真正要执行的业务数据相当于传统交易的datamax_priority_fee_per_gas、max_fee_per_gas沿用 EIP-1559 的费用字段sender_validation_gas、paymaster_validation_gas、sender_execution_gas、paymaster_post_op_gas四个帧各自的 gas 上限access_listEIP-2930 风格的访问列表authorization_list授权列表可类比 EIP-7702 中的授权条目概念。可以看出这笔交易把谁是发送者、谁付钱、怎么验证、执行什么全部显式地编码在交易载荷中由协议层按固定流程驱动。四、CURRENT_ROLE与ACCEPT_ROLE操作码显式的角色生命周期上下文变量current_context_role规范引入一个上下文变量current_context_role由 AA 交易在执行时设置在 AA 交易期间对于每个顶层调用它被设置为该交易生命周期中当前所处的角色在非 AA 交易期间它始终为ROLE_SENDER_EXECUTION它在DELEGATECALL时保持不变但在CALL/STATICCALL/CALLCODE时被重置为ROLE_SENDER_EXECUTION——这个传播行为与msg.sender类似见 EIPS/eip-7701.md。配套文档进一步说明该角色值只对顶层帧以及通过不间断DELEGATECALL链建立的 Entity 上下文内层帧保持用其他操作码发起的调用帧一律以ROLE_SENDER_EXECUTION运行。CURRENT_ROLE操作码CURRENT_ROLE返回当前的current_context_role值供合约查询我正在以什么角色被调用。这是TXPARAM*之外另一条与交易类型相关的自省通道。ACCEPT_ROLE操作码授权与有效性闸门ACCEPT_ROLE在语义上等价于RETURN——它复制一段内存切片、结束当前执行并把该切片粘贴到父调用的 returndata 中——但有一处关键修改它额外接受一个输入参数frame_role如果该参数与current_context_role不一致则直接回滚。换句话说ACCEPT_ROLE是一个带角色校验的 RETURN合约只有在正确的角色上下文中显式声明我接受当前角色才能正常返回。交易生命周期中的每个角色都必须有一次成功的ACCEPT_ROLE其frame_role 当前角色只要任何一个验证帧没有执行与自身角色匹配的ACCEPT_ROLE交易就通不过有效性检查无法被打包。配套文档还给出了一条重要规则如果 Entity 代码执行结束时current_context_role尚未通过ACCEPT_ROLE显式接受则该 EIP-7701 Call Frame 回滚。因此一笔 AA 交易有效当且仅当对role_sender_deployment、role_sender_validation、role_paymaster_validation中的每一个角色同时满足顶层调用帧没有回滚在某个未回滚的帧中ACCEPT_ROLE至少被调用一次且传入的角色参数等于current_context_role。这套机制把交易是否被授权从静态签名校验变成了 EVM 内可编程、可审计的显式断言。五、TXPARAM*操作码家族交易参数的自省接口指令形态与参数标识符为了让验证合约能基于交易细节做出接受或拒绝的知情决策EIP-7701 新增TXPARAMDLOAD、TXPARAMSIZE、TXPARAMCOPY三个操作码它们遵循CALLDATA*/RETURNDATA*操作码家族的既有模式但每个指令都额外接受一个栈输入作为第一个参数参数标识符txparam_idn。参数标识符取值表n返回值数据大小默认值说明0x00当前交易类型320x01nonce320x02sender320x03sender_validation_data动态0x04deployer0 或 32address(0)0x05deployer_data动态空数组0x06paymaster0 或 32address(0)0x07paymaster_data动态空数组0x08sender_execution_data动态0x0Bmax_priority_fee_per_gas320x0Cmax_fee_per_gas320x0Dsender_validation_gas320x0Epaymaster_validation_gas3200x0Fsender_execution_gas320x10paymaster_post_op_gas3200x11access_list哈希320x12authorization_list哈希320xf1execution_status32交易作用域变量见处理流程0xf2execution_gas_used32交易作用域变量见处理流程0xfftx_hash_for_signature32不含签名的交易哈希可见验证合约可以读到交易的几乎所有关键字段Sender、Paymaster、四段 gas 上限、费用参数、访问列表与授权列表的哈希等其中deployer/paymaster在未提供时返回address(0)动态数据字段返回空数组gas 相关字段在未提供时返回0。0xff提供的不含签名的交易哈希可用于在 EVM 内实现自定义签名/授权方案例如验证基于非 ECDSA 曲线的签名。使用限制TXPARAM*操作码有严格的使用边界见 assets/eip-7701/README.md只在所有角色的顶层帧中可用在其他上下文调用时返回零值与零长度请求execution_status0xf1与execution_gas_used0xf2参数时只有role_paymaster_post_op角色的帧内才能读到有效值其余上下文返回零值合约可以通过CURRENT_ROLE来判断当前帧角色进而决定能否安全使用这些参数。六、受影响的全局变量与冷地址访问成本顶层帧中的全局变量语义在 AA 交易的所有顶层帧中传统全局变量的含义被重新定义操作码Solidity 对应值CALLERmsg.senderAA_ENTRY_POINT地址address(0x7701)ORIGINtx.origin交易的sender地址CALLDATA*msg.data除 Sender 执行帧外所有调用帧均为空Sender 执行帧中为sender_execution_data也就是说所有 Entity 帧看到的调用者都是固定的协议入口address(0x7701)而tx.origin始终指向 Sender 账户业务数据只在执行帧通过msg.data暴露。这与传统交易中ORIGIN CALLER 签名地址的行为形成鲜明对比配套文档对此有专门说明传统交易中两者都等于由 ECDSA 签名(yParity, r, s)确定的地址。冷地址预热与 2400 gas 附加成本Sender地址作为AA_BASE_GAS_COST15000的一部分被预预热pre-warmed避免重复支付冷访问成本当为Paymaster或Deployer提供非零且不等于 Sender 地址的地址时额外收取一次 EIP-2930 的ACCESS_LIST_ADDRESS_COST即2400 gas并将该地址加入accessed_addresses。其余协议常量汇总见 EIPS/eip-7701.md常量值AA_TX_TYPETBDAA_ENTRY_POINTaddress(0x7701)AA_BASE_GAS_COST15000七、AA 交易处理流程规范给出了完整的state_transition_function伪代码这是理解整套协议最直观的入口def state_transition_function(tx, block, state): # Empty refunds, warm list, execution status and gas used (new), etc state.transaction_scoped_vars {} max_gas tx.sender_validation_gas tx.paymaster_validation_gas tx.sender_execution_gas tx.paymaster_post_op_gas gas_price min(tx.max_fee_per_gas, block.base_fee_per_gas tx.max_priority_fee_per_gas) payer tx.sender if tx.paymaster is None else tx.paymaster total_max_cost max_gas * gas_price balances[payer] - total_max_cost gas_used 0 if get_code(tx.sender) is None: deployer_result call(tx.deployer, [], tx.sender_validation_gas_limit, ROLE_SENDER_DEPLOYMENT) assert deployer_result.accepted_role ROLE_SENDER_DEPLOYMENT gas_used deployer_result.gas_used sender_result call(tx.sender, [], tx.sender_validation_gas_limit - gas_used, ROLE_SENDER_VALIDATION) assert sender_result.accepted_role ROLE_SENDER_VALIDATION gas_used sender_result.gas_used if tx.paymaster: paymaster_result call(tx.paymaster, [], tx.paymaster_validation_gas, ROLE_PAYMASTER_VALIDATION) assert paymaster_result.accepted_role ROLE_PAYMASTER_VALIDATION gas_used paymaster_result.gas_used checkpoint state.take_snapshot() sender_execution_result call(tx.sender, [], tx.sender_execution_gas, ROLE_SENDER_EXECUTION) gas_used sender_execution_result.gas_used state.transaction_scoped_vars[execution_status] sender_execution_result.output_code state.transaction_scoped_vars[execution_gas_used] gas_used if tx.paymaster: postop_result call(tx.paymaster, [], tx.paymaster_post_op_gas, ROLE_PAYMASTER_POST_OP) gas_used postop_result.gas_used if postop_result.accepted_role ! ROLE_PAYMASTER_POST_OP: state.revert_snapshot(checkpoint) balances[payer] gas_price * (max_gas - gas_used)流程逐步拆解初始化清空退款、热地址列表、执行状态与已用 gas 等交易作用域变量。费用预扣max_gas是四段 gas 上限之和gas_price按 EIP-1559 规则取max_fee_per_gas与base_fee_per_gas max_priority_fee_per_gas的较小值付款方payer在有 Paymaster 时是 Paymaster否则是 Sender先从 payer 余额中预扣total_max_cost max_gas * gas_price。Sender 部署帧可选若get_code(tx.sender)为空账户尚不存在先以ROLE_SENDER_DEPLOYMENT角色调用 Deployer只有其accepted_role ROLE_SENDER_DEPLOYMENT断言通过才继续。Sender 验证帧必需以ROLE_SENDER_VALIDATION调用 Sender断言其接受了对应角色。注意 gas 上限用的是sender_validation_gas_limit - gas_used即扣除部署帧消耗后的剩余量。Paymaster 验证帧可选以ROLE_PAYMASTER_VALIDATION调用 Paymaster同样断言角色接受。快照与执行take_snapshot()建立检查点后以ROLE_SENDER_EXECUTION执行 Sender随后把execution_status执行帧的 output code与execution_gas_used写入交易作用域变量——这两个值正是TXPARAMLOAD0xf1 / 0xf2 的数据来源。Paymaster 后置操作帧可选以ROLE_PAYMASTER_POST_OP调用 Paymaster若该帧没有接受角色则revert_snapshot(checkpoint)连同 Sender 执行的改动一起回滚。结算退款最后把gas_price * (max_gas - gas_used)退回给 payer。完整的帧清单与两阶段划分综合规范与配套文档一笔 AA 交易可能产生的全部顶层帧为验证阶段Validation PhaseSender 部署帧可选每账户一次——role_sender_deployment0xA0Sender 验证帧必需——role_sender_validation0xA1Paymaster 验证帧可选——role_paymaster_validation0xA2执行阶段Execution PhaseSender 执行帧必需——role_sender_execution0xA3Paymaster 后置操作帧可选——role_paymaster_post_op0xA4验证阶段的所有帧必须全部成功且不回滚交易才被认为在区块的某个位置有效执行阶段含 postOp不参与有效性判定。Paymaster 后置操作帧的设计意图postOp 帧属于执行阶段而非验证阶段它为 Paymaster 提供三个能力详见配套文档 Rationale在 Sender 执行结果已知后完成自身的记账/退款结算强制执行后置条件确保 Sender 做了 Paymaster 预期的事如果 postOp 回滚Sender 执行的状态改动一并回滚用户得不到交易价值消除了利用 Paymaster 的动机Paymaster 虽然仍支付 gas 但阻止了不合规操作完成并能识别出违规 Sender、拒绝其后续交易。典型触发 postOp 回滚的场景包括用户没有完成 Paymaster 打算付费的特定动作用户在验证时提供的信息在 postOp 检查时被证实为虚假求解器solver未在 postOp 校验中正确履行某个意图intent。八、交易执行上下文跨帧的状态一致性将交易拆成多个帧并不意味着破坏 EVM 的交易作用域语义。配套文档明确指出以下依赖交易上下文的特性不受多帧拆分影响SSTORE (0x55)的 gas 成本按 EIP-2200冷地址与冷槽位的访问成本按 EIP-2929瞬态存储transient storage中可用的值按 EIP-1153执行后分配的最大 gas 退款额按 EIP-3529。例如某个帧中用TSTORE (0x5D)写入的值在下一个帧中依然可读。这一点保证了 Sender 验证帧与执行帧之间、以及 postOp 帧与执行帧之间可以共享状态是实现先验证后执行且整体记账一致性的基础。九、交易流程示意图以下两张示意图直接取自本仓库的配套文档 assets/eip-7701/README.md分别展示了最简流程与完整流程中AA_ENTRY_POINT与各 Entity 之间的调用与角色接受关系。简单流程中验证阶段仅包含 Sender 验证帧ACCEPT_ROLE 0xA1执行阶段包含 Sender 执行帧ACCEPT_ROLE 0xA3执行帧内部再向 Target Contract 发起业务调用。完整流程在此基础上叠加了可选的 Sender 部署Deployer 通过CREATE2部署 SenderACCEPT_ROLE 0xA0、Paymaster 验证ACCEPT_ROLE 0xA2与 Paymaster PostOpACCEPT_ROLE 0xA4。两张图的原始 PlantUML 源码分别位于 assets/eip-7701/simple_flow.md 与 assets/eip-7701/complete_flow.md。十、设计取舍Rationale为什么引入TXPARAM*而不是为每个字段单独造操作码智能合约账户的验证代码需要访问绝大多数交易细节才能做出接受/拒绝的知情决策。虽然CALLER (0x33)、GASPRICE (0x3A)等现有操作码能提供一小部分数据但为每个交易参数单独创建操作码既不现实也不可取。TXPARAM*家族以统一的txparam_id索引方式解决了这个问题。同时这些值不向交易的执行帧或传统交易类型开放。这一限制防止TXPARAM*成为新的全局可观测状态globally observable state来源从而避免未来出现向后兼容问题——执行代码不应能根据只读的交易参数产生分支依赖否则会增加重放与兼容风险。为什么 postOp 回滚要连带回滚主执行如第七节所述postOp 帧回滚时回滚 Sender 执行的整体改动本质上是让 Paymaster 的后置条件成为用户操作生效的硬约束用户无法在未满足条件的情况下白嫖交易结果Paymaster 也不会为不合规操作买单虽然仍承担 gas并能借此识别与封锁恶意 Sender。十一、向后兼容与安全考虑向后兼容EIP-7701 以全新的 EIP-2718 交易类型引入与传统交易legacy、EIP-1559 等在编码层天然隔离——类型字节落在[0x00, 0x7f]区间不会与以 0xc0开头的 RLP 传统交易冲突这是 EIP-2718 信封设计本身提供的保证见 EIPS/eip-2718.md。规范正文中该小节未展开额外细节。安全考虑ACCEPT_ROLE是一个通用的、代表合约授权任何操作的机制因此其实现正确性与安全性至关重要规范期望面向 EVM 的编译器在启用与保障智能合约账户安全性方面发挥主要作用——由编译器生成并约束ACCEPT_ROLE的使用降低手写汇编出错的可能对于智能合约安全审计人员与安全导向的开发工具关键是确保不打算在 AA 交易中扮演角色的合约不会意外包含ACCEPT_ROLE操作码否则这些合约可能构成直接的安全威胁——例如一个普通合约若在错误上下文里接受了角色可能被攻击者利用来放行未经授权的操作作为示例区块浏览器应当在合约源码中检测到ACCEPT_ROLE时将其标记为用户账户user account或paymaster帮助用户识别其语义。十二、协议演进从 EIP-7701 到 EIP-8141需要特别说明的是EIP-7701 的 front matter 明确标注status: Withdrawnwithdrawal-reason为 Superseded by EIP-8141。也就是说这份规范在当前仓库中是以历史提案的形式存在的。它的后继者 EIPS/eip-8141.mdFrame TransactionDraft 状态继承了把交易分解为验证、批准 gas 支付与执行标准用户操作的帧序列的核心理念并做了大量演进引入FRAME_TX_TYPE0x06、ENTRY_POINT address(0xaa)、FRAME_TX_INTRINSIC_COST 12000、FRAME_TX_PER_FRAME_COST 475等具体常量将帧的定义、签名方案含后量子方案与费用结构系统化。因此阅读 EIP-7701 的最佳方式是把它看作原生账户抽象这一设计方向的重要早期蓝图——它的角色模型、ACCEPT_ROLE授权机制与TXPARAM*自省接口为后续 frame 交易的设计奠定了概念基础。十三、总结EIP-7701 以一份交易类型 一族操作码的方式把账户抽象的三大诉求落到了协议层可编程验证通过ROLE_*角色 ACCEPT_ROLE显式授权替代固定 ECDSA 签名校验可编程付费通过可选的 Paymaster 角色帧实现他人代付 gas且 postOp 帧让代付方可执行后置约束可编程执行通过TXPARAM*让验证代码基于完整交易上下文做决策同时限制其在执行帧的可见性以规避可观测状态问题。对于钱包、dApp 与 Layer2 研究者而言EIPS/eip-7701.md 与 assets/eip-7701/README.md 是理解原生账户抽象设计空间的第一手资料而 EIPS/eip-8141.md 则展示了这一设计后续的成熟形态。文中涉及的伪代码、常量表与参数表均可直接对照规范原文验证未做任何推测性改写。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
