Account Abstraction 201: the journey of a user operation
The Lifecycle of an ERC-4337 User Operation: From Initiation to Completion
Decentralized apps (dapps) on Ethereum offer exciting possibilities like decentralized finance, social networks, and permissionless marketplaces. But for average users, interacting with Ethereum’s mechanics can be frustrating.
Managing private keys and the 24-word secret phrases, dealing with gas fees, handling transaction nonces — these blockchain intricacies create serious friction for mainstream adoption.
Account abstraction aims to solve these usability issues and provide a smooth user experience. It separates a user’s identity from their blockchain account using smart wallets and replaces transactions with ‘User Operations’. Let’s dive deep into how account abstraction works and walk through the entire lifecycle of a ‘user operation’.
What is Account Abstraction?
When you use a browser wallet like Metamask or Coinbase Wallet, the address you see, your identifier, is generally referred to as an Externally Owned Account (EOA). It looks like 0x2039Ca5c9A445c0CC1b740bb81cA15e3aa6d168B. With account abstraction, a user’s identity is managed by a smart contract wallet rather than directly by their EOA. This wallet acts as an intermediary between the user and the blockchain. This wallet is a Smart Contract with additional functionalities that enable it to act like a regular EOA wallet.
The smart wallet handles all the complex blockchain transactions and mechanics on the user’s behalf. This obscures intricacies like gas costs, nonce management, and signing from the end user. The user gets an abstracted identity that persists across decentralized apps. Their smart wallet address remains the same, but the mechanics are obscured. This approach offers several benefits:
Smoother UX — No more dealing with gas fees, nonces, signing transactions, etc. The smart wallet handles all the blockchain complexity behind the scenes.
Cross-dapp identity — Because the smart wallet works across multiple dapps, users enjoy a unified experience. No more creating new accounts and funding them with ETH for every new dapp.
Privacy — User identity is abstracted away from the on-chain activity. Their smart wallet address doesn’t reveal all their behaviour across different dapps.
Security — Smart wallets allow advanced security mechanisms like multi-factor authentication, social recovery, and additional checks before signing transactions. No more losing everything if you lose your private key!
Cross-chain — Most current Smart Wallet implementations use “deterministic” algorithms to deploy your wallet’s Smart Contract. This means that the address of this Smart Contract remains the same, no matter which chain it is deployed on, as long as it is EVM compatible.
Account Abstraction Components
The ERC4337 Ethereum standard defines several key components that collectively enable account abstraction:
Smart Wallet — As described above, the smart wallet is a smart contract that manages a user’s identity details, assets, and account activity. It stores everything necessary and handles all blockchain transactions.
Bundler — An off-chain service that batches multiple user operations from a dapp into a single Ethereum transaction. This saves gas costs by reducing the total number of transactions required.
Paymaster — An off-chain service that sponsors and pays the gas fees for bundled transactions on behalf of users. This abstracts away the complexity of dealing with gas costs. Using a Paymaster is optional while sending/generating User Operations.
Signature Aggregator — An off-chain service aggregating signatures from multiple user operations into a single signature. This allows submitting one transaction representing operations, thus saving on gas fees.
Note — Currently (as of September 2023), Aggregators are not widely implemented. Most of the signatures are individually verified.
Entry Point Contract — A singleton smart contract that bridges off-chain components like bundlers and the on-chain Ethereum network. It validates user operations, checks that gas is sponsored, and relays bundles.
Introducing User Operations
At the core of account abstraction are user operations. These are similar to Ethereum transactions but have additional properties to enable the above-mentioned functionality.
A user operation contains
Sender — The user’s smart wallet address.
Nonce — A unique incrementing operation number that prevents replay attacks.
initCode — Any contract creation bytecode if the operation needs to deploy a new contract.
callData — The encoded parameters to be passed to the contract function call.
callGasLimit — The maximum gas specified for executing the operation.
verificationGasLimit — This is the gas limit used for the verification phase
preVerificationGasLimit — This is the gas used to compensate the bundlers
maxFeePerGas — Maximum fee per gas (this is similar to EIP 1559)
maxPriorityFeePerGas — Maximum priority fee per gas (this is similar to EIP 1559)
paymasterAndData — Encoded data from a Paymaster in case you want to sponsor the gas for this user operation
signature — The user’s wallet signature approving this operation.
Unlike regular transactions, user operations are not submitted directly to the Ethereum blockchain. Instead, they go into a custom mempool queue managed by the Entry Point Contract. This keeps operations isolated from the main Ethereum network until they can be efficiently batched together.
Lifecycle of a User Operation
Now, let’s dive into the complete lifecycle of a user operation from initial creation to final execution:
1. Initiation
The process begins when a user tries to take some action within a dapp’s user interface, like transferring tokens or interacting with a protocol’s smart contract.
Based on the specific action the user wants, the dapp constructs a User Operation struct containing the necessary details: the user’s smart wallet address as the sender, the target contract address, the properly encoded function parameters, the gas limit, and other relevant fields.
This User Operation serves as a request to the user’s Smart Wallet to perform the specified action.
2. Construction and Validation
The dapp constructs the initial User Operation struct carefully, ensuring that all the necessary fields are populated correctly:
- The `sender` field is set to the user’s Smart Wallet address.
- The `nonce` field is incremented from the last User Operation to prevent replay attacks.
- The `callData` field is encoded based on the target contract’s function ABI specification.
- The `callGasLimit` and other gas fields are adequately set for the intended function execution.
Before asking the user to sign the unfinished User Operation, the dapp may simulate the function call to ensure the parameters are valid. This prevents wasting users’ time with operations destined to fail. Some bundlers provide this functionality through their APIs.
3. Signing
Next, the user’s Smart Wallet is asked to sign the constructed User Operation cryptographically.
The Smart Wallet can take several steps to validate the operation before signing:
- Confirm the user authorized this action (e.g. through a signature from their connected wallet app).
- Ensure the nonce is correctly incremented from the last operation.
- Verify the `sender` field matches the user’s wallet address.
- Check the wallet has sufficient ETH balance or ERC20 tokens (in case they are used to pay for gas) for the operation’s estimated gas cost.
The Smart Wallet will approve the operation if all validations pass by generating a cryptographic signature and populating the `signature` field.
4. Broadcast
The dapp broadcasts the signed User Operation to a bundler service’s mempool.
As it stands (as of September 2023), each bundler implements its mempool, and there is no connected mempool from which all the bundlers can pick up user operations.
Hence, currently, a Dapp has to use the API endpoints of different bundler services individually.
The community is working to create a unified mempool for all the bundlers, but we are unsure when that will happen.
5. Verification
A bundler will usually call the handleOps() function from the singleton Entry Point Smart Contract, wherein it would send the signed user operation.
When the Entry Point Contract receives a signed User Operation, it first cryptographically verifies that:
- The signature is correctly generated from the Ethereum address specified in the `sender` field.
- This is usually done by calling the validateOp() function in the Smart Wallet
- The Smart Wallet signing the user operation or the Paymaster (in case the user operation is gas-sponsored) has a sufficient gas limit to cover the cost of signature verification.
- This is usually done by calling the validatePaymasterOp() function from a particular Paymaster if this user operation is gas-sponsored.
- The user’s nonce is correctly incremented compared to previous operations.
If these verifications fail, the User Operation is rejected as invalid. This prevents users from being able to submit improperly signed operations.
6. Execution
Once a User Operation is validated, for it to be executed, the Entry Point needs to ensure that enough gas is available. This gas can be paid by either the Smart Wallet or a Paymaster.
This gas amount is usually pre-paid to the Entry Point contract by either the Smart Wallet or the Paymaster. The Entry Point contract, in turn, compensates the bundler for its activities and services from this deposit. The Smart Wallet can withdraw from this deposit at any time.
Once the Entry Point determines that there is enough pre-paid gas for this user operation, this operation is then executed by calling a function from the Smart Wallet.
After that, this user operation becomes a “transaction” and is sent to the blockchain to be bundled in a block.
7. Completion
Finally, once the bundle transaction has been successfully mined and executed on-chain, all of the User Operations it contained are completed.
Their intended state changes occur, such as token transfers, contract interactions, etc.
The users are notified their requested actions have finished successfully. Behind the scenes, their nonces are incremented on their Smart Wallets.
Conclusion
This deep dive has covered the complete lifecycle of ERC4337 user operations — from initial creation and signing through bundling and execution to completion.
Account abstraction powered by user operations provides an elegant solution to many blockchain usability issues that hinder mainstream adoption. Understanding innovations like this will be essential for any blockchain developer crafting seamless dapp experiences for end users.
As Ethereum progresses toward mass adoption, technologies like account abstraction will enable the smooth user experience essential for success. By abstracting away cryptocurrency’s underlying complexities, innovations like user operations will help fuel the next generation of blockchain applications.
Plug
Our team at Indorse is working on an Account Abstraction wallet SDK called Bastion. You can find it here.
Bastion is a modular, lightweight, and open-source account abstraction SDK designed to simplify the integration of decentralized wallet functionality into your applications. Written in TypeScript and fully ERC4337-compatible, Bastion ensures type safety while abstracting away the complexities of blockchain interactions.
With Bastion, you can provide a seamless multi-chain experience to your users. It allows secure storage of assets from different blockchains like Ethereum, Polygon, Optimism, Arbitrum, Scroll, and Taiko in a unified interface.
If you are looking for expert advice for your next blockchain project, or Smart Contract consultants, check out my website.
Subscribe to DDIntel Here.
DDIntel captures the more notable pieces from our main site and our popular DDI Medium publication. Check us out for more insightful work from our community.
Register on AItoolverse (alpha) to get 50 DDINs
Support DDI AI Art Series: https://heartq.net/collections/ddi-ai-art-series
Join our network here: https://datadriveninvestor.com/collaborate
