Original author: Mocaverse consultant cygaar
Compiled by: Odaily Azuma
Editors note: On April 12, local time, the 185th meeting of the Ethereum Core Developer Executive Conference (ACDE) was held. The meeting continued to discuss the content planning of the two subsequent major version upgrades of Ethereum (Prague upgrade and Osaka upgrade). One of the most important results of this meeting is that EIP-3074, which adds smart contract functionality to ordinary addresses, has been determined to be included in the Prague upgrade.
The following is an analysis by Mocaverse consultant cygaar on the utility and significance of EIP-3074. The content was compiled by Odaily.
EIP-3074 has just been approved and will be activated in the next hard fork upgrade of Ethereum (Pectra, or Prague upgrade).
This EIP is expected to permanently change the way users interact on the EVM chain, making the user experience on the wallet side simpler, cheaper, and richer. The following is a brief overview of EIP-3074 and an analysis of how it will change existing rules.
If we summarize the functions of EIP-3074 in one sentence, it is that it will give ordinary EOA addresses (that is, our most commonly used wallet addresses) smart contract functions, including batch transactions, wallet asset recovery, fee (gas) funding, and Authorize a single transaction and so on.
First, let’s talk about the current problems with ordinary wallets.
@lightclients has done an excellent analysis on EIP-3074, and I will directly quote their PPT here. As shown in the figure below, here are some user experience issues faced by ordinary wallets currently.
Transactions are made one by one when authorizing tokens;
All operations tend to be linked one-to-one to transactions;
There is no protection against losing private keys;
Transactions cannot be executed without ETH…
The above problems can be solved through smart contract wallets, but this will force users to migrate addresses, resulting in a poor user experience, and on-chain migration will consume a lot of costs. So this is not a good solution.
So how do we give smart contract functions to existing ordinary addresses?
The answer is to implement new functions by adding two new opcodes (computer instructions) such as AUTH and AUTHCALL. These two opcodes will work together to allow smart contracts to perform specific operations instead of ordinary addresses.
The following is a brief overview of how the AUTH and AUTHCALL opcodes work.
AUTH is responsible for accepting the users signature and expected actions, and verifying that the signature is correct. It will also set a variable indicating the starting address from which the transaction was initiated.
AUTHCALL is responsible for calling the target contract and letting the starting address of the initiated transaction replace the caller address (that is, the smart contract address that is actually calling the target contract) as the call source.
The following is a schematic diagram of the transaction process under EIP-3074.
The user signs a message (off-chain operation, no need to consume gas);
The user or fee sponsor (the address that helps the user pay for gas) can send this information as a transaction to a caller address;
The callers address is verified using AUTH and AUTHCALL, and the starting address of the user-initiated transaction is set as the calling source, and then the target contract is called.
With this new transaction process, we will activate some completely new features.
For example, the first potential new feature is the ability to implement fee subsidy. Assuming that the user does not have any ETH in his wallet, major applications after EIP-3074 can also help users advance gas, eliminating the need for users to purchase or bridge ETH themselves. . This feature is very important for Ethereum to achieve mass adoption on the consumer side.
The second potential new feature is the ability to perform multiple actions in one transaction. Currently, when users trade a new token on Uniswap, they must first authorize Uniswap to use the token before they can actually conduct the transaction. This experience is also very bad. With EIP-3074, the two operations can be completed directly through one transaction.
The third potential new feature is asset recovery. Through EIP-3074, users can set up a special caller contract. If the private key is lost, the user can also use verified social media information to restore the asset - if the recovery conditions are met, it can be submitted to the caller contract Sign to transfer assets from the original address.
However, in addition to these significant advantages, the emergence of EIP-3074 will also create some new risk points. The biggest risk point comes from calling the contract - it must be fully audited, non-upgradeable and trustless, otherwise user funds can easily be stolen. Additionally, some existing reentrancy checks may not work with EIP-3074.
Since 3074 adds two new opcodes, a hard fork upgrade is required to add this update. This is part of the reason why EIP-3074 has been delayed until now, and why ERC-4337 (Asset Standard for Account Abstraction) was adopted in the first place. ERC-4337 does not require a hard fork because it is purely a smart contract and off-chain system level change.
This is a summary of ACDE#185 compiled by Tim Beiko. As you can see from the picture below, EIP-3074 is now officially included in the scope of the Pectra hard fork upgrade.
Many thanks to @lightclients for his contribution to this work. He is also one of the original authors of EIP-3074. @lightclients has been working hard to promote the implementation of this EIP for many years.
If you want to know more about the contents of EIP-3074, you can start with the following information.
EIP-3074 formal proposal content:https://eips.ethereum.org/EIPS/eip-3074
Video analysis by @lightclients:https://www.youtube.com/watch?v=AffftIs6XFE
All in all, EIP-3074 is expected to significantly change the current on-chain interaction model. The EVM environment will welcome two brand new opcodes that will allow almost normal addresses to run as smart contracts. Going forward, it will be very exciting to see how developers take advantage of this paradigm shift.
