# Chapter 2: Account abstraction
<br>

In the last chapter we talked about Externally owned accounts and Contract accounts. Traditionally till now what ethereum has been is, users having an EOA account in which they store all their assets and use them to interact with smart contracts deployed by various protocols for specific use cases. Many wallets have been built allowing to control these EOA's and send transactions using the private keys.

<br>

### Limitations of EOA's

* #### Private Keys

EOA's are controlled by private keys. Managing private keys is dufficult. Having the private key gives complete ownership to an account. So if a private key is leaked or lost it can lead to complete loss of funds. This gives a really bad user experience for new users.

Personal Experience
In a hackathon, I once mistakenly pushed my private key in a github repository and made it public. Because of this i lost around $1000 that were in my account and around $5000 which I received in airdrops in the future.

* #### Gas and Ether

To send a transaction a user must hold ether in their EOA. This is also a really bad user experience for new users.

Personal Experience
My friend won $500 worth of USDC in a hackathon. He was preety new to web3 so didn't have had any ether before in his wallet on the mainnet. Due to this he was not able to withdraw those USDC from his account. I had to send him additional $10 worth of ethereum.

* #### No Customization

With EOA's, you can't customize your accounts. The features of EOA are limited to sending transactions. You cant have any additional featues like spending limits, multiple owners, Webauthn, etc. This also give a bad UX.

<br>

All these features and limitations are hardcoded in the Ethereum Protocol and can only be changed with protocol upgrade. Because of all these it is very dufficult to onboard new people to web3.

<br>

## Smart Contract Wallets (SCW)

<br>

We know that smart contract is just a code on the blockchain. So we can write a smart contract that acts as our ethereum account. This gives us infinite customization. The smart contract stores all our assets. We can code any feature we want. We can have multiple owners for that account each with different powers. We can have spending limits. We can have webauthn for verifcation.

Traditionally too, smart contract wallets like **Safe** existed which provided feautes like multi-sig and were used widely. But still the private keys and gas problem remained which were a hurdle to mass adoption.

<br>

## Account Abstraction

<br>

Abstraction is a term in computer science that roughly means hiding information about a system or application so it can be used with less knowledge of the processes running in the background.

Current accounts (EOA) are fairly complicated to use. Account abstraction is a proposal to increase flexibility in the management and behavior of Ethereum accounts.
<br>
<br>
So, how does “abstraction” fit into all of this?

From a network-level perspective, “account abstraction” means the details of account types are invisible to the Ethereum protocol. Every account (including self-custodial accounts) is simply a smart contract, and users are free to determine how individual accounts are managed and operated.

From a user-level perspective, “account abstraction” means certain technical details about interacting with Ethereum accounts are concealed behind higher-level interfaces. This improves wallet designs and significantly reduces the complexity of using web3 applications.
<br>
## How to achieve
<br>

There are two generally accepted ways of achieving account abstraction: (a) letting EOAs execute EVM code and (b) allowing smart contracts to initiate transactions. Hence, you’ll find that many account abstraction proposals either want EOAs to behave as smart contracts or contract accounts to act as EOAs.

<br>

#### Approach #1 (Upgrading EOAs to execute code)

By giving EOAs the ability to execute code, we can add complex functionality to user-controlled accounts. This supercharges EOAs and transforms them into smart accounts, setting the stage for native account abstraction. Importantly, this approach allows you to enjoy the benefits of a programmable wallet without incurring the cost of deploying a new contract account.

<br>

#### Approach #2 (Upgrading smart contracts)

With this approach, we upgrade contract accounts so they can approve transactions and pay gas fees (just like EOAs). This provides another route to achieving account abstraction by introducing “supercharged contracts” that can act as EOAs (ie. account contracts). Plus, it solves a pressing problem in Ethereum: lack of support for contract wallets at the protocol level.

Smart contract wallets already exist today. But using these wallets can be incredibly difficult because Ethereum treats smart contracts as “second-class citizens” and requires all transactions to start from an EOA.

In the next chapter we discuss both approaches and see how ERC-4337 becomes the logical choice.

<br>
<hr>
<br>

A lot of this post is inspired by the article [Account Abstraction: Past, Present, Future](https://metamask.io/news/latest/account-abstraction-past-present-future/) by Metamask.

<br>

Further reading resources

[Ethereum docs](https://ethereum.org/en/roadmap/account-abstraction/)
[Argent wallet](https://www.argent.xyz/blog/wtf-is-account-abstraction/)
[Alchemy](https://www.alchemy.com/learn/account-abstraction)

<br>
#### Sugar Kid
[Twitter](https://twitter.com/sugarbaybe)

<br>

<div style="display: flex; justify-content: space-between;">

[Chapter 1: Introduction](https://hackmd.io/GZGSAA3eTvGeOYxEjEKRfg?view)

[Chapter 3: Account abstraction and ERC-4337](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)

</div>