feat: chain orchestrator #185

frisitano · 2025-07-02T19:06:49Z

closes: #182

Copilot

Pull Request Overview

This PR implements a new ChainOrchestrator to replace the previous indexer, integrates it throughout the node, watcher, network, and engine, and updates tests and database migrations accordingly.

Introduces ChainOrchestrator in place of Indexer, refactors RollupNodeManager to consume orchestrator events instead of indexer events.
Adds Synced notifications to L1Watcher and updates engine driver to handle optimistic sync via ChainOrchestrator.
Refactors configuration (ScrollRollupNodeConfig), network manager, and database migrations; adjusts tests to cover the new orchestrator flows.

Reviewed Changes

Copilot reviewed 40 out of 41 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
crates/indexer/src/lib.rs	Rename `Indexer` to `ChainOrchestrator` and overhaul API flows
crates/manager/src/manager/mod.rs	Replace indexer usage with `ChainOrchestrator` in node manager
crates/node/src/args.rs	Instantiate `ChainOrchestrator` in `ScrollRollupNodeConfig`
crates/watcher/src/lib.rs	Add `Synced` variant and `is_synced` flag to `L1Watcher`
crates/scroll-wire/src/protocol/proto.rs	Adjust doc comment for `NewBlock::new`
crates/node/tests/e2e.rs	Add/revise reorg and sync end-to-end tests
crates/watcher/tests/reorg.rs	Update tests to skip `Synced` notifications
crates/database/db/src/operations.rs	Extend DB ops with `L1MessageStart` and block-and-batch queries
crates/database/migration/src/migration_info.rs	Add `genesis_hash()` to migrations and insert genesis blocks
crates/network/src/manager.rs	Wire up eth-wire listener and dispatch chain-orchestrator events
crates/engine/src/driver.rs	Support `ChainImport` and `OptimisticSync` futures in engine driver

Comments suppressed due to low confidence (2)

crates/scroll-wire/src/protocol/proto.rs:33

The doc comment uses "blocks" (plural) but the constructor takes a single block; change to "block" for accuracy.

    /// Returns a [`NewBlock`] instance with the provided signature and blocks.

crates/node/tests/e2e.rs:95

The follower_can_reorg test has no assertions; either add meaningful checks or remove the empty test to maintain coverage.

async fn follower_can_reorg() -> eyre::Result<()> {

Copilot · 2025-07-16T14:15:04Z

crates/watcher/tests/reorg.rs

@@ -91,15 +91,19 @@ async fn test_should_detect_reorg() -> eyre::Result<()> {
            continue
        }

+        // skip the `L1Notification::Synced` notifications
+        let mut notification = l1_watcher.recv().await.unwrap();
+        if matches!(notification.as_ref(), L1Notification::Synced) {


This only skips one Synced notification; consider looping (e.g. while matches!(...) { ... }) to skip all consecutive Synced messages.

Suggested change

if matches!(notification.as_ref(), L1Notification::Synced) {

while matches!(notification.as_ref(), L1Notification::Synced) {

greged93

Couple of comments and some small nits and leftover code to clean.

greged93 · 2025-07-23T09:24:47Z

.github/workflows/test.yaml

            --log.stdout.format log-fmt -vvv \
            --l1.url "https://eth-sepolia.g.alchemy.com/v2/$ALCHEMY_KEY"  --l1.cups 500 \
-            --beacon.url https://eth-beacon-chain.drpc.org/rest/ --beacon.cups 100 --engine.en-sync-trigger 10000000000 \
-            --engine.sync-at-startup=false --engine.always-process-payload-attributes-on-canonical-head &


I think we need this argument, I ran into issues during reorgs if the arg isn't passed.

--engine.always-process-payload-attributes-on-canonical-head this one? Oh, I thought it was a typo. What does it do?

greged93 · 2025-07-23T09:44:05Z

crates/chain-orchestrator/src/metrics.rs

@@ -33,7 +36,7 @@ impl IndexerItem {
    }
 }

-/// The metrics for the [`super::Indexer`].
+/// The metrics for the [`super::ChainOrchestrator`].
 #[derive(Metrics, Clone)]
 #[metrics(scope = "indexer")]
 pub struct IndexerMetrics {


nit: ChainOrchestratorMetrics

greged93 · 2025-07-23T10:18:28Z

crates/chain-orchestrator/src/lib.rs

+        let mut received_chain_headers = vec![received_block.header.clone()];
+        let mut received_header_tail = received_block.header.clone();
+
+        // We should never have a re-org that is deeper than the current safe head.


why up to the safe head and not the finalized head?

This becomes a protocol design question. This assumes that L1 is the source of truth and batches posted to L1 should never be reorged. If so, then we would never expect a reorg deeper than the safe head. If there is a L1 reorg or a batch revert, then the safe head would change and deeper reorg would be allowed. If we allowed safe blocks to be reorged then a rogue sequencer could override batches posted to L1, would we want to allow this?

greged93 · 2025-07-23T10:19:59Z

crates/chain-orchestrator/src/lib.rs

+            // If we are in optimistic mode and the received chain can not be reconciled with the
+            // in-memory chain we break. We will reconcile after optimistic sync has completed.
+            if *optimistic_mode.lock().await &&
+                received_chain_headers.last().unwrap().number <
+                    current_chain_headers.front().unwrap().number
+            {
+                return Ok(ChainOrchestratorEvent::InsufficientDataForReceivedBlock(
+                    received_block.hash_slow(),
+                ))
+            }


Isn't this redundant with the check at line 231?

We may start with received_chain_headers.last().number > current_chain_headers.front().number but as we fetch more more headers for received_chain_headers via the loop we can reach a point where received_chain_headers.last().number < current_chain_headers.front().number as and such we should terminate the loop. Let me know if this makes sense to you.

greged93 · 2025-07-23T10:40:15Z

crates/chain-orchestrator/src/lib.rs

+                        received_header_tail = header;
+                    } else {
+                        return Err(ChainOrchestratorError::MissingBlockHeader {
+                            hash: current_chain_headers.front().unwrap().parent_hash,
+                        });
+                    }
+                }
+            }
+
+            // We search the in-memory chain to see if we can reconcile the block import.
+            if let Some(pos) = current_chain_headers
+                .iter()
+                .rposition(|h| h.hash_slow() == received_header_tail.parent_hash)


I'm not sure I understand this part of the code: you fetch 50 blocks from the L2 client, starting at the received block. At the end of the fetch phase, received_header_tail = received_block - 50 and current_chain_headers contains blocks from received_block to received_block - 50. But would the above branch ever work then?

I think there is a bug here, we shouldn't be updating received_header_tail = header. Let me update this and add some test cases for deep reorgs.

greged93 · 2025-07-23T15:32:21Z

crates/node/tests/sync.rs

+        signer_args: Default::default(),
+    };
+
+    // Create the chain spec for scroll dev with Euclid v2 activated and a test genesis.


nit:

Suggested change

// Create the chain spec for scroll dev with Euclid v2 activated and a test genesis.

// Create the chain spec for scroll dev with Feynman activated and a test genesis.

greged93 · 2025-07-23T15:33:45Z

crates/sequencer/tests/e2e.rs

