ERC4337 and Native Account Abstraction

a game changer for the web3 industry

The Ethereum ecosystem has been evolving rapidly, and one of the most exciting developments in recent times is the introduction of ERC-4337, which brings the concept of Account Abstraction to the forefront. This new standard is set to revolutionize how users interact with blockchain wallets, making them more user-friendly, secure, and programmable. In this article, we will explore what ERC-4337 is, how it works, and why it is a game-changer for the Web3 industry. Furthermore, we will examine how blockchain networks are utilizing this architecture to develop native account abstraction SDKs.

What is ERC4337

ERC-4337 is an Ethereum Improvement Proposal (EIP) that introduces Account Abstraction (AA), a feature that allows Ethereum accounts to function as programmable smart contracts. This means that instead of relying on traditional externally owned accounts (EOAs) that require users to manage private keys and seed phrases, ERC-4337 enables the creation of smart accounts. These accounts can contain custom logic, making them more flexible and secure.

In simpler terms, ERC-4337 abstracts the complexities of managing cryptographic keys and seed phrases, allowing users to interact with the blockchain in a more intuitive and secure way. This is achieved without making changes to the core Ethereum protocol, which makes it easier to implement and adopt across various Ethereum Virtual Machine (EVM)-compatible blockchains like Polygon, Optimism, and Arbitrum.

The need for ERC4337 in web3

The current user experience in Web3 wallets is far from ideal. Users are required to manage complex seed phrases, private keys, and manually sign every transaction. This not only creates a steep learning curve but also introduces security risks. For instance, if a user loses their private key or seed phrase, they lose access to their assets permanently.

ERC-4337 addresses these issues by introducing smart accounts that can be programmed to include features like:

• Social recovery: Users can recover their accounts through trusted contacts or other mechanisms, eliminating the need for seed phrases.
• Multisig wallets: Multiple parties can control a single account, making it ideal for organizations like DAOs.
• Gasless transactions: Users can delegate gas fees to third parties, making transactions more accessible.
• Automated payments: Users can schedule recurring payments, similar to traditional banking systems.

These features make ERC-4337 a powerful tool for improving the user experience in Web3, making it more accessible to a broader audience.

How does ERC4337 work ?

At its core, ERC-4337 introduces a new transaction type called UserOperation. This pseudo-transaction object allows users to interact with the blockchain without needing to manage EOAs directly. Here’s how it works:

1. UserOperation Mempool: Instead of sending transactions to the regular Ethereum mempool, users send UserOperation objects to a separate mempool known as the Alt-Mempool.
2. Bundlers: These are entities that collect multiple UserOperations and bundle them into a single transaction. Bundlers act similarly to validators in a Proof-of-Stake (PoS) network, prioritizing transactions based on gas fees.
3. Global Entry Point: Once the bundled transactions are validated, they are sent to a Global Entry Point, which coordinates the execution of the UserOperations across the network.
4. Contract Accounts: The UserOperation data is then transmitted to the user’s Contract Account, where the custom logic is executed. This could include anything from verifying signatures to executing complex multi-step transactions.

By using this architecture, ERC-4337 allows for greater flexibility and customization in how accounts operate, without requiring changes to the underlying Ethereum protocol.

Use cases of ERC4337

The flexibility and programmability of ERC-4337 open up a wide range of use cases across various industries:

• Decentralized Finance (DeFi): Users can automate complex financial operations, such as yield farming or liquidity provision, without needing to manually approve each transaction.
• Non-Fungible Tokens (NFTs): Artists and creators can set up automated royalty payments or schedule the release of new content without needing to interact with the blockchain manually.
• Decentralized Autonomous Organizations (DAOs): DAOs can use multisig wallets to ensure that important decisions, such as fund allocation or governance changes, are approved by multiple members.
• Subscription Services: Web3 projects can implement subscription models where users pay for services on a recurring basis, similar to how traditional SaaS models work.

1 million ERC4337 UserOps milestone

We’ve witnessed a record-breaking 1 million transactions through ERC4337 Smart Accounts.

The announcement, made on August 18, 2023, has celebrated the combined efforts of core developers, bundlers, and paymasters dedicated to enhancing wallet user experiences.

Leading the pack in bundled transactions are PimlicoHQ with 662,000 UserOps, followed by:

• Alchemy at 179,000
• Biconomy with 79,000
• Stackup standing at 38,000.

Apps utilizing paymasters, which cover transaction gas fees for users, have shown Pimlico dominating with 660,000, Alchemy at 179,000, Biconomy with 79,000, and Stackup closing the ranks with 33,000.

Binance research explores the evolution of Account Abstraction

In a recent study titled A Primer on Account Abstraction, Binance Research, led by analyst Colin Chan, explores the advancements and innovations in Account Abstraction (AA).

