Title: RIP_7560__Native_Account_Abstraction
Category: RIPs

Author: alex-forshtat-tbk
Date: 2023-11-16T14:49:00.879Z

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.


github.com/ethereum/RIPs








Add RIP: Native Account Abstraction


master ← eth-infinitism:native_account_abstraction



          opened 02:40PM - 16 Nov 23 UTC




            forshtat
          



+878
-0






EIP draft to support a native account abstraction transaction type. This is one …of three EIPs: AA transaction, aggregation, validation rules. See https://hackmd.io/@alexforshtat/native-account-abstraction-roadmap
and https://vitalik.eth.limo/general/2023/09/30/enshrinement.html

Author: cejay
Date: 2023-11-16T16:58:54.719Z

Wow! That’s awesome!
and what does ‘EIP-9999’ refer to in the markdown file?

Author: pantaovay
Date: 2023-11-16T17:42:46.769Z

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!

Author: ankurdubey521
Date: 2023-11-17T00:12:12.847Z

Why is unused gas a concern specifically for AA transactions and not regular EOA transactions?

Author: Ivshti
Date: 2023-11-17T07:27:39.525Z

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

Author: Ivshti
Date: 2023-11-17T07:31:55.127Z

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.

Author: makemake
Date: 2023-11-17T15:20:04.185Z

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.

Author: PixelCircuits
Date: 2023-11-17T18:38:35.914Z

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.

Author: PixelCircuits
Date: 2023-11-17T18:59:16.873Z

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?

Author: sk1122
Date: 2023-11-20T08:14:58.845Z

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

Author: alex-forshtat-tbk
Date: 2023-11-20T11:46:40.102Z

@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.

Author: alex-forshtat-tbk
Date: 2023-11-20T11:54:14.050Z

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.
Unused Gas Attack Block overview (1)1460×1580 112 KB

Author: PixelCircuits
Date: 2023-11-20T17:05:23.255Z

So does the unused gas penalty go away after ERC-7562?

Author: alex-forshtat-tbk
Date: 2023-11-21T22:50:00.517Z

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.

Author: dror
Date: 2023-11-22T18:57:52.035Z

PixelCircuits:

IMO, the amount of complexity that this adds to the core protocol makes it not worth it


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)

Author: PixelCircuits
Date: 2023-11-22T19:25:16.515Z

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.

Author: yoavw
Date: 2023-11-28T19:52:47.317Z

ankurdubey521:

Why is unused gas a concern specifically for AA transactions and not regular EOA transactions?


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.

Author: yoavw
Date: 2023-11-28T20:04:52.112Z

Ivshti:

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.


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.



 Ivshti:

Otherwise great job!


Thanks!



 Ivshti:

My main comment would be about the version parameter in the validation function


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.



 Ivshti:

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.


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

Author: yoavw
Date: 2023-11-28T20:28:44.211Z

makemake:

IMO, this adds lots of complexity to the core protocol for something that can be done outside of it.


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).



 makemake:

If AA ends up being enshrined, it should look like what the leading AA standard looks like.


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.



 PixelCircuits:

and this would lock things into only the current solution.


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.



 PixelCircuits:

does this remove support for signature aggregation?


No.  But aggregation will be a separate RIP, to be published soon.



 PixelCircuits:

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.


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.

Author: EGreg
Date: 2023-12-24T02:37:01.901Z

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?


github.com/ethereum/RIPs








Add RIP: secp256r1 precompile (copies eip-7212) in last call


master ← ulerdogan:ulerdogan/move-eip-7212



          opened 07:39PM - 12 Dec 23 UTC




            ulerdogan
          



+260
-0






# WHAT

