RIP-7560: Native Account Abstraction

RIPs
, ,
27

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

28

I have two questions:

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

  2. 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 :heart_hands:

29

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

30

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 .

31
  1. Nonce:

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

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)

2 Likes
32

Thank you very much for clarifying!

33

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

1 Like
35

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

1 Like
36

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

37

looking forward to the geth implementation

38

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:

  1. RPC nodes can accept and validate transactions before relaying them to the sequencer.
  2. The sequencer can implement a reputation based system with RPC nodes to mitigate DoS.
  3. 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?

2 Likes
39

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

40

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!

41

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:

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:

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.

1 Like
42

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?

43

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 :grinning:

1 Like