An abstract overview of Ethereum blockchain accounts

An Overview of Account Abstraction in Ethereum Blockchain

Original article by Yash Kamal Chaturvedi

Translation: ETH Chinese

Abstraction and data abstraction in computer programming refers to the process of hiding all data except the "object" related data, with the aim of reducing complexity and increasing effectiveness. It represents objects by omitting unnecessary details. Abstract is one of the three principles of Object-Oriented programming, which is related to encapsulation and data hiding. This article will provide an overview of:

Ethereum account abstraction

· External account/user account

Contract,

Abstract the proposed EIP for the account

· IP-86: abstraction of transaction sources and signatures

· EIP-2938: Account abstraction

· IP-4337: Account abstraction through Entry Point Contracts

Use cases

Wallet,

· Sponsorship deals

Mixed COINS,

DeFi agreement,

Account abstract

Ethereum's account abstraction aims to create a single account type that will include all relevant aspects and none of the extranets, making the developer's job easier.

Type of Ethereum account

Currently, there are two types of accounts on the Ethereum blockchain:

User Account (EOA)

User accounts are for ordinary people (humans).

· These accounts are controlled by a private key corresponding to a public address, such as a user's wallet account.

· These accounts, also known as external accounts (EOA), do not require ETH balances to create an external account on the blockchain. However, transactions can be made between two external accounts using ETH, as well as other tokens supported by ERC.

· External accounts (wallets) for sending and receiving cryptocurrencies exist outside the Ethereum Virtual Machine (EVM).

contract

A contract is a set of instructions controlled by code.

· There are usually costs associated with creating a contract due to the use of network storage.

· Users can operate multiple functions, such as receiving transactions from external and contract accounts and sending transactions to them.

· It can also launch a code that performs a variety of activities, including exchanging tokens or creating a new contract.

· Contract account is a "smart contract" that exists in the EVM.

If you send an ETH to an account controlled by a code contract, no one can control the ETH anymore. The only thing that can move this ETH is the execution of the contract, the code itself.

Both account types have the ability to receive, retain, and send ETH and  Token And the potential to communicate with other smart contracts deployed on the network.

Account abstraction proposal

Ethereum Account Abstraction (AA) is an enhancement of these two account forms, making them more comparable and also making the management logic of external accounts as common as contract accounts.

Its purpose is to reduce the two forms of contract account to one form. The uses of the single account form include coinage and contract transfers. Developers and users will no longer need to distinguish between account types, as transactions will be completely transferred to the EVM and off the blockchain protocol.

Ethereum developers have been looking for ways to do this, but haven't been able to get there. Final  The status of the proposal. In the following sections, we outline the three Ethereum Improvement Proposals (EIP) that have proposed account abstractions so far.

The timeline of the account abstraction proposal

2016:

· Vitalik Buterin came up with the original abstract change idea for Metropolis.

· Its purpose is to prepare an abstraction of account security. In the traditional model, ECDSA (Elliptic Curve Digital Algorithm signature) and the default NONCE scheme are the only ways to protect the account. In this model, all accounts are contract accounts that can pay for GAS, and users are free to define their security model.

2017:

· Vitalik Buterin proposed the abstract EIP-86 for transaction source and signature.

· It aims to abstract away signature verification and nonce checking mechanisms, allowing users to establish account contracts to perform any required signature or nonce checking, rather than relying on traditional methods.

2020:

· Vitalik Buterin, Ansgar Dietrichs, Matt Garnett, Will Villanueva, and Sam Wilson proposed EIP-2938 for account abstraction.

· The purpose is to allow the contract to be a "top tier" account type that can pay fees and perform transactions.

2021:

· Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, and Dror Tirosh proposed EIP-4337 for account abstraction through entry point contract specification.

· The aim is to avoid consensus-layer protocol changes and instead rely on higher-level infrastructure.

Ip-86: Abstraction of transaction source and signature

According to its "summary," EIP-86 proposes to implement a series of changes that serve the combined purpose of "abstracting out" signature verification and nonce checking, allowing users to create "account contracts" for performing any required signature /nonce checking, rather than relying on the use of current mechanisms that are hard-coded into transactions.

The traditional model: ECDSA and the default nonce scheme are the only ways to protect an account.

The new modelAll accounts are contract accounts that can pay for GAS, and users are free to define their security model.

Taking the Forwarding Contract as an example, author Vitalik Buterin explains that the contract verifies the signature. If the signature is valid, it starts issuing payments to the miner and then sends call instructions to the specified address using the given values and data.

The main advantages of this proposal are as follows:

Sign the purse

