The next hard fork upgrade of Ethereum, Prague/Electra, is planned to include both EIP-3074 and EIP-5003, taking into account EOA migration and AA development. This article is sourced from LUKAS SCHOR & SAFE.
Summary:
Ethereum core developers have reached a consensus to include EIP-3074 in the upcoming hard fork upgrade, Prague/Electra, scheduled for the fourth quarter of 2024 or early 2025. EIP-3074 allows externally owned accounts (EOA) to delegate their transaction capabilities to smart contracts, enhancing transaction sponsorship and batch processing functionalities.
While EIP-3074 is a short-term fix aimed at improving the user experience of EOAs, the Ethereum community believes that the ultimate goal is to migrate all users to smart accounts. EIP-3074 brings some improvements to smart accounts and serves as a step towards achieving complete Account Abstraction (AA), but it still requires comprehensive support from EIP-5003.
EIP-3074 modifies the Ethereum protocol, allowing EOAs to delegate their transaction capabilities to smart contracts, referred to as “callers,” thereby enabling the following additional functionalities:
– Transaction sponsorship: DApps or other participants can sponsor the fuel cost of transactions.
– Batch transactions: This allows the execution of multiple contract calls in a single transaction. For example, a user can call “approve” and “transferFrom” in a single transaction.
– Delegated access: Users can delegate control of their EOA to another key with potentially different security attributes. For example, users can add a mobile hot wallet key with a daily spending limit to their account.
These functionalities are currently only available on smart accounts, which means that applications must build two different user experiences for EOAs and smart accounts.
EIP-3074 primarily empowers EOAs with more capabilities, but it also brings some new beneficial side effects to smart accounts:
– Easier migration: By granting more capabilities to EOAs, users can easily migrate to smart accounts. Previously, migrating existing assets to smart accounts posed a significant challenge in transitioning users, in terms of workload and fuel costs. EIP-3074 allows for smoother migration in a single batch and sponsored transaction.
– Unified user experience and development: DApps can build better user experiences without excluding EOAs. This greatly increases the motivation to utilize transaction sponsorship and batch processing, along with the standards surrounding them. DApps often need to adjust for more flexible account logic, which will better accommodate smart account features such as session keys or multisig within the overall development framework.
– Hybrid accounts: EOAs can set smart accounts as callers. For example, this would allow a smart account to control an EOA while the private key of the EOA remains dominant and can disable secure control. This could lead to interesting new types of hybrid custody use cases or enable EOA users to “test” smart accounts before migrating assets.
Although EIP-3074 allows delegating control of EOAs to smart accounts, the original private key still authorizes any operations on the EOA. This means that EIP-3074 cannot introduce any (secure) functionalities such as multisignature wallets or on-chain multi-factor authentication, as smart accounts are still required for those.
To bridge this gap and allow for a full migration of existing EOAs to smart accounts, a feasible migration path is being discussed: EIP-5003. This upgrade extends the capabilities of EIP-3074, allowing for the deployment of smart contract code at EOA addresses while revoking access permissions to the original private key. This fully converts the EOA into a smart account while retaining the public address, non-transferable tokens, reputation, and generally ensuring forward compatibility with the future account abstraction roadmap.
However, there are concerns regarding the feasibility of this upgrade path, particularly regarding issues related to the assumption that the revoked private key can still authorize operations on the account:
– Cross-chain: Revoked EOA keys remain valid on other networks, including future networks that may emerge. This could allow anyone to declare the same account and transfer assets on different networks by accessing the original private key. If EOAs are migrated to smart accounts on a specific network, it cannot be assumed that EOAs will automatically migrate to the new network. Smart accounts already face similar issues today, where they cannot deploy on new networks or synchronize state changes (key rotation). Cross-chain methods like key storage rolling could mitigate this problem to some extent.
– Off-chain signatures: Leaked keys can still be abused in off-chain systems, such as DApp login processes or approvals for permit2 tokens, which verify signatures. While these systems may support smart contract signature standards like EIP-1271, they are usually used only as a fallback when the standard ecrecover fails, leaving room for compromised keys.
A prudent approach would be to always make ecrecover (a function in Ethereum) fail for EOAs that have been migrated to smart accounts in EIP-5003. The migration to smart accounts should be a clear and complete transition to new identity verification logic.
In the past months, the community has leaned towards using ERC-4337 as the first step towards achieving complete AA. It provided assistance for the bootstrapping of the developer ecosystem, stabilized specifications and tooling, and created some valuable lessons. The plan is then to implement native AAs on Layer 2 (RIP-7560) and eventually introduce a similar EIP on Layer 1.
The initial expectations for ERC-4337 were exaggerated, which helped attract motivation and developers. There are positive signals indicating that we are approaching a tipping point, with major exchanges (OKX, Coinbase) and wallets (Trust, Metamask) investing in supporting ERC-4337. However, the exaggerated expectations also mean an inevitable reality check, that achieving complete AA (via RIP-7560 or similar means) will take longer than initially expected, as there is still limited interest and urgency in focusing on RIP-7560 for Layer 2.
The debate surrounding EIP-3074 is a critical juncture in the Ethereum account abstraction roadmap.
The original AA roadmap aimed to implement AA at the application layer (ERC-4337), demonstrate native AA on Layer 2 (RIP-7560), and eventually introduce native AA on Layer 1. The challenges lie in finding a way to migrate existing EOAs since EOAs still dominate the Ethereum user base, influencing the priorities of developers and teams. This can be achieved through two methods: (1) manually switching users to smart accounts, or (2) implementing a way to convert EOAs into smart accounts.
Including EIP-3074 carries the risk of further distancing us from achieving complete AA. While it enhances EOAs, it has a negative effect on (1) and does not truly solve the problem of (2).
Without EIP-5003, EIP-3074 currently lacks a clear path for achieving complete AA and adversely impacts the adoption of AA. Furthermore, there may not be another two-year window to include AA-related upgrades after the Prague/Electra hard fork upgrade, as the focus will shift to verkle trees. Therefore, it is recommended to include EIP-5003 in the Prague/Electra upgrade to prevent further entrenchment of EOAs.
The action we should take is to implement EIP-3074 while including EIP-5003 in the Prague/Electra hard fork to achieve a complete migration to smart accounts. This ensures that legacy users are not left behind while also ensuring they do not hinder AA efforts. The worst-case scenario would be to only implement EIP-3074, risking the establishment of EOAs or at least severely impeding the adoption of smart accounts.