Preface

EIP-4337 is a smart contract wallet solution to achieve account abstraction. The objective of account abstraction is to allow users to use an address, in this case an address of a smart contract wallet, to interact with blockchain, regardless of transaction verification logic. As a pure smart-contract-based solution, this protocol introduces neither consensus-layer changes nor EVM-related changes. By adding up off-chain protocols with a few on-chain smart contracts, EIP-4337 is largely viewed as the most feasible way to account abstraction for Ethereum. In this EIP, a lot of roles and contracts such as Bundler, EntryPoint, Paymaster, and Aggregator, are introduced. With such many pieces interacting with each other, and the abstruse EIP itself, understanding the whole picture becomes pretty challenging. There are already many well-written articles out there explaining EIP-4337 in a top-down manner. Here we are going with a different approach.

EIP-4337 proposes that every user account is a smart contract, which is pretty much the same as our own solution, Blocto’s Contract Wallet on EVM. In fact, there are some shared concepts between Blocto and EIP-4337 approach because we are essentially an abstract wallet over users’ email addresses that supports sponsored transactions. With the contract wallet as a starting point, we will examine the Blocto ecosystem, taking the EIP-4337’s motivations into consideration, and bring out the pieces in EIP-4337 and the corresponding design objectives behind them.

In this article, we aim to describe the qualitative objectives of each component in EIP-4337. While we won’t go through the technical details such as interface specifications, quantitative analysis, etc., the overall goal is to provide a bottom-up thinking path to construct the EIP-4337 account abstraction. As such, this article only requires very basic knowledge about blockchain, EVM, and contract wallets.

EIP-4337’s Motivations

Account Abstraction

This is the key goal of the whole thing. Account abstraction is to allow users to use an abstract wallet, in this case, a smart contract wallet, that is to do the following

• use arbitrary verification and recovery features, such as multi-sig, social recovery, etc.
• completely remove any need for users to have EOA wallets

Decentralization

Decentralization is one of the core values of blockchain technology. The equivalent statement to decentralization is to avoid trust assumptions on most, if not all, parties involved in any operations. EIP-4337, as a community-driven proposal, inherits the faith and tries to construct a trustless standard for account abstraction.

Sponsored Transactions

Web3 itself is still facing great challenges in onboarding new users. Having to own cryptocurrencies for gas first before playing around with dApps can be a huge stopper for new users. Some dApps even don’t require the users to have gas in the full product lifecycle, while still leveraging the infrastructure of the blockchain system, e.g issuing NFTs for items in a game. There are also privacy-preserving applications, such as mixers, where users may want to interact with contracts from a plain address even without any gas at all.

Hint: Contract Wallet Is Not Enough?

At a glance, Blocto Wallet on EVM is already an account abstraction solution. Users send offline intents of transactions to Blocto sever with a signature, and the Blocto server sends the actual transactions to the contract wallets to invoke the original intents by meta transactions. The meta transaction approach allows us to pay gas fees for our users with arbitrary currencies, even when there are no assets under their accounts. We incorporate a mixed-custodial key management model to balance user experience and the risk of malicious operators.

It already sounds like a pretty solid approach, right? But good is just not enough.

The Centralized Piece – Transaction Relayer

Although all the transactions are signed from users’ devices before being sent over to the transaction relayer – the Blocto server in our case – and later submitted to the blockchain, they are still pretty much affected by the centralized relayer. The server could potentially be out of service, causing hassles for users to manage their wallets and assets. A contract wallet such as Blocto Wallet will not be compromised or locked even if the relayer is malicious, because it usually implements on-chain verification and recovery logic. However, it’s still a disaster to users if the relayer is down – the whole contract wallet system suddenly falls back to an EOA-ish operation model, with no fee subsidization and an even worse user experience. One of the objectives of EIP-4337 is to eliminate the trust assumptions on transaction relayers, or so-called, bundlers.

Bundler – The Decentralized Transaction Relayer

Ignoring the “bundle” concept for a while, bundlers are essentially a group of decentralized transaction relayers. They accept users’ intents, or more specifically the UserOperation (user op) in EIP-4337’s terminology, offline in the same manner as the blockchain nodes accept users’ transactions, and submit them to the blockchain. In this way, we can avoid the whole wallet system being out of service with the centralized transaction relayer as a single point of failure.

Is it that simple? Absolutely not. Imagine you were a bundler, what would you be thinking about when relaying a user operation?

• Will the transaction fail and my gas be wasted?
• Will anyone actually pay the gas fee?
• Which transactions should I prioritize?

When we try to answer those questions, more EIP-4337 pieces come into view.

EntryPoint – A Trusted Smart Contract for Transaction Simulation

As bundlers are to know the outcome prior to transaction execution, they have to simulate a transaction based on a given EVM state. Bundlers basically simulate all the user ops among the latest block. However, simulation among arbitrary contract wallets could be quite troublesome because of the unknown contract code and inconsistency chain state between the simulation and the actual execution. To make bundlers’ lives easier, EIP-4337 defines a singleton smart contract, EntryPoint. In EIP-4337’s design, bundlers always submit transactions through the EntryPoint contract. The EntryPoint contract defines the required interface of a contract wallet, in favor of bundlers to run the off-chain simulation to determine if the transaction is going to succeed, and how much fee will be paid. The EntryPoint specifications set clear contract interfaces and restricted storage access, such that bundlers are able to run off-chain validations with controlled boundaries and results. With the EntryPoint contract, bundlers are now able to run transaction simulations before actually submitting transactions to the blockchain and protect themselves from wasting gas for failed or unpaid transactions.

UserOperation MemPool – Bundlers’ Incentives

A more fundamental question is, why the heck would I want to be a bundler? It’s pretty straightforward: bundlers are paid. As mentioned previously, bundlers are expected to always run off-chain simulations before actually submitting transactions to the blockchain. Bundlers will pre-calculate the income from bundling each transaction to prioritize transactions from the UserOperation MemPool. This is very similar to the block proposers’ behavior, where we could include priority gas fees in our transactions to incentivize block proposers to prioritize those transactions.

The incentive model could be quite complex since it involves many parties and distinct account behaviors. The MemPool could also be potentially fragmented among different bundlers. This is still an ongoing discussion for actually pushing out EIP-4337.

Users’ Incentives – Why Bundlers?

So bundlers are now satisfied to relay the transactions, kind of. They get paid after all. What about users? At first sight, you may feel that the whole EntryPoint architecture and on-chain validation/execution may consume much more gas than the existing contract wallet implementation. Users may still opt for a centralized transaction relayer for a lower cost, with just a little compromise to their wallet security. With a legit contract wallet implementation, the only tangible risk, after all, is just that their accounts will be malfunctioning due to service downtime. The very intuitive incentive for a user to switch from a centralized relayer to the public bundler network is simple – Sending a transaction via bundlers is cheaper. But how?

Let’s take a closer look at the gas consumption per transaction for different wallet architectures.

1. EOA wallet
   • Transaction Fixtures: The very basic fixtures for an EVM transaction, including ECDSA verification, account nonce verification, etc.
   • Transaction Content: The actual execution gas consumption required for the transaction itself, such as ERC20 transfer.
2. Non-EIP-4337 Contract Wallet
   • Transaction Fixtures: similar to EOA wallet
   • On-Chain Verification: Since the transaction is submitted via a relayer, the verification in the transaction fixture authorized the relayer but not the actual wallet owner. A smart contract wallet’s verification usually includes an ecrecover for an EOA private key, or even more complicated multi-sig verification logic.
   • Transaction Content: similar to EOA wallets
3. EIP-4337
   • Amortized Transaction Fixtures: Now it’s the time for us to come back to the idea of “bundling”. By bundling multiple transactions from different users, the cost of transaction fixtures is amortized.
   • EntryPoint Contract Execution: The extra execution logic within the EntryPoint contract adds up more gas consumption for the whole transaction.
   • On-Chain Verification: similar to non-EIP-4337 contract wallet
   • Transaction Content: similar to EOA wallets

Here we can see that with EIP-4337 bundlers, the cost of transaction fixtures is amortized among multiple transactions, but the EntryPoint contract execution introduces an extra cost. Note that the extra cost is mainly for loading the EntryPoint from storage and packing/unpacking user ops since the following verification logic is very likely to be the same given the same wallet contract implementation. Hence, the cost is also somewhat amortized among transactions in the same bundle. As a result, there is theoretically a sweet spot where the reduction of cost overruns the excess, and the dominant factor in finding it is the number of transactions bundled. In words, as there are more EIP-4337 participants, it’s more likely for users to turn to the shared bundler network for a lower cost per transaction.

