Here are some thoughts I have about the way we build op-node and how I think we should be building op-supernode in the future. Rather than attempt to convince the reader of just one point, I am covering a variety of related ideas. The premise of this article is: if we are headed into a Superchain world, we need a Super Architecture to handle our Abstractions.
First, if you haven’t, check out the Safety Index Design Document which lays out the basic case that “Tracking L1:L2 Derivation metadata is important”. It points out that a number of problems share a common solution: Track which L2 blocks were derived from which L1 source blocks.
The need for a Safety Index has been so great that we actually already have implemented them multiple times. The first one, for Fault Proofs, I am not very familiar with.
The second implementation of the Safety Index has been in service of op-supervisor, which requires L1:L2 relationships to be known. More detail on that as we proceed.
OP-Supervisor is a new component in the Stack which serves Interoperability between chains. It does this by taking the following responsibilities:
With the introduction of Interop, the infrastructure requirements of a Node operator go up. Now they must run one Validator (op-node) and Executor (op-geth) per Chain, plus one Supervisor (op-supervisor). Because of this requirement, you could consider this collection as atomic - you do not have a node unless you have all these pieces running.
For this reason, we could think of this collection of binaries as a “Supernode”
The reason this “Supernode” descriptor is powerful is that it reveals an abstraction that we would benefit from embracing: To run the Superchain, you need to run “all this” infrastructure. Modeled against our existing architecture this means adding new components (op-supervisor) and therefore increasing the number of cross connections, and complexity, within the scope of a single node operator.
Rather, by thinking of these required components as being achievable by one total entity, we can start to imagine ways to reduce complexity and embrace Superchain concepts at the right level of abstraction.
(This statement provided without data, the author could be biased)
Production OP Networks have suffered various outages and unavailability events during operation. While some of these outages were due to application bugs or Protocol design issues, a more common story was that interdependencies between components were the source of failures. When a component is unavailable and RPC calls fail, dependent work can cascade into larger issues. For example, when Beacon Nodes are unavailable or inconsistent, infrastructure can fail to discover blobs and experience stalling.