Abstraction or data abstraction in computer programming is the process that hides all but the relevant data about an “object” in order to reduce complexity and increase efficiency. It works in a way to represent the object with unwanted detail omitted. Abstraction is one of three principles of object-oriented programming and is related to both encapsulation and data hiding. This article will provide an overview of

• Ethereum Account Abstraction
  • EOA
  • Contract
• Proposed EIPs for Account Abstraction
  • EIP-86: Abstraction of transaction origin and signature
  • EIP-2938: Account Abstraction
  • EIP-4337: Account Abstraction via Entry Point Contract
• Use case
  • Wallet
  • Sponsored transaction
  • Mixer
  • DeFi Protocol

Account Abstraction

Account abstraction in Ethereum has the goal of creating a single account type that will have all the relevant aspects included and none of the extraneous ones making the developers life easier.

Types of Ethereum accounts

Currently, on Ethereum blockchain there are two types of accounts -

User Account (EOA)

User Account is for general people (human).

• These accounts are controlled by private keys to the corresponding public address, eg. user's wallet account.
• These are also known as externally-owned accounts (EOA) that can be created on the blockchain with 0 ETH balance. However, transactions between two externally-owned accounts can be carried out by ETH and other ERC supported tokens.
• The send & receive function of EOA (wallet) used for cryptocurrency exist outside of the Ethereum Virtual Machine (EVM).

Contract

Contract is set of instructions and is controlled by code.

• Creating a contract usually has a cost associated because of network storage usage.
• A user can perform multiple functions such as accepting & sending a transaction to & from an external account, to a contract account.
• It can also initiate a code that can do several other activities including exchanging tokens or even creating a new contract.
• Contract accounts are "smart contracts" that exist in the EVM.

If you send 1 ETH to the account that is controlled by contract of code then, no person controls that any more. The only thing that can move that ETH is the execution of contract is code itself.

Both account forms include the potential to receive, keep and transmit ETH and tokens as well as Communicate with other smart contracts deployed on the network.

Account Abstraction proposals

Ethereum Account Abstraction (AA) is an enhancement to make these two forms of accounts more comparable and to make external account management logic as versatile as contract accounts.

The goal is to reduce the contract account from two forms of accounts to one. The functionalities of the single account form include coin and contract transfers. Developer and customer will no longer need to differentiate between the account type, since the transaction will be entirely transferred to the EVM and out of the blockchain protocol.

Ethereum devs have been looking into methods of implementation and still there is no proposal in Final status. In the following section, we will have an overview of three Ethereum Improvement Proposals proposed for Account Abstraction till date.

Timeline of Account Abstraction proposals

2016:

• Vitalik Buterin proposed an idea for initial abstraction changes for Metropolis.
• The goal was to prepare an account security abstraction. In traditional model, ECDSA and the default nonce scheme are the only way to secure an account. In this model, all accounts are contracts, contracts can pay for gas, and users are free to define their security model.

2017:

• Vitalik Buterin proposed EIP-86 for abstraction of transaction origin and signature.
• The goal was to abstract out signature verification and nonce checking and allowing users to establish account contracts that conduct any required signature/nonce checks rather than relying on the traditional method.

2020:

• Vitalik Buterin, Ansgar Dietrichs, Matt Garnett, Will Villanueva and Sam Wilson proposed EIP-2938 for account abstraction.
• The goal was to allow a contract to be the top-level account that can pay fees and start transaction execution.

2021:

• Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel and Dror Tirosh proposed EIP-4337 for account abstraction via entry point contract specification.
• The goal is to avoid consensus-layer protocol changes instead of relying on higher-layer infrastructure.

EIP-86: Abstraction of transaction origin and signature

According to "Simple Summary", the EIP-86 proposed to implements a set of changes that serve the combined purpose of “abstracting out” signature verification and nonce checking, allowing users to create “account contracts” that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.

The goal was to prepare an account security abstraction. It included changes to abstract out signature verification and nonce checking and allowing users to establish account contracts that conduct any required signature/nonce checks rather than relying on the traditional method.

Traditional Model: ECDSA and the default nonce scheme are the only way to secure an account.

New Model: All accounts are contracts, contracts can pay for gas, and users are free to define their security model.

With an example of forwarding contract, the author Vitalik Buterin explained that this contract verifies the signature, and if it is valid, it initiates a payment to the miner and then sends a call to the specified address with the given value and data.

_Forward Contract is a contract between 2 parties to buy or sell an asset at a specified price on a future date._

Advantages

The main advantages of this proposal as suggested are:

Multisig Wallets

