Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -133,7 +133,7 @@ You can get some Sepolia ETH from [this faucet](https://sepoliafaucet.com).

## Deposit ETH

Now that you have some ETH on L1 you can deposit that ETH into the `L1StandardBridge` contract. You'll then receive the same number of ETH on L2 in return.
Now that you have some ETH on L1 you can deposit that ETH into the `OptimismPortalProxy` contract. You'll then receive the same number of ETH on L2 in return.

<Tabs items={['depositETH', 'Full Code']}>
<Tabs.Tab>
Expand Down Expand Up @@ -167,7 +167,7 @@ Now that you have some ETH on L1 you can deposit that ETH into the `L1StandardBr

Wait for the L1 transaction to be processed and log the receipt.

```js file=<rootDir>/public/tutorials/cross-dom-bridge-eth.js#L52-L53 hash=0de1fe6dd17f753ab80d356b38d9ca41
```js file=<rootDir>/public/tutorials/cross-dom-bridge-eth.js#L52-L53 hash=bccea143ce3571de154531c40e9a0d04
```

{<h3>Extract the L2 transaction hash</h3>}
Expand All @@ -188,7 +188,7 @@ Now that you have some ETH on L1 you can deposit that ETH into the `L1StandardBr
</Tabs.Tab>

<Tabs.Tab>
```js file=<rootDir>/public/tutorials/cross-dom-bridge-eth.js#L3-L63 hash=b7d72a54dcdbb9b89c6874e2862fde00
```js file=<rootDir>/public/tutorials/cross-dom-bridge-eth.js#L3-L63 hash=1198e2379e95a0e6c72c03692f10e9ee
```
</Tabs.Tab>
</Tabs>
Expand Down
5 changes: 5 additions & 0 deletions pages/stack/interop.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -27,4 +27,9 @@ Documentation covering Cross Chain Message, Explainer, Message Passing, Op Super
<Card title="Cross domain assets" href="/stack/interop/assets" />

<Card title="Interop devnet" href="/stack/interop/devnet" />

<Card title="Interoperability predeploys" href="/stack/interop/predeploy" />

<Card title="Cross-chain security" href="/stack/interop/security" />

</Cards>
69 changes: 32 additions & 37 deletions pages/stack/interop/explainer.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -11,27 +11,27 @@ import { InteropCallout } from '@/components/WipCallout'

<InteropCallout />

# Interoperability explainer
# Interoperability explainer

## Why do we need interoperability?

It is easy for a blockchain to be certain about information it generates itself.
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](https://chain.link/education-hub/oracle-problem)).
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.
* 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*](/stack/interop/op-supervisor).
Interoperability among OP Stack chains is enabled via a new service called [*OP Supervisor*](/stack/interop/op-supervisor).
Every node operator is expected to run this service in addition to the [rollup node](/builders/node-operators/architecture#rollup-node) and [execution client](/builders/node-operators/architecture#execution-client).

```mermaid
Expand Down Expand Up @@ -145,28 +145,26 @@ Interop expands the scope of trust for unsafe blocks (blocks that are shared thr
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.

<details>

<summary>What is the transitive dependency set?</summary>

The transitive dependency set of a blockchain is all the chains on which it depends, and all the chains that depend on them, and so on.
For example, in the illustration above, the dependency set of chain A is just chain B.
However, the *transitive* dependency set includes chain B, the chains that depend on it (C and D) and the chains that depend on them (E).
If there was a chain that depended on E, that chain would be part of the transitive dependency set too.

```mermaid

flowchart LR
A[Chain A] <--> B[Chain B]
B <--> C[Chain C]
B <--> D[Chain D]
D <--> E[Chain E]
F[Chain F] <--> G[Chain G]
```

For example, there could be a block in chain D that depends on an initiating message in chain E>
If the block with that initiating message is still unsafe (not written to L1), then the block in chain D is also usafe, even if it has been written to L1.
As a result, a block in chain B that depends on the chain D block can also be unsafe, as can a block in chain A that depends on the block in chain B.

<summary>What is the transitive dependency set?</summary>

The transitive dependency set of a blockchain is all the chains on which it depends, and all the chains that depend on them, and so on.
For example, in the illustration above, the dependency set of chain A is just chain B.
However, the *transitive* dependency set includes chain B, the chains that depend on it (C and D) and the chains that depend on them (E).
If there was a chain that depended on E, that chain would be part of the transitive dependency set too.

```mermaid

flowchart LR
A[Chain A] <--> B[Chain B]
B <--> C[Chain C]
B <--> D[Chain D]
D <--> E[Chain E]
F[Chain F] <--> G[Chain G]
```

For example, there could be a block in chain D that depends on an initiating message in chain E>
If the block with that initiating message is still unsafe (not written to L1), then the block in chain D is also usafe, even if it has been written to L1.
As a result, a block in chain B that depends on the chain D block can also be unsafe, as can a block in chain A that depends on the block in chain B.
</details>

Notably this trust assumption is only for *unsafe* blocks, and *only* if the sequencer allows messages from unsafe blocks to be processed.
Expand Down Expand Up @@ -202,8 +200,8 @@ To move an asset from chain E to chain B, it is necessary to move the asset from

### 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.
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.

```mermaid
Expand All @@ -213,10 +211,8 @@ flowchart LR
A <--> C <--> E <--> B <--> D <--> A
```


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](https://gov.optimism.io/t/season-6-standard-rollup-charter-ratification/8135#p-36758-governing-policies-11), 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.


{/*
## Interop assets

Expand All @@ -229,8 +225,7 @@ This means ETH and ERC-20s can seamlessly and securely move across L2s, and inte
*/}

## Next steps
* 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).
* Ready to get started? Use [Supersim](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](https://specs.optimism.io/interop/overview.html).


* 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).
* Ready to get started? Use [Supersim](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](https://specs.optimism.io/interop/overview.html).
20 changes: 10 additions & 10 deletions pages/stack/interop/predeploy.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ import { InteropCallout } from '@/components/WipCallout'

# Interoperability predeploys

The following predeploys have been added to enable interoperability.
The following predeploys have been added to enable interoperability.
*Predeployed smart contracts* exist at predetermined addresses, coming from the genesis state.
They're similar to [precompiles](https://www.evm.codes/precompiled) but run directly in the EVM instead of running as native code.

Expand All @@ -22,19 +22,19 @@ They're similar to [precompiles](https://www.evm.codes/precompiled) but run dire
The `CrossL2Inbox` is the system predeploy for cross chain messaging.
Anyone can trigger the execution or validation of cross chain messages, on behalf of any user.

- **Address:** `0x4200000000000000000000000000000000000022`
- **Specs:** [`CrossL2Inbox`](https://specs.optimism.io/interop/predeploys.html#crossl2inbox)
- **Source code:** [`CrossL2Inbox`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol)
* **Address:** `0x4200000000000000000000000000000000000022`
* **Specs:** [`CrossL2Inbox`](https://specs.optimism.io/interop/predeploys.html#crossl2inbox)
* **Source code:** [`CrossL2Inbox`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol)

## L2ToL2CrossDomainMessenger

The `L2ToL2CrossDomainMessenger` is a higher level abstraction on top of the `CrossL2Inbox` that provides general message passing.
It's utilized for secure ERC20 token transfers between L2 chains.
Messages sent through the `L2ToL2CrossDomainMessenger` on the source chain receive both replay protection and domain binding (the executing transaction can only be valid on a single chain).

- **Address:** `0x4200000000000000000000000000000000000023`
- **Specs:** [`L2ToL2CrossDomainMessenger`](https://specs.optimism.io/interop/predeploys.html#l2tol2crossdomainmessenger)
- **Source code:** [`L2ToL2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol)
* **Address:** `0x4200000000000000000000000000000000000023`
* **Specs:** [`L2ToL2CrossDomainMessenger`](https://specs.optimism.io/interop/predeploys.html#l2tol2crossdomainmessenger)
* **Source code:** [`L2ToL2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol)

{/*
## OptimismSuperchainERC20Factory
Expand All @@ -60,6 +60,6 @@ This contract is the `Beacon` part, which provides the implementation address fo

The `SuperchainTokenBridge` is an abstraction on top of the `L2toL2CrossDomainMessenger` that facilitates token bridging using interop. It has mint and burn rights over `OptimismSuperchainERC20` tokens, as described in the [token bridging spec](https://specs.optimism.io/interop/token-bridging.html).

- **Address:** `0x4200000000000000000000000000000000000028`
- **Specs:** [`SuperchainTokenBridge`](https://specs.optimism.io/interop/predeploys.html#superchainerc20bridge)
- **Source code:** [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol)
* **Address:** `0x4200000000000000000000000000000000000028`
* **Specs:** [`SuperchainTokenBridge`](https://specs.optimism.io/interop/predeploys.html#superchainerc20bridge)
* **Source code:** [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol)
Loading