Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337

Ismael Darwish
Nethermind.eth
8 min readFeb 3, 2022

--

By Ismael Darwish.
Special thanks to
Kristof Gazso and Jorge Mederos from Nethermind, Sam Wilson and Matt Garnett from ConsenSys, and Yoav Weiss from OpenGSN for feedback.

Table of contents:

  • Introduction
  • Accounts and wallets
  • Wallets today
  • Better wallets today
  • Better wallets tomorrow — EIP 3074 & ERC 4337
  • The long term plan
  • Wen standard smart contract wallets?

Introduction

Wallets in Ethereum today are pretty limited. For simplicity, when Ethereum was initially created, the wallet mechanism was inspired by previous blockchains with battle-tested solutions. But pretty early on, developers were well aware of the limitations and possibly better solutions that could be added in future versions of Ethereum. After many proposals and iterations, it seems we’re very close to having a definite solution.

Accounts, Wallets, and Account Abstraction

In Ethereum today, there are two types of accounts: Ones controlled by the user’s private keys, known as externally owned accounts (EOA), and Smart Contract accounts, controlled by their code. Today, a transaction can only start from an EOA containing ETH to pay for it, and those transactions can interact with smart contracts with arbitrary logic.

A wallet in Ethereum refers to a system used to hold users’ funds. An EOA is the most common type, but specially designed smart contracts can also be wallets, and we call these smart contract wallets.

Account Abstraction is the process of making all Ethereum accounts nearly indistinguishable, effectively removing the need for EOAs and special handling for smart contract wallets.

Wallets today

Simplified EOA transaction mechanism

The vast majority of wallets used in Ethereum today are EOAs. Users randomly choose their 256-bit private key to get their EOA. Given the extremely low chance that two randomly chosen keys access the same account (comparable to picking the same grain of sand on Earth twice), it’s fair to assume it’s impossible.

To execute transactions, users use their private key to sign them with a standard ECDSA signature and then send them to the Ethereum network for miners to include in a block.

It’s important to note that for a transaction to be included in a block, a fee in ETH has to be paid to the miner and burned, as per EIP 1559. This means that, although the creation of an EOA is free, executing transactions requires the user to find a way to send ETH to that EOA first. Some solutions might involve using an exchange or having someone you know send ETH to that account.

The Ethereum community has expressed several concerns with EOAs. Today these concerns include:

  • Key management: Since the only way to access the funds is by knowing the private key, managing how to store the key and who has access to it can pose a difficult and stressful challenge.
  • Reliance on ECDSA signatures: Simpler and quantum-resistant digital signatures are a clear improvement over the current ECDSA.
  • Transactions are tied 1 to 1 with actions: Not being able to perform more than one action at a time can incur unnecessary costs and a poor user experience.

The solutions below try to address them.

Better wallets today

Smart contract wallet transaction

As outlined earlier, smart contract wallets are smart contracts specifically designed to hold and manage users’ funds and actions. Current solutions like Argent, Gnosis, or Loopring wallets have advanced functionality compared to EOAs.

Since transactions can only start from an EOA, in an effort to improve the user experience, these projects offer relay services that take the signed messages from users and submit them on-chain from the service provider’s EOA, with a custom fee mechanism that returns ETH to the EOA to make the whole process sustainable. It’s important to note that these transactions can be started from any EOA, giving the user complete ownership over their funds, but the process would be more cumbersome.

There’s no standard for smart contract wallets to operate on, so each project has to turn to meta-transaction solutions like GSN or take on the effort of creating and managing their own relayer service, as well as managing the fee mechanism and auditing their complex smart contracts. In turn, their users get the added benefits a smart contract wallet can offer. Some of these improvements include:

  • Social recovery: Users can determine a list of accounts that can make use of the user’s funds or recover access to their wallet. This is extremely useful, giving the user the peace of mind of not having to worry about losing their keys. Also, in case of a fatal accident, those accounts could come together to retrieve funds.
  • Multisig transactions: Transactions that need the approval of more than one user to go through.
  • Batched transactions: Users can bundle together a set of actions they want to perform in a single transaction, improving the experience significantly by saving fees and ensuring the sequence and atomicity of the actions.
  • Custom verification logic: The smart contract wallet can include custom ways of verifying the user’s intent, using simpler or quantum-resistant signatures.

The benefits of smart contract wallets over regular EOAs are clear, and the Ethereum community has been working on standards to include these benefits natively into the protocol.

Better wallets tomorrow — EIP-3074 & ERC-4337

