Partnered With:

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

Read this article in 32 Minutes

In this paper, we address the need for account abstraction in the context of smart contract wallets.

Original source: Crypto Valley

There are two types of accounts in Ethereum. External Own Account (EOA) and Contract Account (CA). 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 initiate transaction execution by paying gas. Account Abstraction (AA) is a proposal that would allow a contract, like EOA, to be a "top-level" account that 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 to pay gas.

The Status Messenger app integrates a privacy-focused messaging system along with an Ethereum wallet and a Web3 DApp browser. The Status wallet is currently an EOA wallet, which limits us from offering the rich user experience that only smart contract wallets can, such as multi-signature security, social recovery, interest rate limits, allow/deny address lists, and gas-free meta transactions. At present, users of smart contract wallets experience 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 paper, we propose the need for account abstraction in the context of smart contract wallets. We then dive into key aspects of the account abstraction by describing protocol changes and the impact on nodes. Finally, we discussed some proposals for scaling, and concluded by rationalizing the planned roadmap for the Status project interfacing with Ethereum, which may all be affected by the account abstraction.

History & Motivation

Account abstraction was originally introduced in 2017 as EIP-86 It was proposed in the form of "transaction origin and signature", but the origin of this idea can be traced back to 2016. It was suggested at the time: “Instead of having an in-protocol mechanism with ECDSA and the default nonce scheme as the only “standard” way to keep accounts secure, it would be better to take initial steps and build a model where in the long run all accounts are is a contract, and the contract can pay for gas, and users can freely define their own security model. ”

The original proposal was considered challenging due to the many protocol changes required and the need to maintain security. More recently, Vitalik Buterin et al. proposed a draft of EIP-2938, which outlines a more achievable approach: by minimizing protocol/consensus changes and enforcing the required safety guarantees through node mempool rules. Vitalik's Ethereum Engineering Group Meetup presentation and ETH Online presentation (and related articles 1 and 2) by Sam Wilson and Ansgar Dietrichs (two other EIP authors) provide a more detailed introduction to this topic. This article highlights key takeaways from all of these sources.

Motivation

The motivation behind account abstraction is simple but fundamental : Today’s Ethereum transactions have programmable effects (implemented by calling smart contracts), but they only have fixed validity, that is, only when they have valid ECDSA signatures and valid nonces, and have sufficient account balances, Transactions are valid. Account Abstraction Upgrade 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, nonces or balance checks on it. The validity of such account abstraction transactions is determined by the target smart contract, which can enforce its own validity rules, after which it can decide to pay for such transactions.

