1 of 35

EIP-4337: Account Abstraction via Alternative Mempool

Presented by: Yoav Weiss, Kristof Gazso

2 of 35

Yoav Weiss

hacker @ ethereum foundation

twitter: yoavw�github: yoavw

3 of 35

Kristof Gazso

pm & researcher @ nethermind

twitter: kristofgazso�github: kristofgazso

4 of 35

What is Account Abstraction?

5 of 35

The “How” - Overview

  • Introduces User Operations
  • Kept in a separate mempool and propagated using p2p
  • Routed through EntryPoint
  • Introduces IWallet and IPaymaster interfaces
  • Can be included on chain by anyone (Miners/Searchers/etc.)
  • Compatible with current Ethereum protocol

6 of 35

7 of 35

Use cases & why make it a standard

8 of 35

We get Account Abstraction Now

9 of 35

Incentivize Smart Contract Wallet Adoption

10 of 35

Universal & Widespread Interface

11 of 35

Custom Signature Schemes

12 of 35

Upgradeability

13 of 35

Paymasters

14 of 35

Pay with Tokens

15 of 35

Trading without native currency

16 of 35

Private withdrawal from ZK Mixers

17 of 35

Paying off-chain with a Credit Card

18 of 35

Multi-operations

19 of 35

Decentralized

20 of 35

Incentive-aligned

21 of 35

Slow rollout possible

22 of 35

Future-proof

23 of 35

Drawbacks

  • Higher potential DoS vector
  • One User Operation per sender at a time
  • Gas overhead - 54k gas overhead, 28k shared

24 of 35

25 of 35

26 of 35

EntryPoint interface

  • Bundler interface:
    • handleOps(UserOperation[] calldata ops, address payable beneficiary) public
    • simulateValidation(UserOperation calldata userOp) external returns (uint256 preOpGas, uint256 prefund)
  • Paymaster stake management:
    • addStake(uint32 _unstakeDelaySec) payable
    • unlockStake()
    • withdrawStake(address payable withdrawAddress)
  • Wallet / Paymaster deposit management:
    • balanceOf(address account) view returns (uint256)
    • depositTo(address account) payable
    • withdrawTo(address payable withdrawAddress, uint256 withdrawAmount)

27 of 35

Wallet and Paymaster interfaces

  • IWallet
    • validateUserOp(UserOperation calldata userOp, bytes32 requestId, uint256 missingWalletFunds)
  • IPaymaster
    • validatePaymasterUserOp(UserOperation calldata userOp, bytes32 requestId, uint256 maxCost) external view returns (bytes memory context)
    • postOp(PostOpMode mode, bytes calldata context, uint256 actualGasCost)

​

28 of 35

Security considerations - contract risks

  • EntryPoint is trusted by everyone. Requires thorough auditing.
  • Must maintain security invariants:
    • UserOperation only executes if wallet validation succeeds for it.
    • If wallet validation succeeds, the matching UserOperation must execute.
    • Validations must not affect each other. All validations happen before any execution.
    • If all UserOperations are valid, bundler must be compensated correctly.
    • Wallet only pays for valid UserOperations and only if no paymaster is specified.
    • Paymaster only pays if its validation of the UserOperation succeeds.
    • If paymaster requested a postOp, then postOp must be called after the operation.
    • If postOp reverts after a UserOperation, it must be called again after the UserOperation side effects were reverted.
    • Wallet and paymaster deposits can only be withdrawn by their owner.
    • Paymaster stake cannot be withdrawn of paymaster is active or during the unlock delay.
    • Paymaster can withdraw its stake after the unlock delay, and no one else can.

​

29 of 35

Security considerations - DoS

  • UserOperation validity relies on EVM state.
  • DoS vector: invalidate many ops with a single change.
  • Bundlers must resimulate ops in order to drop them.
  • A lot of unpaid work.
  • Made worse by malicious or buggy paymasters.
  • Mitigation: restrictions during validation, at the mempool and bundler level:
    • Limited validation gas.
    • Banned opcodes.
    • No code changes after admitted to mempool.
    • Restricted storage access.
    • Paymaster sybil resistance and throttling.

​

30 of 35

DoS mitigation - validation gas

  • Validation represents a risk of unpaid work.
    • By mempool nodes during propagation - only valid UserOperations are propagated.
    • By bundlers - previously valid UserOperation becoming invalid before bundling.
  • Validation gas is declared by the UserOperation.
  • Bundlers won’t accept the UserOperation if validation gas is too high.
  • EntryPoint enforces gas limits.

​

31 of 35

DoS mitigation - environment consistency

  • Environment opcodes banned during validation.Only state affect validity.
  • Banned: GASPRICE, GASLIMIT, DIFFICULTY, TIMESTAMP, BASEFEE, BLOCKHASH, NUMBER, SELFBALANCE, BALANCE, ORIGIN, GAS, CREATE, COINBASE.
  • Restricted: CREATE2 allowed once, only if UserOperation.initCode!=0, and must result in the creation of UserOperation.sender.
  • When admitting a UserOperation to mempool, code hash of all accounts accessed during validation is saved.
  • During bundling, if any of the hashes changed, UserOperation is dropped.

32 of 35

DoS mitigation - storage access

  • Single state change shouldn’t be able to invalidate O(n) UserOperations.
  • Wallet validation only allowed to access wallet storage.
  • Only one UserOperation per wallet allowed in mempool.
    • Can be a batched UserOperation.
    • Can be replaced by fee.
  • Paymaster validation only allowed to access paymaster storage.
    • Multiple UserOperations use the same paymaster. Buggy/evil paymaster can enable DoS.
  • Paymaster reputation based throttling/banning:
    • Sybil resistance: paymaster locks a stake, has unstake delay.
    • Exponential moving average tracks paymaster inclusion rate.
    • Paymasters that cause a lot of unpaid work get throttled and eventually banned.

​

33 of 35

Client / Bundler Implementation

34 of 35

Links

35 of 35

Questions