-
Couldn't load subscription status.
- Fork 3.8k
Description
When running L3s, the hard-coded finalization parameters at
optimism/op-node/rollup/finality/finalizer.go
Lines 18 to 35 in cb54822
| // 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
optimism/op-node/rollup/finality/finalizer.go
Lines 37 to 50 in cb54822
| // 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.