账户抽象
ERC-4337 概述
ERC-4337 详细说明了如何在不更改协议级别(即区块链本身的规则)的情况下实现处理操作所需的逻辑。该规范定义了以下组件:
UserOperation
UserOperation
是一个更高层的伪交易对象,表示账户的意图。这与常规 EVM 交易有一些相似之处,例如 gasFees
(Gas 费用)或 callData
(调用数据)的概念,但包括了启用新功能的字段。
struct PackedUserOperation {
address sender;
uint256 nonce;
bytes initCode; // 工厂地址和工厂数据的串联(或为空)
bytes callData;
bytes32 accountGasLimits; // verificationGas (16 字节) 和 callGas (16 字节) 的串联
uint256 preVerificationGas;
bytes32 gasFees; // maxPriorityFee (16 字节) 和 maxFeePerGas (16 字节) 的串联
bytes paymasterAndData; // paymaster 字段的串联(或为空)
bytes signature;
}
捆绑用户操作的过程涉及捆绑者必须承担的多个成本,包括基本交易费用、calldata 序列化、EntryPoint 执行和 Paymaster 上下文成本。为了补偿这些开销,捆绑者使用 preVerificationGas
和 gasFees
字段来适当地向用户收费。
估算 preVerificationGas 未标准化,因为它因网络状况(如 Gas 价格和操作捆绑包的大小)而异。
|
使用 ERC4337Utils 来操作 UserOperation 结构和其他 ERC-4337 相关值。
|
Entrypoint
每个 UserOperation
都通过一个名为 EntryPoint
的合约执行。此合约是一个单例,部署在多个网络上的同一地址,尽管可以使用其他自定义实现。
EntryPoint 合约被帐户视为受信任的实体。
Bundlers
捆绑器是一种 offchain 基础设施,负责处理用户操作的替代内存池。捆绑器本身使用要执行并包含在块中的 UserOperations 数组调用 EntryPoint 合约的 handleOps
函数。
在此过程中,捆绑器支付执行交易的 Gas 费用,并在 EntryPoint 合约的执行阶段获得退款。
/// @dev 处理 `userOps`,`beneficiary` 接收在捆绑包执行期间收集的所有 Gas 费用。
function handleOps(
PackedUserOperation[] calldata ops,
address payable beneficiary
) external { ... }
Account Contract
账户合约是一个实现验证 ERC-4337 上下文中的 UserOperation
所需逻辑的智能合约。任何智能合约账户都应符合 IAccount
接口以验证操作。
interface IAccount {
function validateUserOp(PackedUserOperation calldata, bytes32, uint256) external returns (uint256 validationData);
}
同样,账户应该有一种方法来执行这些操作,方法是在其 fallback
上处理任意 calldata 或实现 IAccountExecute
接口:
interface IAccountExecute {
function executeUserOp(PackedUserOperation calldata userOp, bytes32 userOpHash) external;
}
IAccountExecute 接口是可选的。开发者可能想使用 ERC-7821 来获得最小的批量执行接口,或者依赖 ERC-7579 或任何其他执行逻辑。
|
要构建你自己的账户,请参阅 accounts。
Factory Contract
智能合约账户由账户开发者定义的 Factory 合约创建。此工厂接收任意字节作为 initData
,并返回部署账户逻辑的 address
。
要构建你自己的工厂,请参阅 account factories。
Paymaster Contract
Paymaster 是一种可选实体,可以赞助账户的 Gas 费用,或者允许他们以 ERC-20 代币而不是原生货币支付这些费用。这以与云服务器的计算成本从最终用户处抽象出来的方式相同的方式抽象了用户体验中的 Gas 费用。
要构建你自己的 Paymaster,请参阅 paymasters。
更多说明
ERC-7562 验证规则
为了处理 UserOperations
的捆绑包,捆绑器在每个操作发送者上调用 validateUserOp
以检查是否可以执行该操作。但是,捆绑器无法保证区块链的状态在验证阶段之后保持不变。为了克服这个问题,https://eips.ethereum.org/EIPS/eip-7562[ERC-7562] 提出了一组对 EVM 代码的限制,以便捆绑器(或节点运算符)免受意外状态更改的影响。
这些规则概述了通过规范内存池处理操作的要求。
账户可以在验证阶段访问其自身的存储,它们可能会以非直接的方式很容易地违反 ERC-7562 存储访问规则。例如,大多数账户在验证签名时从存储中访问其公钥,从而限制了拥有为其他账户验证操作的账户的能力(例如,通过 ERC-1271)。
尽管任何违反此类规则的账户仍然可以由私有捆绑器处理,但开发者应牢记依赖私有基础设施而不是 permissionless 执行的中心化权衡。 |