Understanding EIP 4337: Account Abstraction for Beginners

In the world of blockchain technology, Ethereum has emerged as a trailblazer, and Ethereum Improvement Proposal 4337, known as EIP 4337 Account Abstraction, is a groundbreaking development that's shaping its future. This proposal introduces a concept known as "account abstraction," which has the potential to redefine how Ethereum accounts work, opening up new horizons for developers and users alike. In this beginner-friendly guide, we will explore the foundations of blockchain, the role of smart contracts, and Ethereum's significance before delving into the intricacies of EIP 4337, making it accessible and understandable for enthusiasts, developers, and entrepreneurs looking to grasp its transformative implications. So, let's dive into this exciting journey of discovery and innovation in the Ethereum ecosystem.

Blockchain transactions can only be initiated from an Externally Owned Account (EOA) because an EOA account has a private key to sign a transaction and ETH to pay for gas. Contract accounts can only respond to a transaction initiated by an EOA. This is a problem, for users who want to carry out transactions from a contract account without having to own an EOA too.

Account abstraction creates a way for contract accounts to initiate and authorize blockchain transactions without an EOA.

This article attempts to explain the EIP 4337 Account Abstraction process in its simplest form, however, it?does?not cover explanations on paymasters and aggregate signatures.

EIP 4337 -Account Abstraction

In?EIP 4337?Account Abstraction proposal, the major players are:

1. sender
2. UserOperation
3. Bundler
4. EntryPoint

1.Sender

The contract account that sends the transaction

2.UserOperation:

The contract will contain a data called UserOperation. which contains data that determines if the contract will be executed. UserOperation is what the contract sends out.

You can think of a UserOperation as a ticket to watch your favorite music concert or football match. Which has information like the event's date, ticket no, type(regular, VIP) e.t.c

Let’s define what a UserOperation would look like.

Struct UserOperation{

Address sender
uint256 nonce
bytes initCode 
bytes callData
uint256 callGasLimit
uint256 maxFeePerGas
uint256 maxPriorityFeePerGas
bytes signature

}        

who or where will the UserOperation be sent?

3.?Bundler

Referred to as a “specialized class of actors”?by?EIP 4331. Responsible for grouping UserOperation waiting in a?mempool,?together in bundles before adding to a block.

A bundler could be the bouncer at the event door that checks our ticket for the necessary information before we can be allowed in.

Before bundling, the bundler calls a simulation function that checks that the UserOperation:

• contains a valid signature
• ha and can actually pay gas fees.
• do not have access to?forbidden opcodes?and storage

function simulation(UserOperation calldata userOps)

if a UserOperation does not meet the above checks, it is dropped and not added to the Mempool.

The reason for this is to ensure invalid UserOperation are not sent to the blockchain, where it will get rejected, and the bundler will bear the burden of paying for gas. This is to prevent Denial of Service (DOS) attack

A bundler cannot allow more than one UserOperation from one user in a bundle. Valid UserOperations from the mempool are sent to an Entry Point via a handleOps function

function handleOps(UserOperation[] calldata ops, address payable beneficiary

4.?EntryPoint

this is where the contract is executed and added to a block.

Entrypoint could be the guy with a computer cross-checking our tickets with the organizer's database to confirm the ticket is not fake.

The EntryPoint performs two(2) calls.

a) Verification loop

b) Execution loop.

a)Verification loop

the EntryPoint will do the following on each UserOperation:

• create the contract account.
• Normally, contract accounts are created only when a transaction has been initiated from an EOA. With account abstraction, the Entrypoint will create the contract account if it doesn’t already exist on the blockchain using?initcode?in our?UserOperation?struct.
• The bundler verifies that the?signature?is valid.
• EOA authorizes transactions with a private key. With a contract account, users can authorize transactions through any preferred logic.
• verifies that the UserOperation has enough fee to cover the cost of the verification and execution gas.

b)Execution loop

At this point, it has been established that the UserOperation is valid after passing all verification steps and won’t be rejected on the Blockchain.

Each valid UserOperation is executed on the chain and added to a block.

Conclusion

The goal of Account abstraction is to enable users to send transactions from a contract account without needing an EOA too. Also, it allows other transaction authorization methods other than only EOA digital signature.

For references and further reading:

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4337.md#simulation