Why is Account Abstraction a game-changer and what I learned from creating an ERC-4337 smart contract

tl;dr

Account Abstraction is a standard on the Ethereum protocol that changes nothing about the base Ethereum layer but everything about the user experience. A few things that can be done once it is implemented include:

• Social recovery of wallet i.e. the ability to recover a user’s account and funds even if the user has lost a wallet’s private keys.
• Sponsor the transaction fees of a user on a dapp.
• Pay transaction fees with other ERC-20 tokens(e.g. USDC) and not just native ETH.
• Enable session keys to authenticate temporary social logins.
• Remove jargon like gas and seed phrases from a user perspective.
• Tailor security by enabling spending limits on certain devices and requiring multiple signatures for certain transaction types.
• Allow multiple operations in a single transaction for e.g., approving and swapping in the same transaction.

The topics covered in this article include:
- What is Account Abstraction?
- Bitcoin UTXO
- History of Account Abstraction
- ERC-4337 Workflow
- Major components of an ERC-4337 smart contract
- Modern Account Abstraction challenges

Let’s dive in!

What is Account Abstraction?

Before we dive into what Account Abstraction is, let’s briefly cover what an account on Ethereum is.

An Ethereum account is an entity that can send transactions on the Ethereum blockchain. There are two types of accounts on Ethereum:

• Externally owned accounts (EOAs) — These are accounts controlled by private keys and can send transactions. EOAs are controlled by humans.
• Contract accounts — These are accounts that contain smart contract code and are controlled by that code. Contract accounts are controlled programmatically based on the logic in their smart contract code.

This is an EOA on a popular wallet Metamask which I control by my password enabled through private keys.

These are the private keys that control the above mentioned account. (CAUTION: As the warning suggests, never reveal your private keys to anyone but since this is just a free developer account in which I won’t deposit any assets, it’s okay.) (FUN FACT: If someone gets hold of your private keys, they only get access for that particular account, but if they get your 12/24 word seed phrase, they can access all the accounts associated with that wallet.)

Transactions initiated from an EOA require a cryptographic signature using the account’s private key to authorize them. Contract accounts can send transactions programmatically without keys or signatures based on their code.

The way these accounts are structured leads to a poor use experience. Currently, if someone forgets their private keys, they lose their funds forever. Or, to authenticate a simple operation they might need to sign multiple transactions. Or, understand jargons that aren't particularly useful.
Account Abstraction solves all these pain points.

Account abstraction is a feature of the Ethereum blockchain that allows users to interact with the network through smart contracts instead of traditional externally owned accounts (EOAs). This means that users can store their funds and execute transactions without having to manage their own private keys.

ERC-4337 is an Ethereum Improvement Proposal (EIP) that defines a standard for account abstraction. Account abstraction aims to leverage the capabilities of smart contract accounts to benefit end users. Smart contracts allow accounts to be programmed with customized logic. This programmability enables user wallets to do much more than just sign and send transactions like a basic externally owned account (EOA). With an abstracted smart contract account, users can take advantage of advanced account features and functionality tailored specifically for their needs.

Since ERC-4337 makes no adjustments to the consensus layer no hard-fork or extensive testing is required for its launch. A few details on implementation status:

• Ethereum mainnet — ERC-4337 is not yet supported on mainnet. It is still in draft form and going through the EIP process for consideration.
• Testnets — ERC-4337 has been implemented on some Ethereum testnets like Goerli for experimentation purposes. But it is not yet on major public testnets like Ropsten. Companies like Visa have already started testing it out for alternative transaction “gas” methods.
• Layer 2s — There is some prototyping of ERC-4337 on optimistic rollups like Optimism and Arbitrum, but no production deployments yet. Whereas, some zk rollups like zkSync, StarkWare already offer “native account abstraction” solutions. Polygon is experimenting with account abstraction through Supernets.
• Wallets— Wallets like Safe(Gnosis Chain), Ambire, Argent, and Avocado have implemented forms of account abstraction, but these are separate from ERC-4337.

Account abstraction has a number of benefits, including:

