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

Crypto Valley Live (ID: cryptovalley)"Crypto Valley Live (ID: cryptovalley)", Author: Rajeev Gopalakrishna, Translator: Olivia, Odaily reproduced with permission.

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 because only EOAs can start transaction execution by paying gas. Account Abstraction (AA) is a proposal that allows a contract to be a

top floor

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. 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 address 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 discuss some proposals for scaling, and conclude by rationalizing the planned roadmap for the Status project interfacing with Ethereum, which may all be affected by the account abstraction."secondary title"History & Motivation"Account abstraction was originally proposed in 2017 as EIP-86 to enable"

Summary of transaction origin and signature

, but the origin of this idea can be traced back to 2016. At that time it was suggested that:

Rather than having an in-protocol mechanism that uses 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 contracts and contracts Gas can be paid, and users are free to define their own security model.

The initial proposal was considered challenging because of the many protocol changes required and the need to guarantee security. More recently, Vitalik 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 the account abstraction is very simple, but fundamental: Ethereum transactions today have programmable effects (implemented by invoking smart contracts), but they only have fixed validity, i.e. only if they have A valid ECDSA signature, a valid nonce, and sufficient account balance are valid for the transaction. 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, 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 the 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.

Smart contract wallets are implemented on-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, this risk can be mitigated by security testing and audits performed by wallet providers. The risk of the EOA wallet lies entirely with the wallet users, who are entrusted with the security of the seed phrase without any procedures 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 enables keyless social recovery through their concept of Guardians, where Guardians are people or devices that users trust to help retrieve their 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 usability (by using ENS names instead of addresses and supporting meta transactions).

Gnosis Safe is a multi-signature smart contract wallet focused on team management of funds, requiring a minimum number (m-of-n) of team members to approve transactions to occur. It also enables gas-free 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 buying 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 the wallet provider on-chain/on-chain off-chain and/or user off-chain compensation.

However, relayer-based architectures have three major disadvantages: (1) they may be considered centralized intermediaries, potentially censoring transactions (2) transactions due to relayers require an additional 21,000 base gas fee, and their business needs to make profits outside of gas fee, so it is technically/economically inefficient (3) using a relayer-only protocol forces applications to rely on non-base layer Ethereum infrastructure, which has a smaller user base, Availability guarantees are not guaranteed.

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

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.

secondary title

The account abstraction proposed by EIP-2938 allows contracts to be the highest-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, 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.

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, multiple users and the same set Smart contract interaction.

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

secondary title

protocol change

A new transaction type has been introduced, along with 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 abstraction transaction are specified by the target account abstraction contract during execution. The ECDSA signatures v, r, s omitted in the account abstraction transaction are replaced by a verification check on the data by a specific contract. The to address is replaced by the target contract address. The reason why this value is omitted is 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 15,000 instead of the current 21,000 (to reflect the cost savings from 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 the verification in the account abstraction contract.

PAYGAS opcode: The PAYGAS opcode (0x49) fetches two parameters from the stack: (top) version_number, (top second) memory_start. version_number allows future implementations to 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 an exception)

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

Check AA execution frame == top 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.

At the end of the execution of the account abstraction transaction, (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 the 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.

"Mempool "The new transaction type and two new opcodes constitute protocol/consensus level changes, and their semantics are relatively easy to understand."secondary title"Mempool rules"Refers to a set of in-memory data structures inside an Ethereum node that store candidate transactions prior to mining. Geth calls it"transaction pool"; Parity calls it"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 area

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 a sufficient account balance, it can be sure that a transaction will actually pay a fee. Other transactions in the miner's mempool may invalidate this pending transaction only if they originate 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 sufficient confidence in their mempools to perform block waiting or replaying respectively.

Opcode Restriction

Account abstraction transactions introduce additional 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.

secondary title

To prevent the validity of an account abstraction transaction from being dependent on any factors 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 calls/creates or precompiles to 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 give up the account abstraction transaction targeted at the account abstraction contract in the mempool, 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.

secondary title

Bytecode prefix restrictions

Together, these two restrictions imposed on the account abstraction contract ensure that (1) the only state accessible to the validity logic of the account abstraction transaction is the state inside the account abstraction contract, and (2) this state can only be accessed by other The account abstraction transaction modification of the account abstraction contract.

expand

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.

secondary title

expand

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

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

RESERVE_GAS opcode, which, when called from a non-account abstraction transaction, establishes a lower bound on the gas consumed by an account abstraction contract seeking to write to the contract state. 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, cached results for validation, dynamic gas limits for validation, and sponsored transactions, which are all needed to support multi-tenant applications and zk proofs, such as Tornado Cash. Details about them are beyond the scope of this article.

secondary title

The next step of the job

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 clearly a hard fork after Berlin (Berlin is tentatively scheduled for sometime in early 2021), and its timetable is currently unclear. So it's too early for EIP-2938.

Status: The Status wallet is currently an EOA wallet, which is differentiated by bundling a privacy-focused SMS system and enabling integrations such as payments in chat or enhanced security for Keycard. 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.

Summarize

Status is also evaluating an L2 solution, both to support multi-chain in its wallet and to provide the required scaling for various use cases, as we covered in an earlier post. For example, Keycard is exploring a payment network whose design requirements for credit card-level scalability and near-instant finality are currently unmet by 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 deployment 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.

secondary title

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