[Indexer] Refactor `Indexer` to `ChainOrchestrator`

[frisitano]

Overview

This is a proposal to refactor the Indexer into a ChainOrchestrator component. The ChainOrchestrator component will have the following responsibilities:

• Determine when we are in optimistic mode
• Validate that L1 messages are correct and continuous
• Detect reorgs on L2 and issue an appropriate event
• Be the primary driver of the EN

Optimistic Mode

We define optimistic mode as a mode when we have not fully synced from L1, and as such, we will not be in a position to validate all L1 messages.

When a node starts up, the ChainOrchestrator will be instantiated with optimistic_mode = true. We then will have to wait for the L1Watcher to sync, at which point it should emit a L1Synced event. We need to ensure that all previously emitted batches and L1 messages have been consolidated and indexed before switching the ChainOrchestrator to optimistic_mode = false. At this point we should validate that any blocks that we have optimistically synced have valid L1 messages included in them. Following this, for every new block received over the network, we should validate the L1 messages before pushing the blocks to the EN.

L2 Reorgs

The ChainOrchestrator should be responsible for detecting L2 reorgs. When we receive a block over P2P, we should reconcile the block with the chain data we have in the database. If we have a gap between the database chain tip and the P2P block, then we should recursively request parent blocks until we find the highest common ancestor. If the highest common ancestor is the chain tip, then we know this chain extends the chain the RN is following; if it is some deeper block, then we have detected a reorg and must unwind the chain to the highest common ancestor. We must then validate L1 messages from the new chain blocks and issue messages for the EN to execute these blocks and issue an FCU. On startup, we encounter a challenge in which the gap between the indexed data in the database and the block received over P2P is very large. As such, we need a means of addressing this. A simple approach would be to optimistically sync the last N (~300?) blocks and persist them in the database such that on future blocks we can detect reorgs against this optimistic chain. A more robust solution would be to fetch the latest finalized block from L1 and then use that as an anchor to recursively sync back to. In the name of practicality, I propose we implement the former solution first and then subsequently implement the latter.