What is ERC-4337

An intro to the AA EVM Standard

ERC-4337 is a standard proposed in EIP-4337 and is today probably the most popular model regarding AA implementations. At a high level, it's a model that enables users to use Smart Contract Accounts as their primary accounts without having to manage private keys themselves. This feat is far from trivial given the fact that an EOA is needed to initiate transactions and a private key is needed to sign them on behalf of the EOA.

This proposal came up with a complex model to achieve this goal without requiring changes at the base protocol layer, which is crucial for its viability given the fact that consensus layer changes have really slow timelines (for good reasons) and developments at this level have been focused on scalability for quite some time.

Related concepts

Before we dive in on how the model works it is important to pin down some important concepts you should know. If haven't already, checkout our section on Account Abstraction.

  • Accounts: In most smart contract blockchain protocols, every state change needs to involve objects called accounts. Accounts can be of two types: contract accounts and externally owned accounts or EOA's. The first type are accounts that are controlled by code deployed to the blockchain as smart contracts (SC). The second type are controlled by private keys, usually held by primate users and used to sign transactions that trigger state changes in the network.

  • Smart Contract Wallet: It's a SC used to manifest a wallet that holds assets inside a blockchain and is controlled by one or more individuals. Ordinarily, this role would be fulfilled by an EOA, but there are some advantages of using a SCW. One classical example is to use a multi-sig wallet, i.e., a wallet that requires more than one signature from a specified set in order to execute some types of transactions.

  • Mempool: Blockchains are asynchronous networks, which means that information travels through nodes in a disorderly manner. This is one of the reasons why it is difficult to reach consensus in blockchains. Since transactions are the main type of fundamental information being transmitted between nodes, most consensus mechanisms have nodes pick transactions in need of validation from a memory pool, the mempool.

  • Relayers: This term can be used broadly to refer to a third party entity used to facilitate a given operation. In the context relevant to this material, a relayer is an agent relied upon to call the required methods present in SCW's. Relayers are convenient in this case to enable users to enjoy the functionalities of a SCW without needing each to rely upon their own EOA. That way the SCW can indeed fulfill the purpose of an EOA with all the added functionalities embedded in its internal code.

  • Validation: Validation can be thought of here as an algorithm that checks if a call meets a certain set of requirements. It should return a binary output, true or false. In the latter case, the call should not be completed with all the current related state changes being reverted. The algorithm will generally be conditioned by either its inputs or state variables or both. In many cases, a form of signature will be among its inputs.

  • Execution: the actual execution of a transaction can be realized completely separately from the validation process in some cases. In these cases, the execution, i.e., the actual set of state changes required by the call, will only be initiated once the validation returns true. Also, the set of conditions used by validation need to be verifiable a priori.

Objectives

As hinted above the main goal of this ERC is to empower users to enjoy the benefits of SCW's without needing to rely on EOA's and manage private keys. As secondary objectives, the proposal aims to achieve,

  1. Decentralization

  2. Trustlessness

  3. Compatibility with consensus-layer

1 is achieved mainly by having transactions communicated to relayers through public mempools. 2 by having agents properly incentivized to work in support of the system. As was already mentioned, this is an application level proposal, meaning it was designed without changes in the base layer, so by implication we have 3.

Main Components

Before we show how this system works let's checkout the main components that make up the model.

  • userOperation: an object that represents a transaction in this system. It is passed by SCW users to bundlers as an ABI-encoded struct with the relevant and necessary info to specify the action they want their account to take (see its structure here).

  • bundlers: fulfill the role of relayers with the possibility of bundling multiple userOp's in a single block tx.

  • mempool: public pool of pending userOp's from which bundlers can pick to make the required calls. It is NOT the same mempool as the tx mempool of the base protocol layer.

  • EntryPoint: a contract that acts as an intermediary between the bundler and the SCW's. Their primary purpose is to enable the bundler to be sure he is going to be refunded for gas, since it may not be possible to check this by simulating the tx for a couple of reasons. Unlike SCW's the EntryPoint can be an audited trustworthy singleton contract used by many bundlers to make calls to many different SCW's. It also acts as a trusted source of calls by the SCWs by following the proper validation protocol.

  • aggregator: a contract with the role of enabling signature aggregation with the purpose of saving gas in the validation phase.

  • paymaster: account used as a sponsor that pays for the gas used up by the SCW tx. It can be useful mainly in cases where a dapp wants to cover its user's gas expenses or when the possibility for the end user to cover gas expenses in ERC-20 tokens is desirable.

Operation Flow

Now let's go through the flow of how a userOperation turns into a state changing tx. The sketch below helps illustrate the steps described in the lists. The steps are numbered by order and separated by the component responsible by it.

This is a high-level description. Many details are being omitted for the sake of simplicity. Checkout the references to get more detailed information.

Steps

User

  1. Sends UserOperation to mempool containing a signature for proper validation.

Bundler

  1. Listens to UserOp mempool.

  2. Runs simulations: checks if the userOp will pass validation, only picks userOp's that pass.

  3. Bundles a list of UserOp's.

  4. Relays bundles to the EntryPoint.

EntryPoint

  1. Creates contract accounts in case they don't exists.

  2. Validates each UserOp with respective SCW,

    • If there is a payMaster appointed, validates operation with paymaster.

    • If no paymaster, checks if there is enough balance to cover whole operation.

    • if UserOp not valid, reverts.

  3. If UserOp passes validation, calls UserOp execution with SCW.

  4. Refund bundler for gas expenses.

Paymaster

  1. If paymaster validation passes, sends ETH to EntryPoint to cover gas expenses.

SCW

  1. Executes internal logic as instructed by userOp.

This model is already being used by a good amount of projects and we expect this number to grow at a high pace. Checkout the references below for more details on this subject

References

PreviousWhat is Account Abstraction