• Improved user experience: Users no longer need to manage their own private keys, which can be a complex and error-prone process.
• Increased security: Bundlers can implement additional security features, such as multi-signature verification and social recovery while still depending on the main blockchain for security through validation.
• Reduced gas fees: Bundlers can aggregate multiple user operations into a single transaction, which can save users money on gas fees, and transactions initiated from a smart contract can be paid for by a third party.
• Speed: Increases throughput of transactions by enabling faster dApp interactions.
• Atomic multi-operations: A transaction can include multiple operations for e.g. approving and swapping in same transaction, reducing the number of signatures from a user.

Bitcoin UTXO

The way Ethereum handles execution and verification is different from other blockchains like Bitcoin.

Bitcoin uses a simple, stack-based, not Turing-complete scripting language to record value on the blockchain through discrete units known as UTXO(Unspent Transaction Output). The UTXOs are one-time accounts and a bitcoin transaction can contain any number of inputs and outputs. This allows UTXOs to be combined and split to make payments of any amount. When a bitcoin in a UTXO is sent as a transaction, it is spent completely and doesn't exist anymore and if any money needs to kept, it has to be in a new UTXO.

For example, if Alice wants to pay Bob 1 BTC and she has 2 UTXOs worth 0.5 BTC and 0.7 BTC, she can use both UTXOs as inputs and send an output worth 1 BTC to Bob. In order to claim the leftover value as change, Alice creates another output worth 0.199 BTC, which she sends to herself. She is not able to send 0.2 BTC to herself because she must pay a transaction fee, which is the difference between the value of the inputs and the value of the outputs. Source.

According to Vitailk, the Bitcoin scripting language is weak and is difficult to use for anything but only simplest applications such as multi-sig. This is one of the reasons why Ethereum was founded so that contracts can have their own internal storage, hold assets, make actions, send transactions and talk to other contract functions to help enable programmability on the blockchain.

In Ethereum, only the Ethereum Virtual Machine(EVM) is used for the execution part of an Ethereum transaction. Whereas, all EOAs need to use the ECDSA( Elliptic Curve Digital Signature Algorithm) public/private key pair for verification. This is the reason why we currently need private keys (EOAs) to interact with the chain. The core goal of AA is to enshrine smart contract accounts as 1st class citizens and the default account, which would help us get away from EOAs.

History of Account Abstraction

Source

2016: EIP-86

In 2016, the first attempt at Account Abstraction was made by the Ethereum community through EIP(Ethereum Improvement Proposal)- 86. The P2SH or “pay to script hash” was inspired by Bitcoin. Source.

2017

The goal was to abstract out signature verification and nonce checking and allowing users to establish account contracts that conduct any required signature/nonce checks rather than relying on the traditional method. Source.

2018

The goal was that during the verification time of a transaction, there would be restriction that the code won’t be allowed to read/write state outside of that account to avoid multi-invalidation. Source.

Problems with the versions of AA proposed till 2020:

• A new user who didn’t have coins had to find an existing user to create an AA account.
• Required complex logic inside the account to handle complicated things like paying the miner, getting a gas refund etc.
• Transaction hashes were not necessarily unique because the nonce could be updated every 24 hours, resulting in duplicate transactions.
• Multi-invalidation: This happens when a single transaction invalidates or conflicts with multiple unconfirmed transactions in Bitcoin’s memory pool (mempool). The earlier EIPs were prone to this DOS attack.

A multi-invalidation example where a user could theoretically create an arbitrarily large number of transactions and pollute the mempool with those transactions. This would make miners do a huge amount of work to verify them, resulting in a cheap DOS attack.

2020: EIP-2938

The goal was to allow a contract to be the top-level account that can pay fees and start transaction execution but the proposed change was very complex at the protocol level. Source.

2020: EIP-3074

Takes a slightly different approach in which instead of converting smart contracts to EOAs, EIP-3074 tries to adapt EOAs, adding a few changes here and there to make them behave like smart contracts. Furthermore, the users are required to back up their seed phrase. Source.

2020: EIP-4337

ERC-4337 Workflow

Source

“First verify all, then execute all” workflow:

Step 1: An entry point contract is created and pushed on-chain.

Step 2: The wallets must individually choose which contract to trust to authorize root operations from their account.

Step 3: A bundler creates a transaction that can wrap many user operations.

Step 4: Each transaction is verified and then executed.

Step 5: The users separately send their trsanction to a mempool which is a peer-to-peer network. Depending on the MEV, the bundlers actively batch transactions in the mempool.

