账户抽象 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 RPC：

import 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(primitive=op_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, json=payload, timeout=10) return resp.json()["result"]

四、生产避坑与防御 EIP-7562 模拟截断

在企业级部署 Bundler 架构时，必须深刻理解并遵循EIP-7562 账户抽象存储访问验证规则：

验证阶段禁止读取不可预测的全局状态：在validateUserOp执行期间，为了防止恶意合约在模拟时通过、在上链时故意 revert 导致 Bundler 白白损失垫付的 Gas，EIP-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）抵扣 Gas，Paymaster 在链下计算代付费用时必须加入 $5% \sim 10%$ 的预估安全溢价（Overhead Buffer），以抵抗去中心化交易所价格闪烁或交易打包延迟造成的利差倒挂；
单 Agent 配额速率限制（Rate Limiting）：在合约层为每个注册的 Agent 钱包设定每小时/每日的最大 Gas 消耗上限，防止 Agent 策略程序陷入死循环向全网广播海量无效操作。

摆脱了原生代币的束缚，自主 Agent 才能真正实现“即拉即跑、零钱自理”，在分布式赛博网络中大步迈向大规模自主协同。