November 26, 2024

Attendees: @Axel Kingsley @Proto @Tyler Smith @Mark Tyneway

Supervisor as L1 Source - Move Forward

L1 as canonical definition of what the chain is ☑️

• But, who should do the derivation?
• Lower lift if the supervisor simply hosts the L1 input in a raw form and acts as an L1 (ie, no modification for op-node besides pointing L1 at the supervisor)

Supervisor to Orchestrate Sync Actions - Move Forward

When multiple OP Nodes are attached per chain on a Supervisor, the nodes could be slightly desynchronized.

Supervisor can orchestrate sync work amongst many nodes if the Supervisor is the controller of what is syncing and when

Suggesting: we need a place where the difference between OP Nodes can be considered, which must exist inside the Supervisor. Therefore, the Supervisor should be “in control” of the work op nodes do. This can simplify the OP Node

Difficulty: more involved because the APIs and Derivers need to be re-pointed. But seems worth it because the new code would reduce complexity

Can we even support Multiple OP-Node:Supervisor

Bidirectional RPC? - Move Forward (only for writer “owned” nodes)

We can bind an RPC backend to an RPC client, and as op-node serve some functions to the op-supervisor. Or vice-versa.

→ Makes sense for the nodes owned by supervisor, that write to it, in a trusted setting.

Consensus testing in the Supervisor