In-depth丨What changes will EIP-2938 proposed by Vitalik bring to Ethereum?

There are two types of accounts in Ethereum. External Owned Accounts (EOAs) and Contract Accounts (CAs). EOAs are controlled by private keys, while CAs are controlled by the smart contract code contained within them. EOAs have always been more privileged than CAs, as only EOAs can start transaction execution by paying gas. Account Abstraction (AA) is a proposal that allows contracts to be a "top-level" account like an EOA, which can pay fees and start transaction execution.

The motivation for account abstraction is to significantly improve the user experience when users interact with Ethereum in various scenarios such as wallets, DApps, and DeFi. Account abstraction provides a base layer function in Ethereum to decide when gas can be paid and to whom gas can be paid.

The Status Messenger app integrates a privacy-focused messaging system, as well as an Ethereum wallet and a Web3 DApp browser. The Status wallet is currently an EOA wallet, which limits us from providing a rich user experience that only smart contract wallets can provide, such as multi-signature security, social recovery, interest rate limits, allowed/denied address lists, and gas-free meta transactions. Current smart contract wallet users experience the impact of gas fee fluctuations, and third-party relayers are unable to effectively address this issue. Account abstraction aims to solve this problem.

In this article, we proposed the need for account abstraction in the context of smart contract wallets. We then delved into the key aspects of account abstraction by describing the protocol changes and the impact on nodes. Finally, we discussed some extension proposals and ended by rationalizing the planned roadmap of the Status project that interfaces with Ethereum, all of which may be affected by account abstraction.

History & Motivation

Account abstraction was first proposed in 2017 as EIP-86 to implement "summaries of transaction provenance and signatures", but the origins of the idea date back much earlier to 2016. At the time, it was suggested that "rather than having an in-protocol mechanism that makes ECDSA and the default nonce scheme the only "standard" way to secure accounts, it would be better to take initial steps towards a model where, in the long run, all accounts are contracts, and contracts can pay for gas, and users are free to define their own security models."

The original proposal was considered challenging because many protocols needed to be changed and security guarantees needed to be met. Recently, Vitalik et al. proposed a draft of EIP-2938, which outlines a more achievable approach: by minimizing changes to the protocol/consensus 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 from all of these sources.

Motivation: The motivation behind account abstraction is very simple, but fundamental: Ethereum transactions today have programmable effects (implemented by calling smart contracts), but they only have fixed validity, i.e. they are valid only if they have a valid ECDSA signature and a valid nonce, and have sufficient account balance. Account abstraction upgrades transactions from fixed validity to programmable validity by introducing a new account abstraction transaction type. This account abstraction transaction type always comes from a special address and the protocol does not require signatures, nonce or balance checks on it. The validity of this account abstraction transaction is determined by the target smart contract, which can enforce its own validity rules, after which it can decide to pay for this type of transaction.

So why is this useful? Let’s use the Ethereum wallet as an example to highlight the benefits of account abstraction.

Smart Contract Wallets: Most Ethereum wallets today are EOA wallets, which are protected by a private key generated by a seed phrase. (A BIP-39 seed phrase is an ordered list of 12-24 words that are randomly selected from a pool of 2048 words. This provides the entropy required to obtain a binary seed, which is generated using the PBKDF2 function. The binary seed is then used to generate an asymmetric key pair for a BIP-32 wallet.) Users should write down the seed phrase in a safe place, as it may be needed later to recover the key on another wallet. However, such wallets are vulnerable to theft of private keys or loss of seed phrases, resulting in loss of user funds.

Smart contract wallets are implemented on-chain through smart contracts. This type of wallet provides programmable functionality, risk mitigation, and user-friendly experience by implementing multi-signature security, social or time-based recovery, rate limits on transactions or amounts, allowed/denied address lists, gas-free transactions, and batch transactions.

While smart contract wallets are exposed to the security risk of vulnerable smart contracts, this risk can be mitigated by security testing and audits performed by wallet providers. The risk for EOA wallets lies entirely with the wallet user, who is entrusted with the security of the seed phrase, without any procedures in place to ensure security in the smart contract.

