A Complete Guide to EIP-3074

Ethereum improvement proposal (EIP) 3074 was just approved for inclusion in the upcoming Prague/Electra hard fork. This EIP aims to simplify transaction processes and reduce costs through third-party transaction sponsorship.

Basically, 3074 allows an externally owned account (EOA) to delegate various actions to smart contracts. This change will significantly alter how users interact on EVM chains, enhance wallet UX, and, ultimately, make Ethereum more accessible. 

Solving UX problems for EOAs

To understand EIP-3074, you must first understand the problems it's trying to address. At its core, this proposal is looking to remedy various UX challenges inherent in Ethereum transactions, including: 

• the need for separate transactions for token approvals
• a lack of defense against lost keys
• the inability to perform actions without Ether 

The root of these problems is how contracts are developed in Ethereum. Most contracts rely on the message sender as an authentication mechanism, which poses challenges when chaining transactions together as the message sender changes at each step. 

One solution is creating a standard way for more advanced wallets to operate.

Enter EIP-3074

Formalized by Sam Wilson, Matt Garnett, et al., EIP-3074 can be thought of as an evolution of EIP-2938. While this is true, 3074 isn't really account abstraction (AA) in the purest sense.

Rather, it represents the way many people have come to understand AA, which is really more about allowing smart account features, like batching and recovery, something 3074 will provide to most users.

Okay, so what is it actually?

EIP-3074 introduces two new operations to the EVM: AUTH and AUTHCALL. These operations allow third-party transaction sponsorship through a smart contract (sometimes defined as an "invoker"), a built-in method for separate entities to cover gas fees associated with user transactions. 

To break each down:

The "auth" operation functions by taking a signed message from a user, recovering the address from that message, and placing it into a context variable within the EVM. This process authenticates the user, similar to how a meta-transaction operates, but without the need for an intermediary contract. 

The "authcall" operation mirrors the functionality of the existing "call" opcode but updates the sender of the call from the invoker of these operations to the authorized address.

In action, users sign a message with their private keys, signaling their intent. That message then gets included in a transaction onchain that calls an invoker contract. 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.

Crucially, invoker contracts enforce transaction rules encoded in the commit, providing flexibility in implementation.

The flow looks something like this:

Benefits of 3074

The introduction of EIP-3074 enables a lot of cool things, including

1. signing one message off-chain to be used later as an account recovery mechanism 
2. batching approve and execute transactions into a single interaction
3. an Ether-less EOA to transact via sponsored transactions

Ultimately, the appeal of EIP 3074 lies in its simplicity and versatility. By leveraging cryptographic signatures, EOAs can authorize invoker contracts to act on their behalf, significantly streamlining processes and enhancing user experience. 

EIP-3074  vs EIP-4337

It has taken a while to get here. And support for EIP-3074 has grown slowly over the years. At the same time, there's been a debate, with some arguing against giving invokers so much power. Out of these discussions, ERC-4337 was proposed based on a concept by Vitalik Buterin.

EIP-4337 often gets compared to 3074 due to their common goals. And at a glance, they can appear as two somewhat opposing solutions: 1) Give EOA wallets smart functionality (3074) or 2) create a new class of accounts that upgrades how we interact with Ethereum (4337).

People like to weigh EIP-3074 against 4337, but it's not a good comparison. It's like comparing a screwdriver to a toolkit.

Both proposals aim to advance AA, but they do so in different ways. While EIP 3074 provides a foundational tool for developers to build on, EIP 4337 offers a more opinionated, application-level standard. Where EIP-4337 adopts an account-driven design, EIP-3074 focuses more on validation, leveraging cryptographic mechanisms for authentication. 

And truthfully, they can play nicely together. 

EIP-4337…how works?

EIP-4337 achieves account abstraction by replicating the functionality of the transaction mempool in a higher-level system. It should be said, though, that a decentralized mempool is still on the wishlist. 4337 then is effectively supercharged meta-transactions. 

With 4337, what's really happening under the hood is that the standard defines a smart contract wallet similar to Gnosis Safe and also defines a few extra parameters on how someone can interact with it.

There are two key players in this ecosystem: there are now paymasters, and there are entry point contracts. Entry point contracts act as a gateway that's similar to 3074 invokers, so it's this gateway contract that allows paymasters or the owner of an EOA to submit transactions to their 4337 wallets.

To put it lightly, with an entry point, you, a paymaster who's doing meta-transactions, so to speak, can sponsor an operation on your behalf via the entry point contract. In essence, it adds a trustless layer with a bunch of stuff built on top of it.

For more depth:

EIP-3074: Security considerations

EIP-3074 offers substantial benefits, but of course, it's important to assess its security implications. This has been done for years, and the result is that EIP-3074 incorporates various security protocols to safeguard the ecosystem and shield users from potential threats. 

The discussion is focused on ensuring the implementation of robust invokers that prioritize security measures. These invoker contracts, responsible for executing user transactions, require the right design to avoid unauthorized access and prevent nefarious use. They need to be fully audited, non-upgradeable, and trustless; otherwise, funds can easily be stolen.

Numerous strategies for constructing secure invokers have been considered, including things like employing multisigs and implementing time-locked authorizations. Here's a bit more:

Final thoughts 

The community opted for EIP-3074 because the road to full AA (via EIP-4337 & RIP-7560 or similar) will likely take longer than initially expected. In the meantime, it makes sense to fix EOAs. This is good news, but EIP-3074 is also not a cure-all.

For instance, with 3074, key rotation becomes trickier, and it will also open up a new class of potential attacks. Further, as mentioned in a recent post by Lukas Schor, the introduction of 3074 carries the risk that it will bring us further away from achieving full AA.

"Without EIP-5003, EIP-3074 currently lacks any clear pathway to full AA and has a net-negative impact on AA adoption. Even more, after the Prague/Electra hard fork, there might not be a window to include AA-related upgrades for another two years as focus will shift towards verkle trees. Therefore, we should include EIP-5003 in the hardfork to prevent having EOAs enshrined further.''

It's a reasonable point about 5003. With any opcode, new attack possibilities are expected. And we need 4337 as much as we needed yesterday. Yet, the inclusion of EIP-3074 is still exciting due to its potential to transform the user experience on Ethereum. In the near term, it will open the door to a wide range of innovative applications and create a new design space for developers to explore. We can't wait to see what people do with it.

ChainSafe is currently experimenting with a PoC implementation of an EIP-3074 plugin for web3.js. Learn more about plugins → here

For those interested, there's an ongoing discussion about implementation details on the ethresearch forum → here

EIP-3074 at Ethereum Developer Meetup Toronto

Special thanks to Gregory Markou, Phil Ngo, and Ben Adar for their contributions to this article.

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in protocol engineering, cross-chain interoperability, and web3 gaming. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, and Filecoin, ChainSafe creates solutions for developers across the web3 space utilizing expertise in gaming, interoperability, and decentralized storage. As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open-source and community-oriented ethos to advance the future of the internet.

Website | Twitter | Linkedin | GitHub | Discord | YouTube | Newsletter