Foreword
This article is divided into two major modules:
The first half will start from the first AA proposal in 2015, and systematically organize the main contents of the Eip proposals so far, hoping to explore the history of AA historical proposals and comprehensively evaluate the advantages and disadvantages of each plan.
The second half focuses on comparing the market downturn feedback faced by EIP4337 after it was proposed, and then deeply analyzes EIP7702, which is about to be included in the next version of Ethereum upgrade. Once this proposal is merged, it will change the form of on-chain applications in all aspects.
EIP-7702 has epoch-making changes, and let's listen to Shisijun's detailed explanation
Ethereum founder Vitalik updated the ETH development roadmap again at the end of 2023, but the setting for account abstraction has not been changed. Today's mainstream model is also entering the next stage of VoluntaryEOA Conversion (voluntary conversion of EOA accounts) from EIP-4337.
https://x.com/VitalikButerin/status/1741190491578810445
More than a year after the launch of EIP4337 (at the WalletCon in Denver on March 1, 2023, it was officially announced that the core contract of ERC-4337 designed and implemented by Ethereum Foundation developers has passed the audit of OpenZeppelin and is considered to be the historical node of the official launch).
It has always been widely recognized by users, but not widely used. In such a contradictory market environment, the progress of EIP-7702 has been greatly advanced, and it has even been confirmed that it will be merged in the next upgrade.
No need to say more, just look at the data.
After a year and a half of development, EIP4337 has only 12 million addresses in the collection of mainstream chain accounts. The most surprising thing is that on the Ethereum mainnet, there are only 6,764 active addresses. Maybe there are some problems with the statistical dimension, but at least it is very different from the number of addresses of EOA and CA. You must know that the number of independent addresses on the Ethereum mainnet has reached 270 million (data source: https://etherscan.io/chart/address).
It can be said that EIP4337 has no substantial development on the main network.
(Chart data source: https://dune.com/niftytable/account-abstraction)
However, this does not erase the essential value of AA, because it was destined from the beginning of the design of EIP4337. It could not do well in the face of the serious forward compatibility issues of the main network. Therefore, with the widespread embedding of native AA in various L2 layer chains, the number of EIP4337 addresses on L2 has exploded. Among them, the monthly active users of base and polygon chains in July were 1 million and 3 million respectively, which is quite impressive.
So, it is not that EIP4337 is designed wrong. It has many advantages. We will summarize it systematically in a while. The current situation is due to the differences between the main network and L2. They need to use their own suitable solutions.
Account abstraction sounds very confusing, but in fact it essentially solves the problem of property rights separation.
There are two types of accounts in the EVM architecture (i.e. Ethereum Virtual Machine), external accounts (EOA) and contract accounts (Contract Account). The ownership and signature rights of external accounts are actually held by the same entity. The person who holds the private key not only has the "ownership" of this account, but also has the right to "sign and transfer all assets".
This is determined by the transaction structure of the Ethereum account
From the structure in the figure below, it can be found that in fact, the standard transaction of Ethereum does not have a From party. So if I make a fund transfer, what address of funds is consumed? In fact, the From address is deconstructed through its VRS parameter (i.e. user signature).
This involves asymmetric encryption such as ECDSA, one-way threshold function and other concepts, we will not expand on them. In short, cryptography is used to ensure security here. Of course, this also caused the current EOA address dilemma of property rights merger.
The core effect of EIP4337 is to add the Sender Address field in the transaction field, so that the private key can be separated from the address being operated.
Why is property separation so important?
Because the design of external accounts (EOA) will lead to more problems:
Private keys are difficult to protect: users lose their private keys (loss, hacker attacks, cryptographic cracking) means losing all assets.
Few signature algorithms: The native protocol can only use ECDSA signature and verification algorithms to verify transactions.
High signature authority: No native multi-signature (multi-signature can only be achieved through smart contracts), a single signature can perform any operation.
Transaction fees can only be paid through ETH, and batch transactions are not supported.
Transaction privacy leakage: One-to-one transactions make it easy to analyze the privacy information of account holders.
The above constraints make it difficult for ordinary users to use Ethereum:
First, to use any application on Ethereum, users must hold Ether (and bear the risk of Ether price fluctuations).
Second, users need to deal with complex fee logic, and concepts such as Gas price, Gas limit, and transaction blocking (Nonce order) are too complicated for users.
Finally, although many blockchain wallets or applications try to improve user experience through product optimization, their actual effects are minimal.
Therefore, the solution lies in realizing account abstraction and decoupling ownership (Owner) and signature rights (Signer), so as to solve the above problems one by one.
In fact, there are many historical solutions, and they will eventually converge into two routes
The solution to the problem seems to have many EIP proposals, but in the final analysis, there are two core ideas. Therefore, the problems considered by each EIP that has not been passed in the past have converged into the solution to the current solution.
As early as November 15, 2015, around EIP-101, Vitalik proposed a new structure of using contracts as accounts. Change the address to only have code and storage space, change the handling fee to support payment by ERC20, change the native token to ERC20-like to store the balance through pre-compiled contracts (with functions such as deduction authorization), and simplify the transaction fields to only to, startgas, data and code.
Now it seems that it is a great leap forward reform, which will greatly change the underlying design, so that each account address has its own "code" logic (in fact, this is exactly what EIP-7702 is trying to achieve now).
Other functions can also be derived, such as
allowing transactions to use more encryption algorithms, and the signature verification and authentication method can be specified by the internal code of each address
having anti-quantum attack characteristics because the code has upgrade features.
Let Ethereum have the same functional characteristics as the ERC20 contract, and the core effect has the authorization of withholding, so there is no need for the loss of native currency
Increase the custom space of the account, and be compatible with social recovery, sbt support, key retrieval, etc.
The reason for not continuing to move forward is also very simple. Obviously, the step is too big. For the current transaction hash conflict problem, the security risks are not well considered, so it has been shelved, but the concept of each advantage has become one of the core functions of the subsequent EIP4337 and EIP7702.
Later, a series of EIPs attempted to improve this logic
EIP-859: Main Chain Account Abstraction--2018-01-30
Tried to solve the problem of Code deployment. The core function is that if the contract of the transaction party is not deployed, the contract wallet deployment is executed using the code parameter attached to the transaction. Secondly, a new PAYGAS operation code is proposed. In addition to paying gas, it also becomes a separator between the verification part and the execution part of the parameters of a transaction.
Although it ended in failure at the time, it has become one of the core logics of EIP7702 now. Each transaction of EIP7702 can be accompanied by a certain code in combination with a special transaction structure, so that the EOA address has contract capabilities in this transaction.
EIP-7702: Set EOA account code 2024-05-07
This is also the core EIP of the mechanism discussed later in this article. Vitalik published EIP-7702 as an alternative to EIP-3074 (2024-05-07). Therefore, EIP-3074 was abandoned, and EIP-7702 was determined to be included in the upcoming ETH Prague/Electra (Pectra) hard fork. The specific content is expanded below.
EIP-3074: Add AUTH and AUTHCALL opcodes--2020-10-15
Add two new OpCodes AUTH and AUTHCALL to the EVM, so that the EOA can use these two opcodes to authorize the contract to call other contracts instead of the EOA's identity.
Combined with the figure below, in summary, an EOA can send a signed message (transaction) to a trusted contract (called Invoker), and this Invoker contract can use the AUTH and AUTHCALL opcodes to replace this EOA to send the transaction.
EIP-4337: Account Abstraction with Transaction Memory Pool--2021-09-29
In short, it was inspired by MEV and its core value is to completely avoid changes to the consensus layer protocol.
eip4337 proposes a new transaction object UserOperation. The user sends this object to the memory pool, and bundlers batch package and deliver the contract to execute the transaction from the miner dimension. In essence, it pulls the underlying transaction and account operation to the contract level for execution.
EIP-5189: Operate abstract accounts through endorsers—2022-06-29
This is an optimization of the logic of EIP4337. It is to prevent Dos blocking attacks by malicious Bundler by establishing a mechanism for endorsing endorsers with financial penalties.
EIP-2718: Packaging envelope for new transaction types--2020-06-13
This is a Final proposal. It defines a new transaction type as an envelope for new transaction types to be added in the future.
The final effect is that when a new transaction type is introduced, a specific encoding is used to distinguish which type of transaction it is, so that it only needs backward compatibility without forward compatibility. The most common example is EIP1559, which distinguishes the transaction fees and uses a new transaction type encoding without affecting the original legacy transaction type.
EIP-3607: Make it impossible to deploy contracts on EOA addresses--2021-06-10
This is a supplementary solution on the AA path to prevent conflicts between contract deployment addresses and EOA addresses. It will control the contract generation method so that the system does not allow code to be deployed to an address that is already an EOA address. This risk is actually very small. After all, the Ethereum address is 160 bits long. Although there is a way to collide the private key of a specified contract address with a private key, it will take another year based on the full computing power of Bitcoin.
First, you need to understand the value of switching to CA
Basically, it is the actual effect of EIP-4337, which can be achieved
However, the core disadvantage of EIP-4337 is that it violates the principle of human motivation.
It looks better, but it has fallen into a dead cycle of market development. Many Dapps are not compatible, so users are not willing to use CA addresses, and even using CA has higher transaction costs (in ordinary transfer scenarios, the transaction fees will also double), and it is too dependent on the compatibility of Dapp itself.
So it has not been popularized on the Ethereum mainnet so far.
Cost is the most important criterion for users, and costs must be reduced.
However, to truly reduce GAS, Ethereum itself must be soft-forked and upgraded, modifying GAS calculation or modifying modules such as GAS consumption of opcodes. However, since soft forks are required, why not directly consider EIP-7702?
It distinguishes through new transaction types, allowing EOA to temporarily have the function of smart contracts in a single transaction, thereby supporting batch transactions, gas-free transactions, and custom permission management in business, without introducing new EVM opCode (affecting forward compatibility).
It allows users to obtain most of the capabilities of AA without deploying smart contracts, and can even provide the ability for third parties to initiate transactions on behalf of users, without the need for users to provide private keys, only signature authorization information.
It defines a new transaction type 0x04, the TransactionPayload of which is the RLP encoded serialization result of the following content
It is important to add the authorization_list object, which stores the code that the signer wants to execute in his EOA. When the user signs the transaction, he also signs the contract code to be executed. It exists as a two-dimensional list, which means that multiple operation information can be stored in batches and batch operations can be performed.
4.3.1 Verification phase
At the beginning of the transaction execution, for each [chain_id, address, nonce, y_parity, r, s] tuple of authorization_list:
Use ecrecover from signatures r and s to recover the signer address (note that this is the mechanism of Ethereum itself, so this EIP does not change the signature algorithm). authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s] (Similar to the previous decryption of the from address, here is the local signature address for this list)
Verify the chain ID (anti-fork chain replay).
Verify whether the code of the authority signer is empty or has been delegated (verify whether the transaction is a valid 7702 transaction, and the delegation mechanism will be used to execute the transaction later).
Verify the nonce of the authority signer (anti-signature replay of authority).
Set the code of the authority signer to 0xef0100 ||
Add the nonce of the authority signer (to prevent local signature replay).
Add the authority signer account to the list of visited addresses (to convert to hot addresses, reduce the gas fee for querying storage)
4.3.2 Execution phase
Where is the contract code to be executed and the operation instructions?
The "new" version only changes the behavior in terms of code deployment.
It no longer sets the account code to contract_code, but retrieves the code address from authorization_list and sets that code to the account code.
So, when the authorization code needs to be executed, the code is loaded from the address specified by the address field of the authorization_list and executed in the context of the signer's account.
This means that the user's contract code is actually stored at a specific address on the chain, rather than being directly included in the transaction.
The operation instructions and related parameters are stored in the data field of the transaction payload.
It will change the entire link of the Web3 wallet, and the user experience will also change dramatically, because ordinary transactions initiated by EOA can also execute multiple logics similar to contracts, such as batch transfers. For CeFi scenarios, it will affect transaction identification and also affect the collection fees for deposits and withdrawals.
Due to its appearance, many previous stereotypes have been broken, such as:
The invariant that the account balance can only be reduced by transactions originating from the account has been broken.
The invariant that the EOA nonce increases by 1 after the transaction execution begins (may increase multiple at the same time).
The protection logic of the comparison of tx.origin and msg.sender has been broken, and many past contracts are at risk.
The current situation that EOA itself cannot issue events has been broken, and attention may need to be paid to the identification and monitoring of some on-chain events.
It breaks the status quo that EOA addresses accepting ERC20, 721, 1155 and other assets will inevitably succeed (because of the callback mechanism, it may fail)
1. Advantages of EIP-7702
Lower gas because there is no need to go through the entrypoint module, reducing on-chain operations.
User migration costs are lower, and there is no need to deploy on-chain contracts as the main body in advance
Compared with Eip4337, there will also be code delegation execution, and there will also be two ways:
Full Delegation
Full delegation means delegating all permissions for an operation to a specific address. For example, a user can delegate the management permissions of all ERC-20 tokens to a smart contract address, so that this smart contract can perform all related operations on behalf of the user.
Protected Delegation
Protected delegation means adding some restrictions and protection measures in the delegation process to ensure the security and controllability of the delegated operation.
For example, users can delegate the management rights of only some ERC-20 tokens to a smart contract, or set some restrictions (such as spending a maximum of 1% of the total balance per day).
2. Disadvantages of EIP-7702
Its core disadvantage is that it is a soft fork upgrade, which requires consensus and huge changes, and has a wide impact on the chain ecology. After preliminary evaluation, Shisijun has the following challenges, but challenges are also market opportunities:
It has a high degree of freedom and is difficult to be audited. Users will need more reliable wallets to take on security protection.
The changes to the original architecture are too large. Although different transaction types are used to distinguish them, many infrastructures, especially the unchangeable contracts on the chain, cannot be directly adapted.
Contract capabilities are provided for EOA addresses, but the corresponding storage space cannot be retained.
The cost of a single transaction is slightly higher because the Calldata part will be greatly increased. The estimated total cost of the call will be 16 (gas) * 15 (bytes) = 240 (gas) calldata cost, plus the cost of EIP-3860 2 * 15 = 30, plus the runtime cost of about 150. Therefore, just preparing the account and doing nothing will increase the Gas by 500.
"If the receiver signs the code without the receive function, the sender may face DoS when trying to send assets." See the case. The problem is that EOA A signed something it shouldn't have signed - a replayable file with an incorrect implementation (no receive()).
The on-chain withdrawal logic may be inconsistent. For example, when transferring ERC-20 tokens, if the recipient account has a code, the token contract will call onERC20Received the recipient account. If onERC20Received restores or returns an incorrect value, the token transfer will be restored.
In addition, if EOA can emit events, will there be any problems? Some infrastructure may need attention.
These are just some of the shortcomings summarized by Shisijun based on the current EIP7702 proposal content and the corresponding official forum discussion. In the end, it is necessary to analyze it based on the final implementation code.
References are as follows:
This article seems to be very long, but in fact the text content is only more than 6k words. Many of the previous EIP interpretations involved in the middle can be expanded through links in the text, so I will not trace them further.
At present, account abstraction can only be placed in the sixth module, that is, to repair everything, that is, to promote it in the end. Now that the progress of EIP7702 has been greatly accelerated, it still brings more challenges to the security of the system. It can be expected that it will eventually be realized. After all, subversive events such as Ethereum mergers and modifications to consensus algorithms can occur, let alone new transaction types.
However, there are too many subversive contents this time, breaking the impossible unspoken rules on multiple chains and breaking the application logic of most Dapps, but he firmly occupies the most core point, that is, the cost of users is lower! Compared with the nearly doubled transaction cost of EIP4337.
The user itself is still an EOA address, and only drives and uses the CA logic when needed, so the holding cost is low. There is no need to convert the on-chain CA identity before performing operations, which means that users do not need to register.
Users can easily use EOA to do multiple transactions in parallel, such as the combination of authorized deduction and execution deduction, which reduces the transaction cost for users. For Dapp, especially for project parties that need to do on-chain enterprise-level management, such as exchanges, it is a subversive optimization. Once the original ecology of batch aggregation is realized, the basic exchange cost can be reduced by more than half in an instant, which can also benefit users in the end.
Therefore, although he has changed a lot, it is worth studying and adapting all Dapps to occupy the dimension of cost, because this time, users must stand on the side of EIP7702.
Elon Musk confirmed at a recent press conference that Tesla will soon enable Dogecoin payments, stating that DOGE will soon become one of the official payment methods for purchasing Teslas. But he did not specify when the payment method is expected to be enabled.
JinseFinanceMetaverse is still very much important as the days of the internet are taking a new shape with the migration of different projects into Web3.
NulltxMerchants that accept crypto rather than credit cards for payments can expect to save as much as 3.5% — or more.
CointelegraphA quant has suggested that the reason behind the recent negative Coinbase Premium could have been due to Tesla's Bitcoin ...
BitcoinistOne thing’s for sure, Tesla’s CEO knows how to generate headlines. The infamous Elon Musk was the talk of the ...
BitcoinistElon Musk's electric car maker has sold off most of its BTC reserves, according to a financial report released Wednesday.
CointelegraphNulltxThe SpartaCats meme coin project is going to place an advertising billboard in front of Elon Musk's office. Since the ...
BitcoinistTesla has started accepting Dogecoin for company merchandise. However, the company states that it does not offer refunds for products purchased using DOGE.
CointelegraphThe site will use a combination of solar panels and battery storage from excess daylight to power Bitcoin mining.
Cointelegraph