Examples of smart contract wallets are Argent, Authereum, Dapper, Dharma, Gnosis Safe, Monolith, and MYKEY. As shown in the chart below, the adoption of this type of wallet appears to be increasing.

Argent enables keyless social recovery through their concept of Guardians, where Guardians are people or devices that the user trusts to help recover the user's wallet. Argent also aims to combine bank-like security (through features such as daily transaction limits, account locking, and trusted contacts) with Venmo-like usability (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-managed funds and requires a minimum number of team members (m-of-n) to approve transactions before they can occur. It also enables gas-free signatures through meta transactions.

All of these advanced wallet features require the use of sophisticated smart contracts. Wallet users either need to interact with EOAs or rely on wallet providers to support meta transactions through the provider's relayers or third-party relayer networks such as the Gas Station Network. The former relies on purchasing ETH on a centralized exchange after KYC, while the latter aims to reduce this on-chain user experience friction by shifting the burden of the user to the relayer, with the cost compensated by the wallet provider on-chain/off-chain and/or the user off-chain.

However, relayer-based architectures have three major drawbacks: (1) they may be perceived as centralized intermediaries that can potentially censor transactions; (2) relayer transactions require an additional 21,000 base gas fee, and their operations need to make a profit on top of the gas fee, making them technically/economically inefficient; and (3) using relayer-only protocols forces applications to rely on non-base layer Ethereum infrastructure, which has a smaller user base and uncertain availability guarantees.

Account abstraction will enable smart contract wallets to accept gas-free transactions from users and pay gas fees for them without relying on the relayer network. Therefore, this base layer capability will greatly improve the onboarding user experience of such wallets without sacrificing Ethereum’s decentralized guarantees.

Tornado Cash: A related motivation application is a mixer, such as tornado.cash, where Tornado improves transaction privacy by breaking the on-chain connection between addresses using a smart contract that accepts ETH deposits that can be subsequently withdrawn by different addresses. Users are required to provide a hash of a secret when depositing, and then provide a zkSnark proof when withdrawing to show knowledge of the secret without revealing the secret or the previous deposit itself. This decouples withdrawals from deposits.

But there is a problem with withdrawals. To perform a withdrawal transaction from a 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 undermine Tornado's privacy. The preferred alternative is to use the relayer 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 the 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 EIP-2938 allows contracts to become the highest-level accounts that pay fees and start executing transactions. This is achieved by introducing protocol changes, new account abstraction transaction types require two new opcodes: NONCE and PAYGAS, changes to the rules of the mempool, 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 protocols.

There are two aspects to consider when applying account abstraction: 1) Single-tenant applications, such as smart contract wallets, where a new contract is created for each user 2) Multi-tenant applications, such as tornado.cash or Uniswap, where multiple users interact with the same set of smart contracts.

Account abstraction support for multi-tenant applications requires more research and is recommended as future work. So we will focus on the support of single-tenant account abstraction in this article.

Protocol Changes

A new transaction type is introduced, along with two opcodes supporting NONCE and PAYGAS. These are the only protocol changes.

Account Abstraction Transaction: A new account abstraction transaction type AA_TX_TYPE is 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 omitted gas_price and gas_limit in the account abstraction transaction are specified by the target account abstraction contract during execution. The omitted ECDSA signatures v, r, s in the account abstraction transaction are replaced by a specific contract to verify the data. The to address is replaced by the target contract address. The reason for omitting this value is that the originating address of all account abstraction transactions is a special ENTRY_POINT address (0xFFFF...FFF) instead of the EOA value associated with it.

If the check fails, the transaction is considered invalid, otherwise, tx.target.nonce is incremented and the transaction proceeds.

The base gas cost of account abstraction transactions is proposed to be 15000, rather than the current 21000 (to reflect the cost savings from the lack of intrinsic ECDSA signatures). Additionally, account abstraction transactions have no intrinsic gas limit. At the start of execution, the gas limit is simply set to the remaining gas for the group.

NONCE opcode: The NONCE opcode (0x48) pushes the callee's NONCE (i.e. the account abstraction target contract) onto the EVM stack. As a result, the Nonce is exposed to the EVM to allow signature verification of all transaction fields (including the nonce) as part of the verification in the account abstraction contract.