Bundlers’ Trick – Aggregation

What if the amortization of transaction fixtures is not enough to attract users from a centralized transaction relayer? EIP-4337 proposes another partner for bundlers – the Aggregator. Aggregator is a smart contract that handles aggregated signatures verification. Instead of sending all user ops separately, bundlers can aggregate the signatures of multiple user ops and send them in a batch. To make this happen, EIP-4337 specifies that a wallet contract can provide the support aggregator list for the EntryPoint to know if the verification delegation is valid. The bundlers are then able to sort those user ops from the MemPool into the lists of user-ops-per-aggregator, run aggregator-specific code to create aggregated signatures, and submit those ops by batches. This will further amortize the On-Chain Verification part compared to the non-EIP-4337 contract wallet and hopefully, get us closer to the sweet spot to switch to the public bundler network.

These are purely hand-waving arguments. In fact, one of the biggest challenges of EIP-4337 is the high gas consumption by the nature of a pure smart contract solution. This is, again, an ongoing discussion to reduce the gas consumption of EIP-4337 to a reasonable level for users to adopt.

Now we seem to have a good incentive for users to switch from a centralized transaction relayer to a public, properly incentivized bundler network. Are we all done? Let’s take a closer look at one of Blocto Wallet’s key features—fee subsidization. Blocto Wallet pays the on-chain gas fees for users by charging them Blocto points, which is basically an off-chain payment method. How is this managed by EIP-4337?

Paymaster – Extension for Sponsored Transactions

Paymaster itself is another smart contract that pays the fee for sponsored transactions, of which the contract interface is defined in EIP-4337 and supported by the mighty EntryPoint contract. By including the paymasterAndData in a user op, the paymaster contract will handle the transaction gas with customized logic. This could be quite useful for many scenarios such as the following:

• A dApp paying the fee for its users, aiming to have a frictionless onboarding user experience
• A payment service provider charging fee payment in different currencies, including off-chain payment, on-chain tokens, or even provider-issued NFTs
• A privacy-preserving application, such as tornado cash, providing absolutely zero prerequisites for a wallet to interact with, even without having ETH for a gas fee

Closing

That’s it! These are pretty much all the pieces of EIP-4337. We started from an existing account abstraction solution, in our case Blocto Wallet, and tried to decentralize the transaction relayer while still keeping the sponsored transaction functionality by introducing all the components in EIP-4337 and the corresponding objectives.

• Bundler – The decentralized transaction relayers
• EntryPoint – The singleton contract that facilitates bundlers to validate UserOperations
• UserOperation MemPool and Fee – The model that incentivizes bundlers to relay and prioritize UserOperations
• Aggregator – The helper contracts that help bundlers to reduce gas consumption for bundled UserOperations by verifying aggregated signatures
• Paymaster – The extension contracts that fulfill the sponsored transaction feature

There are actually more details in the EIP. To protect the bundler network from malicious behaviors, such as sybil-attack, EIP-4337 introduces a sophisticated contract interface design, restricted storage access, forbidden opcode, bundler specifications, reputation scoring, and staking mechanism. Another topic we didn’t cover in this article is supporting contract wallet creation. Those nasty technical problems make the whole EIP a pretty tough read, but overall, it’s actually just trying to break down and solve those small puzzles of account abstraction, while keeping the fundamental feature of the blockchain ecosystem—decentralization.

As an abstract account wallet provider, Blocto is very excited to see the Ethereum community, which is so far the largest blockchain community, actively looking into the rather primitive EVM account system. We acknowledge that there are some shortages regarding the current contract wallet solution, especially for the low adoption rate and high gas consumption. Since the EVM ecosystem is so large, a widely adopted account abstraction solution could affect the user experience of the Web3 industry tremendously. We can’t wait to see that happen and be a part of it!

References

ERC-4337: Account Abstraction Using Alt Mempool

The road to account abstraction – HackMD

You could have invented Account Abstraction