Interoperability architecture

An 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. 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 blockchain 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 inteoperates 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.

Safety levels

Interop expands the scope of trust for unsafe blocks, blocks that are shared through the gossip protocol. To trust that an unsafe block is valid and is going to become safe and then finalized, you need to trust not only the sequencer that produces it, but also all the other sequencers that produce other blocks that are still unsafe, but that include initiating messages that are executed in that block.

However, this is only for unsafe blocks, and only if the sequencer allows messages from unsafe blocks to be processed. A block is only considered promotable to safe, and therefore ready to be written to L1, when all the blocks on which it depends are safe.

For example, in the image below, 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 is also unsafe.

Next steps

• Want to learn more? Read our guide on the anatomy of a cross-chain message or check out this interop design video walk-thru (opens in a new tab).
• Ready to get started? 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).