Skip to main content
Superchain interop is in active development. Some features may be experimental.
A chain reorganization, or “reorg”, happens when validators disagree on the most accurate version of the blockchain. If not handled correctly, reorgs in a cross-chain context could result in a double-spend problem. The most frequent solution to mitigate the double-spend problem is to wait for Ethereum finality; however, that solution results in high latency cross-chain communication and a poor user experience. Most solutions to mitigate the double-spend problem rely on L1 finality. However, that solution results in high latency and poor user experience. To mitigate the double-spend problem while delivering a low-latency cross-chain experience, Superchain interop uses block safety levels. This means users can transfer assets across chains in the Superchain with 1-block latency, and should a reorg happen, either both the source and destination transactions would remain, or both of them would revert. In every case, there is no window of opportunity to double spend.

​
Block safety levels

In the diagram above, solid arrows are the derivation of a block from the previous block in the chain. Dotted arrows go from the block with the initiating message (the source) to the block with the executing message (the destination). Blocks can either be finalized (grey), cross-safe (green), or unsafe (red). Blockchain A has only written block A100 to the blockchain. As a result, block A101 is unsafe, and so are all the blocks that depend on it, directly (A102 and B302) or indirectly (A103 and B303). Blocks B302 and B303 may be local-safe (if they are written to L1), but they cannot be cross-safe because they depend on a block that isn’t. If all goes well, eventually A101 will be written to L1, turn safe, and then the blocks that depend on it can become safe as well. The message between A101 and B302 can be an asset moving across the bridge. In that case, the initiating message (A101) burns n tokens on the source chain (A), and the executing message (B302) mints n tokens on the destination chain (B).

​
L1 reorg

In this case, an L1 block is replaced, and the new block either contains the same blob with chain data that was contained in the old block, or it doesn’t. If the new block contains the same blob, the change is meaningless from the L2 perspective. If the new block does not contain the same blob, then the sequencer on the chain will know it is missing and reposts it. So L1 reorgs are basically invisible to L2.

​
Equivocation

Sequencers inform the rest of the Superchain about a new block in two ways:
  • The gossip protocol, which is typically used as soon as the block is created. The problem is that the gossip protocol does not create a commitment.
  • Posting to L1, which typically happens a few minutes after the block is created. The reason is cost, it is a lot cheaper if compression and L1 posting are done in large batches, rather than for each individual block.
Equivocation happens when a sequencer publishes a block using the gossip protocol that is different from the one that eventually gets written to L1. In this case, the block that is written to L1 (let’s call it A’101) is the valid one, and that causes every dependent block to be recalculated. Note that a block can only depend directly on a block in a separate chain if the block includes an executing message that uses an initiating message from that block. So the change from A101 to A’101 cannot invalidate any existing safe blocks.

​
Invalid block

If a block is invalid, even if it is posted on L1, the canonical chain replaces it with a block that only includes the deposit transactions, those transactions posted to L1. This is functionally equivalent to equivocation, and dealt with the same way, so it can change unsafe blocks but only those blocks.

​
Next steps

⌘I