Doc by Proto, follow-up to Axel Argues About Interop Architecture Abstractions.
Status-quo
Currently we have 3 types of nodes:
- execution engine, e.g. op-geth.
- Syncs EVM: local processing
- owns tx-pool: queries supervisor
- builds blocks: queries supervisor
- serves receipts: serves supervisor
- rollup node, e.g. op-node.
- Turns L1 data into block attributes: local-safe links sent to supervisor
- Applies block attributes / full blocks to engine: local-unsafe signal sent to supervisor.
- Checks if blocks are cross-safe: polls supervisor
- Checks if blocks are finalized: polls supervisor
- superchain backend, e.g. op-supervisor.
- Indexes all blocks and log events: queries engine
- Verifies which L2 block has cross-chain message dependencies met: cross-unsafe data is updated
- Stores which L2 block is reproduced from which L1 block: local-safe data from op-node
- Verifies which L2 block has valid message dependencies, derived fully from data reproducible from L1: cross-safe data is updated.
- Determines which L2 block is finalized: given a L1 finalized block from rollup node.
Building a monolith?
A lot of data is exchanged here, and connections are set up both ways.
Axel wrote a document (link) sharing his thoughts of combining the above into a “super node”: all of these services have to run, to effectively fully verify the chain. And potentially we can embed some or all of this into one process.
But should we?
We’re not going to solve the CAP theorem (”Consistency/Availability/Partition-tolerance”, pick 2). It’s a trade-off, and we have to find something that works well enough.
So what are we optimizing for?
There is:
- Reducing operation costs, by de-duplicating processing/storage.
- Reducing risk of downtime, by making things redundant.
- Reducing complexity, by having fewer interactions, more consistency.
To me, this boils down to “should we build a monolith to save cost?”.
We still need to roll out upgrades, handle local failures, etc. without total chain downtime.
So I believe a monolith is obviously bad.
But we can do some things to improve. This doc suggests what we could do there.