RIP-7560: Native Account Abstraction

[dror]

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