Infinitism
Published in

Infinitism

ERC 4337: account abstraction without Ethereum protocol changes

  • Multisigs and social recovery
  • More efficient and simpler signature algorithms (eg. Schnorr, BLS)
  • Post-quantum safe signature algorithms (eg. Lamport, Winternitz)
  • Upgradeability

How does this proposal work?

  • sender: the wallet making the operation
  • nonce and signature: parameters passed into the wallet’s verification function so the wallet can verify an operation
  • initCode: the init code to create the wallet with if the wallet does not exist yet
  • callData: what data to call the wallet with for the actual execution step
  • validateUserOp, which takes a UserOperation as input. This function is supposed to verify the signature and nonce on the UserOperation, pay the fee and increment the nonce if verification succeeds, and throw an exception if verification fails.
  • An op execution function, that interprets calldata as an instruction for the wallet to take actions. How this function interprets the calldata and what it does as a result is completely open-ended; but we expect most common behavior would be to parse the calldata as an instruction for the wallet to make one or more calls.

What properties does this design add, maintain and sacrifice compared to the regular Ethereum transaction mempool?

  • No centralized actors; everything is done through a peer-to-peer mempool
  • DoS safety (a UserOperation that passes simulation checks is guaranteed to be includable until the sender has another state change, which would require the attacker to pay 7500+ gas per sender)
  • No user-side wallet setup complexity: users do not have to care about whether or not their wallet contract has been “already published”; wallets exist at deterministic CREATE2 addresses, and if a wallet does not yet exist the first UserOperation creates it automatically
  • Full EIP 1559 support, including fee-setting simplicity (users can set a fixed fee premium and a high max total fee, and expect to be included quickly and charged fairly)
  • Ability to replace-by-fee, sending a new UserOperation with a significantly higher premium than the old one to replace the operation or get it included faster
  • Verification logic flexibility: the validateUserOp function can add arbitrary signature and nonce verification logic (new signature schemes, multisig…)
  • Sufficient to make the execution layer quantum-safe: if this proposal gets universally adopted, no further work on the execution layer needs to be done for quantum-safety. Users can individually upgrade their wallets to quantum-safe ones. Even the wrapper transaction is safe, as the miner can use a new freshly created and hence hash-protected EOA for each bundle transaction and not publish the transaction before it is added in a block.
  • Wallet upgradeability: wallet verification logic can be stateful, so wallets can change their public keys or (if published with DELEGATECALL) upgrade their code entirely.
  • Execution logic flexibility: wallets can add custom logic for the execution step, eg. making atomic multi-operations (a key goal of EIP 3074)
  • Slightly increased DoS vulnerability despite the protocol’s best effort, simply because verification logic is allowed to be somewhat more complex than the status quo of a single ECDSA verification.
  • Gas overhead: somewhat more gas overhead than regular transactions (though made up for in some use cases by multi-operation support).
  • One transaction at a time: accounts cannot queue up and send multiple transactions into the mempool. However, the ability to do atomic multi-operations makes this feature much less necessary.

Sponsorship with paymasters

  1. Allowing application developers to pay fees on behalf of their users
  2. Allowing users to pay fees in ERC20 tokens, with a contract serving as an intermediary to collect the ERC20s and pay in ETH
  • The paymaster verifies that the paymasterData contains a signature from the sponsor, verifying that the sponsor is willing to pay for the UserOperation. If the signature is valid, the paymaster accepts and the fees for the UserOperation get paid out of the sponsor’s stake.
  • The paymaster verifies that the sender wallet has enough ERC20 balance available to pay for the UserOperation. If it does, the paymaster accepts and pays the ETH fees, and then claims the ERC20 tokens as compensation in the postOp (if the postOp fails because the UserOperation drained the ERC20 balance, the execution will revert and postOp will get called again, so the paymaster always gets paid). Note that for now, this can only be done if the ERC20 is a wrapper token managed by the paymaster itself.

How far along is this proposal?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store