Skip to content

Add finalization configurability #18009

@sebastianst

Description

@sebastianst

When running L3s, the hard-coded finalization parameters at

// defaultFinalityLookback defines the amount of L1<>L2 relations to track for finalization purposes, one per L1 block.
//
// When L1 finalizes blocks, it finalizes finalityLookback blocks behind the L1 head.
// Non-finality may take longer, but when it does finalize again, it is within this range of the L1 head.
// Thus we only need to retain the L1<>L2 derivation relation data of this many L1 blocks.
//
// In the event of older finalization signals, misconfiguration, or insufficient L1<>L2 derivation relation data,
// then we may miss the opportunity to finalize more L2 blocks.
// This does not cause any divergence, it just causes lagging finalization status.
//
// The beacon chain on mainnet has 32 slots per epoch,
// and new finalization events happen at most 4 epochs behind the head.
// And then we add 1 to make pruning easier by leaving room for a new item without pruning the 32*4.
const defaultFinalityLookback = 4*32 + 1
// finalityDelay is the number of L1 blocks to traverse before trying to finalize L2 blocks again.
// We do not want to do this too often, since it requires fetching a L1 block by number, so no cache data.
const finalityDelay = 64

don't work well. L2s usually have a block time of 2s, so a sixth of Ethereum's target block time of 12s.

We could make those constants optionally configurable, or even better make the L1 block time optionally configurable and then adjust these constants accordingly, similar to how the finality loopback is already calculated differently for AltDA chains at

// calcFinalityLookback calculates the default finality lookback based on DA challenge window if altDA
// mode is activated or L1 finality lookback.
func calcFinalityLookback(cfg *rollup.Config) uint64 {
// in alt-da mode the longest finality lookback is a commitment is challenged on the last block of
// the challenge window in which case it will be both challenge + resolve window.
if cfg.AltDAEnabled() {
lkb := cfg.AltDAConfig.DAChallengeWindow + cfg.AltDAConfig.DAResolveWindow + 1
// in the case only if the altDA windows are longer than the default finality lookback
if lkb > defaultFinalityLookback {
return lkb
}
}
return defaultFinalityLookback
}

We could then also auto-detect at startup if a L1ChainID is known in the embedded superchain-registry and then load the block time automatically. This way, L3s using e.g. Base or OPM would just work out of the box without additional configuration.

In a next step we may even consider adding an optional L1BlockTime to the rollup config.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-op-nodeArea: op-nodeM-needs-triageMeta: this issue needs to be labelled

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions