Can EIP-3074 make Ethereum simple again?

Author: LUKAS SCHOR & SAFE; Compiler: Vernacular Blockchain

Key Points:

Ethereum core developers have agreed to include EIP-3074 in the upcoming hard fork upgrade Prague/Electra (expected in Q4 2024/early 2025). EIP-3074 allows externally owned accounts (EOAs) to delegate their transaction capabilities to smart contracts, enhancing features such as transaction sponsorship and batch processing. While EIP-3074 is intended as a short-term fix to improve the user experience of EOAs, most of the Ethereum community still agrees that the ultimate goal is to migrate all users to smart accounts. EIP-3074 brings some improvements to smart accounts and is a step towards full AA (account abstraction, also known as smart contract accounts), but it absolutely requires the full support of EIP-5003. Without EIP-5003, we will further establish the status of EOAs.

1. What is EIP-3074?

EIP-3074 modifies the Ethereum protocol to allow externally owned accounts (EOAs) to delegate their transaction capabilities to smart contracts (called "callers"), thereby enabling the following additional features:

Sponsored transactions: dapps or other participants can sponsor the gas fees of transactions.

Batch transactions: This allows two or more contract calls to be executed in the same transaction. For example, a user can call approve and transferFrom in a single transaction.

Access delegation: Users can delegate control of their EOA to other keys that may have different security properties. For example, a user can add a mobile phone hot wallet key with a daily quota to their account.

These features are currently only available on smart accounts, which means that applications must build two different user experiences for EOAs and smart accounts.

2. Opportunities for Smart Contract Accounts (AA)

EIP-3074 mainly gives EOAs more power, but it also brings some new beneficial side effects to smart accounts:

Easier migration: With more power given to EOAs, users can migrate to smart accounts more easily. To date, an important challenge for users to convert to smart accounts is the workload and gas cost of migrating existing assets. EIP-3074 allows for smoother migration in single batches and sponsored transactions.

Unified user experience and development experience: dapps can build better user experience without excluding EOAs. This greatly increases the motivation to take advantage of sponsored transactions and transaction batching, as well as the standards around them. dapps often need to be adjusted to more flexible account logic, which will make smart account features (such as session keys or multi-signatures) better fit into the overall development framework.

Hybrid accounts: EOAs can set smart accounts as callers. For example, this would enable a smart account to control an EOA, while the EOA's private key still retains dominance and can disable secure controls. This could lead to interesting new hybrid custody use cases, or allow EOA users to "test" smart accounts before migrating assets.

3. EIP-5003: Bridging the gap with smart accounts

Although EIP-3074 allows control of an EOA to be delegated to a smart account, the original private key can still authorize any action on the EOA. This results in EIP-3074 being unable to introduce any (security) features, such as:

Multi-signature: Smart accounts are still required for multi-signature wallets or on-chain multi-factor authentication, because EIP-3074's EOA is always controlled by the original private key.

Recovery: While some recovery scenarios may be feasible, the primary private key that controls the EOA cannot be recovered (changed) using EIP-3074, so many recovery scenarios require a full smart account.

Quantum resistance: Ultimately, we will need to migrate users to Smart Accounts to achieve quantum resistance anyway, either naturally or via an emergency hard fork.

Other features: deny lists, co-signers/protectors, fallback handlers for different signature schemes depending on the use case.

There is a possible migration path discussed that could bridge this gap and allow existing EOAs to be fully migrated to Smart Accounts: EIP-5003. This upgrade extends EIP-3074 by allowing smart contract code to be deployed at the EOA address while revoking access to the original private key. This would allow the full conversion of an EOA to a Smart Account while retaining the public address, non-transferable tokens and reputation, and generally guaranteeing forward compatibility in the future account abstraction roadmap.

However, there are some concerns about the viability of this upgrade path, particularly related to the following edge cases: assuming that revoked private keys can still authorize operations on accounts:

