Bringing RIP-7560 into OP Stack

[sm-stack]

This discussion is a space to deliberate on our reasons for implementing RIP-7560 in the OP Stack and the approach we are taking to achieve this.

Since the Entrypoint Deployment of ERC-4337 in March of last year, it has been increasingly impacting users. Recently, particularly through AA-applied Dapps like Alfafrens on Base, around 580,000 UserOps were generated in the last week. Users have been enjoying the benefits of gas abstraction, custom authentication, batch transactions, and session keys, experiencing blockchain usage similar to Web2.

However, ERC-4337 has the following limitations:

1. ERC-4337's UserOp has a higher gas overhead compared to regular transactions due to multiple operations within the Entrypoint, such as authentication, validation of paymaster, and etc. Typically, this overhead is more than twice as high.

2. Currently, all Bundlers of ERC-4337 operate in a centralized manner without a public mempool. We need to at least make this structure public, reducing the risks of censorship or MEV.

RIP-7560, a proposal for native account abstraction for rollups, are suggested to address these problems. It enshrines ERC-4337 into the protocol, removing the Entrypoint contract and reducing dependency on specific Bundlers, thereby enabling a more decentralized and scalable network.

The greatest advantage of RIP-7560 is its architecture, which is similar to ERC-4337, allowing us to leverage existing infrastructure with cheaper gas fee. Given that most users of ERC-4337 are currently on rollups, applying RIP-7560 to the OP Stack could significantly enhance user experience across the board.

Moreover, multiple Superchains such as Base, CyberConnect, and Redstone, as well as Ethereum, aim to eventually make all accounts contract accounts. RIP-7560 on OP Stack can serve as a foundation for this goal, enhancing user experience throughout the entire Ethereum ecosystem.

Lightscale is building the Kroma Network based on the OP Stack, and aims to contribute Native AA to the OP Stack, thereby providing a better UX for users across the entire OP Stack, including Kroma.

We propose implementing Native Account Abstraction, specifically RIP-7560, in the OP Stack. We are currently working on RIP-7560 PoC in this repository, based on the eth-infinitism's geth implementation.

Detailed specifications will follow in the comments. Please make comments if you have any questions or discussion points regarding the implementation.

Reference

RIP-7560 Official Docs

Ethereum Magicians Thread on RIP-7560

What is Native Account Abstraction? RIP-7560 Explained

[tynes]

This is an awesome initiative! I still consider RIP-7560 to be very experimental and we need to make sure that it has product market fit before committing to it as part of the protocol roadmap. I think one of the best ways to find product market fit is to run the software end to end and build things that users actually use, which is why I am very supportive of this. If the OP Stack can be used to test out ideas and further Ethereum R&D, that would be great. @hamdiallam has been working on better support for decentralized UserOp mempools, you can see his thinking here. Shipping an OP Stack based RIP-7560 testnet would push forward the Ethereum AA roadmap a ton

[sm-stack]

I think one of the best ways to find product market fit is to run the software end to end and build things that users actually use, which is why I am very supportive of this.

Definitely that's right. We have plans to launch a public OP Stack devnet and let everyone to come and test it, after we finish working with PoC.

@hamdiallam has been working on better support for decentralized UserOp mempools, you can see his thinking here.

Thanks for the recommendation, I'll look through it :)

[sm-stack]

We are actively working on the mentioned repo, and ship a public devnet soon. Before that, I wanna specify the basic architecture we are planning to deliver. Our Native Account Abstraction architecture for this proposal will include three RIPs: RIP-7560, RIP-7711, and RIP-7712.

RIP-7560: ERC-4337 compatible new transaction type, lowering gas fees

RIP-7560 implements Native Account Abstraction by combining EIP-2938 and ERC-4337. It introduces a new transaction type called AA_TX_TYPE, which divides an Ethereum transaction into three steps: validation, execution, and post-transaction logic. This allows RIP-7560 to include all the functionalities defined in ERC-4337.

This means that the Entrypoint contract is no longer needed. Removing it implies an overall reduction in the gas required to send AA transactions. Simple benchmark results showed that an ETH transfer consumes about 60,000 to 70,000 gas, which is 30-40% less than the gas cost for an ERC-4337 UserOp (detailed benchmark soon).

RIP-7712: Enabling 2D Nonce for the new transaction type

RIP-7712 enables the use of 2D nonce as supported by the ERC-4337 Entrypoint. It defines the inclusion of a 'bigNonce' parameter in AA_TX_TYPE transactions, formatted as a uint256 with the first 24 bytes as the key and the last 8 bytes as the seq. To manage 2D nonces, a predeployed contract called NonceManager must be deployed on the network.

