The Road to Account Abstraction

Three years ago, in 2021, Ethereum’s lord and saviour Vitalik, proposed a new account-abstraction model, sparking a series of creative discussions that eventually led to the development of the now live ERC-4337: Account Abstraction Using Alt Mempool. The proposal marked the beginning of a lengthy and ambitious journey aimed at achieving absolute Account Abstraction (AA).

You can find SumCap’s 2023 research piece on it here → Account Abstraction - Wallets of the Future.

To put it simply, Account Abstraction aims to completely overhaul every facet of Ethereum’s account management - from the authentication, authorisation, replay protection to gas payment and execution - all whilst maintaining the core principles of network decentralisation and censorship resistance.

But the rabbit hole turned out to be deeper than everyone anticipated… 🕳️

In accordance woth the momentum from the relatively smooth implementation of the Shapella 🐉 (Shanghai & Capella) and Dencun 👻 (Deneb & Cancun) hard forks, Ethereum's upcoming hard fork was also anticipated to be straightforward. However, several analysts have raised concerns regarding one possible specific improvement proposal inclusion on Pectra’s hard fork, the EIP-3074.

At its heart, EIP-3074 is a straightforward proposal. It introduces two new opcodes, AUTH and AUTHCALL, which allows a smart contract - commonly referred to as an "invoker" - to assume control of an address. With this EIP, the Ethereum protocol itself does not handle the complexity of these AA features - instead, the responsibility is shifted to the application layer, specifically to invokers and relayers.

For the first time, externally owned accounts (EOAs) will be able to access the advantages of account abstraction, enabling additional functionality like:

• ⛽️ Sponsored transactions: Ability for dApps or other parties to sponsor the gas fee of a transaction.
• 🏗️ Batched transactions: Allow for two or more contract calls to be executed in the same transaction.
  • Example: A users will now be able to call an approve and transferFrom in a single transaction, allowing for a better swap UX.
• 🔏 Access delegation: Users can delegate control of their EOA to other private keys which might have different security properties.
  • Example: A user may add a phone hot wallet key with a daily allowance to their account.

In order to properly function and to disambiguate from all other types of signable data in Ethereum, EIP-3074 introduces a new message prefix to sign transactions that wallets like Metamask 🦊, will have to actively opt-in to allow this new feature.

Unfortunately, by excluding most of the complexity associated with AA from the specification, it opens up possibilities for implementations that carry risks, leading to an AA version that is more centralised and permissioned, the oposite of what was originally intended or desired!

A common misconception is that EIP-3074 alone enables AA - it actually facilitates only execution abstraction, allowing EOAs to execute calls via smart contracts, like transaction batching. The essence of account abstraction lies in validation abstraction - using smart contracts to validate transactions, enabling features like session keys.

Unlike EIP-7560, which incorporate validation directly into the Ethereum protocol, EIP-3074 depends on relayers to integrate Smart Account (SA) transactions with EOA transactions in order to function, only then can it achieve validation abstraction and unlock the main benefits of account abstraction.

Using EIP-3074 without a relay service is really challenging since it would require users to sign twice: once for AUTH and once for the transaction CALL, which leads to poor UX. Creating an invoker that functions as a ERC-4337 account (a smart account) with a permission-less mempool is extremely complex, meaning users and developers would inevitably be pushed towards the simpler option, centralised relayers.

💸 To further stir the pot, Ethereum is cheaper to censor than people realise, given how current block building is devised.

Censorship Resistance

The intended remedy for Censorship Resistance (CR) is EIP-7547: Inclusion Lists - a mechanism that allows block proposers to specify a set of transactions that must be promptly included for subsequent blocks to be considered valid. However, EIP-3074 is incompatible with EIP-7547, since the former introduces the possibility of “mutually exclusive transactions” - due to batching, which makes it impossible to produce an inclusion list that’s impossible to satisfy.

⚔️ A true battle between UX (EIP-3074) & CR (EIP-7547).

