|
| 1 | +--- |
| 2 | +title: OP Supervisor |
| 3 | +lang: en-US |
| 4 | +description: Learn the basics of OP Supervisor. |
| 5 | +--- |
| 6 | + |
| 7 | +import { Callout, Tabs, Steps } from 'nextra/components' |
| 8 | + |
| 9 | +# OP Supervisor |
| 10 | + |
| 11 | +<Callout> |
| 12 | + Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. |
| 13 | +</Callout> |
| 14 | + |
| 15 | +OP Supervisor is a service that verifies cross-chain messages and manages interoperability between chains in the OP Stack. It serves as a hub where each `op-node` can index the data needed for cross-chain verification. Chain operators and teams running full nodes like RPC providers are expected to run this service. |
| 16 | +Some features and benefits include: |
| 17 | + |
| 18 | +* Enables secure cross-chain message passing on the Superchain |
| 19 | +* Provides a unified point for managing interoperability data |
| 20 | +* Supports multiple networks simultaneously |
| 21 | +* Offers potential for public endpoints to aid in node synchronization |
| 22 | + |
| 23 | +## How cross-chain message verification works |
| 24 | + |
| 25 | +OP Supervisor verifies messages between different chains in the OP Stack, reducing the risk of invalid or malicious cross-chain interactions. It centralizes the verification process, which reduces the complexity of operating individual nodes. |
| 26 | + |
| 27 | +* `op-geth`: queries `op-supervisor` during block-building to verify if a message is sufficiently safe to include. This process involves checking each executing message and potentially undoing transactions if conflicts or unknown states are encountered. |
| 28 | +* `op-node`: queries cross-chain safety information and coordinates safety updates between OP stack nodes and `op-supervisor`. It uses the API provided by `op-supervisor` to perform actions like: |
| 29 | + * Updating and retrieving various safety levels |
| 30 | + * Checking and returning the `cross-unsafe` head for a given chain |
| 31 | + * Attempting to promote a block to `cross-safe` status |
| 32 | + * Attempting to finalize an L2 block based on L1 finality |
| 33 | + |
| 34 | +## Log data indexing and management |
| 35 | + |
| 36 | +OP Supervisor acts as a hub for indexing data that every `op-node` needs to cross-verify with other chains, centralizing the process of managing interoperability data. Maintains the integrity of cross-chain interactions by tracking safety changes across the Superchain, ensuring consistent application of invalid dependency resolutions. |
| 37 | + |
| 38 | +`op-supervisor` indexes two types of cross-chain dependencies: |
| 39 | + |
| 40 | +* Interop messages (events): `op-supervisor` maintains an events-index per L2 chain, which determines message-dependencies to check if blocks are safe |
| 41 | +* L1 DA (data availability): `op-supervisor` tracks the L1 DA for L2 blocks and maintains a DA safety-index per L2 chain, which helps determine how to rewind L2 chains to resolve invalid dependencies |
| 42 | + |
| 43 | +## API for cross-chain safety |
| 44 | + |
| 45 | +OP Supervisor provides an interface for `op-node` to query cross-chain safety information and coordinate safety updates between OP stack nodes and `op-supervisor`. OP-Supervisor uses a global read API to determine **message safety** and **block safety,** utilizing both the events index and the safety index (See op-supervisor's [log data indexing](#log-data-indexing-and-management)). The API is designed to handle potential L1 reorgs that can affect the validity of cross-chain messages. |
| 46 | + |
| 47 | +Key API methods include: |
| 48 | + |
| 49 | +| Method | Description | |
| 50 | +| ----------------------------------------- | ------------------------------------------------------------------------------------- | |
| 51 | +| `UnsafeView` and `SafeView` | Returns the Local and Cross heads for their respective levels | |
| 52 | +| `DerivedFrom` | OP Nodes use to check the L1 source of the Supervisor (needed for Safe Head tracking) | |
| 53 | +| `UpdateLocalSafe` and `UpdateLocalUnsafe` | Tells the Supervisor when the Node's heads change | |
| 54 | +| `Finalized` | Returns the Finalized Head | |
| 55 | +| `UpdateFinalizedL1` | Signals to the Supervisor new finality signals | |
| 56 | +| `CheckMessage` | Checks logs in the DB directly in tests | |
| 57 | + |
| 58 | +For a full listing of API names, see the [`op-supervisor` client](https://github.com/ethereum-optimism/optimism/blob/develop/op-service/sources/supervisor_client.go). |
| 59 | + |
| 60 | +## RPC access to all chains |
| 61 | + |
| 62 | +OP Supervisor requires RPC access to all chains in the dependency set. This allows `op-supervisor` to verify cross-chain messages and sync data across multiple networks simultaneously, such as OP Mainnet and Base nodes using the same instance. |
| 63 | + |
| 64 | +Benefits: |
| 65 | + |
| 66 | +* Scalability: As the number of chains in the Superchain grows, `op-supervisor` can handle the increasing complexity of cross-chain interactions. |
| 67 | +* Improved reliability: It enables a more redundant setup, which is good for stability in the growing ecosystem. |
| 68 | + |
| 69 | +## Next steps |
| 70 | + |
| 71 | +* Want to learn more? Read our guide on the anatomy of a [cross-chain message](/stack/interop/cross-chain-message) or check out this [interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). |
| 72 | +* For more info about how OP Stack interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). |
0 commit comments