• Traditional Method: Each transaction in a multisig wallet must be approved by all the participants. We can simplify this by combining all participants' signatures into a single ratification transaction, but it still increases complexity as all participants' accounts must have ETH.
• New Method: With this EIP, the contract will now be able to hold the ETH, submit a transaction with all signatures to the contract directly, and the contract will be able to pay the fees.

Custom Cryptography

• Traditional Method: Users must follow ECDSA, which uses elliptic curve cryptography.
• New Method: Users can upgrade to ed25519 signatures or any other scheme they wish on their terms; they are not required to adopt ECDSA.

EIP-2938: Account Abstraction

As per simple summary of the proposal-2938, "Account abstraction (AA) allows a contract to be the top-level account that pays fees and starts transaction execution."

Traditional Model: Transaction validity is strictly defined by: ECDSA signature, a simple nonce, and account balance.

New Model:

1. Account abstraction expands transaction validity conditions through the execution of arbitrary EVM bytecode.
2. To indicate validity, a new EVM opcode PAYGAS, which also sets the contract's gas price and gas limit is used.
3. Account abstraction is now divided into two categories;

• Single-Tenant AA: It is intended to support wallets or other use cases with few participants.
• Multi-Tenant AA: It is intended to enable applications like Uniswap, which have many users.

Changes in Consensus

This is a Core proposal requesting changes to the Ethereum client consensus. Expected changes are:

• NONCE opcode: Adding a NONCE opcode pushes the nonce field of the transaction.
• PAYGAS opcode: Adding a PAYGAS opcode creates an irreversible checkpoint that ensures changes to the state before PAYGAS cannot be reversed.

Sam Wilson, one of the authors of the proposal explained how an AA transaction differs from a traditional transaction here.

In AA transactions, there is no gas price or limit, no value to send, no signature fields, and target in place of to. In the multisig contract, these fields are delivered in the calldata and processed by the contract.

If a transaction arrives at a node, the validity of the transaction is checked. But the checks are different in Traditional transactions and AA transactions.

• In Traditional Transactions: Nodes check that; their nonce matches the account’s next nonce, the account balance is enough to cover their value in addition to maximum gas fees, and their signature matches the account’s address.

• In AA Transactions: Nodes check that; their nonce matches the contract’s next nonce exactly, contract’s bytecode begins with a standard prefix, validation logic calls PAYGAS before reaching the validation gas limit, no banned opcodes are called before PAYGAS, and contract’s balance is sufficient to cover the gas fees set by PAYGAS.

Block Propagation is the average amount of time required for a new block to reach the majority of nodes in the network.

When the block with the AA transaction comes, any pending transactions for the same account are dropped. Traditional transactions, on the other hand, are revalidated and probably published when a new block is received.

EIP-4337: Account Abstraction via Entry Point Contract

This is the latest proposal by Vitalik Buterin & community. It is proposed as an ERC and this proposal includes changes to avoid consensus-layer protocol changes instead of relying on higher-layer infrastructure.

It aims to accomplish the following goals;

• Account abstraction: Allowing users to use smart contract wallets which contains arbitrary verification logic instead of EOAs as their primary account.
• Decentralization: Allow any bundler to participate in the process of including account-abstracted user activities. Users do not need to know the direct communication addresses of any actors to work with any activity occurring across a public mempool.
• No Consensus Changes: For faster adoption, this proposal avoids consensus changes.
• Payment of Transaction Fees: Pay transaction fees using ERC-20 tokens, enable developers to pay fees for their users, and EIP-3074-like sponsored transaction use cases.

How does this work?

Image Source: Infinitism

The working of the proposal is well explained by Vitalik Buterin here.

This is the most recent proposal for account abstraction, waiting to be merged to become an EIP. This design add, maintain and sacrifice some features compared to the regular Ethereum transaction mempool.

Key highlights

• No centralized actors, no user-side wallet setup complexity, Full EIP 1559 support, and ability to replace-by-fee, sending a new UserOperation with a significantly higher premium than the old one to replace the operation or get it included faster features are maintained.
• Some of the new added advantages are:
  • Verification logic flexibility
  • Sufficient to make the execution layer quantum-safe
  • Wallet upgradeability
  • Execution logic flexibility
• However, it will slightly increased DoS vulnerability despite the protocol’s best effort, it will also increase gas overhead and will execute only one transaction at a time.

There is an implementation in progress here.

Account Abstraction Use Cases

Wallet

EOA and Contract Wallets

EOA Wallets: Wallets which are protected by a private key.
Contract Wallets: Wallets which are implemented on-chain using smart contracts.

Security consideration: Contract Wallets are exposed to security risk from vulnerable smart contracts if there is a bug in smart contract coding. This risk can be minimized by security testing and reviews done by the wallet provider. However, in EOA wallets, risk is entirely on the wallet user as if the user loses its private key by mistake.

