<meta property="og:image" content="https://drive.google.com/file/d/1Pn2GJoAujxm4J9UF6-bh3yB1MPtMdnFg/view?usp=sharing" />

# Current State of Ethereum's UX

One of the biggest challenges in the blockchain industry is user experience. Ideally, users should seamlessly interact with apps and achieve their goals with the minimal action steps. Unfortunately, that is not an easy task, especially if we want to keep core benefits of blockchain, such as self custody of assets.

> 💡 **Note**
> Ethereum currently supports two account types:
> - **Externally Owned Account** - able to execute transactions, but doesn't have code.
> - **Smart Contract Account** - not able to execute transaction, but has code.

In the following sections we will explore different ways to interact with Ethereum blockchain, and how they impact user experience.

## Externally Owned Accounts (EOAs)

Externally Owned Accounts (EOAs) are able to execute blockchain transactions by signing them with the private key. Ethereum core protocol checks transaction signature before including it into the blockchain. On the other hand, EOAs can’t be programmable, meaning we can’t execute batch transactions or have social recovery features.

In the picture below, a user tries to execute a batch of transactions. Unfortunately EOAs are not able to execute batching logic, hence transactions will be executed one by one. This results in a bad user experience, since users need to sign every single transaction.


## Smart Accounts

Another approach would be to use a smart account. Smart account is a smart contract that can define arbitrary transaction execution and authorization logic. This allows users to execute multiple transactions in a single batch by signing them all at once. Current limitation of smart accounts is that they cannot initiate transactions by themselves. The reason for this is a signature check on the protocol level, meaning only accounts controlled by private keys can execute transactions.

Hence, smart accounts rely on other entities with private keys to execute transactions on their behalf. We call these entities relayers.


The transaction execution flow is as follows:

1. EOA deposits funds to smart account (this is a one time action, but still adds additional complexity for users)
2. EOA signs batch transaction
3. transaction is sent to the relayer
4. relayer signs transaction and sends it onchain (pays for the gas)
5. smart account reimburses the relayer

This architecture improves UX and works pretty well, except that the relayer is the centralised point of trust. Relayer can censor transactions if it chooses to. To tackle transaction censoring problem, [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) was introduced.

### ERC-4337

In order to combat censorship, ERC-4337 architecture consists of decentralized network of bundlers (relayers) that operate on the abstract mempool, which contains UserOperations. Bundlers then validate and bundle UserOperations into a single Ethereum transaction that will be executed.

We could think about this as another network layer on top of Ethereum which abstracts away authentication, replay protection and payment.

**Why do we need this?**

The end goal is to have native [account abstraction](https://ethereum.org/en/roadmap/account-abstraction/) (enshrined in the protocol), but Ethereum decided to go step by step and iteratively achieve that goal. ERC-4337 is just a one step towards that goal which allows Ethereum to benefit from account abstraction without immediate protocol changes, while keeping decentralization and censorship resistance.

## Account Delegation (EIP-7702)

Pectra upgrade comes with [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), which implements a change on the protocol level. It introduces new transaction type which allows EOAs to delegate execution to a smart contract.

By utilising EIP-7702 we avoid an extra step of depositing funds into the smart account. An EOA authorises smart account to execute a batch of transactions on its behalf. This results in even better UX, as we have one action step less.


## Conclusion
In this article, we covered different approaches to transacting on the blockchain and their impact on user experience. By combining account delegation (EIP-7702) with ERC-4337’s account abstraction, developers can unlock a new wave of blockchain applications, enabling seamless interactions without compromising security or decentralization.

## References

- How ERC-4337 combats censorship: https://notes.ethereum.org/@yoav/unified-erc-4337-mempool
- EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
- ERC-4337: https://eips.ethereum.org/EIPS/eip-4337