|
| 1 | +--- |
| 2 | +title: Interoperability Explainer |
| 3 | +lang: en-US |
| 4 | +description: Learn the basics of interoperability on the OP Stack. |
| 5 | +--- |
| 6 | + |
| 7 | +import { Callout } from 'nextra/components' |
| 8 | +import Image from 'next/image' |
| 9 | + |
| 10 | +# Interoperability Explainer |
| 11 | + |
| 12 | +Interoperability is the ability for a blockchain to securely read the state of another blockchain. |
| 13 | +Native OP Stack interoperability provides the ability to read messages and transfer assets across the Superchain (without having to go through L1) via secure message passing. This results in the following benefits: |
| 14 | +* fungible and portable assets and liquidity |
| 15 | +* lower fees and lower latency |
| 16 | +* less fragmentation across the Superchain |
| 17 | +* improved user experience for developers on the Superchain |
| 18 | + |
| 19 | +## Secure Message Passing |
| 20 | +Native interop includes both the protocol layer message passing and the Superchain ERC20 token specification. |
| 21 | + |
| 22 | +* **Message passing protocol:** the initial + finalizing/executing [message](https://specs.optimism.io/interop/messaging.html) that fire events to be consumed by the chains in the [dependency set](https://specs.optimism.io/interop/dependency-set.html) |
| 23 | +* **SupERC20 token specification**: the [SuperchainERC20](https://specs.optimism.io/interop/token-bridging.html) turns message passing into asset transfer between chains in the interop set |
| 24 | + |
| 25 | +This means ETH and ERC-20s can seamlessly and securely move across L2s, and intent-based protocols (i.e., bridges) can build better experiences on top of the message passing protocol. |
| 26 | + |
| 27 | +## Low Latency |
| 28 | +Interoperability allows for horizontally scalable blockchains, a key feature of the Superchain. With native interop, latency can be low (~2 seconds) by optimistically accepting cross-chain messages. |
| 29 | +The fork choice rule enforces eventual consistency, meaning that if an invalid cross-chain message is accepted, it will be reorganized out eventually. |
| 30 | +The fault proof guarantees that all of the cross-chain messages are accounted for from the perspective of handling withdrawals through the bridge to L1. |
| 31 | + |
| 32 | +## Permissionless Chain Set |
| 33 | +It is permissionless to define a dependency on a chain, so chain operators will be able to choose which chains their chains depend on, and it is not a requirement that chains are in each other's dependency set. |
| 34 | +Chain operators can add or remove chains from the dependency set through the `SystemConfig`. For example, the dependency set for OP Mainnet is managed by Optimism Governance. |
| 35 | + |
| 36 | +However, since the nature of defining a dependency is one way, it is impossible for a chain to know of all of the other chains that depend on it. |
| 37 | + |
| 38 | +## Considerations |
| 39 | +Chain operators will need to run additional infrastructure to be part of the interoperable set. |
| 40 | +* The Superchain-backend service, `op-supervisor`, will be a requirement for running an OP Stack chain that has interop enabled. |
| 41 | +`op-supervisor` is responsible for validating all cross-chain messages and will need to have an RPC configured for each chain in the dependency set. |
| 42 | +* In the future, to reduce infrastructure costs, `op-supervisor` will rely on the P2P network and cryptographic schemes for validating cross-chain messages. |
| 43 | + |
| 44 | +<Callout type="info"> |
| 45 | +For additional considerations, join the [Interop discussion](https://github.com/ethereum-optimism/specs/discussions/128) in our specs repo. |
| 46 | +</Callout> |
| 47 | + |
| 48 | +## Next Steps |
| 49 | +* Want to learn more? Read our guide on the anatomy of a [cross-chain message](cross-chain-message) or check out this [interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). |
| 50 | +* Ready to get started? Use [SuperSim](https://github.com/ethereum-optimism/supersim), a local dev environment that simulates interop for testing applications against a local version of the Superchain. |
| 51 | +* For more info about how OP Stack interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). |
| 52 | + |
| 53 | +## FAQs |
| 54 | + |
| 55 | +### What is the latency/security tradeoff? |
| 56 | +If a sequencer does not want to trust another sequencer at all, they can choose to only accept executing messages where the initiating message has been finalized with L1 levels of security. This demonstrates the difference in latency vs speed. The L2 data must be submitted to L1 and then the L1 block containing the transaction with the L2 data must be finalized. It takes about 15 minutes for an L1 block to finalize, and higher throughput OP Stack chains like Base and OP Mainnet submit a batch about every 5 minutes. This means that it could take about 20 minutes for an L2 transaction to be considered final and be able to be trustlessly consumed by another chain. At lower latencies, the sequencer accepting the executing message takes on some amount of equivocation risk. It could be possible to build a bonding system to add economic security to prevent equivocation, but that is not in the scope of the first release. |
| 57 | + |
| 58 | +See this [dune dashboard](https://dune.com/oplabspbc/op-stack-chains-l1-activity#submission-frequency) to see how often OP Stack chains submit batches. |
| 59 | + |
| 60 | +<br /> |
| 61 | + |
| 62 | +<Image src="/img/op-stack/protocol/safe-unsafe.png" alt="Safe and Unsafe Security Diagram" width={700} height={500} /> |
| 63 | + |
| 64 | +### What is stopping a sequencer from censoring a cross-chain message? |
| 65 | +There is nothing stopping a sequencer from censoring a transaction when it is sent directly to the sequencer. This does not mean the network has no censorship resistance, users can always send a deposit transaction for censorship resistance as strong as L1 guarantees. The tradeoff here is the latency, instead of being confirmed in ~2 seconds, the transaction can be confirmed at the rate of L1 block production. It may be possible to adopt something like [EIP-7547](https://eips.ethereum.org/EIPS/eip-7547) in the future to enable low latency censorship resistance. |
| 66 | + |
| 67 | +### Are callback style transactions possible? |
| 68 | +If two blocks are being built at the same time with shared knowledge of their contents, it is possible to build blocks where a transaction calls to another chain, does compute and then a transaction calls back with the results. This requires no protocol level changes, it just requires more sophisticated block builder infrastructure. |
| 69 | + |
| 70 | +### What is stopping a shared sequencer from including just the executing message and not the initiating message? |
| 71 | +The protocol enforces the fact that all executing messages are valid. It does this by reorganizing out executing messages that have invalid initiating messages. Running software that does not enforce this would be non-standard behavior and would leave yourself at risk of accepting an invalid executing message and therefore running on a forked chain. |
| 72 | + |
| 73 | +### What is the trust/verification model? Do sequencers that opt into this interop system have to trust each other fully? |
| 74 | +Sequencers only have to trust each other, if they are accepting executing messages where the initiating message is unsafe. This is because the sequencer's ability to equivocate on unsafe data, i.e., batch submit something different from what they gossip over the p2p network. Once data is submitted to L1, it is considered final relative to the L2 and therefore there is no longer an equivocation risk. |
| 75 | + |
| 76 | +### Is interop different between chains with non-fungible blockspace? |
| 77 | +Chains that have non-fungible blockspace are chains that have different features - it could be that they use Plasma for data availability, a custom gas paying token or have a large execution gas limit. As long as the chain can be fault proven, it can work with native interoperability. At the application layer, it is important for chains to have legibility into the type of chain that the message originated from. This ensures that applications do not accept messages from chains they consider not secure enough. See this [discussion](https://github.com/ethereum-optimism/specs/issues/121) for additional thoughts. |
| 78 | + |
| 79 | +When it comes to chains that have different gas limits that are interoperable, it creates a set of transactions that can execute on one chain but not the other. This happens when the transaction consumes more than the gas limit of the smaller chain but less than of the bigger chain. At 2024 usages levels, these sorts of transactions are very rare. In the future, it may be the case that these transactions become more common, it will be up to the chain operators to ensure quality of service for their users. |
0 commit comments