@@ -40,7 +40,7 @@ async fn can_build_blocks() {
    reth_tracing::init_test_tracing();

    const BLOCK_BUILDING_DURATION: Duration = Duration::from_millis(0);
-    const BLOCK_GAP_TRIGGER: u64 = 100;
+    // const BLOCK_GAP_TRIGGER: u64 = 100;


greged93 · 2025-07-23T15:33:56Z

crates/sequencer/tests/e2e.rs

@@ -284,7 +281,7 @@ async fn can_build_blocks_with_finalized_l1_messages() {

    let chain_spec = SCROLL_DEV.clone();
    const BLOCK_BUILDING_DURATION: Duration = tokio::time::Duration::from_millis(0);
-    const BLOCK_GAP_TRIGGER: u64 = 100;
+    // const BLOCK_GAP_TRIGGER: u64 = 100;


greged93 · 2025-07-23T15:34:07Z

crates/sequencer/tests/e2e.rs

@@ -671,7 +674,7 @@ async fn can_build_blocks_and_exit_at_time_limit() {
    let chain_spec = SCROLL_DEV.clone();
    const MIN_TRANSACTION_GAS_COST: u64 = 21_000;
    const BLOCK_BUILDING_DURATION: Duration = Duration::from_secs(1);
-    const BLOCK_GAP_TRIGGER: u64 = 100;
+    // const BLOCK_GAP_TRIGGER: u64 = 100;


greged93 · 2025-07-23T15:35:20Z

crates/watcher/src/lib.rs

-            if self.is_synced() {
+            if self.is_synced {
                tokio::time::sleep(SLOW_SYNC_INTERVAL).await;
+            } else if self.current_block_number == self.l1_state.head {
+                // if we have synced to the head of the L1, notify the channel and set the
+                // `is_synced`` flag.
+                if let Err(L1WatcherError::SendError(_)) = self.notify(L1Notification::Synced).await
+                {
+                    tracing::warn!(target: "scroll::watcher", "L1 watcher channel closed, stopping the watcher");
+                    break;
+                }
+                self.is_synced = true;


the current logic suggests the watcher can never transition from is_synced = true -> false. Is this expected?

Good question. In the context of the RN, Synced should mean that we have synced all L1 messages required to validate messages included in unsafe L2 blocks. Given that we only include L1 messages after the corresponding L1 block has been finalized I think this should be fine provided the watcher doesn't start to lag > 2 epochs behind the safe tip then the Synced status should still remain valid. What do you think about this?

frisitano added 12 commits July 2, 2025 19:44

feat: chain orchestrator

c1e5cc2

Merge branch 'main' into feat/chain-orchestrator

bbe0e8f

lint

4032fa5

lint

39802e2

docs lint

c84dc0d

fix: clone the in-memory chain instead of taking it

ea3140c

Merge branch 'main' into feat/chain-orchestrator

a28a5b2

update chain consolidation and l1 message validation

fa6952c

add missing network block error

43cc2be

update fork sync / reconcilliation to use network as opossed to database

5dfc813

Merge branch 'main' into feat/chain-orchestrator

a50558d

fix merege

19458f7

frisitano mentioned this pull request Jul 15, 2025

[ChainOrchestrator] Monitor performance of recursive syncing of blocks #199

Open

frisitano added 2 commits July 16, 2025 12:56

refactor and add test cases

4578d49

cleanup

e6248f5

frisitano marked this pull request as ready for review July 16, 2025 14:10

Merge branch 'main' into feat/chain-orchestrator

626e29b

frisitano requested a review from Copilot July 16, 2025 14:13

Copilot AI reviewed Jul 16, 2025

View reviewed changes

frisitano added 2 commits July 16, 2025 22:21

rename chain orchestrator crate

7a6ebfc

cleanup

7d35185

frisitano requested a review from greged93 July 17, 2025 17:14

frisitano added 7 commits July 18, 2025 18:36

Merge branch 'main' into feat/chain-orchestrator

74fd7b8

remove expect for sequencer in rnm

fe75ed5

sync test

f3bab0d

sync test

56a0ff3

sync test

1320f14

add error handling for missing paylaod id

0fa87fe

remove networking for L1 consolidation sync test

cecbd03

greged93 mentioned this pull request Jul 22, 2025

feat: bump reth #211

Merged

greged93 reviewed Jul 23, 2025

View reviewed changes

	if matches!(notification.as_ref(), L1Notification::Synced) {
	while matches!(notification.as_ref(), L1Notification::Synced) {

	// Create the chain spec for scroll dev with Euclid v2 activated and a test genesis.
	// Create the chain spec for scroll dev with Feynman activated and a test genesis.

feat: chain orchestrator #185

Are you sure you want to change the base?

feat: chain orchestrator #185

Uh oh!

Conversation

frisitano commented Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Jul 16, 2025

Choose a reason for hiding this comment

Uh oh!

greged93 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

frisitano commented Jul 2, 2025 •

edited

Loading