Given the need for a standard way for these more advanced wallets to operate, proposals have been suggested for years. Currently, the community is discussing seemingly opposing solutions:

  • Give EOA wallets smart functionality.
  • Give standard EOA functionality to smart contract wallets.
EIP-3074 transaction flow

One proposal for giving EOAs advanced capabilities is formalized in EIP-3074 by Sam Wilson, Matt Garnett, and others.

This solution involves adding two new opcodes to the EVM: AUTH and AUTHCALL, which are meant to be used by smart contracts referred to as “invokers.” These invokers gain control over the EOA that authorizes them and can make calls on their behalf.

With EIP-3074, users sign a message with their private keys that contains their intent. That message then gets included in a transaction on-chain that calls an invoker. The invoker uses the signed message alongside the AUTH opcode to gain control over the user’s account, and with AUTHCALL it can perform actions on behalf of the user. It’s important to note that the transaction containing the user’s signed message doesn’t necessarily have to be sent from that user’s account, which frees a user from relying on ETH at all to send transactions. In fact, it might be possible to pay fees in other ways, such as with ERC-20 tokens.

EIP-3074’s invokers are an instant upgrade to every EOA in Ethereum. The proposal doesn’t require existing users to migrate all their assets to a new kind of wallet to benefit from it (like with ERC-4337 discussed below). The opt-in mechanism of EIP-3074 can be thought of as adding extensions to your EOA.

There are several concerns about this approach, mainly arguing that giving invokers so much power can lead to catastrophic events similar to the DAO hack.

Out of these discussions, ERC-4337 was proposed based on a concept by Vitalik Buterin.

ERC-4337 transaction flow

ERC-4337 achieves account abstraction by replicating the functionality of the transactions mempool in a higher-level system. Instead of transactions, users send UserOperation objects to Ethereum bundlers, and they package a set of these objects into a single bundle transaction that gets included in the Ethereum chain.

These bundle transactions are handled by an “Entry point” contract that handles the deployment of the user’s wallets and takes care of User Operation objects verification by querying the deployed wallet.

The UserOperation is ultimately handled by the smart contract wallet the user chooses, given that it includes the necessary logic to interact with EntryPoint.

The long term plan

Discussions around these implementations led developers to try to outline a long-term plan for both proposals. Given the UX and security issues of current EOAs, acknowledging a future where current EOAs are eradicated is obvious.

Proponents of ERC-4337 see a path where in the future, this new User Operation mempool could replace the current transaction mempool. An Ethereum hard fork would transform all existing EOAs into smart contract wallets with the ability to be upgraded, in a similar fashion as the attempt already tried by Optimism. EIP-3074 would be challenging to adapt to this vision, generating a lot of technical debt in a post AA Ethereum. For that reason, ERC-4337 proponents suggest changes to 3074 that would either make it easier for it to be removed in the future or simplify its mechanism to adapt it to the new structure easily.

On the other hand, EIP-3074 proponents frame the question from a different angle, where wallets are focused on validating the user’s intent, providing a different path towards account abstraction where EIP-3074 and account abstraction complement each other. In this roadmap, EOAs are replaced by a basic smart contract wallet with functionality to ban invokers from being authorized to perform actions on their behalf, mitigating the concerns about malicious invokers.

Wen standard smart contract wallets?

Soon™. Both proposals are close to being ready for adoption, but given the different nature of the changes, timelines look a bit different:

EIP-3074 is a Core EIP, meaning it modifies the consensus mechanism, requiring an Ethereum hard fork to be implemented. This EIP is being discussed for inclusion in the Shanghai fork sometime this year after The Merge. Still, in terms of implementation, it’s relatively simple for node developers to include.

By contrast, implementing ERC-4337 requires more code than 3074, but development can be unaffected by The Merge since it doesn’t need an Ethereum fork to be implemented. There’s already support for it from Nethermind, very soon in Go-Ethereum clients, and a working implementation in the Goerli testnet. There’s also ongoing work to fork other projects like Metamask to support it and active talks with L2s to adopt it.

The two solutions proposed are the result of years of experimentation with the goal of improving Ethereum users’ experience. The days when we’ll laugh about the idea of having to rely on a piece of paper to access blockchains are very close. Account abstraction is a giant leap forward toward mainstream Ethereum, and it’s just around the corner.

There are many cool projects at Nethermind, and we’re always looking for passionate people to join us. If you’re interested in working on Ethereum, drop us an email with your CV at talent@nethermind.io.

--

--