interop: Supervisor Derivation Control

[axelKingsley]

From this document: https://github.com/ethereum-optimism/design-docs/pull/171/files

Decomposed into: https://www.notion.so/oplabs/tasks-to-make-150f153ee162809e981ac7d30c0bfae2?showMoveTo=true&saveParent=true

What

The Supervisor should tell the "sync nodes" when to take on new L1 data, and when to process derivation. The Supervisor should also be positioned to tell the sync nodes to reset to a specific point.

The two parents of this feature request are tracked here:

• interop: Supervisor Drives L1 Data Source #13181 : The Supervisor tracking L1 directly and using it to drive itself
• interop: Bidirectional RPC For Owned Nodes #13182 : The client<>server connection for Nodes to be driven by a Supervisor.

Now, we need to join these two sides of work by using the L1 data we are sourcing to control the sync nodes.

Why

In service of having the Supervisor control its own internal consistency by using "Sync Nodes" as controlled derivation pipelines, the Supervisor should leverage new functionalities to drive the sync nodes derivation processes.

How

• Add a new resource to the Supervisor representing the sync nodes and attach it to the backend, or expand an existing resource (like chain processors) to become representations of sync-nodes.
• Have the L1 Processor trigger a process or otherwise direct the sync nodes to synchronize against a new L1
  • The L1 head should be passed down as part of a TryDeriveNext call (new API for Sync Nodes)
  • The TryDeriveNext return should be whatever new L2 block is derived, if any
  • If the derivation yielded an L2 block, repeat derivation again with the same L1
  • As new L2s come back, record them in the derivation databases

Also to implement:

• Reset (prestate): directs the Sync Node to reset back to a specified prestate, which skips all the L1 traversal work the node does today.
• NewSafetyLevels: which just directly informs the Sync Nodes of the latest safety levels, to be propagated through its derivers system.

If implementing these APIs are helpful to the core task of driving derivation, then they should be included. But if the scope of this task is large enough just with TryDeriveNext, these other APIs can be split out into parallel work.

[protolambda]

FYI, I opened an issue to track the op-node side of this: #13336
This GH issue can then focus on the op-supervisor part of the managed-mode syncing.

[axelKingsley]

#13344

Here's the start of the Node Controller code