Cross-chain: Revoked EOA keys remain valid on other networks, including those that may appear in the future. This could allow anyone to claim the same account on a different network and transfer assets with access to the original private key.

Sponsored Business Content

If an EOA is migrated to a Smart Account on a specific network, it cannot be assumed that the EOA will automatically migrate to the new network. Smart Accounts already face similar issues today, with inability to deploy on new networks and inability to synchronize state changes (key rotation). Cross-chain methods like key storage rolling may alleviate this problem to some extent.

Off-chain signatures: Compromised keys can still be abused in off-chain systems, such as dapp onboarding flows or permit2 token approvals, which verify signatures. While these systems may support smart contract signature standards such as EIP-1271, they are typically only used when standard ecrecover fails, leaving room for revoked keys to potentially compromise accounts.

It would be wise to always fail ecrecover (a function in Ethereum) for EOAs that have migrated to smart accounts in EIP-5003. The migration to smart accounts should be a clear and complete transfer of the new authentication logic.

4. Is EIP-3074 good or bad for AA?

Over the past few months, the community has tended to favor ERC-4337 as the first step toward full AA. It has helped the developer ecosystem get started, stabilized specifications and packaging tools, and created some lessons learned. It is then planned to implement native AA on Layer 2 (RIP-7560) and eventually introduce a similar EIP on Layer 1.

ERC-4337 initially started with exaggerated expectations, which helped to gain momentum and attract developers. There are positive signs that we are approaching a tipping point, with major exchanges (OKX, Coinbase) and wallets (Trust, Metamask) investing in support for ERC-4337. But exaggerated expectations also mean the inevitable sobering moment that achieving full AA (via RIP-7560 or similar) will take longer than initially expected, as there is still little interest and urgency for Layer 2 to commit to RIP-7560.

AA-related Ethereum standards/upgrades are going through their own "hype cycles".

This is one of the reasons why parts of the community are turning to EIP-3074. Since it seems too early to migrate users to smart accounts, some voices have become louder to at least partially fix the EOA problem in the meantime. EIP-3074 does not replace ERC-4337, they actually have considerable synergy, but it does shift the focus further away from ERC-4337/RIP-7560.

In order to achieve a full AA, we need to find a way to migrate existing EOAs. Since EOAs still make up the majority of Ethereum users, this affects the priorities of developers and teams. This can be done in two ways: (1) have users manually switch to Smart Accounts, or (2) implement a way to convert EOAs to Smart Accounts.

The inclusion of EIP-3074 runs the risk of moving us further away from achieving full AA. It strengthens EOAs, which has a negative impact on (1) while not truly solving the problem of (2).

Without EIP-5003, EIP-3074 currently lacks a clear path to achieve full AA and has a negative impact on AA adoption. More importantly, after the next hard fork upgrade Prague/Electra, there may no longer be a 2-year window to include AA-related upgrades as the focus will shift to verkle trees. Therefore, we should include EIP-5003 in the Prague/Electra upgrade to prevent further establishment of EOAs.

The impact of EIP-3074 on the AA roadmap, including with/without EIP-5003

5. Conclusion

The debate around EIP-3074 is a key node in the trajectory of Ethereum account abstraction.

The original AA roadmap: try application layer AA (ERC-4337), show native AA through L2 (RIP-7560), and finally introduce native AA on L1. Resolve legacy EOA issues via migration transactions (EIP-5003, EIP-7377 or even forced migration). This path may take much longer than expected and is hindered by the dominance of EOAs.

Action we should take: Implement EIP-3074, but also include EIP-5003 in the Prague/Electric hard fork to enable a full migration to smart accounts. This ensures that legacy users are not left behind while ensuring that they do not hinder AA efforts.

What we currently plan to do (worst case scenario): Implement only EIP-3074 and risk establishing EOAs, or at least severely hindering the adoption of smart accounts.

Crossroads of Ethereum AA Roadmap (Thanks to Vitalik for the improvement ideas)