Design discussion: reorgs and sync triggers on unsafe (p2p) L2 blocks

[protolambda]

When a block is distributed by the sequencer via p2p then it can trigger a reorg or sync in the execution engine.

Some quick block validation / heuristics may be applied to filter the L2 block itself (to avoid replaying attacks etc. by other p2p nodes) based on block number and time, but the sequencer itself still has the power to create a block that creates a deeper reorg or sync.

Ultimately that reorg is temporary and can be recovered from by reorging back to what L1 says is canonical (if different at all), but we should protect users from unnecessary reorg/sync work to avoid any possible downtime.

[norswap]

Should we just only accept p2p blocks that extend what we currently hold to be the canonical L2 chain (derived from L1)?

In that case, the issue arises only when the sequencer sees an L1 reorg first, reorgs and creates a new L2 block on top of the reorg, and that block reaches a validator that has not yet reorged. In that case, we'd drop the block, but then we'd be missing it later, when we finally reorg L2 following L1.

Some possible solutions:

• cache the rejected p2p blocks in some way (e.g. index them by height, or create a DAG that links blocks to their possible descendants)
• let the validators query the network for p2p blocks later