RIP-7560: Native Account Abstraction

[Rjected]

RIP-7560 is described as a combination of EIP-2938 and ERC-4337, meant to be backwards compatible with ERC-4337.

The spec: ethereum/RIPs#3

This overview is split up into sections outlining either:

• What would need to be implemented (if the reth node builder supports it)
• What additional extensibility would the node builder require

The proposal is complex and would require many changes, some of which are currently not possible with the reth node builder.

AA transaction type

A new EIP-2718 transaction type is introduced. This would be difficult to support with the current node builder API.

The new transaction type is encoded like this:

0x04 || 0x00 || rlp([
  chainId, sender, nonce, builderFee,
  callData, paymasterData, deployerData,
  maxPriorityFeePerGas, maxFeePerGas,
  validationGasLimit, paymasterGasLimit, callGasLimit,
  accessList, signature
])

This also adds a "transaction counter header" which adds more encoding / decoding complexity. Discussion here on whether or not this should be included in the block:
ethereum/RIPs#3 (comment)

NonceManager pre-deployed contract

Transaction nonces for AA_TYPE transactions are now not necessarily sequential, see the "Non-sequential nonce support" section.

Nonce management and validation are proposed as a pre-deployed contract. There is no bytecode yet.

Transaction validation "Frames"

AA transactions are validated and executed in a specific order, similar to ERC-4337:

1. Validation
   • nonce validation and increment frame (required, uses predeployed contract)
   • sender deployment frame (once per account)
   • sender validation frame (required)
   • paymaster validation frame (optional)
2. Execution phase
   • sender execution frame (required)
   • paymaster post-transaction frame (optional)

These steps could be implemented with the validation and execution handlers in the EVM builder.
Mempool DoS prevention rules are shared between ERC-4337 and RIP-7560, located here:
https://eips.ethereum.org/EIPS/eip-7562

EIP-7562 would need its own issue and scope

• EIP-7562: Account Abstraction Validation Scope Rules

Opcode values

This is included as a reference:

Opcode Name	Solidity Equivalent	Value
CALLER	msg.sender	The AA_ENTRY_POINT address. AA_SENDER_CREATOR for the "deployment frame".
ORIGIN	tx.origin	The transaction sender address
CALLDATA*	msg.data	The transaction data is set to inputs of the corresponding frame

Unused gas penalty charge

There is a penalty for unused gas, discussion on why this is included here:
ethereum/RIPs#3 (comment)

Alt mempool

The new transaction type is suggested to be propagated in a 4337 style alt mempool:

Such transactions MUST NOT be propagated through the default transaction mempool as they will be rejected by the nodes and the sending node will be blocked as a spammer. They may be propagated in the alternative mempool that allows them explicitly as defined in ERC-7562.

Block validation

Block validation is extended with calls to the AA predeployed contract. This logic would be possible to implement if the reth processor / executor were configurable.

RPC changes

This requires changes to:

• eth_call
• eth_getTransactionReceipt
• eth_sendTransaction
• eth_sendRawTransaction

Open questions and notes

• Is an alt mempool optional, or required?
• The spec seems incomplete, has no reference implementation, and there are many quirks with long github discussions without a clear resolution.
• It's not clear which EIPs are required. Is EIP-2938 required?

This is very complex and requires more time to understand fully - this issue is here for now, and the fact that this RIP is so complex motivates some things to add to the node builder. It's also possible that the spec could be made simpler, and some of the quirks could be removed with more thought.

[Vid201]

@Rjected

Do you know if someone has started working/thinking about this already? Or any other status update on RIP-7560 + reth?

[Rjected]

@Rjected

Do you know if someone has started working/thinking about this already? Or any other status update on RIP-7560 + reth?

hi! RIP-7560 / the RIPs that make up native AA are very complex and touch almost every part of the node, so this would require at the very least the following reth SDK features:

• types abstraction in reth (we do not support custom tx types yet)
• custom or modified mempool

These are two significant tasks, and there may be unknown unknowns. We're working towards these but can't commit to any timeline yet