This was adopted to provide backward compatibility for ERC-4337 contract wallets. Currently, features like parallel transactions and multisig wallets are implemented in ERC-4337 compatible wallets using 2D nonce.

The NonceManager predeployed contract will be deployed at the address NONCE_MANAGER_ADDR (to be decided later).

In addition, it is allowed to use legacy 64-bit nonce when key in bigNonce parameter is specified as 0. It will help reduce more gas fees, by eliminating the need for 1 cold SLOAD and 1 warm SSTORE at NonceManager contract.

RIP-7711: RIP-7560 Bundle transaction type

RIP-7711 proposes bundling AA_TX_TYPE transactions, similar to ERC-4337, and separating validation and execution to prevent invalidation between transactions within a bundle.

Although the block building in the OP Stack is done by a single sequencer, the mempool is public, and transactions are sorted by priority fee. This means that during the AA transaction processing, the execution of a specific transaction can easily affect the validity of others. If this occurs, two issues can arise:

1. The sequencer might not fill the block, as gas fees cannot be collected from invalid transactions.

2. A bulk of invalid transactions could lead to a DoS attack, disrupting the sequencer's block building.

Therefore, rule checking of RIP-7711 and ERC-7562 is essential in the OP Stack. Their roles are as follows:

• RIP-7711 separates the validation and execution of AA_TX_TYPE transactions to ensure that the result of the execution phase does not affect the validity of other transactions in a specified bundle.

• ERC-7562 defines rules that limit storage access and opcode execution during the validation phase. Checking these rules before block building ensures that the validity of a transaction is not influenced by other transactions' validation phases or state changes within the block.

In summary, Native Account Abstraction within the OP Stack requires bundling, validation/execution separation, and storage/opcode checks before block building. We propose introducing a Bundler node to perform these tasks. Anyone meeting the required specifications and conditions can operate this node, which performs tasks nearly identical to the current ERC-4337 Bundler, and can therefore be run by existing Bundler providers like Pimlico, Biconomy, Stackup, Alchemy and so on.

This node collects users' AA_TX_TYPE transactions, bundles them, debugs the validation phase to ensure no prohibited slot access or opcode use, and then sends the bundle to the mempool via the eth_sendRip7560TransactionsBundle RPC API.

To effectively distinguish between bundles within a block, the sequencer inserts a Bundle Header Transaction, as defined in RIP-7711, at the start of each bundle. This transaction informs how many transactions are in each bundle and does not alter the blockchain state.

Also, we are planning an architecture that a permissionless bundler node network can cover all compatible Superchain networks.

[sm-stack]

We are excited to announce the launch of the Pioneer Alpha devnet. Based on the OP Stack, this devnet implements the full functionalities of the above RIPs. You can now test and deploy your own AA contracts on the network and experience a 30-40% reduction in gas fees compared to ERC-4337.

Here's some helpful resources for the devnet.

• Launch Announcement
• Docs
• Faucet
• Explorer

If you have any feedback or wanna keep updated, please join the below telegram group link.

https://t.me/rip7560_pioneer

[sm-stack]

A few updates on Native Account Abstraction and the devnet, Pioneer Alpha.

Bundler as a part of the sequencer

The structure for Native Account Abstraction on OP Stack we proposed was designed to enable multiple bundlers to participate in the system, similar to ERC-4337. However, after discussions with the ERC-4337 team and various bundler providers, we concluded that it would be better to keep the bundler as part of the sequencer (block builder).
Having multiple bundlers opted in this system exacerbates the following problems:

1. Bundle Frontrunning
2. Potential liveness attack to the blockchain

For these reasons, we have opted to keep the bundler as part of the sequencer. So there will be only one bundle per a block, and only one global bundler handling AA transactions, if it is applied to the current OP Stack networks. Geth has a predefined Bundler RPC URL, and only bundles from this URL are treated as valid. This setup is akin to a trusted RPC, and arbitrary bundles from other bundlers are not accepted in the mempool.

More details are on this Medium article.

Open source scripts for gas benchmark and RIP-7560 transaction

We have been working on a simple script for gas benchmarks and sending RIP-7560 transactions at Pioneer Alpha, and it's now available on Pioneer Network. Please visit the following repo and test the scripts based on the README.

rip7560-scripts

Regarding the gas benchmark, we checked the exact gas reduction at Native Account Abstraction appears to be about 38% compared to ERC-4337 UserOp, for both ETH and ERC20 transfer.