Skip to main content
Superchain interop is in active development. Some features may be experimental.

​
Superchain interoperability

It is easy for a blockchain to be certain about information it generates itself. Information that comes from other sources is harder to provide in a safe, decentralized, and uncensorable manner (this is called The Oracle Problem). The next major scalability improvement to the OP Stack is to enable a network of chains, the Superchain, to feel like a single blockchain. This goal requires low-latency, seamless message passing and asset bridging. Superchain interoperability is a set of protocols and services that lets OP Stack blockchains read each other’s state. Superchain interoperability provides the following benefits:
  • ETH and ERC-20 tokens to move securely between chains via native minting and burning. Asset interoperability solves the issues of liquidity fragmentation and poor user experiences caused by asset wrapping or liquidity pools.
  • Apps to compose with data that exist on other chains.
  • Horizontal scalability for applications that need it.

​
Superchain interoperability architecture

A pre-interop OP Stack node consists of two pieces of software: a consensus client (e.g. op-node) and an execution client, which is responsible for processing user transactions and constructing blocks (e.g. op-geth). Superchain interoperability among OP Stack chains is enabled via a new service called OP Supervisor. Every node operator is expected to run this service in addition to the rollup node and execution client. OP-Supervisor holds a database of all the log events of all the chains in the Superchain interoperability cluster. Every event can potentially initiate a cross-domain message, and it is the job of OP-Supervisor to validate that the log event really happened on the source chain. Additionally, OP-Supervisor reads information from L1’s consensus layer to determine the transaction safety of L2 blocks.

​
How messages get from one chain to the other

To understand why we need this additional service, it is useful to know how interop messages get from one OP Stack chain to another. Cross-domain messages require two transactions. The first transaction creates an initiating message on the source chain. The second transaction creates an executing message on the destination chain. This executing message could result in a contract function being executed on the destination chain. The initiating message is simply a log event. Any log event on any chain that interoperates with the destination can initiate a cross-domain message. The transaction that receives the message on the destination chain calls a contract called CrossL2Inbox. This call can be at the top level, directly from the externally owned account, or come through a smart contract. The call to CrossL2Inbox, also known as the executing message, needs to identify the initiating message uniquely, using the chain ID of the source chain, the block number, and the index of the log event within that block, as well as a few other fields as a sanity check. CrossL2Inbox can either validate the message exists, or call a contract if the message exists.

​
Block safety levels

Superchain interop expands the scope of trust for unsafe blocks (blocks that are shared through the gossip protocol). If a sequencer chooses to accept unsafe messages, the sequencer must trust the sequencer that produces the inbound message as well as any referenced unsafe messages produced from sequencers in the transitive dependency set. Notably this trust assumption is only for unsafe blocks, and only if the sequencer allows messages from unsafe blocks to be processed. In Superchain interop, the traditional safe level of a block is divided into two types of safety. A block is local safe once it is written to L1. But it is only cross safe when in addition to the block itself all of the blocks on which it depends (directly or indirectly) are written to L1, including the dependencies of previous blocks in the same chain. For example, in the image above, most blocks are safe. Block n in chain A is even finalized, and immune from reorgs. However, block n+105 in chain A is unsafe, it (or a block on which it depends) is not written to L1. Because the new block depends upon it, it can be either unsafe or local safe, but it cannot be cross safe.

​
Interop clusters

The interop protocol works via a dependency set which is configured on a per-chain basis. The dependency set defines the set of chains that can send and receive messages with a specific chain. For example, in the illustration above, the dependency set of chain B is chains A and C. To move an asset from chain E to chain B, it is necessary to move the asset from chain E to chain A, and then from chain A to chain B, because there is no direct dependency between B and E.

​
Superchain interop cluster

The Superchain builds on top of the interop protocol and implements a single mesh network with complete dependencies. In this model, each blockchain in the Superchain interop cluster would have direct connections to every other blockchain, creating a fully connected mesh network. This model provides the highest level of interoperability, as any blockchain can transact directly with any other. Each blockchain in the Superchain interop cluster shares the same security model to mitigate the weakest-link scenario. As outlined in the Standard Rollup Charter, these chains share the same L1 ProxyAdmin Owner. Any changes to the Superchain interop cluster must follow the standard Protocol Upgrade vote procedure—the established governance process for Superchain modifications. The Superchain interop cluster will be rolled out iteratively, but to see a list of eligible chains that could join the cluster visit the Superchain Index and look at chains that have a Standard charter.

​
Next steps

⌘I