|
| 1 | +This document explores how Polygon zkEVM deals with _reorganizations_, or simply _reorgs_, compared to Ethereum reorgs, and discusses the role the synchronizer plays in these reorgs. |
| 2 | + |
| 3 | +Among other tasks, the synchronizer is responsible for managing the reorg process. |
| 4 | + |
| 5 | +## L2 reorgs |
| 6 | + |
| 7 | +Consider a reorg of L2 batches. Suppose a sequencer, called _sequencer A_, has closed batch $\mathtt{724}$ and has not sequenced it yet. |
| 8 | + |
| 9 | +So the batch, denoted by $\mathtt{724^A}$, is part of the trusted state. And thus, the figure below depicts batch $\mathtt{724^A}$ in red. |
| 10 | + |
| 11 | + |
| 12 | + |
| 13 | +However, suppose that another sequencer, called _sequencer B_, closes and sequences a different batch $\mathtt{724}$. |
| 14 | + |
| 15 | +The batch, denoted by $\mathtt{724^B}$, is therefore part of the virtual state. The figure below depicts batch $\mathtt{724^B}$ in green. |
| 16 | + |
| 17 | + |
| 18 | + |
| 19 | +Therefore, to align with the current virtual state, sequencer A must re-synchronize its state from batch $\mathtt{724^B}$ onwards. |
| 20 | + |
| 21 | +To accomplish this, sequencers must always check sequenced transactions present in the L1, in case another sequencer has virtualized a different batch. |
| 22 | + |
| 23 | +In the zkEVM architecture, a component called the _synchronizer_ is responsible for checking events emitted in L1 when batches are sequenced. |
| 24 | + |
| 25 | +This way the sequencer can re-synchronize if necessary. |
| 26 | + |
| 27 | + |
| 28 | + |
| 29 | +In general, the synchronizer checks Layer 1 for instances of sequenced batches. If two or more sequencers, $\mathtt{A}$, $\mathtt{B}$, $\mathtt{C}$, $\mathtt{ \dots }$, have closed different $\mathtt{X}$-th batches, |
| 30 | + |
| 31 | +$$ |
| 32 | +\mathtt{batch\ X^A_i},\ \mathtt{batch\ X^B_i},\ \mathtt{batch\ X^C_i},\ \dots |
| 33 | +$$ |
| 34 | + |
| 35 | +and some of these $\mathtt{X}$-th batches have been virtualized and some consolidated, then the synchronizer must notify, |
| 36 | + |
| 37 | +- The sequencers whose batches are 'un-virtualized', and |
| 38 | +- The sequencers whose batches are 'un-consolidated', |
| 39 | + |
| 40 | +of the need to reorg. |
| 41 | + |
| 42 | +And, as in the above scenario of sequencer A and B, the synchronizer alerts sequencer A of the need to reorg. |
| 43 | + |
| 44 | +!!! info |
| 45 | + |
| 46 | + Currently, reorgs do not occur in the zkEVM system because a single sequencer is implemented, the _trusted sequencer_. |
| 47 | + |
| 48 | +The possibility of L2 reorgs arises only in the event of L1 reorgs. |
| 49 | + |
| 50 | +There’s a slight chance for a reorg occurrence in the event of [_forced batches_](../protocol/malfunction-resistance/sequencer-resistance.md), where a user is sequencing a batch. |
| 51 | + |
| 52 | +However, the design of forced batches is specifically crafted to mitigate such scenarios. |
| 53 | + |
| 54 | +## L1 reorgs |
| 55 | + |
| 56 | +L1 reorgs happen if there is a reorg in Ethereum itself. |
| 57 | + |
| 58 | +In general, L1 reorgs should never happen because once a state is consolidated, then users have the guarantee that the transactions are finalized. |
| 59 | + |
| 60 | +L1 reorgs are far more critical, since it might be the case that the sequencer has to re-synchronize already virtualized or consolidated batches. |
| 61 | + |
| 62 | +A reorg in L1 requires a change of the state. |
| 63 | + |
| 64 | +The figure below, depicts a reorg scenario where two batches are in the virtual state and one batch is in the consolidated state. |
| 65 | + |
| 66 | + |
| 67 | + |
| 68 | +The synchronizer is responsible for identifying such scenarios and informing the sequencer to perform the appropriate reorg. |
| 69 | + |
| 70 | +## Synchronizer |
| 71 | + |
| 72 | +Although the synchronizer is essential for performing reorgs, it is generally needed for detecting and recording any relevant event from L1 (not just reorgs) in the node’s `StateDB`. |
0 commit comments