So, why is this useful? We 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 secured by a private key generated from a seed phrase. (The BIP-39 seed phrase is an ordered list of 12-24 words randomly selected from 2048 words. This provides the entropy needed to obtain the 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 keep the seed phrase in a safe place, as it may be needed later to recover keys on another wallet. However, such wallets are vulnerable to theft of private keys or loss of seed phrases, resulting in loss of users' funds.

The smart contract wallet is implemented on the chain through smart contracts. This wallet provides programmable risk mitigation and user-friendly experience by implementing features such as multi-signature security, social or time-based recovery, rate limiting on transactions or amounts, allow/deny address lists, gas-free transactions, and batch transactions.

While smart contract wallets are exposed to the security risk 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 user, who is entrusted with the security of the seed phrase without any program in the smart contract to ensure security.

Examples of smart contract wallets are Argent, Authereum, Dapper, Dharma, Gnosis Safe, Monolith and MYKEY. As the chart below shows, adoption of such wallets appears to be increasing.

Argent implements keyless social recovery with their Guardians concept, Among them, Guardians are people or devices that the user trusts and can help retrieve the user's wallet.

Argent also aims to achieve bank-like security (through features such as daily transaction limits, account locks, and trusted contacts) and Venmo-like usability ( Combined by using ENS names instead of addresses and supporting meta transactions).

Gnosis Safe is a multi-signature smart contract wallet that focuses on team management funds and requires a minimum number of team members (m-of-n) to approve transactions. occur. It also enables gasless signatures via meta transactions.

All of these advanced wallet features require the use of well-established smart contracts. Wallet users will either need to interact with EOA, or rely on the wallet provider to support meta transactions through the provider's relayer or a third-party relayer network such as the Gas Station Network. The former relies on purchasing ETH on post-KYC centralized exchanges, while the latter aims to reduce this on-chain user experience friction by shifting the burden of users onto relayers, the cost of which is borne by wallet providers on-chain/on-chain down and/or user off-chain compensation.

However, relayer-based architectures have three major disadvantages: (1) they may be perceived as centralized Censorship is (2) technically/economically inefficient as relayers' transactions require an additional 21,000 base gas fee, and their business needs to make a profit on top of the gas fee (3) using a relayer-only protocol forces The application relies on the non-base layer Ethereum infrastructure, which has a small 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 relay layer network. Therefore, this grass-roots capability will greatly improve the onboarding user experience of such wallets without sacrificing the decentralization guarantees of Ethereum.

Tornado Cash: A related motivational application is coin mixers such as tornado.cash, where Tornado uses smart contracts to break on-chain ties between addresses to To improve transaction privacy, the contract accepts ETH deposits, which can then be withdrawn by different addresses. Users are required to provide the hash of the secret when making a deposit, and later 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 the withdrawal, to execute the withdrawal transaction from the newly generated address, the user needs to have some ETH in it to pay for the gas. The source of this ETH (typically an exchange) would compromise Tornado's privacy. The preferred alternative is again to use a network of repeaters, but it has the disadvantages outlined earlier.

Account abstraction will solve this problem, allowing the Tornado contract to accept the user's withdrawal account abstract transaction, then verify the zkSnark and deduct some gas fees (from the previous deposit amount deduction), and then transfer the remaining deposit amount to the withdrawal address.

Account Abstraction

EIP-2938 The account abstraction proposed by the document allows contracts to be top-level accounts that pay fees and start executing transactions. This was achieved by introducing a protocol change, a new account abstraction transaction type requiring two new opcodes: NONCE and PAYGAS, a rule change to the mempool, and an extension 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.

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 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.

The protocol change

Introduced a New transaction type, 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 is introduced. Its effective type is interpreted as RLP([nonce, target, data]) instead of the existing transaction type. The valid type for 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 omitted ECDSA signatures v, r, s in the account abstraction transaction are replaced by specific contract verification checks on the data. The to address is replaced by the target contract address. This value is omitted because the origination address of all account abstract transactions is a special ENTRY_POINT address (0xFFFF...FFF), not 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 for account abstraction transactions is proposed to be 15000 instead of the current 21000 (to reflect the cost savings of the lack of intrinsic ECDSA signatures). Additionally, account abstract transactions have no intrinsic gas limit. At the start of execution, the gas limit simply needs to be set to the remaining gas for the group.

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

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

check version_number == 0 (otherwise throw 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 exception)< /p>

Check globals.transaction_fee_paid == False (otherwise an exception is thrown)

Check AA execution frame == top-level frame, that is, if the current EVM execution exits or restores, the EVM execution of the entire transaction Terminate (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 already consumed.

At the end of the account abstraction transaction execution, (globals.gas_limit - remaining_gas) *globals.gas_price is transferred to the miners, and the account abstraction contract returns remaining_gas * globals.gas_price.

PAYGAS performs checkpointing as EVM. Any reverts after this point will only be reverted here, then the contract does not accept refunds, and globals.gas_limit * globals.gas_price is transferred to the miner.

The new transaction type and two new opcodes constitute protocol/consensus level changes, and their semantics are relatively easy to understand.

Mempool Rules

"Mempool" means is a set of in-memory data structures inside an Ethereum node that stores candidate transactions prior to mining. Geth calls it a "transaction pool"; Parity calls it a "transaction queue". Regardless of the name, it is a pool of transactions sitting in memory waiting to be included in a block. Think of it as a "waiting zone", waiting for transactions to be accepted into a block.

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

Account abstraction transactions introduce further complexity with their programmable effectiveness. Account abstraction transactions do not pay any upfront gas, and rely on their target account abstraction contracts to pay for gas (via PAYGAS). Conceptually, account abstraction transaction processing is divided into two phases: a shorter verification phase (before PAYGAS) and a longer execution phase (after PAYGAS). If the verification phase fails (or throws an exception), the transaction is invalid (like non-account abstraction transactions with invalid signatures today), will not be included in a block, and the miner receives no 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 one transaction may invalidate many/all account abstract transactions in the mempool, resulting in a DoS attack. To avoid this, there are two proposed rules to be enforced on account abstraction transactions in mempools (by miners and nodes, but not in the protocol itself).

Opcode Restriction

In order to prevent account abstraction The validity of a transaction depends on any factor other than the account abstraction contract itself, the following opcodes are considered invalid during the verification phase (i.e. before PAYGAS: BEFORE PAYGAS): Environment 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 state access to read code (EXTCODESIZE, EXTCODEHASH , EXTCODECOPY, DELEGATECALL), unless the address is the target.

The node should abandon the account abstraction transaction in the mempool that targets the account abstraction contract, and break this opcode restriction rule. This ensures that valid account abstraction transactions in the mempool will remain valid as long as the account abstraction contract state does not change.

bytecode prefix limit

if Non-account abstract transactions can affect the state of account abstract contracts, which will affect the validity of account abstract transactions in mempool. To prevent this from happening, account abstract 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 a special ENTRY_POINT address for account abstract transactions. This effectively prevents non-account abstract transactions from interacting with account abstract contracts.

The node will throw the account abstraction transaction to the account abstraction contract that does not have this AA_PREFIX in its bytecode entry point.

These two restrictions imposed on the account abstraction contract together ensure that: (1) the only state accessible to the validity logic of the account abstraction transaction is the account abstraction The state inside the contract, (2) This state can only be modified by other account abstract transactions for this specific account abstract contract.

Therefore, an outstanding account abstraction transaction will only be invalidated if there is another pending transaction for 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.

Extension

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

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

IS_STATIC opcode, returns true if the current context is static, allows non-account abstract transaction callers to override previous bytecode prefix restrictions, safely from Read the value in the account abstract contract.

RESERVE_GAS opcode, when called from a non-account abstraction transaction, it establishes a lower bound on the gas consumed by an account abstraction contract seeking to write to the contract state of. What this does is force an attacker to not consume a minimum amount of gas to inhibit attempts to invalidate any account abstract transactions in the mempool.

There are others such as multiple pending transactions, validating cached results, validating dynamic gas limits and sponsoring transactions, which are support for multi-tenant applications and zk proofs like Tornado Cash. Details about them are beyond the scope of this article.

Next step

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 authors are clearly targeting a post-Berlin hard fork (Berlin is tentatively scheduled for sometime in early 2021), the timeline for which is currently unclear. So it's too early for EIP-2938.

Furthermore, it is not clear whether adding EIP-2938 to the Ethereum base layer 1 (L1) is necessary. Given the relative flexibility of Layer 2 (L2) solutions (as discussed in our previous post), 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, uniform support for account abstraction at L1 has benefits. Therefore, where and how the account abstraction is implemented remains to be seen.

"Account abstraction is less important because it can be implemented at L2 regardless of whether L1 supports it or not." --- Vitalik in his talk about rollup-centric The article on the Ethereum roadmap talks about things that will continue to work at the base layer).

Status: The Status wallet is currently an EOA wallet. Its difference is that it bundles a privacy-centric SMS system and realizes payment or Keycard's enhanced security and more integrations. Smart contract wallet features such as multi-sig and social recovery are being considered, and support for account abstraction EIP-2938 will help remove reliance on centralized and inefficient relayer-based architectures, as discussed earlier.

Status is also evaluating L2 solutions both to support multi-chain in its wallet and to provide the required extensions for various use cases, as we have done in described in the previous article. For example, Keycard is exploring a payment network whose design requirements for credit card-level scalability and near-instant finality are currently beyond the reach of the Ethereum network. In addition, there are many other programs such as Referral Program, Tribute-to-Talk, and ENS Names, all of which will benefit from L2 scalability for viable deployments and reasonable user experience. If a viable L2 solution implements account abstraction, projects built on that L2 will be able to take advantage of account abstraction without having to rely on L1.

Summary

One of the Ethereum protocols The basic aspect is that only externally owned 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 purpose-built CAs to programmatically check the validity of new account abstraction transactions, decide to pay gas fees on their behalf, and thus effectively initiate their execution without the need for an EOA .

Account abstraction makes sense to significantly improve user experience in various scenarios such as wallets, mixers, DApps and DeFi, without relying on centralization and inefficiency The 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 article, we mentioned the need for account abstraction in the context of smart contract wallets. We highlight key aspects of the account abstraction by describing protocol changes and their impact on nodes. We touched on some proposed extensions for advanced use, and finally, we positioned the account abstraction within Ethereum's current roadmap and Status' priorities.

In Web3 Reducing friction and improving user experience are the top priorities of all projects in this ecosystem. In some form, account abstraction will probably certainly play an important role in future endeavors.