celestiaorg
EPIC: Add Forced Inclusion Mechanism from the DA layer
Only relevant for single sequencer implementation
To give Rollkit the unstoppable property, better liveness, censorship resistance, and provide a way to get around a centralized sequencer going down, and be considered a "stage 1" L2 (see L2 Beat framework), we can add a forced inclusion mechanism where the chain's fork choice rule is modified to follow this simple scheme:
The canonical state of the chain is always deterministically derived by looking at the DA layer where two types of txs can exist:
- batches of txs posted by the sequencer
- direct txs (not posted by the sequencer)
The centralized sequencer must keep track of the direct txs posted to the DA layer, and include the direct txs in a produced rollup block. In the corresponding rollup block header, it must include a reference to the "origin" DA layer block. All direct txs posted on that DA layer block must be included in a rollup block at that point in time.
To prevent the sequencer from referencing the same DA layer block again and again in order to prevent forced inclusion txs in subsequent DA layer blocks, each rollup block should include or check the DA layer block’s timestamp for consistency. Typically, each new rollup block has a timestamp that moves forward in real time. If the L2 block’s timestamp becomes significantly larger than the L1 block it claims to derive from, the block becomes invalid per the protocol rules (there’s should be a maximum allowed difference in time with the DA layer).
In order to give the centralized sequencer enough time to post its batches, there can be a configurable delay in L1 block heights passed after which the sequencer is considered down, and only the direct txs from the DA layer are used to deterministically produce blocks.
Once the sequencer comes back online, it’ll have to start proposing new blocks on top of the canonical chain tip as it exists.
Each rollup block also includes or checks an L1 block’s timestamp for consistency. If the L2 block’s timestamp becomes significantly larger than the L1 block it claims to derive from, the block becomes invalid per the protocol rules (there’s a maximum allowed difference or direct equality constraints, depending on the exact chain config).
Could we generalize this by thinking about it as a fall back sequencing scheme? Which is essentially based sequencing?
There is the reliability piece of the centralized sequencer potential downtime, but also there is the censorship piece too correct?
So wouldn't node always want the option to be able to post directly?
I don't think this changes the implementation necessarily, just that it would apply to all sequencing schemes but based, since that would just be duplicate.
This seems similar to OP stack's forced transaction.
The corresponding delay for avoiding reorg while the sequencer is up would be in the order of ~12 hrs.
The sequencing window is a rolling 12-hour delay from when an L1 block is first known. This design allows the sequencer a grace period to come back online without causing L2 chain reorganizations.
There's also a max time drift:
Max Time Drift: 30 minutes, the maximum delay for including a deposit transaction, relative to the L2 chain.
I am preparing an ADR to describe the implementation changes needed for the forced inclusion mechanism. The ADR will outline the required modifications to both the single sequencer node and full node components of Rollkit.
https://github.com/rollkit/rollkit/blob/main/specs/lazy-adr/adr-019-forced-inclusion-mechanism.md - Forced inclusion ADR
Implemented by https://github.com/evstack/ev-node/pull/2797. Will be live after https://github.com/evstack/ev-node/issues/2906
