You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The diagram below shows how these feeds update and how a consumer retrieves the status of the Arbitrum sequencer.
34
36
@@ -43,9 +45,9 @@ The diagram below shows how these feeds update and how a consumer retrieves the
43
45
44
46
If the Arbitrum network becomes unavailable, the `ArbitrumValidator` contract continues to send messages to the L2 network through the delayed inbox on L1. This message stays there until the sequencer is back up again. When the sequencer comes back online after downtime, it processes all transactions from the delayed inbox before it accepts new transactions. The message that signals when the sequencer is down will be processed before any new messages with transactions that require the sequencer to be operational.
45
47
46
-
## Optimism, BASE, Metis, and Scroll
48
+
## Optimism, BASE, Metis, Scroll, and zkSync
47
49
48
-
On Optimism, BASE, Metis, and Scroll, the sequencer's status is relayed from L1 to L2 where the consumer can retrieve it.
50
+
On Optimism, BASE, Metis, Scroll, and zkSync, the sequencer's status is relayed from L1 to L2 where the consumer can retrieve it.
@@ -69,7 +71,7 @@ On Optimism, BASE, Metis, and Scroll, the sequencer's status is relayed from L1
69
71
70
72
1. Consumers can then read from the `AggregatorProxy` contract, which fetches the latest round data from the `OptimismSequencerUptimeFeed` contract.
71
73
72
-
### Handling outages on Optimism, BASE, Metis, and Scroll
74
+
### Handling outages on Optimism, BASE, Metis, Scroll, and zkSync
73
75
74
76
If the sequencer is down, messages cannot be transmitted from L1 to L2 and **no L2 transactions are executed**. Instead, messages are enqueued in the `CanonicalTransactionChain` on L1 and only processed in the order they arrived later when the sequencer comes back up. As long as the message from the validator on L1 is already enqueued in the `CTC`, the flag on the sequencer uptime feed on L2 will be guaranteed to be flipped prior to any subsequent transactions. The transaction that flips the flag on the uptime feed will be executed before transactions that were enqueued after it. This is further explained in the diagrams below.
0 commit comments