· Traditional method: Each transaction in the multi-sign wallet must be agreed upon by all participants. We can simplify this by combining all participant signatures into a single approval transaction, but this approach still adds complexity because all participant accounts must hold ETH.

· New approach: With the help of this EIP, the current contract can hold the ETH, directly submit the transaction containing all the signatures to the contract, and the contract will pay the fee.

Custom cryptography

· Traditional approach: Users must follow ECDSA, a cryptography that uses elliptic curves.

· New method: Users can upgrade to ED25519 signature or any scheme they wish to upgrade; Users are not required to adopt ECDSA.

Ip-2938: Account abstraction

According to the summary of EIP-2938, "Account abstraction (AA) allows the contract to be a" top tier "account that can pay fees and perform transactions.

· Traditional model: The validity of a transaction is defined directly by the ECDSA signature, a simple nonce value, and the account balance.

· New model:

1. Account abstraction extends the validity conditions of a transaction by executing random EVM bytecode.

2. In order to express the validity, a new EVM opcode & NBSP is introduced; PAYGAS, also sets gas prices for contracts and caps on gas usage.

3. Account abstractions are now divided into two categories:

Single tenant AA: This type is intended to support use cases where wallets or other actors are few and far between.

Multi-tenant AA: This type is designed to enable multi-user applications like Uniswap.

Consensus change

· NONCE opcode: add an & NBSP; NONCE  Opcode, the nonce field of the push transaction.

· PAYGAS opcode: add an & NBSP; PAYGAS  The opcode, creating an irreversible checkpoint, ensures &NBsp; PAYGAS  Previous state changes cannot be reversed.

Sam Wilson is one of the authors of this proposal, which explains how AA transactions differ from other traditional transactions.

In an AA transaction, there is no GAS price or GAS cap, no sent value and signature field, and     target  Instead of & have spent to  . In a multi-sign contract, these fields are passed in CallData and processed with the contract.

If a transaction arrives at a node, the validity of the transaction is checked. However, traditional transactions and AA transactions are checked in different ways.

· In a traditional transaction: nodes check that their nonce matches the account's next Nonce, that the account balance is sufficient to cover their value and the highest GAS charge, and that their signature matches the account's address.

· In AA transactions: nodes check that their nonce exactly matches the next nonce of the contract, that the bytecode of the contract starts with a standard prefix, and that the validation logic invokes &NBSP before the upper limit of the validation GAS is reached; PAYGAS  , no prohibited opcodes in &NBsp; PAYGAS  Before being called, and the contract balance is sufficient to pay. PAYGAS  Set GAS charges.

Block broadcast time is the average time it takes for a new block to reach most nodes in the network.

When a block with AA transactions arrives, all pending transactions for the same account are deleted. On the other hand, traditional transactions are revalidated and may be published when a new block is received.

IP-4337: Account abstraction through entry point contracts

This is the latest proposal from Vitalik Buterin and the community. It is proposed as an ERC, and this proposal includes changes that avoid consensus layer agreements and rely on higher-level infrastructure.

It aims to achieve the following objectives:

· Account abstraction: allows users to use a smart contract wallet containing random validation logic as their primary account instead of an EOA.

· Decentralized: allow the person who packs the transaction bundle to participate in the process that contains the account abstraction user activity. The user does not need to know the direct communication address of any actor to handle any activity that occurs in the entire common memory pool.

· No consensus change: This proposal avoids consensus change for faster adoption.

· Payment of transaction fees: Payment of transaction fees with ERC-20 standard tokens, enabling developers to pay for their users, and use cases supported by sponsored transaction proposals such as EIP-3074.

How does the proposal work?

Photo credit: Infinitism

Vitalik Buterin explains the operation of the proposal very well here.

This is the latest proposal of account abstraction, which is still in the draft state and waiting to be merged into an EIP. This design adds, maintains, and sacrifices functionality compared to the regular Ethereum transaction memory pool.

Key highlight

No centralized activists, removes client-side wallet setup complexity, fully supports EIP-1559, has the ability to replace charges, sends a new UserOperation at a higher premium than the old UserOperation to replace the operation or retains the functionality to get it packaged faster.

There are some new advantages added:

1. Verify the flexibility of the logic

2. Enough to make the execution layer quantum secure

3. Wallet upgradability

4. Flexible execution logic

However, despite the protocol's best efforts, it slightly increases the likelihood of DoS attacks, it also increases the GAS overhead, and it performs only one transaction at a time.

Account abstraction use case

The wallet

EOA and contract wallet

· EOA wallet: a wallet protected by a private key.

