# native account abstraction

vitalik and others recently post an RIP (rollup improvment proposal) that specifies the implementation of enshrining account abstraction in rollups or base layer

## rip (rollup improvement proposal)

hadn't heard about this before, so did a little bit of digging and its a set standards that rollups can adhere to, to make the whole ecosystem better. its not mandatory but optional for rollups to implement.

## why native aa?

eip-4337 introduced ethereum community to account abstraction with added actors to the ecosystem namely bundlers and paymasters who bundled user operations and paid for gas respectively.

this eip required dapps to change the way they used to handle transactions and interact with blockchain because ethereum/evm wasn't built keeping smart contract wallets in mind, it was built for eoa based accounts.

enshrining account abstraction directly into the protocol will help possibly eliminate these actors or figure out a way to abstract away these actors, it will be much less pain for both users and developers. this was the endgame for eip-4337 when it was proposed.

## rip-7560

[rip-7560](https://github.com/ethereum/RIPs/pull/3/files) was proposed last week, it specifies the implementation of enshrining account abstraction in rollups or base layer.

it is backwards compatible with eip-4337, so smart contracts for wallets, factory and paymasters will be the same, even off-chain components like bundler will become compatible with rip-7560

### user operation

in eip4337, a transaction is represented as a user operation which is sent to mempool maintained by bundlers, right now its private, but working is going on for decentralizing it.

in rip-7560, a new transaction type `TransactionType4` is introduced which is enshrined into protocol, so user will send those transaction as normal transaction but it will contain some extra fields.

the only difference between a `UserOp` and `TransactionType4` is that it `TransactionType4` includes some more fields than `UserOp`

- `builderFee` - this is the reward that bundler receives for inclusion of `TransactionType4` in a partial block
- `deployerData` - similar to `initData`
- `paymasterGasLimit` - how much gas can paymaster contract use for running validation logic

and some more fields were renamed

each user operation has 2 phase similar to eip4337 - validation and execution

validation occurs on the scw and paymaster level and execution happens at scw level

in a sequence of `TransactionType4`, all of the validation operations are executed first and then immediately execution operations are executed so as to not have any non-aa transactions between them, as well as complete all of the validation before execution


### mempool

`TransactionType4` can use the existing mempool itself, but bundlers can create private mempools.

as usual, mempool needs to be DoS protected and needs some level of security gurantees to ensure that those transaction can't execute opcodes that may affect the protocol.

this is similar to what it is right now and there is nothing about it i want to change, it just works the way it is. though i am fascinated by the idea of not having a mempool ;)

### bundler

rip-7560 is backwards compatible, bundlers of eip4337 can become block builders in rip-7560 or even build partial `TransactionType4` only blocks and send them to block builder who will reward them with `builderFee`, if the block is included


### eip-9999

this is a mystery eip that will be revealed in coming weeks, it contains many of the major answers to questions and situations posed in rip-7560 and it is very crucial for it.

it might include non sequential nonce support, storage access rules in mempool and much more

### api changes

it doesn't affect much in the api design but it affects the type of data it accepts.

`eth_sendTransaction`, `eth_signTransaction`, `eth_sendRawTransaction` and some other methods will start accepting `TransactionType4`

this will help developers because they wouldn't need to change anything other than a very simple transaction type change.

## my thoughts

i don't think eip4337 was a bad decision but it sure was not the chosen one. looking at the situation of ethereum protocol, it totally made sense to implement eip4337 because enshrining aa into core protocol wasn't an option on ethereum but rollups are all about innovation and what's better than to enshrine aa directly into the protocol while being evm compatible.

rollups are better off enshrining aa to improve user and developer experience. they should make eoa and aa powered wallet indistinguisble from each other, there shouldn't be an onboarding process to aa, it should exist there, without anyone initializing it. maybe that's not possible on evm because of the restrictions but zksync and starkware already have aa directly enshrined into the protocol.

paymasters should be a first class citizen, it will help eoas too to enjoy services of paymasters and not only scws, also scws should also be treated as first class citizen, this eases a lot things for smart contract developer, starting and ending with `tx.origin` mess

i think after this rip, more rollups will focus on enshrining account abstraction into their protocol, it will be quite interesting to look at how current aa companies will look towards this and how their future will look like!