PAYGAS opcode: The PAYGAS opcode (0x49) takes two parameters from the stack: (top) version_number, (second from top) memory_start. version_number allows future implementations to change the semantics of the opcode. Currently, the semantics of this opcode are as follows.

Check if 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 throw an exception)

Check globals.transaction_fee_paid == False (otherwise throw an exception)

Check that the AA execution frame == the top-level frame, i.e. if the current EVM execution is exited or rolled back, 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 - consumed gas.

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 acts as an EVM checkpoint. Any restore after this point will only restore to 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 relatively easy to understand.

Mempool Rules

"Mempool" refers to a set of in-memory data structures inside an Ethereum node that stores candidate transactions before they are mined. Geth calls it the "transaction pool"; Parity calls it the "transaction queue." Regardless of the name, it's a pool of transactions sitting in memory waiting to be included in a block. Think of it as a "waiting area" for transactions to be accepted into a block. "

Currently, with fixed transaction validity rules, miners and other nodes only need minimal effort to verify transactions in their mempool, thus avoiding DoS attacks. For example, if a miner has a valid ECDSA signature, a valid nonce, and a sufficient account balance, it can be certain that a transaction will actually pay the fee. Other transactions in the miner's mempool can only invalidate this pending transaction if they come from the same address and increase the nonce or sufficiently reduce the account balance. These conditions are computationally minimal to allow miners and nodes to have enough confidence in their mempools to wait for blocks or replay, respectively.

Account abstraction transactions introduce further complexity with their programmable validity. Account abstraction transactions do not pay any upfront gas, and rely on their target account abstraction contract to pay for gas (via PAYGAS). Conceptually, account abstraction transaction processing occurs in two phases: a shorter validation phase (before PAYGAS) and a longer execution phase (after PAYGAS). If the validation phase fails (or throws an exception), the transaction is invalid (just like invalidly signed non-account abstraction transactions today), 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 dependencies of the validity of a pending account abstraction transaction on other pending transactions in the mempool. Otherwise, the execution of one transaction could invalidate many/all account abstraction transactions in the mempool, leading to a DoS attack. To avoid this, there are two recommended rules to be enforced on account abstraction transactions in mempools (by miners and nodes, but not in the protocol itself).

Opcode Restriction

To prevent the validity of account abstraction transactions from depending on anything other than the account abstraction contract itself, the following opcodes are considered invalid during the verification phase (i.e. before PAYGAS): environmental opcodes (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT), BALANCE (any account, including the target itself), external calls/creations or precompiles of anything other than the target (CALL, CALLCODE, STATICCALL, CREATE, CREATE2), and external state accesses that read code (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL), unless the address is the target.

Nodes must abandon account abstraction transactions in the mempool that target the account abstraction contract, breaking this opcode restriction rule. This ensures that valid account abstraction transactions in the mempool will remain valid as long as the state of the account abstraction contract does not change.

Bytecode prefix restrictions

If non-account abstraction transactions can affect the state of account abstraction contracts, then it will affect the validity of account abstraction transactions in the mempool. To prevent this from happening, account abstraction transactions should only be allowed for contracts that have AA_PREFIX at the beginning of their bytecode, where AA_PREFIX implements a check that msg.sender is the special ENTRY_POINT address of the account abstraction transaction. This effectively prevents non-account abstraction transactions from interacting with account abstraction contracts.

The node should pass the account abstraction transaction to the account abstraction contract which does not have this AA_PREFIX at its bytecode entry point.

Together, these two restrictions on the account abstraction contract ensure that: (1) the only state accessible to the validity logic of an account abstraction transaction is the state internal to the account abstraction contract, and (2) this state can only be modified by other account abstraction transactions targeting this specific account abstraction contract.

Therefore, an outstanding account abstraction transaction will only be invalidated if there is another pending transaction targeting the same account abstraction contract. However, given that these are not protocol/consensus changes, miners are free to include transactions in blocks that break these rules.

Extensions

