Interoperability explainer

Why do we need 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 (opens in a new tab)). The next major scalability improvement to the OP Stack is to enable a network of chains to feel like a single blockchain. This goal requires low-latency, seamless message passing and asset bridging.

Interoperability is a set of protocols and services that lets OP Stack blockchains read each others' state. Interoperability provides the following benefits:

• 1-block latency asset movement, removing the problem of capital fragmentation leading to better capital efficiency.
• Improved experience for both users and developers.
• Secure transfer of assets, such as ETH and ERC-20 tokens, across L2s.
• Horizontal scalability for applications that need it.

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). 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 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 (opens in a new tab). 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 (opens in a new tab), 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 (opens in a new tab), or call a contract if the message exists (opens in a new tab).

For more information, see the cross-chain messages anatomy page.

Block safety levels

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 interop, the traditional safe level (opens in a new tab) of 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 C, 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.

Next steps

• Watch this video that gives an overview of OP Stack interoperability (opens in a new tab).
• Learn more about the predeploys that have been added to the OP Stack to enable interoperability.
• Use Supersim, a local dev environment that simulates interop for testing applications against a local version of the Superchain.
• For more info about how OP Stack interoperability works under the hood, check out the specs (opens in a new tab).