Published on August 17th, 2023, the detailed report emphasizes AA’s efforts to improve user accessibility on the Ethereum network. At its foundation, AA is a key part of Ethereum’s strategy to move from externally owned accounts (EOA) to more sophisticated smart accounts with programmable logic. This significant transition has been achieved without altering the Ethereum Mainnet’s core consensus, thanks to the introduction of ERC-4337.

Leading zk-rollup solutions such as StarkNet and zkSync have also adopted native AA systems. Additionally, wallet providers like Argent and Bravoos are preparing to offer these cutting-edge solutions to their users.

The real-world applications of AA are extensive. For example, global payment leader Visa is actively experimenting with AA’s potential. Furthermore, wallet service providers such as Lens Protocol and CyberConnect have integrated AA, highlighting its practical benefits, particularly in enhancing user engagement within the Web3 ecosystem.

For more insights into AA’s impact and future direction, you can download the full report here.

ZkSync’s Approach to Account Abstraction

In zkSync’s Account Abstraction (AA) model, the bootloader plays a pivotal role. It is a System Contract responsible for managing transactions and executing the AA mechanism, analogous to the EntryPoint Contract in EIP-4337. Unlike typical contracts, the bootloader cannot be directly invoked by users; it can only be triggered by the Operator. Additionally, the bootloader is not deployed like standard contracts, as it runs directly within the node. However, it does have an official address, which can be utilized for payment collection.

The Operator, a key component in zkSync’s ZK rollup architecture, functions as a centralized off-chain server, similar to the Sequencer in other systems. The Operator is responsible for externally triggering System Contracts, such as the bootloader.

Native Account Abstraction protocols, like those in StarkNet and zkSync, are largely inspired by EIP-4337. In zkSync, the user submits a transaction to the Operator, which then forwards it to the bootloader, initiating a series of processing steps.

From the Block Perspective:

When the bootloader receives input from the Operator, it first defines several environment variables for the block, such as the gas price, block.number, and block.timestamp. The bootloader then processes the list of transactions sequentially, querying each account contract to confirm whether it agrees with the transaction by invoking the validate function, as per the Account Abstraction (AA) mechanism. Once validated, the transactions are added to the block.

After each transaction is validated, the Operator assesses whether the block has reached a sufficient size to be sent to the validator or if a timeout has occurred. If either condition is met, the Operator finalizes the block, halts the addition of new transactions to the bootloader, and completes the execution of the current transactions.

From the Transaction Perspective

For each transaction, the bootloader is triggered by the Operator in sequence:

1. Nonce Validation: The bootloader verifies whether the nonce associated with the user’s Account Contract Address is valid.
2. Transaction Validation: The bootloader calls the validate function on the user's Account Contract to confirm the transaction's validity.
3. Gas Fee Transfer: Upon validation, the Account Contract transfers the gas fee to the bootloader’s address, either directly or via a Paymaster (as described later). The bootloader then checks whether it has received the required funds.
4. Transaction Execution: Finally, the bootloader calls the execute function on the user's Account Contract to carry out the transaction.

The first three steps correspond to the Verification Loop in EIP-4337, while the fourth step aligns with the Execution Loop.

Comparison Between EIP-4337, StarkNet, and zkSync Era

While the overall flow of the Account Abstraction (AA) mechanism in EIP-4337, StarkNet, and zkSync Era follows a similar structure — comprising the Verification Phase, Handling Fee Mechanism (paid by the Account Contract or Paymaster), and Execution Phase — there are key differences between these implementations:

Who Performs the AA Mechanism:

• In zkSync Era, the AA mechanism is executed through a collaboration between the Operator and the bootloader (a System Contract). The bootloader is responsible for opening new blocks, defining the relevant block parameters, receiving transactions from the Operator, and validating them.
• In contrast, in EIP-4337, this process is handled by the Bundler and the EntryPoint contract.
• In StarkNet, the Sequencer performs all these tasks, eliminating the need for a separate bootloader or Bundler.

Consideration of Gas Costs and L1 Security:

• L2 Account Abstraction mechanisms, including those in zkSync Era and StarkNet, must account for the cost of uploading data to Layer 1 (L1). This is a critical factor for ZK (Validity) Rollups, as well as for Optimistic Rollups in EIP-4337.
• Specifically, in EIP-4337, the preVerificationGas parameter is used to account for these costs. For more details, refer to the Alchemy documentation.

Sending Transactions Before Account Contract Deployment:

• Unlike EIP-4337, which includes an initCode field in the EntryPoint contract to allow for the deployment of an Account Contract before sending a transaction, both StarkNet and zkSync Era lack this feature. As a result, in these systems, it is not possible to send a transaction before the Account Contract has been deployed.

Author: Mehdi @Tokamak Network