The above protocol changes and mempool rules allow basic account abstraction contracts to fully and safely implement single-tenant applications, such as smart contract wallets. Other advanced usages that require relaxation of the above rules or need to implement multi-tenant applications require account abstraction to provide more support in the form of extensions, such as.

SET_INDESTRUCTIBLE opcode, disabling SELFESTRUCT, allows the account abstraction contract to safely call DELEGATECALL during the verification phase.

IS_STATIC opcode, returns true if the current context is static, allowing non-account abstraction transaction callers to override previous bytecode prefix restrictions and safely read values ​​from the account abstraction contract.

The RESERVE_GAS opcode, when called from a non-account abstraction transaction, establishes a lower limit on the gas consumed by an account abstraction contract that seeks to write contract state. This has the effect of forcing an attacker to not consume a minimum amount of gas to disincentivize attempts to invalidate any account abstraction transactions in the mempool.

There are others like multiple pending transactions, cached results of validation, dynamic gas limits for validation, and sponsored transactions, which are needed to support multi-tenant applications and zk-proofs like Tornado Cash. Their details are beyond the scope of this article.

Next steps

Account Abstraction EIP-2938 is currently in draft mode and is being discussed in the Ethereum Research Forum. The next step for the EIP is to be considered for inclusion in one of the upcoming hard forks. The EIP author is clearly targeting a hard fork after Berlin (Berlin is tentatively scheduled for sometime in early 2021), and the timeline for that is not very clear at this point. So it’s still too early for EIP-2938.

Furthermore, it is not clear whether it is necessary to add EIP-2938 to Ethereum's base layer 1 (L1). Given the relative flexibility of layer 2 (L2) solutions (as described in our previous article), account abstraction can be implemented on a specific L2 without upgrading the entire L1. However, even if some L2s implement 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 account abstraction is implemented.

“Account abstraction is less important because it can be implemented on L2 regardless of whether L1 supports it or not.” — Vitalik in his post on Ethereum’s rollups-centric roadmap (something that will continue to work on the base layer).

Status: The Status wallet is currently an EOA wallet, which is differentiated by bundling a privacy-centric messaging system and enabling integrations such as payments in chat or the enhanced security of Keycard. Smart contract wallet features such as multi-signature and social recovery are being considered, and support for account abstraction EIP-2938 will help eliminate reliance on centralized and inefficient relayer-based architectures, as mentioned previously.

Status is also evaluating L2 solutions, both to support multiple chains in its wallet and to provide the scaling needed for various use cases, as we described in an earlier post. For example, Keycard is exploring a payment network with design requirements of credit card-level scalability and near-instant finality that cannot be met by the current Ethereum network. In addition, there are many other initiatives such as referral programs, Tribute-to-Talk, and ENS names, all of which would benefit from L2 scalability to achieve viable deployments and reasonable user experiences. If a viable L2 solution implements account abstraction, then projects built on that L2 will be able to take advantage of the account abstraction without having to rely on L1.

Summarize

A fundamental aspect of the Ethereum protocol is that only Externally Owned Accounts (EOAs) can pay gas fees and start executing transactions. Contract Accounts (CAs) cannot do this. Account Abstraction (AA) is a proposal to change this distinction, allowing specially constructed CAs to programmatically check the validity of new types of account abstraction transactions, decide to pay gas fees on their behalf, and effectively start their execution without the need for an EOA.

Account abstraction has the potential to significantly improve the user experience in a variety of scenarios such as wallets, mixers, DApps, and DeFi, without relying on a centralized and inefficient relayer-based architecture. Basic single-tenant scenarios, such as smart contract wallets, can be safely supported by account abstraction by introducing a new transaction type, two new opcodes, and two mempool rules. Advanced multi-tenant applications, such as Tornado Cash, require extensions to these protocol changes and node rules.

In this post, we mentioned the need for account abstraction in the context of smart contract wallets. We highlighted key aspects of account abstraction by describing the protocol changes and the impact on nodes. We touched on some proposed extensions for advanced uses, and finally, we positioned account abstraction within Ethereum’s current roadmap and Status’ priorities.

Reducing friction and improving user experience in Web3 is a top priority for all projects in this ecosystem. Account abstraction, in some form, will probably certainly play a big role in future efforts.