原文作者:LUKAS SCHOR & SAFE
原文来源:safe.global
原文标题：EIP-3074: Risks/Opportunities for Smart Account Adoption (and why we need EIP-5003)
Compilation: Vernacular blockchain
Main points of the text:
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 trading power to smart contracts, enhancing features such as transaction sponsorship and batch processing. While EIP-3074 serves as a short-term fix to improve the user experience for EOA, 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 achieving full AA (Account Abstraction, also known as smart contract accounts), but it definitely requires full support from EIP-5003. Without EIP-5003, we would further establish EOA.
1. What is EIP-3074?
EIP-3074 modifies the Ethereum protocol to allow externally owned accounts (EOAs) to delegate their transaction power to smart contracts (referred to as "callers"), enabling the following additional functionality:
Sponsored Deals: Gas costs that DApps or other participants can sponsor deals.
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 attributes. For example, a user can add a mobile hot wallet key with a daily credit to their account.
These features are currently only available on Smart Accounts, which means that the app has to build two different user experiences for EOA and Smart Accounts.
2. Smart contract account (AA) opportunities
EIP-3074 mainly gives EOAs more power, but it also introduces some new beneficial side effects for smart accounts:
Easier migration: By giving EOAs more power, users can migrate to Smart Accounts more easily. To date, a significant challenge for users to convert to a Smart Account has been the effort and gas cost of migrating existing assets. EIP-3074 allows for smoother migrations in individual batch and sponsored transactions.
Unified user experience and development experience: dapps can build a better user experience without excluding EOAs. This greatly increases the incentive to utilize sponsored deals and deal batches, as well as the standards surrounding them. DApps often need to be tweaked to more flexible account logic, which will allow smart account features such as session keys or multisig to better fit into the overall development framework.
Hybrid Accounts: EOAs can set up smart accounts as callers. For example, this will enable smart accounts to control EOA, while EOA's private key remains dominant and secure controls can be disabled. 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 the EOA to be delegated to a smart account, the original private key can still authorize any operation on the EOA. This prevents EIP-3074 from introducing any (security) features, such as:
Multi-signature: A smart account is still required for multi-signature wallets or on-chain multi-factor authentication, as EIP-3074's EOA is always controlled by the original private key.
Recovery: While some recovery scenarios may be feasible, there is no way to recover (change) the primary private key that controls EOA using EIP-3074, so many recovery scenarios require a full Smart Account.
Quantum Resistance: Ultimately, we will need to migrate users to smart accounts anyway in order to achieve quantum resistance, either through natural migration or through an emergency hard fork.
Other features: deny lists, co-signers/protectors, fallback handlers that require different signature schemes depending on the use case.
One feasible migration path was discussed that could bridge this gap and allow for the full migration of existing EOAs into Smart Accounts: EIP-5003. This upgrade extends EIP-3074 to allow access to the original private key to be revoked while the smart contract code is deployed at the EOA address. This allows EOA to be fully converted into a smart account, while retaining the public address, non-transferable token, and reputation, and generally guaranteeing forward compatibility in future account abstraction roadmaps.
However, there are some concerns about the feasibility of such an upgrade path, particularly in relation to the marginal case where it is assumed that a revoked private key can still authorize operations on the account:
Cross-chain: Revocation of EOA keys is still valid on other networks, including networks that may appear in the future. This may allow anyone to claim the same account and transfer assets on different networks by accessing the original private key.
If you migrate EOA to a Smart Account on a specific network, you cannot assume that EOA will automatically migrate to the new network. Smart accounts are already facing similar issues today, not being able to deploy on a new network, and state changes (key rotations) not syncing. Cross-chain approaches like keystore rollover may alleviate this issue to some extent.
Off-chain signatures: Compromised keys can still be misused in off-chain systems, such as the login flow of a DApp or the approval of a permit2 token, which verifies the signature. While these systems may support smart contract signing standards such as EIP-1271, they are usually 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) in EIP-5003 for EOAs that have been migrated to smart accounts. Migrating to a smart account should be a clear and complete transfer of the new authentication logic.
4㉘EIP-30744aase377777777777773?
Over the past few months, the community has leaned towards ERC-4337 as the first step towards full AA. It helped launch the developer ecosystem, stabilized the specification and packaging tools, and created some lessons learned. This is followed by plans to implement native AA (RIP-7560) on Layer 2 and eventually introduce a similar EIP on Layer 1.
ERC-4337 initially started with exaggerated expectations, which helped to attract momentum and attract developers. There are positive signals that we are approaching a tipping point, and major trading platforms (OKX, Coinbase) and wallets (Trust, Metamask) are investing in ERC-4337. But exaggerated expectations also mean an inevitable wake-up moment that achieving full AA (via RIP-7560 or similar) will take longer than initially anticipated, as interest and urgency to commit to RIP-7560 remains small for Layer 2 at the moment.
AA-related Ethereum standards/upgrades are going through their own "hype cycles".
This is one of the reasons why part of the community is switching to EIP-3074. Since it seemed too early to migrate users to smart accounts, some voices became louder, at least partially fixing the EOA issue in the meantime. EIP-3074 does not replace ERC-4337, they actually have a considerable synergistic effect, but it does shift the focus further away from ERC-4337/RIP-7560.
In order to achieve full AA, we need to find a way to migrate our existing EOA. Since EOA still accounts for the majority of Ethereum users, this impacts the priorities of developers and teams. This can be achieved in two ways: (1) by having the user manually switch to a Smart Account, or (2) by implementing a way to convert EOA to a Smart Account.
The inclusion of EIP-3074 runs the risk of moving us further away from achieving full AA. It enhances EOA, which negatively serves (1) and doesn't really solve the problem of (2).
Without EIP-5003, EIP-3074 currently lacks a clear path to full AA and negatively impacts AA adoption. What's more, there may not be another 2-year window to include AA-related upgrades after the next hard fork upgrade, Prague/Electra, as the focus will shift to the verkle tree. Therefore, we should include EIP-5003 in the Prague/Electra upgrade to prevent further EOA status.
Impact of EIP-3074 on the AA roadmap, including with/without EIP-5003
5. Summary
The debate surrounding EIP-3074 is a key node in the abstraction trajectory of Ethereum accounts.
Original AA Roadmap: Experiment with AA at the application layer (ERC-4337), demonstrate native AA via L2 (RIP-7560), and finally introduce native AA on L1. Address legacy EOA issues by migrating transactions (EIP-5003, EIP-7377, or even forced migration). This path is likely to take much longer than expected and is hampered by EOA's dominance.
What we should do: Implement EIP-3074 but also include EIP-5003 in Prague/Electrical Hard Fork for a full migration of Smart Accounts. This ensures that legacy users are not left behind, while at the same time ensuring that they do not hinder AA's efforts.
What we plan to do at the moment (worst-case scenario): just implement EIP-3074 and run the risk of establishing an EOA, or at least a serious hindrance to smart account adoption.
Crossroads of the Ethereum AA roadmap (thanks to Vitalik for the improvement ideas)