账户抽象 Bundler 架构揭秘：自主 Agent 如何在无原生 ETH 时完成 Gas 赞助与批量打包

账户抽象 Bundler 架构揭秘自主 Agent 如何在无原生 ETH 时完成 Gas 赞助与批量打包在构建去中心化多智能体系统Multi-Agent System时架构师最先撞上的墙往往不是大模型的推理能力而是以太坊底层原生代币对交易发起的物理封锁。在传统的 EOA 体系下任何一个新生的 Agent 想要在链上调用一次智能合约其地址中必须预先存有哪怕 0.01 个原生 ETH 用来支付矿工 Gas 费。试想一下如果你在云端动态拉起 100 个微型爬虫 Agent 或套利 Agent运维团队就必须写一个中心化的脚本从主钱包分批向这 100 个地址广播转账 ETH。一旦某个 Agent 的 ETH 用尽整个业务逻辑立刻由于insufficient funds for gas * price value报错瘫痪。更恶劣的是如果 Agent 赚取的是 USDC 稳定币它甚至无法直接拿自己赚来的 USDC 去付 Gas必须再经过一道繁琐的法币中转。彻底终结这一窘境的工业级方案正是ERC-4337 账户抽象中的打包器Bundler与代付合约Paymaster架构。一、ERC-4337 解耦 Gas 发起的底层拓扑ERC-4337 并没有修改以太坊的共识层而是通过在应用层构建一套平行的交易高速公路彻底打破了“发起者必须持有 ETH”的枷锁[自主 Agent] ──► 构造 UserOperation (无须持有 ETH可用 USDC 签名) │ ▼ 广播至专用的 UserOp 内存池 [Bundler 打包器] (垫付真实以太坊主网 ETH) │ ▼ 打包调用 entryPoint.handleOps() [EntryPoint 核心合约] │ ├─► [Paymaster 合约] (扣除 Agent 的 USDC或由项目方全额赞助) │ └─► [Agent 智能账户] ──► [执行业务 Target 合约]关键角色分工UserOperation用户操作一种包含了发送者、Nonce、调用数据、Gas 限额以及签名信息的高层伪交易结构体它在链下独立流转。Bundler打包器运行在全节点旁的独立服务。它从专用的 Alt-Mempool 中收集多个 Agent 提交的 UserOperations在本地执行沙盒模拟随后用自己的 EOA 账户将它们打包成一笔真正的以太坊交易统一向EntryPoint合约提交。Paymaster代付合约允许第三方实体如项目方国库为 Agent 的操作提供 100% 免费的 Gas 赞助或者在链上自动按照实时预言机汇率扣除 Agent 账户中的 ERC-20 代币来抵扣 Gas。二、代码实战可接受 ERC-20 支付的轻量 Paymaster 实现下面的 Solidity 源码实现了一个生产级代付合约它允许 Agent 在自身账户没有半毛钱 ETH 的情况下通过消耗 ERC-20 代币完成链上交易结算// SPDX-License-Identifier: MIT pragma solidity 0.8.28; import {IERC20} from openzeppelin/contracts/token/ERC20/IERC20.sol; import {SafeERC20} from openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol; interface IEntryPoint { function depositTo(address account) external payable; function balanceOf(address account) external view returns (uint256); } contract TokenPaymaster { using SafeERC20 for IERC20; address public immutable entryPoint; address public immutable owner; IERC20 public immutable paymentToken; // 如 USDC uint256 public tokenPriceEquivalent; // 1 ETH 等值多少 Token (由预言机喂价更新) modifier onlyEntryPoint() { require(msg.sender entryPoint, Only EntryPoint can call); _; } constructor(address _entryPoint, address _token, uint256 _initialPrice) { entryPoint _entryPoint; paymentToken IERC20(_token); tokenPriceEquivalent _initialPrice; owner msg.sender; } // 向 EntryPoint 质押原生 ETH用于替 Agent 垫付底层 Gas function depositGasReserve() external payable { IEntryPoint(entryPoint).depositTo{value: msg.value}(address(this)); } /** * EntryPoint 调用的第一阶段校验确认用户是否具备足够的代币余额以备扣除 */ function validatePaymasterUserOp( bytes32 userOpHash, uint256 maxCost ) external returns (bytes memory context, uint256 validationData) { // 解码出发起交易的 Agent 智能账户地址 address sender address(bytes20(userOpHash)); // 折算成所需的代币上限 uint256 tokenRequired (maxCost * tokenPriceEquivalent) / 1e18; require(paymentToken.balanceOf(sender) tokenRequired, Insufficient ERC20 balance for gas); // 验证通过将扣费上下文传给第二阶段 context abi.encode(sender, tokenRequired); validationData 0; // 0 表示校验成功且无时间锁限制 } /** * EntryPoint 调用的第二阶段结算交易执行完成后精确扣除实际消耗的代币 */ function postOp( uint8 mode, bytes calldata context, uint256 actualGasCost ) external onlyEntryPoint { (address sender, ) abi.decode(context, (address, uint256)); // 按照实际消耗的 Gas 精准折现代币金额 uint256 actualTokenCharge (actualGasCost * tokenPriceEquivalent) / 1e18; paymentToken.safeTransferFrom(sender, address(this), actualTokenCharge); } }三、链下 Agent 侧构造并签名 UserOperation在链下端Python Agent 无须管理复杂的 nonce 和 gasPrice 竞价只需组装 Payload 并使用 Session Key 进行离线签名后提交给 Bundler RPCimport json import requests from eth_account import Account from eth_account.messages import encode_defunct class AgentUserOpBuilder: def __init__(self, bundler_url: str, entry_point_addr: str, private_key: str): self.bundler_url bundler_url self.entry_point entry_point_addr self.account Account.from_key(private_key) def build_and_submit_multicall(self, smart_account: str, target_calls: list) - str: 组装批量原子调用如 approve swap stake打包为单笔 UserOp # 1. 组装 ExecuteBatch Calldata call_data self.encode_batch(target_calls) user_op { sender: smart_account, nonce: hex(self.fetch_account_nonce(smart_account)), initCode: 0x, callData: call_data, callGasLimit: hex(200000), verificationGasLimit: hex(150000), preVerificationGas: hex(50000), maxFeePerGas: hex(30 * 10**9), maxPriorityFeePerGas: hex(2 * 10**9), paymasterAndData: 0x, # 填写 Paymaster 地址与策略 signature: 0x } # 2. 计算 UserOpHash 并进行本地 ECDSA 签名 op_hash self.compute_op_hash(user_op) sig Account.sign_message(encode_defunct(primitiveop_hash), self.account.key) user_op[signature] sig.signature.hex() # 3. 提交给 Bundler 节点专用 RPC 端口 payload { jsonrpc: 2.0, id: 1, method: eth_sendUserOperation, params: [user_op, self.entry_point] } resp requests.post(self.bundler_url, jsonpayload, timeout10) return resp.json()[result]四、生产避坑与防御 EIP-7562 模拟截断在企业级部署 Bundler 架构时必须深刻理解并遵循EIP-7562 账户抽象存储访问验证规则验证阶段禁止读取不可预测的全局状态在validateUserOp执行期间为了防止恶意合约在模拟时通过、在上链时故意 revert 导致 Bundler 白白损失垫付的 GasEIP-7562 规定验证逻辑中严禁访问block.timestamp、严禁读取外部不可控合约的存储槽位。如果 Paymaster 试图在验证阶段动态查询 Uniswap 池子的汇率Bundler 会在链下模拟时直接拒绝打包该 UserOp。多操作原子合并优势以往用户在 DEX 交互需要先发一笔交易approve等出块后再发一笔swap。而在智能账户中Agent 可以通过executeBatch将“授权”与“兑换”合并进同一个 UserOp 中原子执行既节省了多余的基础 Gas又从根本上避免了授权成功后因网络拥堵导致交易断挂的尴尬。五、Paymaster 押金管理与链上经济可持续性在维持自主 Agent 长期无人值守运行的生命周期中Paymaster 本身的资本运转模型至关重要。为了防御恶意攻击者利用大量伪造的 UserOp 耗尽代付池余额生产级 Paymaster 合约必须实现如下多级约束机制EntryPoint 押金水位告警Paymaster 在 EntryPoint 合约中必须锁仓充足的 ETH 原生押金。一旦可用余额跌破警戒线链下自动化补仓机器人Rebalance Daemon会立即通过多签渠道补充流动性动态代币滑点抵扣与汇率缓冲若允许 Agent 以 ERC-20 代币如 USDC抵扣 GasPaymaster 在链下计算代付费用时必须加入 $5% \sim 10%$ 的预估安全溢价Overhead Buffer以抵抗去中心化交易所价格闪烁或交易打包延迟造成的利差倒挂单 Agent 配额速率限制Rate Limiting在合约层为每个注册的 Agent 钱包设定每小时/每日的最大 Gas 消耗上限防止 Agent 策略程序陷入死循环向全网广播海量无效操作。摆脱了原生代币的束缚自主 Agent 才能真正实现“即拉即跑、零钱自理”在分布式赛博网络中大步迈向大规模自主协同。