· Contract wallet: wallet implemented on the chain using smart contract.

· Security concerns: If there are bugs in the smart contract code, the contract wallet will be exposed to security risks from vulnerable smart contracts. This risk can be minimized through security testing and vetting done by the wallet provider. However, in an EOA wallet, the risk is entirely borne by the wallet user, just as it is borne by the user who accidentally loses the private key.

Argent, Dapper, Gnosis Safe, and Monolith are all examples of smart contract wallets.

EOA meta-transactions

Ethereum blockchain users require an EOA holding GAS to connect to the blockchain network, or rely on wallet providers to facilitate meta-transactions through their relay or third-party relay networks, such as the Gas Station network. The former relies on ETH purchased by CEX (which needs to do KYC) and tries to minimize UX friction by shifting consumer responsibility to relays, with fees paid by the on-chain/off-chain wallet provider and/or off-chain user.

A meta-transaction is a transaction that contains data information signed by the person who intends to execute the transaction.

Relayer-based architectures have some disadvantages:

1. Think of them as centralized intermediaries with the ability to inhibit transactions

2. Relay transactions are technically/economically inefficient due to the additional 21,000 base GAS charges required and the company's need to make a profit on the gas fee basis.

3. Use of exclusive protocol rights for relays.

Account abstraction allows the smart contract wallet to accept gas-free meta-transactions from users and pay for their GAS without relying on the relay network. The ability of this base layer will also greatly improve the UX (user experience) of the wallet without losing Ethereum's guarantee of decentralization.

Sponsored Transactions

Sponsored Transactions is included in IP-2711 (status revoked), which proposes a mechanism that allows people to conduct Transactions without owning ETH by allowing others to pay for gas.

Some use cases:

1. Allow app developers to make payments on behalf of users.

2. Allow users to pay with ERC-20 tokens, and the contract acts as an intermediary to collect ERC-20 tokens and pay for the network through ETH.

operation

The proposal could support these use cases through a Paymaster mechanism.

· For use case 1: Paymaster verifies that the sponsor's signature is included in   paymasterData  Eg. To show that the sponsorship has been done. UserOperation  Make provision for payment. If the signature is valid, the Paymaster accepts the instruction and deducts the sponsor's share. UserOperation  Of the cost.

· For use case 2: Paymaster checks   sender  Has enough ERC-20 balance in your wallet to pay for this. UserOperation. If it is enough, the Paymaster will accept the instruction and ask for it again. postOp  The ETH fee is paid before the ERC-20 Token in.

Mixed COINS

We will discuss the example of Tornado Cash currency mixing mechanism to understand how we can use AA in DeFi protocol.

Privacy issues in traditional Tornado Cash contracts

· Tornado Cash provides privacy protection when users make withdrawals. They can prove that the money came from a unique deposit, but no one except the user knows where it came from.

· Users do not usually hold ETH in their withdrawal address, if users use their deposit address to pay GAS, this will create an on-chain link between the deposit address and the withdrawal address.

This problem can be solved by third party relays who verify the still valid status of ZK-Snark and Nullifier, publish transactions using their ETH to pay for GAS, and collect user rebates from Tornado Cash contracts.

Solution provided by account abstraction:Users can submit an AA transaction for TC contracts, and then perform ZK-SNARK authentication and Nullifier check, and quickly call &NBSP directly. PAYGAS. This allows withdrawals to pay for GAS directly from the Token sent to their withdrawal address, without a repeater or an on-chain link to their deposit address.

DeFi agreement

Let's discuss the DeFi protocol Uniswap case and see how we can use AA in DeFi protocol.

A new version of Uniswap can be created that allows direct trading of Uniswap contracts.

Currently, users can save their tokens in advance to Uniswap; Uniswap can store a user's balance and public key in order to authenticate transactions that spend those balances.

The goal of AA is to improve the GAS efficiency of the DeFi protocol by prohibiting transactions that do not meet advanced standards from being packaged onto the chain (for example, the presence of matching orders).

In the traditional model:Normal traders would store their tokens outside of Uniswap contracts.

In the new model:Arbitrage traders deposit their tokens on Uniswap and can also transfer trades that execute the arbitrage in the event of a change in the external market. Eventually, the unprofitable trades will not be bundled up if another arbitrage trader executes the trade first. This allows arbitrage traders to avoid paying for GAS and reduces the number of junk deals packaged on the chain. This will increase blockchain scalability and market efficiency, as arbitrage traders are better able to correct price differences across chains.

Arbitrage traderA trader who uses the spread between two or more markets to simultaneously buy at a low price and sell at a high price.

The original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia