What is EIP-3074: A Comprehensive Guide

TL;DR

EIP-3074, is a proposal that has garnered buzz among the account abstraction community because of both its advantages and disadvantages. The proposal allows externally owned accounts (EOAs) to authorize a smart contract to make transaction calls on behalf of the wallet. However, it is a reversible authorization, and control of the EOA’s private keys is never void during the process. 

The EIP introduces interesting benefits for EOA holders, like enjoying gas sponsorships, custom transaction logic, and many more that smart contract accounts in ERC-4337 can do, while still having the option to revert back into being an EOA.

However, caution needs to be taken because one wrong authorization could potentially siphon the wallet assets. The opcodes also introduce technical debt to EVM as the AUTH and AUTHCALL opcode will add complexity to its implementation, even long after all wallets become smart accounts already. To prevent this from happening, known Ethereum developers including Vitalik have proposed “flash smart accounts” in EIP-7702.

What is EIP 3074?

EIP 3074 is a new Ethereum proposal that allows (EOAs) to delegate account control to a smart contract. This allows any user-owned wallet to enjoy new features like custom account logic and gas sponsorships.

To make that possible, this proposal introduced two new opcodes, the AUTH and AUTHCALL.

AUTH works by taking in a ECDSA signature from the user and storing the user’s address as a context in the EVM. This signature signals the EOAs intent to allow the invoker contract to make transaction calls on behalf of the wallet. It is a revocable operation and can be undone by the user anytime. Once the AUTH message is sent by the EOA, then the invoker contract can use AUTH to recover the signer from the message.

Once the EOA has submitted a valid signature with the invoker’s address, the contract can now use the AUTHCALL opcode to execute a transaction on behalf of the EOA. This allows for a wide range of use cases, since the smart contracts are more flexible and programmable. It can:

1. Batch approve a chain of transactions with just one signature from the EOA
2. Execute gas-sponsored transactions
3. Sign an off-chain message that can be later used for recovery
4. Use custom logic to time and execute transactions

The Problem it Solves

Gas has been a long running UX issue to onboard users in Web3. Solutions have emerged, one of the most prominent being ERC-2771, a standard that enables an offchain third party called the relayer to pay for the gas on behalf of the EOA. This is made possible through metatransactions, a typed message that the EOA signs to signal its intent to trigger a transaction.

However ERC-2771 has a few problems, and one is that it requires dApps to upgrade their smart contracts in order to support metatransactions. The adoption turnout has run low and so ERC-4337 was introduced as a way to introduce gas sponsorship without needing any changes in existing dApp smart contracts.

The relayer in ERC-2771 is replaced by paymasters in ERC-4337, hence the executor of the transaction is separated from the gas payer. This allows the smart account to become the msg.sender or the caller of the transaction while having their gas fees sponsored.

Yet.. 

In ERC-4337, there is still no way for existing wallet accounts to convert into a smart account, so the authors of EIP-3074 came up with a solution that allows EOAs to delegate transactions to smart contracts. 

Benefits of EIP-3074

Now that we understand that the 3074 unlocks a variety of features for the EOA user, it is also important to note its specific advantages:

Complete user control - the user does not need to trust the invoker contract for good and for worse, and instead can decide to remove its authorization whenever vulnerabilities arise.

Faster adoption - having a gas-efficient and reversible way to try out ERC4337 accounts lowers the bar for users who want to test it without making big commitments. This hastens the roadmap for account abstraction and, ultimately, better web3 UX.

Aggregated interface - because EOAs simply delegate specific transaction control to smart contracts, there will only be one account abstraction interface for both EOA and native smart accounts. This means that the pipeline for development is simplified and does not need a complicated migration process or separate standards for developers.

EIP-3074 vs ERC-4337 vs EIP-5003

You could be wondering: we already have EIP-4337 to do gas sponsorships and easier account recoverability. Why do we need another standard to do that?

At first glance, EIP-3074 may seem like a contender for ERC-4337, but a closer look makes it clear that the two are meant to be combined in the case of external wallets. While ERC-4337 primarily focuses on transaction sponsoring and relaying, EIP-3074 also enables millions of users who already own a wallet to get the benefits that smart accounts get from account abstraction. This way, the features that can only be done with 4337 is not limited to newly created smart accounts. Wallet owners also now have the option to delegate their transaction calls to smart contracts.

How about EIP-5003?

You may have heard of a similar EIP that proposes converting wallets into smart contract accounts permanently. This is made possible by another opcode called AUTHUSURP. The assumption with EIP-5003 is that EOAs are meant to be migrated to smart accounts anyway, so there must be an option to leave the inflexibility of regular wallets for good.

It is different from EIP-3074 because it introduces a way to revoke the control of the previous wallet address completely. While transactions in 3074 are ultimately controlled by the EOA, 5003 removes access to the original EOA private keys, allowing for more versatile signature schemes to be implemented. 

Many developers in the account abstraction community rally for the AUTHUSURP opcode to be included as an extension of EIP-3074 or as a separate ERC because of its security and forward compatibility with the account abstraction roadmap.

Drawbacks of EIP 3074

While 3074 is generally great for web3 UX, it’s also important to note that it is also new and can come with some downsides:

Not multichain - if an EOA has delegated transaction to a smart contract account in one chain, it cannot be assumed that the same is true with the other chains and some more new chains. That makes it harder to implement consistent logic in the wallet across chains. 

Limited functionality - the access to private key is never revoked in the case of 3074. Which means, it can still be used to make transactions even when it has already delegated to a smart contract. This means that some features that you can implement with purely ERC-4337 accounts cannot be done in accounts that use 3074. Multisig smart contracts, arbitration, and fallback handlers can easily be bypassed by whoever has access to the EOA’s private key. 

Inflexible signature and recovery schemes - the account is still an EOA (that only has an authorized smart contract that can execute on behalf of it), so the signature and key recovery cannot be upgraded to, say, quantum-resistant options like how it can be done with smart accounts.

Security issues - one bad authorization can siphon all your wallet assets. So not only do the users have to check whether they are authorizing a secure contract to make calls for them, the developers also have to make sure that the smart contracts are secure and non-upgradeable.

Update: EIP-7702 to Replace EIP-3704

However, if everyone will be using smart accounts eventually (as planned), the AUTH and AUTHCALL opcodes can be a huge technical burden and add complexity to the EVM. So instead of having two opcodes to delegate the transaction execution to a smart contract and over-enshrining wallets, Ethereum developers have proposed a new EIP that will allow EOAs to become smart contract wallets upon creating a transaction and then revert back right after the transaction has been executed.

EIP-7702 introduces a new transaction type with a contract_code field and sends it along with the other details of the transaction. Take a look at what a payload in ERC-7702 looks like:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, [[contract_code, y_parity, r, s], ...], signature_y_parity, signature_r, signature_s])

This contract_code can be an existing smart contract wallet code in ERC-4337. The EOA only turns into a smart contract wallet in the duration of the transaction and reverts back into being an EOA, preventing any unintended actions from the smart contract.

Now what?

The prevailing view in the cryptocurrency space is that users will ultimately benefit from transitioning their wallets to smart contracts. As account abstraction gains traction, it's crucial not to overlook the needs of Externally Owned Account (EOA) users who may switch to more user-friendly smart contract accounts. Although external wallets currently dominate Web3 usage, EIP-3074 or EIP-7702 could be a vital link in the broader account abstraction strategy.

However, since the technology is still emerging, using the AUTH opcode requires careful consideration. It offers a valuable opportunity to experiment with and understand smart contract wallets, but users must remain vigilant and ensure their accounts are secure.

You might also like:

An ultimate guide to Web3 Wallets: Externally Owned Account and Smart Contract Wallet

Shamir’s Secret Sharing (SSS) vs. Threshold Signature Scheme (TSS) Explained