EIP - EIPs(Ethereum Improvement Proposals) are protocol/application-level upgrade proposals for the Ethereum platform.EIPs broadly contain proposals for protocol/consensus/application layer upgrades whereas ERCs are application-level upgrades

ERC - ERCs (Ethereum Request for Comment) are token/contract standards (application level standards) that start out as EIPs. EIP becomes ERC only when the core Ethereum devs and committee agree and vote on it.

Some of the most popular EIP turned ERC standards are

1. EIP-20 which defined the standard to create a fungible token

2. EIP-721 which defined the standard to create a non-fungible token

3. EIP-1155 which defined a standard to create a hybrid of fungible and non-fungible tokens

One such standard recently proposed by Vitalik Buterin along with some others is a standard called ERC-4337 also simplified as Account Abstraction Using Alt Mempool.

ERC-4337 is a standard that aims to solve the UX problems with traditional wallets without any modification to the protocol/consensus layer.

Traditional wallets are generated using the ECDSA (Elliptic Curve Digital Signature Algorithm) to generate a public & private key pair and the public address is derived from the public key. These wallets can only sign and broadcast a transaction to the chain and cannot perform smart contract-like functionalities.

Account Abstraction as it is popularly known, is a way of bringing contract-like functionality to EOAs (Externally Owned Accounts) without having to manage an EOA and Smart Contract separately.

ERC-4337 brings AA (Account Abstraction) by moving the validity conditions of a transaction like the signature verification, replay protection, etc from the consensus layer to the smart contract layer (execution layer).

ERC-4337 introduces a standard interface for the Ethereum network’s deposit contracts, which allows different applications and wallets to interact with smart contracts in a standardized way.

Normal Ethereum wallets are very standard and can only perform tasks like signing and sending transactions.

A good metaphor is to look at Account Abstraction as having a chip planted into the Ethereum wallets which makes it smart.

The chip is analogous to the code in the wallets which makes it smarter. Programmers can write code to do many other tasks which can extend the functionality of normal wallets beyond just transaction signing.

The additional functionality can include performing any type of logic ranging from batch transactions and time-locked wallets to performing social recovery, multisig wallets, and gas payments using ERC-20 tokens.

1. UserOperation — A higher-level transaction object which gets sent to a separate mempool

2. Paymasters — A contract to pay for transactions on behalf of the wallet

3. Bundlers — Nodes that can bundle transactions from the UserOperation mempool

4. EntryPoint — The EntryPoint contract is a singleton (global) contract that verifies and executes the bundles of UserOperations sent to it.

5. Wallet

• Wallet Contract — A user account in the form of a contract

• Wallet Deployer — A factory contract that creates individual wallet contract

• Wallet Software — Application/User Interface to perform transactions

A UserOperation looks like a transaction; it’s an ABI-encoded struct that includes fields such as :

struct UserOperation {
  uint256 nonce;
  bytes callData;
  uint256 callGasLimit;
  uint256 maxFeePerGas;
  uint256 maxPriorityFeePerGas;
  bytes signature;
  address sender;
  bytes initCode;
  uint256 verificationGasLimit;
  uint256 preVerificationGas;
  bytes paymasterAndData;
}

• sender: This is the wallet making the operation

• callData : The data to call the wallet with for the actual execution step

• nonce : To prevent replay attacks. Also used as salt for first-time wallet creation

• callGasLimit : The amount of gas to allocate the main execution call

• maxFeePerGas : Maximum fee per gas (similar to EIP 1559)

• maxPriorityFeePerGas : Maximum priority fee per gas (similar to EIP 1559)

• signature : Data passed into the wallet along with the nonce during the verification step

• initCode : The initCode of the wallet (only needed if the wallet is not yet on-chain and needs to be created)

• verificationGasLimit : The amount of gas to allocate for the verification step

• preVerificationGasLimit : The amount of gas to pay for to compensate the bundler for pre-verification execution and calldata

• paymasterAndData : Address sponsoring the transaction (or zero for regular self-sponsored transactions) and any additional data

1. Paymasters allows developers to sponsor the fees of a transaction on behalf of the users.

2. Paymasters allows users to pay their fees in ERC20 tokens, with a contract serving as an intermediary to collect the ERC20s and pay in ETH

A Bundler is a node that listens to the UserOperation mempool, bundles multiple UserOperations together, and sends that bundle to the EntryPoint contract for execution.

Bundlers choose which UserOperation objects to include in their bundle transaction based on similar fee-prioritization logic used by block builders on Ethereum today.

Because the Bundler acts as the “from” address when getting the bundle transaction on-chain, the Bundler will pay the gas fee for the bundle transaction in ETH. Bundlers are compensated through fees paid as part of all individual UserOperation executions.

The EntryPoint contract is a singleton contract that verifies and executes the bundles of UserOperations sent to it. It is a global entry point that everyone using ERC-4337 compliant smart contract wallets will use to transact on the EVM. This concept is comparable to the single staking deposit contract.

The use of an EntryPoint simplifies the logic used by smart contract wallets, pushing the more complicated smart contract functions needed to ensure safety to the entry point rather than in the wallet itself.

1. The dApp initiates a signature request from the user’s wallet

2. The wallet signs and broadcasts the transaction to the chain using an RPC call. The UserOperations calls go into a separate mempool which runs parallel to the traditional transaction mempool.

From this point, the on-chain flow starts…

There is a method in the EntryPoint contract called handleOps() .

The transaction now goes through 4 steps

1. If the wallet is not yet on chain, then the transaction goes through the initCode phase where the factory contract will deploy the wallet contract.

2. The validateUserOp() function performs the validation to check if the nonce and signature are valid.

3. Checks if there is a paymaster to pay the user’s transaction fees and accordingly invokes the validatePaymasterUserOp() function in the Paymaster contract.

4. Final step is to execute the transaction in the wallet contract

1. No more worry about seed phrases and the hassle of storing them makeing it easier for non-techy users to get onboarded to the web3 ecosystem

2. No need to worry about having the native coins to pay for fees. Fees can be paid using ERC-20 tokens

3. Improved security. Since the validation layer is taken care of by the contract, users can have their trusted devices manage the authentication of payments making their mobile devices similar to hardware wallets

4. Enable multisig functionalities

1. Easy user onboarding by having a paymaster pay for the user’s transaction fees

2. Enhanced privacy and security: With account abstraction, developers can implement custom privacy and security measures tailored to the specific needs of their applications. This can include advanced cryptographic techniques, such as zero-knowledge proofs, to ensure transaction privacy or multi-signature wallets to enhance security.

…among many more

Folks, this is just a high-level introduction to ERC-4337. I will be writing about this extensively along with some technical guide to creating an ERC-4337 compatible wallet.

Stay tuned..