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)

1 Like
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?