op-node: supprt block finalization [bedrock]#3232
Conversation
|
|
This PR changes implementation code, but doesn't include a changeset. Did you forget to add one? |
d8290d2 to
ed7a802
Compare
|
Hey @protolambda! This PR has merge conflicts. Please fix them before continuing review. |
3c4c230 to
8a06afc
Compare
|
Hey @protolambda! This PR has merge conflicts. Please fix them before continuing review. |
8a06afc to
d8ff359
Compare
4fd1913 to
bffeb5b
Compare
|
Ready for review, but blocked by #3310 |
bffeb5b to
51c4442
Compare
|
Hey @protolambda! This PR has merge conflicts. Please fix them before continuing review. |
51c4442 to
93715b0
Compare
…or testutils fix (#3232)
Description
Update the Engine Queue to maintain a small buffer of L1<>L2 relation data: when a L2 safe block is produced, remember the L1 block the progress was at, this is the L1 block the L2 block was fully derived from.
Once this L1 block is finalized, we can finalize the L2 blocks that were fully derived from up to and including this point.
We only maintain a buffer of
4*32 + 1items, since finality can only change by reaching new finality over recent data of no more than 4 epochs old. Some obscure testnets have smaller epochs, but buffering a few blocks extra does not hurt.Per L1 block we only track the latest L2 block that was fully derived from it.
If the buffer is outdated or incomplete then it'll just repair itself as we rotate into new L1 blocks. Finalization cannot cause divergence, at worst it's a lagging finalization signal for
(4*32 + 1)*12/60 = 25.8minutes (and it only really updates every 6.4 minutes anyway). The extended more complex version of backfilling old finalization data is not worth it: that would require us to reset the pipeline even further back, to reproduce the L2 inclusion-data of the last 65 L1 blocks.This depends on #3291 to provide the
L2BlockRefByLabelRPC method.Metadata
Fix ENG-2312