Account abstraction is significant for significantly improving the user experience in various scenarios such as wallets, coin mixers, DApps, and DeFi. This article locates the account abstraction in the current roadmap of Ethereum and the priorities of Status.
Original title: “Depth丨Vitalik’s EIP-2938 will bring to Ethereum what changes? 》
Written by: Rajeev Gopalakrishna
Translation: Olivia
Editor: Li Hanbo
There are two types of accounts in Ethereum. External own account (EOA) and contract account (CA). EOAs are controlled by the private key, while CA is controlled by the smart contract code contained in it. EOAs have always been more privileged than CA, because only EOAs can start transaction execution by paying gas. Account Abstraction (AA) is a proposal that allows the contract to become a “top-level” account like EOA, which can pay fees and start transaction execution.
The motivation of account abstraction is to significantly improve the user experience of users interacting with Ethereum in various scenarios such as wallets, DApps, and DeFi . Account abstraction provides a basic layer function in Ethereum to determine when gas can be paid and who should pay for gas.
The Status Messenger application integrates a privacy-centric information system, as well as an Ethereum wallet and a Web3 DApp browser. Status wallet is currently an EOA wallet, which limits us to provide rich user experience that only smart contract wallets can provide, such as multi-signature security, social recovery, interest rate restrictions, allow/deny address lists, and gas-free meta transactions. At present, users of smart contract wallets have experienced the impact of gas fee fluctuations, and third-party repeaters cannot effectively solve this problem. The account abstraction aims to solve this problem.
In this article, we propose the need for account abstraction in the context of smart contract wallets. Then, we delve into the key aspects of account abstraction by describing protocol changes and their impact on nodes. Finally, we discussed some extended proposals and ended by rationalizing the planned roadmap of the Status project that interfaces with Ethereum, which may all be affected by account abstraction.
History & Motivation
The account abstraction was originally proposed in the form of EIP-86 in 2017, with the purpose of realizing the “summary of transaction source and signature” , but the origin of this idea can be traced back to 2016. At that time, someone suggested: “Instead of having an in-protocol mechanism that uses ECDSA and the default nonce scheme as the only “standard” way to ensure account security, it is better to take preliminary measures and establish a model. In the long run, all accounts are It is a contract, and the contract can pay gas, and users can freely define their own security model. “
The initial proposal was considered challenging because many protocols need to be changed and security needs to be guaranteed. Recently, Vitalik Buterin et al. proposed a draft of EIP-2938, which outlines an easier way to implement: by minimizing protocol/consensus changes, and enforcing the required security guarantees through node mempool rules. Vitalik’s Ethereum Engineering Group Meetup presentation and ETH Online presentation (and related articles 1 and 2) written by Sam Wilson and Ansgar Dietrichs (two other EIP authors) provide a more detailed introduction to this topic. This article highlights the key content of all these sources.
motivation
The motivation behind account abstraction is very simple, but fundamental: today’s Ethereum transactions have programmable effects (implemented by calling smart contracts), but they only have a fixed validity, that is, only if they have a valid The transaction is valid only when the ECDSA signature and a valid nonce, and there is sufficient account balance. Account abstraction upgrades transactions from fixed validity to programmable validity by introducing a new type of account abstraction transaction. This type of account abstract transaction always comes from a special address and the agreement does not require signature, nonce or balance check. The validity of this kind of account abstract transaction is determined by the target smart contract, which can execute its own validity rules, and then it can decide to pay for this type of transaction.
So why is this useful? We use the Ethereum wallet as an example to emphasize the benefits of account abstraction.
Smart contract wallets : Most Ethereum wallets today are EOA wallets, which are protected by a private key generated from a seed phrase. (The BIP-39 seed phrase is an ordered list of 12-24 words, which are randomly selected from 2048 words. This provides the entropy required to obtain the binary seed, which is generated using the PBKDF2 function. Then, the binary seed is used to generate the asymmetric key pair of the BIP-32 wallet.) The user should write the seed phrase in a safe place, because it may be needed later when recovering the key on another wallet. However, such wallets are easily affected by the theft of the private key or loss of the seed phrase, resulting in the loss of users’ funds.
Smart contract wallets are implemented on the chain through smart contracts. This wallet provides programmable functions to mitigate risks and a user-friendly experience by implementing functions such as multi-signature security, social or time-based recovery, transaction or amount rate limiting, allow/deny address lists, gas-free transactions, and batch transactions.
Although smart contract wallets are exposed to the security risks of vulnerable smart contracts, security testing and audits performed by wallet providers can mitigate this risk. The risk of the EOA wallet lies entirely with the wallet users, who are entrusted to be responsible for the security of the seed phrase, and there is no security procedure in the smart contract.
Examples of smart contract wallets are Argent, Authenticreum, Dapper, Dharma, Gnosis Safe, Monolith and MYKEY. As shown in the chart below, the adoption rate of this type of wallet seems to be increasing.
Argent implements a keyless social recovery function through their Guardians concept , where Guardians are people or devices that users trust and can help retrieve users’ wallets. Argent also aims to achieve a combination of bank-like security (through features such as daily transaction limits, account locks, and trusted contacts) and Venmo-like availability (through the use of ENS names instead of addresses and support for meta-transactions).
Gnosis Safe is a multi-signature smart contract wallet that focuses on team management of funds and requires a minimum number of team members (m-of-n) to approve transactions to occur. It can also achieve gas-free signatures through meta transactions.
All these advanced wallet functions require the use of sophisticated smart contracts. Wallet users either need to interact with EOA or rely on the wallet provider to support meta-transactions through the provider’s repeater or a third-party repeater network (such as the Gas Station Network). The former relies on the purchase of ETH on a centralized exchange after KYC, while the latter aims to reduce the friction of the user experience on the chain by shifting the burden of users to the repeater. The cost of the wallet provider’s on-chain/chain And/or compensation under the user chain.
However, the repeater-based architecture has three main shortcomings : (1) They may be considered as centralized intermediaries, and transactions may be censored (2) Because the repeater’s transactions require an additional 21,000 base gas fee, and their business needs to make profits in addition to the gas fee, so they are technically/economically inefficient (3) The use of relayer-specific protocols forces applications to rely on non-base-layer Ethereum infrastructure, and their user base is small. Availability guarantee is uncertain.
Account abstraction will enable smart contract wallets to accept users’ gas-free transactions and pay gas fees for them without relying on the relay layer network. Therefore, this grassroots capability will greatly improve the user experience of such wallets without sacrificing the decentralization guarantee of Ethereum.
Tornado Cash : A related motivational application is a coin mixer, such as tornado.cash, in which Tornado improves transaction privacy by breaking the on-chain link between addresses by using a smart contract. The contract accepts ETH deposits, which can then be withdrawn from different addresses. The user needs to provide the secret hash value when depositing, and then provide zkSnark proof when withdrawing, to show knowledge of the secret, without revealing the secret or the previous deposit itself. This decouples withdrawals from deposits.
However, there is a problem with withdrawal. To perform withdrawal transactions from the newly generated address, the user needs to have some ETH in it to pay for gas. The source of this ETH (usually an exchange) will destroy Tornado’s privacy. The preferred alternative is to use the repeater network again, but it has the disadvantages outlined earlier.
Account abstraction will solve this problem, allowing the Tornado contract to accept the user’s withdrawal account abstraction transaction, then verify zkSnark and deduct some gas fees (deducted from the previous deposit amount), and then transfer the remaining deposit amount to the withdrawal address.
Account abstraction
The account abstraction proposed in Document EIP-2938 allows the contract to be the highest level account for paying fees and starting transactions. This is achieved by introducing protocol changes. The new account abstract transaction type requires two new opcodes: NONCE and PAYGAS, changes to the mempool rules and extensions to support advanced usage. There are still two types of account types (EOA and contract accounts), and all proposed changes are backward compatible with current transactions, smart contracts and agreements.
The application of account abstraction is divided into two considerations: 1) Single-tenant applications, such as smart contract wallets, create a new contract for each user. 2) Multi-tenant applications, such as tornado.cash or Uniswap, where multiple users and the same set Smart contract interaction.
The support of account abstraction for multi-tenant applications requires more research and is recommended as a future work. So we will focus on the support of single-tenant account abstraction in this article.
Agreement changes
A new transaction type is introduced, and two opcodes supporting NONCE and PAYGAS. These are the only protocol changes.
Account abstract transaction : A new account abstract transaction type AA_TX_TYPE has been introduced. Its effective type is interpreted as RLP([nonce, target, data]) instead of the existing transaction type. The effective type of the latter is RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]).
The gas_price and gas_limit omitted in the account abstract transaction are specified by the target account abstract contract during execution. The ECDSA signature v, r, s omitted in the abstract transaction of the account is replaced by a specific contract to verify and check the data. The to address is replaced by the target contract address. This value is omitted because the originating address of all account abstract transactions is a special ENTRY_POINT address (0xFFFF…FFF), rather than the associated EOA value.
If the check fails, the transaction is considered invalid, otherwise, tx.target.nonce will be incremented and the transaction continues.
The recommended basic gas cost for account abstraction transactions is 15,000, instead of the current 21,000 (to reflect the cost savings due to the lack of intrinsic ECDSA signatures). In addition, there is no inherent gas limit for account abstract transactions. At the beginning of execution, the gas limit only needs to be set to the remaining gas of the group.
NONCE opcode : NONCE opcode (0x48) pushes the NONCE (ie account abstract target contract) of the callee into the EVM stack. Therefore, Nonce is exposed to EVM to allow signature verification of all transaction fields (including nonce) as part of the verification in the account abstract contract.
PAYGAS opcode: PAYGAS opcode (0x49) Take two parameters from the stack: (top) version_number, (top second) memory_start. version_number allows future implementations to change the semantics of opcode. Currently, the semantics of this opcode is as follows.
Check version_number == 0 (otherwise throw an exception)
Extract gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
Extract gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
Check contract.balance >= gas_price * gas_limit (otherwise an exception will be thrown)
Check globals.transaction_fee_paid == False (otherwise an exception is thrown)
Check the AA execution frame == top-level frame, that is, if the current EVM execution exits or restores, the EVM execution of the entire transaction is terminated (otherwise an exception is thrown).
Set contract.balance -= gas_price * gas_limit (limit).
Set globals.transaction_fee_paid = True
Set globals.gas_price = gas_price and globals.gas_limit = gas_limit.
Set the remaining gas of the current execution context=gas_limit-gas consumed.
At the end of the account abstraction transaction execution, (globals.gas_limit-remaining_gas) *globals.gas_price is transferred to the miner, and the account abstraction contract returns remaining_gas * globals.gas_price.
PAYGAS performs checkpoints as EVM. Any restoration after this point will only be restored here, and then the contract will not accept refunds, and globals.gas_limit * globals.gas_price will be transferred to the miner.
The new transaction type and two new opcodes constitute changes at the protocol/consensus level, and their semantics are easier to understand.
Mempool rules
“Mempool” refers to a set of memory data structures inside the Ethereum node, which stores candidate transactions before mining. Geth calls it the “transaction pool”; Parity calls it the “transaction queue”. Regardless of the name, it is a transaction pool sitting in memory waiting to be included in the block. Think of it as a “waiting area”, waiting for transactions to be accepted into a block.
At present, through fixed transaction validity rules, miners and other nodes can verify transactions in their mempool with minimal effort, thereby avoiding DoS attacks. For example, if a miner has a valid ECDSA signature, a valid nonce, and sufficient account balance, it can be determined that a certain transaction will actually pay the fees. Other transactions in the miner’s mempool can only invalidate the pending transaction if they come from the same address and increase the nonce or fully reduce the account balance. These conditions are computationally minimal, so that miners and nodes have enough confidence in their mempools to wait or replay blocks respectively.
The account abstraction transaction introduces more complexity with its programmable effectiveness. Account abstract transactions do not pay any upfront gas, and rely on the abstract contract of its target account to pay gas (via PAYGAS). Conceptually, account abstract transaction processing is divided into two stages: a shorter verification stage (before PAYGAS) and a longer execution stage (after PAYGAS). If the verification phase fails (or throws an exception), the transaction is invalid (just like the non-account abstract transaction with invalid signatures today), it will not be included in a block, and the miner will not receive any fees.
Therefore, miners and nodes need a predictable mechanism to avoid the dependence of the validity of a pending account abstract transaction on other pending transactions in the mempool. Otherwise, the execution of a transaction may invalidate many/all account abstract transactions in mempool, leading to DoS attacks. In order to avoid this situation, there are two recommended rules to be executed on account abstract transactions in mempools (executed by miners and nodes, but not on the protocol itself).
Opcode Restriction
In order to prevent the validity of account abstraction transactions from being dependent on any factors other than the account abstraction contract itself, the following opcodes are considered invalid during the verification phase (that is, before PAYGAS: before PAYGAS): environmental opcodes (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT), BALANCE (any account, including the target itself), external call/creation or precompilation of anything other than the target (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) and external status access to read the code (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL), unless the address is the target.
The node must abandon the account abstract transaction that targets the account abstract contract in the mempool, breaking this opcode restriction rule. This ensures that as long as the account abstract contract status does not change, the effective account abstract transaction in mempool will remain valid.
Bytecode prefix limit
If the non-account abstract transaction can affect the state of the account abstract contract, it will affect the effectiveness of the account abstract transaction in mempool. In order to prevent this from happening, the account abstract transaction should only be allowed for those contracts with AA_PREFIX at the beginning of its bytecode, where AA_PREFIX implements the check of msg.sender which is the special ENTRY_POINT address of the account abstract transaction. This effectively prevents the interaction between non-account abstract transactions and account abstract contracts.
The node must throw the account abstract transaction to the account abstract contract that does not have this AA_PREFIX at its bytecode entry point.
The two restrictions imposed on the account abstract contract together ensure that: (1) The only state that the validity logic of the account abstract transaction can access is the state inside the account abstract contract, and (2) this state can only be targeted by others for this specific Account abstraction transaction modification of account abstraction contract.
Therefore, only in another pending transaction for the same account abstract contract, the uncompleted account abstract transaction will become invalid. However, given that these are not protocol/consensus changes, miners are free to include transactions that break these rules in the block.
Expand
The above protocol changes and mempool rules allow basic account abstract contracts to fully and securely implement single-tenant applications, such as smart contract wallets. Others that need to relax the above rules or need to implement advanced usage of multi-tenant applications require account abstraction to provide more support in an extended form, for example.
SET_INDESTRUCTIBLE opcode, disable SELFESTRUCT, and allow the account abstract contract to safely call the DELEGATECALL library during the verification phase.
IS_STATIC opcode, if the current context is static, returns true, allowing non-account abstract transaction callers to override the previous bytecode prefix limit and safely read the value from the account abstract contract.
RESERVE_GAS opcode, when called from a non-account abstract transaction, it establishes a lower limit of gas consumed by an account abstract contract, which is for seeking to write into the contract state. The effect of this is to force the attacker not to consume the minimum amount of gas, in order to suppress attempts to invalidate any account abstract transaction in mempool.
There are others such as multiple pending transactions, verified cached results, verified dynamic gas limits, and sponsored transactions, which are needed to support multi-tenant applications and zk proofs, such as Tornado Cash. The details about them are beyond the scope of this article.
The next step of the job
The account abstraction EIP-2938 is currently in draft mode and is being discussed in the Ethereum Research Forum. The next step for EIP is to be considered for inclusion in one of the upcoming hard forks . The EIP author’s goal is obviously a hard fork after Berlin (Berlin is tentatively scheduled for some time in early 2021), and the timetable is not very clear. So for EIP-2938, it is still too early.
In addition, it is not clear whether it is necessary to add EIP-2938 to the first layer (L1) of the Ethereum foundation. Given the relative flexibility of the layer 2 (L2) solution (as described in our previous article), account abstraction can be implemented on a specific L2 without the need to upgrade the entire L1. However, even if some L2 implements their own version of account abstraction, there are benefits to unified support for account abstraction on L1. Therefore, it remains to be seen where and how the account abstraction is implemented.
“Account abstraction is not important because it can be implemented on L2 regardless of whether L1 supports it or not.” — Vitalik talked about what will continue to work in the base layer in his article on the summary-centric Ethereum roadmap thing).
Status: Status Wallet is currently an EOA wallet. The difference is that it is bundled with a privacy-centric SMS system, and it realizes the integration of payment in chat or enhanced security of Keycard. The features of smart contract wallets are being considered, such as multi-signature and social recovery. The account abstraction EIP-2938 support will help eliminate the reliance on the centralized and inefficient relayer-based architecture, as mentioned earlier.
Status is also evaluating L2 solutions, both to support multiple chains in its wallet, and to provide the required extensions for various use cases, as we described in the previous article. For example, Keycard is exploring a payment network whose credit card-level scalability and near-instant finality design requirements cannot be met by the current Ethereum network. In addition, there are many other plans, such as the referral plan, Tribute-to-Talk, and the ENS name, all of which will benefit from L2 scalability to achieve feasible deployment and reasonable user experience. If a feasible L2 solution implements account abstraction, then projects built on the L2 basis will be able to take advantage of the account abstraction without relying on L1.
to sum up
A basic aspect of the Ethereum protocol is that only external own accounts (EOAs) can pay gas fees and start executing transactions. Contract accounts (CA) cannot do this. Account Abstraction (AA) is a proposal to change this distinction, allowing a specially constructed CA to programmatically check the validity of the new type of account abstraction transaction, and decide to pay the gas fee on its behalf, thereby effectively launching its execution without the need for EOA .
Account abstraction is meaningful for significantly improving the user experience in various scenarios such as wallets, currency mixers, DApps, and DeFi, without relying on a centralized and inefficient relay-based architecture. Basic single-tenant scenarios, such as smart contract wallets, account abstraction can be safely supported by introducing a new transaction type, two new opcodes and two mempool rules. Advanced multi-tenant applications, such as Tornado Cash, need to extend these protocol changes and node rules.
In this article, we mentioned the need for account abstraction in the context of smart contract wallets. We emphasize key aspects of account abstraction by describing protocol changes and their impact on nodes. We touched on some proposed extensions for advanced uses, and finally, we positioned the account abstraction in Ethereum’s current roadmap and Status priorities.
Reducing friction and improving user experience in Web3 are the top priorities of all projects in this ecosystem. In some form, account abstraction may certainly play an important role in future efforts.
