Rollup Node Design

[frisitano]

Overview

As part of our ambitions to migrate from l2geth (go-ethereum implementation of scroll node) to scroll-reth (reth based implementation of scroll node) we need to consider how we drive the execution client. In l2geth this has been done by utilizing the NewBlock and NewBlockHashes messages on the devp2p implementation. However, these messages have been soft-deprecated following the merge (PoW-to-PoS transition). This document will outline the high-level considerations, proposed architecture, and prospective implementation details.

Rollup Node Description

The rollup node is responsible for driving the scroll chain. This includes monitoring Ethereum to parse posted batches and the p2p network for newly published blocks and using this information to drive the execution layer. In the future the rollup node may also have additional functionality such as deriving fast finality using succinct commitments posted to L1.

Core Considerations

Separation of Concerns

From an architectural perspective, we need to ensure that there is a clear separation of concerns between the execution client and the consensus client (rollup node). This keeps our codebase clean and interfaces well-defined.

Deprecation of Clique

We intend to deprecate Clique consensus and move to a different consensus mechanism. In clique, there is sufficient information in the block header to determine if a block is valid. As we migrate to a different means of consensus this assumption will no longer hold. As such the NewBlock and NewBlockHashes messages from the eth wire protocol are no long sufficient to verify consensus. We will likely need a signature to accompany the payload to verify consensus. As such using the native eth-wire-protocol isn't suitable.

Provable-Derivation Pipeline

We want the derivation pipeline to be provable by a modern zkVM. As such we should ensure that during the implementation we support no_std. Most modern zkVM's work with a riscV instruction set so we should ensure our CI pipeline asserts that compilation to riscV is functional. We may also want to operate as a light client in web browser so support for a wasm target should also be considered and this should be provided if we support no_std.

L2 Unsafe Head

To provide a good user experience we want our nodes to be able to track the L2 chain tip without requiring that batches are posted to L1 as this can take some time. Instead, we want blocks to be gossiped and propagated over an L2 network. Given that the current eth-wire protocol messages are not suitable for the rollup node I think we should define our own RLPx sub-protocol.

Network Discovery and Bootstrapping

Network discovery is achieved via the discv4 and discv5 protocols. We can leverage the same discovery network for both the rollup node and the execution nodes.

Sync Modes

Optimistic Sync

In this mode the rollup nodes gossip blocks that have not yet been published on Ethereum. They block payload should be accompanied by a signature that attests that the block has been signed by an authorized sequencer. These blocks should be sequentially provided to the execution node via the engine API.

Pessimistic Sync

In this mode, the rollup node reads data directly from the L1 (Etheruem). It parses the batches posted on L1 and uses the derivation pipeline to compute PayloadAttributes which are then used to invoke the engine API to execute the payload and progress the chain.

Notes

The pessimistic sync will always be considered the source of truth and as such if there is some disagreement between the pessimistic and optimistic pipelines then the pessimistic pipeline will take precedence.

Finality

The level of finality associated with an L2 block is dependent on the number of attestations the batch the block is included in has on L1. We should clearly define the relationship and rules. As we migrate to a fast-finality off-chain finality gadget this implementation will change.

Proposed Architecture

Implementation

Reference

Optimism have implemented an architecture similar to that which is described in this note. Their go implementation can be found here, a non feature complete rust implementation can be found here.

L1 Watcher

The L1 watcher is used to track the state of L1, it is specifically interested in data relating to the scroll rollup. This data is stored on the L1 settlement contacts which can be quired via rpc on the execution client. Additionally, we are interested in blobs containing batches which can be attained by querying the consensus client. I would propose that we use allloy for this component. However, in the magi implementation referenced above they use ethers, we should try and understand why this decision was made.

L2 Watcher

The L2 watcher is used to identify the current status of the L2 execution client chain. This involves rpc queries to get the block numbers the execution client is aware of at startup. Once again we can use alloy for this purpose, however, we may need to use scroll-alloy implementation as we have some different rpc types.

Derviation Pipeline

The derivation pipeline is used to derive the chain from the data provided on L1. This can be decomposed into a staged pipeline as is done in the op derivation pipeline. We should clearly define the stages required for the pipeline and use optimism's derivaiton pipeline as a reference. There is a rust-based framework that we can use to build the pipeline called kona. Kona has been used to replace the magi derivation pipeline with support for no_std and newers ethereum libraries such as alloy.

P2P Gossip Network

To network discovery I would propose that we exclusively utilize the discv5 protocol. We can either leverage the discv5 library or the light reth-based wrapper which provides some additional functionality that is useful such as advertising of capabilities reth-discv5. For P2P gossip with discovered peers we can use a modified instance of the NetworkManager. By default these components expect the eth-wire protocol to be support and as such we should look to disable this requirement. Custom rlpx subprotocol example: https://github.com/scroll-tech/reth/tree/scroll/examples/custom-rlpx-subprotocol

Scroll-wire protocol RLPx

We will need to define a P2P gossip protocol such that we can communicate new blocks over the network. The optimism specification is defined here.

Engine Driver

This component is responsible for communicating with the L2 node engine API to validate new payloads, create new payloads and submit fork-choice updates. This component can leverage scroll-alloy to invoke the required methods.

Database

The database should be used to store metadata related to the rollup nodes operation. This includes both chain and network metadata. More research is required to better understand what we need to persist. A sqlite database is likely sufficient for this component.

Block Signer

This component is used by the sequencer to sign blocks before it gossips them to the network.

[frisitano]

This discussion will be migrated to https://github.com/scroll-tech/rollup-node when discussions are enabled.

[greged93]

I have a question about the L2 watcher/Fast sync mode: as far as I understand, the L2 watcher is required for the "Fast sync mode" but I am not sure I fully grasp why this mode is required. The fast sync is similar to the pessimistic sync: fetch the block hash for the L2 chain finalized and pass it to the EN via the Engine API (FCU), at what point the EN will decide to run a backfill based on how far it is from the tip. We could have the RN use the pessimistic sync by default at start up, send the first FCU for it and then switch to either optimistic or pessimistic based on the configuration. Maybe I am missing something here or misunderstanding the "Fast sync mode"?

[frisitano]

This was initially inspired by the sync modes available in optimism's rollup node. I would need to do more research into it. I believe it's a mode for syncing the rollup node to the chain tip using a "trusted block anchor" of sorts. However, I agree with your reasoning. Let's remove the mode for simplicity and we can reassess if we need it in the future.

[greged93]

However, in the magi implementation referenced above they use ethers, we should try and understand why this decision was made.

just a note on this, found reading the Kona documentation.