#WhatTheFork - EIP4337
Introduction
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
- EIP-20 which defined the standard to create a fungible token
- EIP-721 which defined the standard to create a non-fungible token
- 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.
#WhatTheFork is ERC-4337 ?
Technical Explanation
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.
Layman Explanation
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.
Under the hood
Components of AA
- UserOperation — A higher-level transaction object which gets sent to a separate mempool
- Paymasters — A contract to pay for transactions on behalf of the wallet
- Bundlers — Nodes that can bundle transactions from the UserOperation mempool
- EntryPoint — The EntryPoint contract is a singleton (global) contract that verifies and executes the bundles of UserOperations sent to it.
- 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
UserOperation
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 operationcallData
: The data to call the wallet with for the actual execution stepnonce
: To prevent replay attacks. Also used as salt for first-time wallet creationcallGasLimit
: The amount of gas to allocate the main execution callmaxFeePerGas
: 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 stepinitCode
: TheinitCode
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 steppreVerificationGasLimit
: The amount of gas to pay for to compensate the bundler for pre-verification execution and calldatapaymasterAndData
: Address sponsoring the transaction (or zero for regular self-sponsored transactions) and any additional data
Paymaster
- Paymasters allows developers to sponsor the fees of a transaction on behalf of the users.
- 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
Bundler
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.
EntryPoint
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.
Offchain Architecture
- The dApp initiates a signature request from the user’s wallet
- 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…
OnChain Flow
There is a method in the EntryPoint contract called handleOps()
.
The transaction now goes through 4 steps
- 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. - The
validateUserOp()
function performs the validation to check if the nonce and signature are valid. - Checks if there is a paymaster to pay the user’s transaction fees and accordingly invokes the
validatePaymasterUserOp()
function in the Paymaster contract. - Final step is to execute the transaction in the wallet contract
What’s in it for users ?
- 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
- No need to worry about having the native coins to pay for fees. Fees can be paid using ERC-20 tokens
- 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
- Enable multisig functionalities
What’s in it for devs ?
- Easy user onboarding by having a paymaster pay for the user’s transaction fees
- 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..