This PR adds a copy of [EIP-7212](https://eips.ethereum.org/EIPS/eip-7…212) as an RIP, which presents the precompiled contract of `secp256r1` EC verifier.

# WHY

This proposal will be discussed at [RollCall#1](https://github.com/ethereum/pm/issues/907) by the L2 teams as a Last Call. The PR prepares preliminary content for the L2-specific discussion. The proposal itself or the format are subject to change based on feedback or the newly decided RIP structure.

# HOW

It's just a copy of content for now. Necessary changes will be implemented subsequently.










EIP-7212: Precompiled for secp256r1 Curve Support RIPs


EIP Update:
As discussed in the RollCall#0 and RollCall#1, the final decision is that it would be more beneficial and quick to continue the proposal as a RIP. Thus, willing rollups will be allowed to complete their implementation around the standardization created with RIP. 
In this regard, a copy of the EIP with RIP naming has been merged into the RIP repo in the Last Call. 
https://github.com/ethereum/RIPs/pull/5 
The RIP specification will be finalized by determining the address …

Author: yoavw
Date: 2023-12-24T02:50:43.768Z

You’re talking about RIP-7212 (for which the answer is yes). But this thread is about RIP-7560.

Author: cejay
Date: 2024-01-02T16:48:30.357Z

I have two questions:



In the section “Accepting EOA account as sender to achieve native gas abstraction,” it might not be explained clearly. When an EOA account acts as the sender (e.g., an EOA address is 0xabc), after the execution, will the ‘old nonce (the current Ethereum built-in nonce)’ of 0xabc increase, or will only the nonce managed in the ‘NonceManager’ increase?
I think the EOA account will only increase the nonce managed in the ‘NonceManager.’ I’d like to confirm this with you.


Regarding RPC methods (eth namespace)
Because AA can no longer check if a transaction is valid like EOAs can (e.g., due to low balance with the paymaster causing temporary or permanent invalidation), a user might need to call the eth_sendTransaction interface multiple times before eth_getTransactionReceipt returns a result to confirm if their previous transaction is in a valid state (before it’s included in a block). However, sending the same transaction to the RPC multiple times might result in errors (e.g., the RPC service provider expecting users to increase the gas by 20% for each eth_sendTransaction call with the same nonce to consider it a valid request).
So, the current RIP doesn’t explicitly explain how users can know the status of a transaction they sent before it’s included in the blockchain. I’m not sure if this is a real issue, but in my opinion, because the validity of AA transactions can be affected by external factors, users need to know if their uninclude transactions are valid, even if it’s not very likely.



thanks

Author: mcoso
Date: 2024-01-04T17:10:57.852Z

Is there an updated timeline for this or progress made towards it?

Author: rvd
Date: 2024-01-20T01:43:32.012Z

Is there any code implementations or references to this RIP-7560 ?
I wanna use this in my dApp for learning purpose.
If yes, please kindly drop the link for it.
Thanks .

Author: dror
Date: 2024-01-23T18:49:26.887Z

Nonce:




 cejay:

When an EOA account acts as the sender (e.g., an EOA address is 0xabc), after the execution, will the ‘old nonce (the current Ethereum built-in nonce)’ of 0xabc increase, or will only the nonce managed in the ‘NonceManager’ increase?


The entire EIP uses a NonceManager, and not the old internal nonce. The internal nonce is left for CREATE operation only.



 cejay:

a user might need to call the eth_sendTransaction interface multiple times


A well-written account should not require the user to submit the same UserOperation multiple times. I think that will happen for badly written (or outright broken) accounts.
The user may re-submit the same userop with a higher gas fee if needed.
Regarding paymasters: In order to be accepted into the mempool (that is, for sendTransaction to return a valid response), a paymaster must hold a balance enough for all pending UserOperations.
In order to be able to notify the calling users that UserOperation gets dropped because of paymaster limitation, RPC nodes should accept UserOps for paymasters that have an extra deposit (e.g. 10% more), so that these UserOperations will not get dropped when passed to other nodes through the mempool.
(This doesn’t fully prevent such silent drop of UserOperations, but the same is true of the Ethereum mempool: you have no guarantee a submitted transaction will not get dropped)

Author: cejay
Date: 2024-01-24T09:00:26.831Z

Thank you very much for clarifying!

Author: yoavw
Date: 2024-01-25T01:19:42.798Z

@mcoso @rvd we’re working on a geth implementation. As soon as it’s ready for testing we will publish it, and then launch a devnet to experiment with.
And of course, if anyone wants to implement it in another client, that would be awesome and we’ll be able to test the two implementations together when ready.

Author: amanraj1608
Date: 2024-02-20T11:12:52.181Z

yoavw:

we’re working on a geth implementation


Is the geth implementation development is currently available on a public github repository Interested in seeing changes required for the project if that’s possible

Author: ankurdubey521
Date: 2024-02-22T08:13:59.130Z

@yoavw when you mean geth, are you referring to the L1 execution client, or the execution node of a roll-up such as op-geth?
Since it’s a RIP I would assume it should be implemented in the context of a roll-up.

Author: ryanli
Date: 2024-02-26T22:33:51.457Z

looking forward to the geth implementation

Author: noam
Date: 2024-03-15T23:25:05.679Z

I’ve been thinking a little bit more about the mempool design for this RIP. At a high level, it seems not necessary and potentially worsens the developer and user experience.
As an alternative model we could consider integrating the bundler into the L2 block builder (e.g. the sequencer). The flow becomes similar to how rollups work today:

RPC nodes can accept and validate transactions before relaying them to the sequencer.
The sequencer can implement a reputation based system with RPC nodes to mitigate DoS.
The sequencer builds blocks from transactions type 1-4 inclusive, providing guarantees to both users and developers that are not available if instead the bundlers run in the RPC nodes.

This implies there really is only one bundler on L2 (the sequencer) and that bundles can be included in the block alongside type 1-3 transactions. This seems to have no worse trust assumptions than layer 2’s today in that the sequencer is still a central point of failure. If this were to extend to decentralized sequencing it would require an implementation of leader election at the L2 level (which would also mitigate the mempool problem today but add a ton of complexity to the system which is largely unnecessary).
What do we think the tradeoffs of such a system would be?

Author: codebyMoh
Date: 2024-07-02T11:28:25.167Z

How would this design interact with existing L2 infrastructure? Would it require significant changes to how rollups operate today?

Author: colinlyguo
Date: 2024-12-19T13:23:24.137Z

Hello, magicians, a few details remain unclear for me after reading through this RIP:
1. Purpose of AA_ECRECOVER_COST:
The constant AA_ECRECOVER_COST = 6000 is defined but not directly used in the RIP. Will it be relevant in the future design of this RIP? Also, can signature verification and gas cost be fully delegated to contract wallets (e.g., using precompiled contracts or the WIP RIP-7696)?
2. Transaction Flow Diagram:
In the RIP, there is a diagram showing tx 4, tx 5, and tx 6 validation frames placed together one by one, followed by their execution frames, also placed together one by one. However, when reading RIP description, I imagine sequential processing (validation + execution per transaction). Are there inconsistencies between the diagram and the RIP description?
3. On-chain Availability of accessList and authorizationList:
The RIP mentioned that “the chainId, accessList and authorizationList parameters are included in the transaction hash calculation but are not available on-chain as part of the TransactionTypeRIP7560 struct”. However, for a follower node to replay a block, it needs to know the accessList and authorizationList to verify the gas usage and state transitions. How can this be achieved?
4. Exclusion of authorizationData from the Signed Payload:
The RIP also mentioned that “In order to calculate the transaction hash that will be used during the signing of the transaction and validation of the transaction signature by the sender, the value of the authorizationData parameter is considered to be an empty byte array”. What is the design rationale for excluding authorizationData from the signed payload? Could the signer simply include authorizationData in the signed payload to improve security?
Thank you for your time and insights, looking forward to your response!

Author: alex-forshtat-tbk
Date: 2025-01-08T14:27:00.034Z

Hello @colinlyguo, thanks for the questions and sorry for a late reply!
Regarding questions 1 and 2, you are absolutely correct. Thanks for pointing out these issues.
The AA_ECRECOVER_COST is not currently and will not be used by the RIP-7560. I removed it from the document.
As for the order of frames’ execution, the RIP-7560 defines a sequential processing while RIP-7711 introduces the separation between validations and executions, so the diagram was not correct for the RIP-7560. I patched the diagram to avoid confusion.
(Note that due to a delay in merging the changes to the RIP repo the up-to-date version of RIP-7711 is stuck in this PR:

github.com/ethereum/RIPs








Update RIP-7711: Remove the no-op header transaction type


ethereum:master ← eth-infinitism:rip-7711-simplified



          opened 02:49PM - 10 Dec 24 UTC




            forshtat
          



+32
-56











I am sorry about this confusion but there is little we can do to speed up the PR reviews there.)
This is the PR to fix the issues you have highlighted:

github.com/ethereum/RIPs








Remove 'AA_ECRECOVER_COST' and update the zoom-in diagram


ethereum:master ← eth-infinitism:update_rip_7560



          opened 01:58PM - 08 Jan 25 UTC




            forshtat
          



+0
-1










Regarding question 3, “On-chain Availability of accessList and authorizationList”, the data in the accessList and authorizationList transaction fields is still part of the transaction object and therefore part of the propagated block.
What we mean by “not available on-chain” is that these fields are not directly observable within the EVM by smart contracts, though, limiting their ability to alter their behaviour based on these fields. This should not present any challanges for the nodes who want to replay the block. Or am I missing something?
Regarding question 4, the RIP-7560 transaction does not have an R,S,V signature at all. Instead, authorizationData contains a signature and potentially other data whatever signing logic is used by the “Sender” smart contract wallet. Therefore, it is impossible to know the authorizationData before siging is performed, so the authorizationData field must be excluded fromthe signed payload.
I hope that I could answer your questions.

Author: colinlyguo
Date: 2025-01-08T19:08:44.279Z

alex-forshtat-tbk:

authorizationData


quite thanks! your reply makes a lot of sense and clears most of my doubts.
While I still have a bit of confusion in the authorizationData field. It seems that EIP-7702 only has an authorization_list. so authorizationData looks like a new field in this RIP. The spec says that authorizationData is “Data that will be used by the Account to verify transaction”, so is the signature field moved to authorizationData to make the structure clear?

Author: alex-forshtat-tbk
Date: 2025-01-08T23:14:42.155Z

colinlyguo:

Is the signature field moved to authorizationData to make the structure clear?


Exactly. The term signature we used earlier was not very precise as the field may contain many things and not just a single signature.
But you are right, now authorizationData can be confused with something related to EIP-7702 authorizations and we probably should find a better name again. Open to suggestions