Partnered With:

What is Vitalik's EIP-2938 proposal?

Read this article in 34 Minutes

Learn how EIP-2938’s abstraction of accounts can help reduce friction and improve user experience.

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

Original source: Encryption Valley

Ethereum has two types of accounts. 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 allows 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 user User experience when interacting with Ethereum in various scenarios such as DApps and DeFi. Account abstraction provides a basic layer function in Ethereum to decide when gas can be paid, and who to pay gas for.

The Status Messenger app integrates a privacy-focused messaging system with an Ethereum wallet and a Web3 DApp browser device. 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 proposed in 2017 in the form of EIP-86 to enable "digests of transaction provenance and signatures", but the origin of the idea dates back much earlier, in 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 the first 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. Recently , Vitalik et al. proposed a draft of EIP-2938, which outlines an easier-to-implement approach: by minimizing protocol/consensus changes and enforcing the required safety guarantees through node mempool rules. By Sam Wilson and Vitalik's Ethereum Engineering Group Meetup presentation and ETH Online presentation (and related articles 1 and 2) by Ansgar Dietrichs (two other EIP authors) provide a more detailed introduction to this topic. This article highlights the key from all these sources Content.

Motivation: The motivation behind account abstraction is simple yet fundamental: Ethereum today Transactions have programmable effects (implemented by calling smart contracts), but they only have fixed validity, that is, transactions are valid only if they have valid ECDSA signatures, valid nonces, and sufficient account balances .Account abstraction upgrades transactions from fixed validity to programmable validity by introducing a new account abstract transaction type. This account abstract transaction type always comes from a special address and the protocol does not need to sign it, Nonce or balance checking. The validity of such account abstract 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 wallet: Most Ethereum wallets today are EOA wallets, which are protected by a private key generated by a seed phrase. (BIP-39 seed phrase is a 12-24 an ordered list of words, randomly selected from 2048 words. This provides the entropy required to obtain the binary seed, which is generated using the PBKDF2 function. The binary seed is then used to generate the BIP-32 wallet asymmetric key pair.) The user should write 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 the private key or loss of the seed phrase , resulting in the loss of the user's 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.

Although smart contract wallets are exposed to vulnerable smart Contracts are under the security risk, but this risk can be mitigated by the security testing and review performed by the wallet provider. The risk of the EOA wallet lies entirely with the wallet user, who is 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 via their Guardians Notion implements a keyless social recovery feature, 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 that focuses on team management funds and requires a minimum number of team members ( m-of-n) approval for the transaction to take place. It also enables gasless signatures via meta transactions.

All of these advanced wallet functions 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 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 (2) Since the relayer's transaction requires an additional 21000 base gas fee, and their business needs to make a profit outside of the gas fee, it is technically/economically inefficient ( 3) Using a relayer-only protocol forces applications to rely on non-base layer Ethereum infrastructure with a small user base and uncertain availability guarantees.

Account abstraction will enable smart contract wallets to accept user’s gas-free transactions, and without relying on the relay layer network Pay the gas fee for it. 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 improve transaction privacy by breaking on-chain ties between addresses, the contract accepts ETH deposits that can later 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 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, and then verify zkSnark and deduct some gas fee (deducted from the previous deposit amount), and then transfer the remaining deposit amount to the withdrawal address.

Account abstraction

EIP -Account abstraction proposed by document 2938, allowing contracts to be the 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, for each A user creates a new contract 2) Multi-tenant applications, such as tornado.cash or Uniswap, multiple users interact with the same set of smart contracts.

Account abstraction support for multi-tenant applications needs 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

Introduction A new transaction type has been added, 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 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 will be incremented and the transaction keep going.

The base gas cost for account abstraction transactions is suggested to be 15000 instead of the current 21000 (to reflect the lack of intrinsic ECDSA signature required cost savings). 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: NONCE opcode (0x48) compresses the callee’s NONCE (that is, the account abstract target contract) into 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, ( 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 version_number == 0 (otherwise throw an exception)

< br>

Extract gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])

< p line="VRqW">extract gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])

Check contract.balance >= gas_price * gas_limit (otherwise an exception is thrown)

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

Check AA execution frame==top frame, that is, if the current EVM execution exits or restore, 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

Abstract transaction execution in the account At the end, (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 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 the protocol/consensus level changes, and their semantics are It is easier to understand.

Mempool Rules

" Mempool "refers to a set of in-memory data structures inside an Ethereum node that store 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 their transactions in the mempool, thereby avoiding DoS attacks. For example, if a miner has a valid ECDSA signature, a valid nonce, and has sufficient account balances, it can be determined that a transaction will actually pay the fee. Others in the miner's mempool Transactions can only be invalidated 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 of their mempools Confidence, block waiting or replay respectively.

Account abstraction transactions introduce more The complexity of account abstraction transactions. 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 (PAYGAS before) and a longer execution phase (after PAYGAS). If the verification phase fails (or an exception is thrown), the transaction is invalid (just like non-account abstract transactions with invalid signatures today) and will not be included in a block, Miners also get no fees.

Therefore, miners and nodes need a predictable mechanism to avoid a pending The validity of account abstract transactions in the mempool is dependent 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

For The effectiveness of preventing account abstraction transactions depends 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 targeting the account abstraction contract in the mempool, breaking 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 the non-account abstract transaction can affect the state of the account abstract contract, it will affect the validity of the account abstract transaction in the 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 account abstract contracts together ensure: (1) the validity logic of account abstract transactions The only state that can be accessed is the state inside the account abstraction contract, and (2) this state can only be modified by other account abstraction transactions for this specific account abstraction contract.

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

Expanding

The above agreement Change 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, allowing non-account abstract transaction callers to override the previous Bytecode prefix restriction to safely read values from account abstraction contracts.

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 , the lower bound is sought to be written 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 verification, dynamic gas limit for verification and sponsorship transactions, which are required to support multi-tenant applications and zk proofs, such as 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.

Also, it is not clear whether EIP-2938 is necessary in the Ethereum base layer 1 (L1). 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. So where and how account abstraction is implemented remains to be seen.

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

Status: The Status wallet is currently an EOA wallet, the difference is that it is bundled with a privacy-centric SMS system , and enable integrations like 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.

Status is also evaluating L2 solutions, both to support multi-chain in its wallet and to support various use cases Provide the required extensions as we 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

Ethereum A fundamental aspect of the 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 .

Account abstraction is meaningful to significantly improve user experience in various 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 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.

Reducing friction and improving user experience in Web3 is a top priority for all projects in this ecosystem. Account abstraction, in some form, is likely to certainly play an important role in future endeavors.