interop: Topology and Tx Flow for Interop Chain Operation #218
Conversation
Design doc that is meant to define clearly the topology for a cloud deployment of an OP Stack cluster. This is not meant to define the only way to deploy a cluster, but is the architecture that we will do our security review against to ensure that it is not possible to attack a cluster.
There was a problem hiding this comment.
I think in general I agree with the premise here: we need to economical with our calls to the supervisor, or else RPC communication will dominate the block-building time, creating the potential that the supervisor can't build fast enough if enough interop transactions occur.
There are lots of places for us to dial things in, and I really agree with:
- Proxyd/Ingress pre-checks, which can use
cross-unsafeas the minimum safety - Regular interval re-checking in the mempool, because the older a tx is, the less accurate the previous check may be.
- Batching calls to the supervisor where possible
I think we can likely set up a batch-submission scheme for the block builder which puts interop checks very near to the block-building while avoiding making many calls -- basically just batch up all the AccessLists for the next X transactions that are going to be applied to the block. I talk about that in more detail in a comment below.
In general I am concerned with time delta between interop checks and tx inclusion. Optimism L2s currently reorg very rarely, but one new reorg vector we are introducting is invalid interop Tx. While it's true that a message may become invalid after unsafe inclusion, that doesn't convince me that checking at build time isn't valuable. If I really wanted to I could make the argument that "L2 chains basically never reorg, so we should just check at proxyd, and then never again".
Hard agree that we need to take measurements to best decide where to set the dial to. We'll need to design those experiments.
Co-authored-by: Axel Kingsley <[email protected]>
|
@axelKingsley Wondering if you could help articulate the differences between standard/managed mode, their value props and how it compares to running 1 supervisor per set of replicas. I would like to contain that context in this document so that we can present a unified piece of information to the platforms team |
axelKingsley
changed the title
|
This looks great to me, thank you @axelKingsley! I cannot approve it given that I opened the PR, but would if i could |
* interop: design doc for topology Design doc that is meant to define clearly the topology for a cloud deployment of an OP Stack cluster. This is not meant to define the only way to deploy a cluster, but is the architecture that we will do our security review against to ensure that it is not possible to attack a cluster. * typo: fix Co-authored-by: Axel Kingsley <[email protected]> * Add Host Redundancy Topic * Editorial Pass * Unsaved edits * Add Conductor Action Item * Explicit op-geth mention --------- Co-authored-by: Axel Kingsley <[email protected]>
Description
Design doc that is meant to define clearly the topology for a cloud
deployment of an OP Stack cluster. This is not meant to define the
only way to deploy a cluster, but is the architecture that we will
do our security review against to ensure that it is not possible to
attack a cluster.