Using the MEV ecosystem, Flashbots has created MEV-Boost, a free open-source, neutral software that enshrines PBS(Proposer-Builder Separation) to create an open relayer market. Therefore, with an open market, if one provider or a group of providers disappear, there can be others who can take their place and hence keep the ecosystem running smoothly.

Major components of an ERC-4337 smart contract

The smart contract I deployed using the tutorial can can be found here.

The major components of Account Abstraction under ERC-4337 include:

• UserOperation: User operations (UserOps) are essentially methods within a smart contract that dictate how transactions are processed. UserOps allow users to establish specific conditions under which a transaction should be accepted, such as setting a maximum gas price, requiring multi-signatures for transaction validation, or implementing complex time locks. Here is an example of a UserOp to allow the owner of the smart contract to transfer funds to another address.:

function transfer(address to, uint256 amount) public {
  require(msg.sender == owner);
  require(amount <= balance);

  // Execute the transfer.
  to.transfer(amount);
}

UserOps are a powerful tool that can be used to improve the security, efficiency, and user experience of Ethereum applications. As account abstraction becomes more widely adopted, we can expect to see even more innovative uses for UserOps.

• Bundler: Bundlers are smart contracts that aggregate multiple user operations (UserOps) into a single transaction. This allows users to perform complex transactions without having to pay the gas fees for each individual operation. Some of the most popular bundlers include:
  - Infinitism Bundler
  - Alchemy Rundler
  - Voltaire
  - Stackup Bundler
  - AA-bundler
  - Skandha
• EntryPoint: The EntryPoint is the smart contract that is responsible for ensuring that all UserOps are valid and executed in the correct order through the following functions:
  - validateUserOp: This function validates a UserOp and returns an error if it is invalid.
  - executeUserOp: This function executes a UserOp and returns the result.
  - handleOps: This function handles a batch of UserOps and returns an error if any of them are invalid.
• Aggregators: It is a smart contract that implements a signature scheme which allows multiple signatures from any transactions to be combined into one object. This object is much smaller and can be verified much more quickly than verifying all the transactions individually. This helps in saving data and gas.

An aggregator contract combines ops from multiple users into a group with a single signature. Source.

Since on Layer-2, computation is cheap but data is expensive, if the multiple signatures can be replaced with a single signature, it would drastically lower data required and potentially lower costs by 8x.

Source

• Paymaster: A paymaster is a smart contract that can sponsor transaction fees for users. This means that users can pay for their transactions in a way that is convenient for them, such as with an ERC-20 token (e.g. USDC) instead of native ETH.
  Paymasters work by interacting with the EntryPoint contract. When a user submits a transaction to the EntryPoint contract, the paymaster can choose to sponsor the transaction fees. If the paymaster agrees to sponsor the fees, the transaction will be executed and the paymaster will be charged the gas fees. Paymasters can be used to implement a variety of payment methods, such as:
  - Direct payment: The paymaster can directly pay the gas fees for the transaction.
  - Subsidies: The paymaster can subsidize the gas fees for the transaction, meaning that the user will only have to pay a portion of the fees.
  - Token payment: The paymaster can accept payment in a token, such as USDC, and then use the token to pay the gas fees for the transaction.

Source

Modern Account Abstraction challenges:

• Striking a key balance between enshrinement for efficiency and anti-censorship like inclusion list to cover AA transactions in addition to EOA transactions.
• Current EOAs cannot upgrade to AA accounts.
• Having Account Abstraction standardized across L2s just like how EOAs across all L2s are the same.
• Integration into existing technology like biometric signers. For e.g. an embedded biometric wallet like DFNS can help people send crypto easily just by scanning their face or fingerprint.
• Integration into existing wallets like Metamask, Keplr or Ledger.

Final Words

The future of account abstraction is bright. As the technology matures, we can expect to see even more innovative uses for account abstraction. For example, account abstraction could be used to create more secure and user-friendly wallets, or to enable new types of decentralized applications, or to help users upgrade their existing accounts to quantum safe cryptography without the protocol dictating or opinionating on which algorithm to use, as mentioned by Vitalik at EthCC6 in Paris.

Overall, account abstraction is a new paradigm that has the potential to revolutionize the way we interact with the current blockchain landscape and would play a crucial role to help onboard the next billion users to the Web3 ecosystem.

Fin.