But what is a more urgent problem for Ethereum, user experience (UX) or censorship resistance (CR)? CR is foundational to Ethereum's value, but it's important to distinguish between what's important and what's urgent - CR is not a binary question, it's a spectrum.

Currently, ~38% of MEV-Boost Relays engage in censorship, a significant figure, yet censored transactions can still generally be processed via the public mempool if they wait there long enough. Those advocating to delaying or the remotion of EIP-3074 tend to view Ethereum's UX as acceptable for its current user base.

However, Ethereum and Web3 have not yet achieved widespread adoption, and most participants are just early users, which raises a pivotal question:

‍

❓ What is the value of implementing foolproof censorship resistance if Ethereum still lacks substantial user engagement? Perhaps the focus should instead be on enhancing usability to encourage broader adoption. ❓

‍

Despite focusing on adoption, EIP-3074 by itself does not fulfil the Ethereum community's ultimate AA goal of transitioning every user to smart accounts. EIP-5003: Insert Code into EOAs is an essential supplement that prevents the further entrenchment of EOAs by facilitating their smooth conversion into smart accounts, while keeping the public address, soulbound tokens and non-transferable reputation intact.

The initial plan for AA end game involved transitioning from application-level AA with ERC-4337 to native AA at the protocol level, addressing legacy/existing EOAs with migration options like EIP-5003. But, this lengthy and possible migration process is severely hindered by the dominance of EOAs.

A better strategy would be to implement EIP-3074 and incorporate EIP-5003 in the upcoming Pectra’s hard fork, ensuring a swift and comprehensive shift to smart accounts and overcoming the challenges posed by EOAs. This method expedites AA adoption and integrates all users smoothly.

• EIP-4337 is the best way to onboard new users to crypto.
• EIP-3074 + EIP-5003 is the best way to onboard existing EOA users to smart accounts.

Unfortunately since EIP-5003 has been flagged as Stagnant 🚧 it’s of no use in its current version.

So… what’s the solution? Well, after a somewhat big turmoil amongst core devs at Ethereum Foundation and on Crypto Twitter, Vitalik once again came in clutch and out of the blue with yet another possible solution, EIP-7702!

Smart Accounts as EOAs

EIP-7702: Set EOA account code for one transaction, co-authored by Vitalik and EIP-3074 authors, aims to give Smart Account like functionality to EOAs only for the duration of the transaction. In simple terms, during transaction execution, the EOA gains access to Smart Account code keeping the same public address that after completion reverts to a simple EOA again.

The essence of the proposal is to create a new transaction type known as "user operations", which differ from standard transactions because they do not require authentication via signature. Instead, they are authenticated by a smart contract wallet linked to the user’s account using its own verification logic, and if validated, a regular transaction is executed to the intended recipient. This new method provides enhanced flexibility in how transactions are authenticated, allowing for multiple signatures or the use of off-chain data like biometric proofs for validation!

Additionally, this transaction type is advantageous because, post-migration from EOAs → SA, the opcodes from EIP-3074 will become redundant, leading to technical debt in the EVM codebase.

Unfortunately, EIP-7702 also introduces complexities to Ethereum clients and wallets since it necessitates significant infrastructural changes, potentially leading to compatibility and security issues. increasing development efforts. Furthermore, the added computational steps for validating transactions might increase gas costs, prompting a need for effective gas optimisation strategies or the implementation of gas sponsorship mechanisms.

While the EIP is yet to be fully cooked, it has seen wide acceptance making it a promising alternative. The main distinctions are as follows:

EIP-3074 was well-intentioned but faced significant issues, including its future incompatibility with the Account Abstraction roadmap and the absence of separation between validation and execution. EIP-7702 addresses the same issues as EIP-3074 but seemingly without these shortcomings.

However, concerns about trusting bytecode and the need for whitelisting still apply to EIP-7702. It will be interesting to see how the community addresses these challenges!