Interop Devnet 1 Architecture

[protolambda]

For devnet 1, reorgs are out of scope.

What this really means is that the integration design-doc, with the superchain safe-db, is out of scope.

Yet, we want an architecture that is more forward compatible; to follow up with reorg-support without redoing the stack.

Conceptually, the final supervisor looks like:

• An events-index per L2 (already largely implemented)
  • A backfiller routine: pulling information from L2 RPC into the events index.
  • Determines message-dependencies, to determine if the blocks are safe at all. I.e. the happy path, checking we can promote the safety-level of a block, or include a tx.
• A DA safety-index per L2 (open design doc + spec)
  • A write API: inserts new data into the index.
  • Determines how to rewind back L2 chains, to resolve invalid dependencies. I.e. the sad-path, handling reorgs.
• A global read API, to determine message-safety (op-geth) and block safety (op-node). (needs more work)
  • Using the events index, determine the dependency of the queried data
  • Using the safety index, determine if all the dependencies may be used

To support the “happy path” for devnet 1, we can model this structure as Go interfaces in the op-supervisor, but dramatically simplify a few things:

• No write API in safety-index
• No work to determine how to rewind back L2 chains. Since no reorg support.
• Upon global reads, when checking dependencies, just check that the dependencies are older than the latest safe head (RPC block label), rather than using an actual index.

Then, for devnet 2, we can implement the DA safety-index, implement the write-API, and reorg support, without changing most of the devnet 1 architecture.

[axelKingsley]

[Safety Index] A write API: inserts new data into the index.

I think given the interactions we've defined, there doesn't need to be an explicit write operation for Safe Indexes. When a Chain asks the supervisor for safety information regarding some messages, it can include with it the head it is trying to promote. When the Supervisor builds the response, it can also conditionally update its own view.

No write API in safety-index

Oh, nice 😜 . But I'm thinking that maybe even into the future we don't need this. 🤔 .

Upon global reads, when checking dependencies, just check that the dependencies are older than the latest safe head (RPC block label), rather than using an actual index.

If the dependencies are older than the latest safe head, they may still belong to an invalid chain-split, right?

[tynes]

Some thoughts on the design can be found here: https://www.notion.so/oplabs/Interop-Reasoning-about-Cross-Safety-Management-and-Reorgs-65f2d84c663947e88acfdb7a3023e91b