Recently announced, EIP-3074 will be included in the next Ethereum hard fork as a protocol-level improvement for the user experience of Ethereum wallet users. The Ethereum community has had various reactions to this announcement: celebration (“…a major upgrade for the Ethereum user experience” – Uniswap founder), concern (“…a big problem” – Gnosis founder), and confusion (“…mixed feelings…uncertain if this is the right strategy” – one of the authors of EIP-3074).
So, what is EIP-3074 exactly? Is it safe for user assets? How does it differ from smart contract wallets, account abstraction, or ERC-4337? And why does the Ethereum community use confusing numbers to name everything?
If you are a regular user or developer of the Ethereum Virtual Machine (EVM), it is important to understand the next steps in wallet development. But first, let’s start from the beginning.
EOAs and Smart Contract Wallets
The basic account primitive of the EVM is the externally owned account (EOA).
Account: an Ethereum address (e.g., 0xabcdef)
Externally owned: the controller of the address possesses the cryptographic private key
Another type of Ethereum “account” is a smart contract, which also has an address but contains code and doesn’t have native control keys: if you want to send a transaction through a smart contract account, you need to build that functionality into its code!
All transactions on Ethereum must be initiated by EOAs, making them the most common type of Ethereum account for users so far. However, EOAs have several major user experience and security drawbacks:
They need to have enough ETH in transactions to use as gas (this can be problematic if a user has other valuable assets like NFTs but no ETH)
They cannot send bundled transactions atomically or interact with >1 smart contract
They cannot have on-chain recovery mechanisms (e.g., social recovery)
They are easily leaked, and if leaked, all your assets can be stolen
To address these challenges, a long-term goal in the blockchain research community has been “account abstraction” (AA): transitioning users from EOAs to “smart contract wallets” controlled by on-chain code. Users typically still need some key material on their devices, but we can write arbitrary logic into smart contract code to control user assets and solve the above problems.
Some chains have introduced account abstraction as a native primitive (e.g., Starknet), while Ethereum has been content to let wallet providers create their own smart contract wallet implementations. Now, there are dozens of smart contract wallets, each offering different functionalities for different purposes (e.g., Gnosis Safe, Argent, Coinbase smart wallet, Immutable Passport).
However, the numbers speak for themselves: less than 0.1% of Ethereum users use smart contract wallets, while there are still tens of millions of active Ethereum EOAs. Getting these users to switch is a daunting task and a security nightmare.
How does EIP-3074 help?
Proposed at the end of 2020, EIP-3074 aims to bring some benefits of account abstraction to EOA users without fully transitioning their accounts to smart contract wallets.
EIP-3074 introduces two new opcodes: AUTH and AUTHCALL. These opcodes allow users to temporarily delegate control of their EOA accounts to another account (“invoker,” typically a smart contract) by signing a message. Then, another account (“sponsor/bundler”) sends a transaction using that message and the AUTH opcode to formalize the delegation on-chain. The “invoker” account can then use AUTHCALL for user transactions.
There may be some standard invoker contracts (e.g., batch processors), and these invokers will replicate some key user experience advantages of account abstraction!
Batch transactions
Consider the common flow of ERC20 approve + transfer, which currently requires two separate Ethereum transactions from an EOA. By delegating to a batch processor, this can be reduced to a single transaction (although the wallet still needs to display two confirmations). Additionally, many apps try to avoid the “double ask” in subsequent interactions by requesting unlimited spending approval during the user’s initial interaction. This exposes users fatally to any future flaws in these protocols, so avoiding it would yield a huge security improvement!
Gas sponsorship
Assume a user’s wallet has $20 worth of USDC but no ETH to pay for gas fees (e.g., swap fees). A dapp can request the permission to act on behalf of the user by invoking, pay the gas fees themselves, and seek compensation from the user’s USDC balance. The invoker contract must include logic to restrict the transactions it sends to only those approved by the user through explicit signatures.
Other custom invokers may follow, allowing users to access this UX without leaving their existing, familiar wallets (assuming those wallets add EIP-3074 support).
How is this different from ERC-4337?
Wait, didn’t we already have a proposal for account abstraction with a weird number? What happened to ERC-4337?
ERC-4337 is a standard for smart contract wallets aimed at integrating the currently fragmented ecosystem of smart contract wallets. ERC-4337 accounts are complete smart contract wallets, with user assets stored in smart contracts instead of EOAs. There are many different implementations, but the overall flow of ERC-4337 transactions is as follows (note that alex.eth is a smart contract):
ERC-4337 aims to lead the widespread adoption of smart contract wallets without making any changes to the core EVM. Eventually, account abstraction is likely to be natively integrated into the chain: there are plans to introduce native account abstraction into Ethereum L2 through RIP-7560, and this may extend to Ethereum itself in the future (via EIP-2938 or subsequent versions).
Currently, ERC-4337 is still in its early stages. The standard has not been finalized, and there were only around 200,000 ERC-4337 transactions on all EVM chains last week (with over 90% of the volume on Polygon). EIP-3074 and ERC-4337 are parallel improvements for the user experience of wallets, and currently, the majority of Ethereum users are EOAs. Supporters of both believe that the fastest way to improve the Ethereum user experience is to push forward on both fronts as soon as possible!
So why are some people against EIP-3074?
EIP-3074 is a potential major security attack vector.
The most common complaint you’ll see on Twitter is that after EIP-3074, “one signature can drain all my ETH, ERC20, and NFTs in my account.” This is true: if delegated to a malicious invoker, all of a user’s assets will be lost. Of course, with an EOA wallet, a malicious “export private key” also results in the loss of a user’s assets. But signatures are more common in the standard flow of web3 applications, and many users simply confirm as quickly as possible.
However, there are some important caveats here. EIP-3074 signatures are very easily identifiable – they must have a “magic prefix” (literally “0x04”). Currently, most wallets only support signatures with different prefixes defined in ERC-191, so the likelihood of any current signature being used to deceive EIP-3074 delegations is low (but not zero!). As wallets implement support for EIP-3074, they may introduce frightening screens that require users to carefully review their actions before signing this message – think of the security level of “export your private key.” This limits the UX advantages of EIP-3074: if you’reAs a professional translator, I will translate this news article into English using descriptive language. The sentences will be accurate and fluent, and I will retain proper nouns and all 
. I will ensure that the meaning remains the same and avoid any grammatical errors. Please note that I will not add a period at the end of the translation. Here is the translation:
To use a different call program each time you want to use a different application is something that has not made any progress.
To solve this issue, many wallets may choose to implement an approved call program list, such as a standard transaction batch program, and only display the dreaded screen when users go beyond these boundaries. However, this is an obvious centralization problem that varies between different wallets and relies on coordination between dapps and wallets (for example, both choosing the same gas sponsorship caller).
Assuming the user’s wallet wisely deploys EIP-3074, there is no reason to believe that EIP-3074 will become a security disaster. However, this is a significant assumption for countless Ethereum wallets. In any case, this will be an important new attack vector that undoubtedly leads to some notable events—I actually wonder if disguised batch transactions (applicable to all AA wallets) are actually the largest long-term risk area.
EIP-3074 does not permanently “abstract” your wallet.
Some have described EIP-3074 as “upgrading your EOA to a smart contract wallet.” This is misleading—more accurately, users are “temporarily allowing smart contracts to act on your behalf,” and it comes with some key limitations:
Delegation to the caller is temporary and can be revoked at any time. This means that if someone leaks your private key or tricks you into signing a malicious transaction, your assets can still be stolen. While you may gain some user experience advantages of account abstraction, there are no security benefits. In fact, EIP-3074 may significantly reduce wallet and user motivation to upgrade to full smart contract wallets, contradicting our long-term goals.
Whenever you send an actual EOA transaction, you clear any existing caller authorization. This is great for quick revocations, but if you need to send a non-EIP-3074 transaction for any reason, you will have to go through the wallet’s “dreaded screen” process again to obtain all existing authorizations. Not fun.
For many in the Ethereum community, this feels like a half-finished job. If we are going to spend 2-3 years getting dapps and wallets to support EIP-3074 interactions, why not implement the ability to make these delegations permanent and fully replace the account’s code (turning it into a fully smart contract wallet)? EIP-5003 introduces another new opcode, AUTHUSURP, which can do this and is now being heavily pushed to be included in the next Ethereum hard fork to “complete the job”.
Safe Founder’s View on the Path to AA Fully Replacing EOA
While the proposal has gained support from many major Ethereum community members, it is not a panacea:
Compared to a full smart contract wallet, EIP-5003 accounts still have some limitations.
There is no simple way to invalidate existing or new signatures in EOA private keys, and many contracts consider these signatures as authoritative.
Cross-chain support presents various challenges, although many of these challenges also exist with ERC-4337 wallets.
EIP-3074 will require significant wallet infrastructure changes.
To enable the aforementioned sponsorship and batch transaction flows, we need a process roughly like this:
The dapp needs to determine that these transactions should be batched together.
The dapp needs to know if our wallet supports batch transactions and may need to include the cost of the specific caller used by the wallet in transaction cost estimation (to see if they want to sponsor it).
The wallet needs to know if the dapp intends to sponsor the transaction.
The wallet needs to check if the user has already approved the necessary batch transactions and sponsor callers.
The wallet needs to be able to convert the dapp’s “approval and transfer” requests into proper EIP-3074 authorizations for the correct callers and subsequent requests—or maybe we ask the dapp to do this?
The wallet needs to use its custom EIP-3074 logic to request EIP-3074 signatures from the user for the batch transaction callers.
The wallet needs to display a UI to the user to confirm each transaction included in the batch. This needs to be built separately by each wallet.
The dapp needs to implement separate processes for batch/non-batch users and customize error handling for any differences. As you can see, getting all users/wallets/dapps to support this flow will be a daunting task—we haven’t even started on L2 UX yet!
This is very similar to the challenges ERC-4337/smart contract wallets currently face, and there have been proposals for new wallet RPC methods such as EIP-5792 (batch transactions), standardized paymaster API (EIP-7677), account-agnostic user operation packages (ERC-7679), and more human-readable wallet permissions. In some/all cases, EIP-3074 batching may be able to piggyback this work, but it’s also entirely possible we end up with three separate processes eventually (EOA, EIP-3074, ERC-4337)!
This massive implementation lift comes with significant real-world costs: the more complex we make Ethereum (at the EVM layer and wallet RPC layer), the more we divide developer attention and prevent them from doing everything else needed for Ethereum’s success.
Summary
For users/dapps/wallets adopting EIP-3074, there is no doubt that EIP-3074 will provide meaningful and immediate user experience improvements.
However, there is a significant risk that the use of this feature will be severely limited: the new user experience will be confusing, complex, and different across wallets. When dapps and wallets widely support EIP-3074, the full smart contract wallet standard is expected to have the tools and maturity to become a more attractive destination for users. I most hope that EIP-3074 serves as an intermediate tool for users to transition to full smart contract wallets, and I agree with the argument that this will be severely limited without a quick inclusion of EIP-5003.
The biggest risk the Ethereum community faces is that the effort required to support EIP-3074 will detract from developers’ efforts to move users to fully account-abstracted wallets. ERC-4337 is still not final, key EIPs at the wallet <> dapp layer are still pending, and efforts to abstract native accounts on L2 through RIP-7560 are relatively unattractive. Further dividing developer attention is unlikely to yield better results!
Ultimately, whether EIP-3074 is a good idea will depend on the extent to which it becomes a Trojan horse for other account abstraction paths (ERC-4337 and native). In successful cases, EIP-3074 is an excellent immediate upgrade that incentivizes dapp developers to integrate the tools necessary for adopting ERC-4337. In failure cases, we’ll end up with dapp developers needing to maintain custom processes for eight different types of Ethereum accounts!
Tags:
Argent
Coinbase
EIP-3074
Gnosis
Gnosis Safe
Uniswap
Ethereum
Golden Finance
Source link:
https://www.jinse.cn/blockchain/3681761.html
Note: The views expressed in this article are solely those of the author and do not constitute investment advice.
Original article link:
https://www.bitpush.news/articles/6616820
Related news
Galaxy Digital: Crypto Weekly Commentary – Halving, Stablecoin Regulation, Lido, and Data
SEC Orders Terraform Labs and Do Kwon to Pay $5.3 Billion in Fines
[Bitpush Market Dynamics Daily] The Next Target for BTC Bulls: $67,000
Summary of New Technological Developments Leading to Bitcoin’s Resurgence
a16z Partner: Bad Regulation Helps Meme, Not Innovation