L1 message validation

[greged93]

Describe the feature

The current implementation of the ScrollBeaconConsensus doesn't validate L1 messages. The EN should have a way to verify during pipeline sync but especially during live sync that the L1 messages that are included in the block by the sequencer are sequential and come from the L1.

The goal is to avoid the sequencer from including invalid L1 messages that it fabricated, since L1 messages aren't signed on the L2 but on the L1. For block building, we could have the verification done as a consistency check in the RN, but for block validation, the EN would need a way to receive or request the rolling hash of the message queue.

Additional context

No response

[Thegaram]

Maybe an elegant way to do this (that does not require callback from EN to RN) is:

1. RN inserts execution payload to EN
2. EN returns valid/invalid, plus returns the resulting messageQueueHash
3. RN checks the messageQueueHash and decides validity based on this.

Though the problem is, if in step 3. we find that the hash is invalid, there's not much we can do, and we do not know the last valid L2 block.

[frisitano]

2. EN returns valid/invalid, plus returns the resulting messageQueueHash

How would the EN know the messageQueueHash?

[Thegaram]

It can compute the rolling hash from the sequence of all L1 message hashes in that chain.

[greged93]

Though the problem is, if in step 3. we find that the hash is invalid, there's not much we can do, and we do not know the last valid L2 block.

I guess if this happens during pipeline sync, you can switch to L1 consolidation and if it happens in live sync you can fallback to the finalized head?

[Thegaram]

Yeah that sounds reasonable.

[greged93]

I personally like your solution as it maintains the decoupling of the two nodes. I think it's worth exploring and checking if there are any blockers in the implementation.

[frisitano]

It would be an elegant property if we could validate L1 messages included in L2 blocks without requiring explicit communication from the Execution Node (EN) back to the Rollup Node (RN). While this might be challenging, I believe we should fully explore all design paths that maintain this decoupling before considering EN → RN communication as a fallback.

Since this discussion also includes validating L1 messages during the L2 initial sync, we may question the utility of optimistic sync in this context. If we need to download and validate all L1 messages anyway, it’s likely simpler and safer to just sync via L1 batches. This gives us a clear and consistent finalized, safe, and head view — where “safe” and “head” will be the same. One prohibitive concern here is sync time, how long would this typically take?

Once the initial sync is complete, we transition to a “live sync” mode using p2p. When we receive a new block via the network, there’s often a gap between the block we receive and our current head. To bridge this, we can have the RN request parent blocks recursively from the network until we reach our current tip. If we fail to reach the tip and instead land on a lower block number, that indicates a reorg.

In this case, the RN handles the reorg by locating the highest common ancestor and pruning all L2 blocks above it (If the highest common ancestor < finalized (safe?) block number, then this indicates equivocation and we should panic). It then replays the newly fetched blocks sequentially back to the EN. Because these blocks are now being passed to the EN in strict sequence, we can assert the continuity and ordering of L1 messages across blocks, while also maintaining reorg awareness inside the RN.

[Thegaram]

You're suggesting moving the whole sync logic to RN, instead of relying on EN to sync.

I agree this is a much more robust and simple design. But sync times might be prohibitively slow. We need to test it. If blob retrieval is the bottleneck, there are ways to accelerate that.

[frisitano]

You're suggesting moving the whole sync logic to RN, instead of relying on EN to sync.

Correct. This proposal addresses two open issues in the rollup-node:

• L1 message validation
• L2 reorg awareness

I agree this is a much more robust and simple design. But sync times might be prohibitively slow. We need to test it. If blob retrieval is the bottleneck, there are ways to accelerate that.

Agreed, we need to evaluate this.

Furthermore, we consider what "modes" we want to support. Do we want to support "optimistic" mode, where the node operator does not provide an L1 rpc or are we happy to make the L1 rpc a hard requirement?

[frisitano]

Having said that, I think we can make this solution compatible with optimistic sync. The main point I'm suggesting is keeping fork choice selection and consensus logic (L1 message validation) in the rollup node. It maintains good separation of concerns, imo.

[greged93]

Resolved by scroll-tech/rollup-node#185