Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RIP-7789: Cross Rollup Contingent Transactions #40

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Prev Previous commit
Next Next commit
formatting
notbdu committed Oct 17, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
commit 84d8e79a41a4f01f72b0749da8a25ac8a8202ee4
16 changes: 14 additions & 2 deletions RIPS/rip-7777.md
Original file line number Diff line number Diff line change
@@ -33,6 +33,7 @@ In reality, every rollup block is anchored to a specific Ethereum block at a con
Depending on the L1 origin or L1 history that the L2 is derived from, the L2 block is technically produced sometime in the past as it’s generally the sum of both historical L1 and current L2 inputs.’’

Let’s use an analogy here. For those of you who are familiar with the Time Variance Authority in the Marvel Cinematic Universe (or any time travel enthusiasts), the canonical Ethereum chain could be considered the “sacred timeline” from which many alternate realities branch off.

![sacred timeline](../assets/rip-7777/sacred_timeline.png)

![ethereum forks](../assets/rip-7777/ethereum_forks.png)
@@ -54,6 +55,7 @@ In this scenario:
This means that depending on their L1 origins, different L2s might be operating with different views of the Ethereum chain. They are either "in the past" or “in the future” relative to one another depending on where they are anchored in the L1 history.

This will hold true if these L2s are following the same Ethereum fork, what will eventually become Ethereum’s sacred timeline. But in some cases the L2 block may be derived from an alternate reality that eventually gets pruned.

![reorg](../assets/rip-7777/reorg.png)

This mental model motivates a number of safety invariants for cross L2 communication that need to be enforced.
@@ -85,33 +87,42 @@ There are a few safety invariants that need to be enforced during cross L2 commu
### Future to past communication

Future to past communication is unsafe due to the following case where the L2 building off of future Ethereum history may be reorged while the L2 building off of past Ethereum history does not.

![reject future to past](../assets/rip-7777/reject_future_past.png)
![future to past reorg](../assets/rip-7777/future_reorg.png)

### Communicating across L1 histories

Communicating L2s must share the same L1 history for communication. Otherwise, we can end up with one L2 reorg’ing while the other L2 does not. Ensuring that both L2s are on the same history guarantees that both L2s reorg together or not at all.
![reject cross L1 history](../assets/rip-7777/reject_cross_history.png)

####
![reject cross L1 history](../assets/rip-7777/reject_cross_history.png)

### Contingent reorg

Once a contingency relationship has been established, a reorg of the originating L2 must also mean a reorg of the contingent L2. This ensures that all downstream dependencies in the contingency DAG also revert.

![contingent reorg](../assets/rip-7777/contingent_reorg.png)

### Contingency DAG in action

Let’s go over how the contingency DAG is created and how the contingencies can be enforced in the event of a reorg. In the example below, both Optimism and Base are building L2 blocks off of the same L1 history in L1’.

![dag1](../assets/rip-7777/dag_1.png)

We then establish a contingency link by updated Base with the knowledge of Optimism block number 1 which is contingent upon L1 history L1’. Since Base is also building off of L1’, the contingency check passes.

![dag2](../assets/rip-7777/dag_2.png)

Messages C1 and C2 are sent over this newly formed contingency link between Optimism and Base. These messages are contingent upon the contingency link being formed in the first place.

![dag3](../assets/rip-7777/dag_3.png)

In the case that Base is building its blocks off of a different L1 history, the contingency link fails to get created and no messages are sent. This enforces the safety invariant that communicating across L1 histories is not allowed.

![dag4](../assets/rip-7777/dag_4.png)

If there’s a reorg that causes both Optimism and Base to switch their L1 history from L1’ to L1’’, the contingency link also fails to get created and no messages are sent. This is correct behavior as the previous contingency link update no longer accurately represents the origin chain.

![dag5](../assets/rip-7777/dag_5.png)

### Example Pseudocode
@@ -199,6 +210,7 @@ function sendCrossL2ContigentTransaction(
```

In the diagrams and pseudocode above, we can see that we build a contingency DAG via links of L2 states and L1 histories. The contingency DAG itself then forms the basis upon which contingent transactions are created. The contingent transactions are dependent on the contingency links which are dependent on the shared L1 history of the communicating L2s.

![dependencies](../assets/rip-7777/dependencies.png)

## Call to action