Implementation of Account Abstraction will allow EOAs to behave as smart contract wallets. Argent, Dapper, Gnosis Safe and Monolith are some examples of smart contract wallets.

Meta Transaction on EOA

An Ethereum blockchain user needs an EOA with gas to connect with them or rely on the wallet provider to facilitate meta-transactions through the provider's relays or third-party relay networks such as the Gas Station Network. While the former relies on ETH usually bought on centralized exchanges after KYC, the latter seeks to minimize on-board UX friction by moving the consumer's responsibility to relayers at an expense that is paid by the on-/off-chain wallet provider and/or the off-chain user.

Meta Transaction is a user transaction that contain message with some data signed by a person who wants to execute a transaction.

Relayer-based architectures have a few drawbacks:

1. They can be viewed as centralized intermediaries with a capacity for repression of transactions.
2. They are technically/economically inefficient due to the additional 21,000 base gas charges needed for the relayer transaction and the need for their company to make a profit on top of the gas charges.
3. The use of relayer-specific protocols powers.

Account Abstraction would allow smart contract wallets to accept gasless meta-transactions from users and pay for their gas without relying on the relay network. This base-layer capability would also dramatically boost the UX onboarding of such wallets without losing the decentralization assurances of Ethereum.

Sponsored Transactions

Transactions which involves the Company or any of its Subsidiaries.

Some of the use cases are:

1. Allowing application developers to pay fees on behalf of users.
2. Allowing users to pay fees in ERC20 tokens, with a contract serving as an intermediary to collect the ERC20s and pay in ETH.

Working

This Proposal can support this use cases through a paymaster mechanism.

• For Use Case 1: Paymaster verifies that the sponsor's signature is included in the paymasterData, indicating that the sponsor is ready to pay for the UserOperation. The paymaster accepts if the signature is valid, and the UserOperation fees are deducted from the sponsor's share.
• For Use Case 2: Paymaster checks if sender wallet has sufficient ERC20 balance to pay for the UserOperation. If it does, the paymaster accepts and pays the ETH fees before claiming the ERC20 tokens in the postOp.

Mixer

Let's consider the example of Tornado Cash as a Mixer to understand how we can use AA in DeFi Protocols.

Problems in Privacy of Traditional Tornado Cash Contract

• Privacy given by Tornado Cash arises when a user makes a withdrawal, they can prove that it came from a unique deposit, but no one other than the user knows from which deposit it came from.
• User usually does not have ETH in their withdrawal address, and if the user uses their deposit address to pay for gas, it creates an on-chain link between deposit address and withdrawal address.

This could be solved by a third-party relayer that verifies the ZK-SNARK and unspent status of the nullifier, publishes the transaction using their ETH to pay for gas and collects the fee back from the user from the Tornado Cash contract.

Solutions by Account Abstraction:
User can submit an AA transaction targeted at the TC contract, after which the ZK-SNARK verification and nullifier checking can be performed, and PAYGAS can be called immediately. This enables the withdrawer to pay for gas straight from the coins sent to their withdrawal address, eliminating the requirement for relayers or an on-chain link to their deposit address.

DeFi protocols

Let's consider the example of Uniswap, a DeFi Protocol, to understand how we can use AA in DeFi Protocols.

A new version of Uniswap can be created that permits transactions that directly target the Uniswap contract.

• Now, Users can deposit tokens into Uniswap in advance.
• Uniswap would store users' balances and a public key so that transactions spending those balances could be verified against.

The goal with AA is to increase the gas efficiency of DeFi protocols by prohibiting transactions that do not fulfil high-level criteria like the presence of a matching order from being included on the chain.

In Traditional Model: Normal traders store their coins outside the Uniswap contract.

In New Model: Arbitrage Traders would deposit their coins in Uniswap and be able to transfer transactions that perform arbitrage when conditions of external market change. As a result, transactions that do not get in as another arbitrage trader executed the trade first, so these would not be included on-chain. This allowing arbitrage traders to avoid paying gas and lowering the number of trash transactions included on-chain. This will increase blockchain scalability and market efficiency as arbitrage traders would be more able to correct cross-exchange discrepancies between prices.

Arbitrage Traders are traders who take advantage of price differences in two or more markets, so they buy at low and sell at high at the same time.

Note: These examples are sighted as use case for EIP-2938, a proposal proposing core changes to consensus Mechanism and EIP-4337.

An early developer alpha version of proposal 4337 is expected to be coming soon. An audit is also expected to be conducted to confirm the scheme’s safety. The hope with the proposal is that developers should be able to start experimenting with account abstracted wallets soon.

________________________________________________________

Disclaimer: The information contained on this web page is for education purpose only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.

To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for easy digestable content.

Support us at Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.