An account abstraction proposal that introduces consensus-layer protocol changes, instead of relying on higher-layer infrastructure.
Combining the EIP-2938 and ERC-4337 into a comprehensive Native Account Abstraction proposal.
We propose splitting the Ethereum transaction scope into multiple steps: validations, execution,
and post-transaction logic.
Transaction validity is determined by the result of the validation steps of a transaction.
Wow! Thatâs awesome!
and what does âEIP-9999â refer to in the markdown file?
This is really nice, stays compatible with 4337, optimizes Gas, and solves the problem of Bundler being private now, which is very significant for account abstraction adoption!
Why is unused gas a concern specifically for AA transactions and not regular EOA transactions?
Because of the separate validation and execution stages for AA transactions, itâs harder for the block builders to account for an unused gas discrepancy.
Itâs described here https://github.com/ethereum/RIPs/blob/e3bead34f1bcf1aa37fd51923ad99a77b801775c/RIPS/rip-7560.md#unused-gas-penalty-charge
Generally this RIP is amazing but the elephant in the room is the upcoming/placeholder EIP-9999, would be really fantastic to see what it refers to.
Otherwise great job!
My main comment would be about the version parameter in the validation function. I think it makes way more sense for upgrading to simply change the signature of the function either by changing the parameters or append a _v* to the function name. The rationale for this is that it allows wallet implementation with fallback handlers and modules to update in an easier way.
At the risk of sounding like an optimizooor, itâs unfair to expect wallet implementations to implement full delegatecall upgradability cause it adds one mandatory SLOAD to each transaction.
IMO, this adds lots of complexity to the core protocol for something that can be done outside of it.
Thereâs the issue of multiple competing AA standards, with none having widespread use. If AA ends up being enshrined, it should look like what the leading AA standard looks like. Changing how AA works after a hard fork enabling it would be a massive PITA for everyone and would only slow progress.
IMO, the amount of complexity that this adds to the core protocol makes it not worth it. AA is continuing to evolve (for example intent based AA like UniswapX, ERC-7521, etc) and this would lock things into only the current solution.
Also, does this remove support for signature aggregation? I thought that was one of the biggest selling points of ERC-4337 since it gives huge cost savings to optimistic rollups.
I also donât see how the âunused gasâ griefing vector described canât also be done with an EOA transaction. Is there a better description of the attack somewhere that explains how itâs unique to user ops?
whatâs the estimated timeline for EIP-9999? it contains some important things regarding this RIP, but overall a good proposal, is backwards compatible, enshrines most of the stuff
@cejay @Ivshti @sk1122
The EIP-9999 was just a temporary placeholder for the âERC-7562: Account Abstraction Validation Scope Rulesâ document before it had an assigned number. I apologise for any confusion.
@pantaovay thank you very much!
@Ivshti
Re: âchanging the signature of the function instead of a version parameterâ, we had an intention to make sure that we are only creating a single set of âspecialâ method IDs. However, if the method signature were to change with every revision of this RIP, their method IDs would change as well.
@makemake @PixelCircuits
This complexity is one of the reasons this proposal has been labeled as a âRollup Improvement Proposalâ, so hopefully it would not lead to locking things into a single solution too much.
Re: Signature Aggregation, it will not be removed from Native Account Abstraction but it is not part of this RIP, which is complex enough. âNative Account Abstraction Signature Aggregationâ will probably be a separate RIP document in the near future.
I also donât see how the âunused gasâ griefing vector described canât also be done with an EOA transaction. Is there a better description of the attack somewhere that explains how itâs unique to user ops?
The issue of unused gas is only relevant for Type 4 Transactions because they can have their execution behaviour influenced by transactions that are coming after them in a block. This does not seem to be a problem unless the transaction suddenly starts using more gas than it used before.
Here is an example of how this could be turned into an attack on the block builder.
Here, Transaction #4 has a gas limit of 10â000â000. However, it only used 50â000 gas so there is a lot of available gas space in a block.
However, once Transaction #6 is included in a block and its validation phase flips some flag, Transaction #4 starts consuming the entire 10â000â000 gas.
So does the unused gas penalty go away after ERC-7562 ?
Unfortunately, there seems to be no way to prevent the âflickeringâ gas usage by transactions with validation rules alone.
The âwaste gas flagâ storage can be read during execution phase of any transaction, and the âvalidation rulesâ are not meant to be applied during the execution phase.
TL;DR: thatâs the cost of account abstraction.
The complexity doesnât come from the protocol itself (eip-7562 or ERC-4337) - It comes from the fact we want to use general-purpose EVM code for validation, which makes one transaction depend on external data - shared with other transactions, or with the external world.
With EOA, the validation is hard-coded into the protocol and depends only on the state of the account itself.
This means that a previously validated transaction can only be invalidated by issuing another transaction with the same sender (and nonce) to replace it.
With account abstraction (ANY implementation - 7560, 4337, 2938, and even 3078) we must have a mechanism to ensure the same isolation, otherwise, maliciously crafted transactions can cause mass invalidation: transactions that are accepted and propagated into the mempool, which later becomes invalid and thus draw resources from all nodes without a cost.
Removing this complexity exposes block-builders to DoS attacks, or requires removing the general EVM-code usage (the essence of account abstraction)
Iâm not against complexity, just complexity at the core protocol level. At least ERC-4337 is opt-in and I can ignore it if I think there is too much risk or chose an alternate smart contract based AA solution. With this proposal, if something goes wrong for builders (some new DoS vector is found and exploited) or some bug is found, it would take down the whole network, including users who never cared about ERC-4337 style AA.
To me, it feels like trying to embed an OS into the bare metal. The bug surface area is too large and it would alienate others who want to use a different OS.
Pasting the reply I sent you in 4337 Mafia on telegram in case others also wonder:
It protects the builder against a DoS vector, also applicable to 4337 bundlers (which is why the next EntryPoint version will have this as well).
Consider a builder trying to construct a block containing many AA transactions. It creates a batch of AA transactions (equivalent to a 4337 bundle) where all the validations will be executed, followed by all the executions. To work efficiently and not have to validate transactions sequentially, it wants to create the largest possible batch, validating all the transactions in parallel against the same state. Otherwise it canât parallelize because transactions can invalidate each other, which makes it vulnerable to DoS by many mutually-exclusive transactions where one transactionâs execution invalidates anotherâs validation.
An attacker could send transactions that have a high callGasLimit which they actually use when simulated separately, but that changes its behavior to use almost no gas when it detects that another transactionâs validation has been executed. Suppose the batch has [tx1,tx2]. tx2.validation sets tx2.sender.flag=1, and tx1.execution does return (tx2.sender.flag==1 || waste5Mgas()). It is allowed to access tx2.sender.flag because it happens during execution rather than validation. The builder created the batch, thinking tx1 will use 5M gas and fill up the rest of the block, but due to the above behavior, 5M gas worth of of blockspace is not utilized. The builder now has to append more transactions sequentially (not parallelized), simulating each of them against the state after all the others in order to know how much gas it really uses.
By penalizing unreasonably high unused gas, we make this attack less scalable.
Itâs ERC-7562. We extracted the ERC-4337 validation rules to a separate (and hopefully more readable) ERC since theyâre identical in both systems.
Thanks!
I see Alex already replied this, but Iâll add that it was requested by one of the L2s. They wanted to be able to add future extensions (maybe even specific to their own network) without having to redeploy or update accounts.
I think making accounts upgradable offers security and usability benefits, well worth the SLOAD. But weâre also looking for ways to make it cheaper. For example, EIP-7557 could make it as cheap as 32 gas for a widely used account while also making the protocol fairer. Support EIP-7557 
To put this in context, the RIP is meant for rollups that already added, or are considering adding the complexity of native AA. Some already have, and some are planning to. The purpose of this RIP is to standardize it for those who do, and avoiding fragmentation of the wallet ecosystem (wallets supporting only one chain, which is currently the case in chains that added their own form of native AA).
and thatâs precisely what this RIP does. ERC-4337 has been gaining some traction, and has been used to add native AA in nonstandard ways by two L2 chains. RIP-7560 is an enshrined version of ERC-4337, optimized for rollups.
It shouldnât. Thatâs why we separated RIP-7560 and ERC-7562. The mempool validation rules are incompatible with some forms of intents, but RIP-7560 isnât. Intent systems could benefit from RIP-7560 while being incompatible with the ERC-7562 mempool and using a separate intent-solvers network. Itâs one of the design goals.
No. But aggregation will be a separate RIP, to be published soon.
Itâs meant for chains that choose to embed this into their âOSâ. For example, Starknet and zkSync already embedded a similar native AA system (both are based on ERC-4337 with some mods). Youâre right that there is no way for you to opt out of it on these chains, whereas on a chain that doesnât implement native AA, you can choose whether to use ERC-4337 or not. L2 chains sometimes choose to be more opinionated about their OS for the sake of optimizing their UX and efficiency. However, the Ethereum ecosystem offers enough choice of L2s so you can opt out by using a different one. Some may choose to implement it early, some may be more conservative and wait.
Will this lead to a precompiled contract for secp256r1 curve support, so we can finally implement wallets that integrate with the built-in private key encryption used in operating systems and secure enclaves?
