chore(pipeline): shorten last block in checkpoint build duration to allow checkpoint construction#21591
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
3850b5a to
94d5685
Compare
e636f49 to
3a1ba92
Compare
3a1ba92 to
6b3361c
Compare
94d5685 to
5c7471a
Compare
6b3361c to
94cdd36
Compare
5c7471a to
2e68fe2
Compare
94cdd36 to
6da9164
Compare
2e68fe2 to
191d1bb
Compare
6da9164 to
dea8538
Compare
191d1bb to
63f38ed
Compare
checkpoint build time Add a new optional `lastBlockDurationMs` config field to SequencerConfig. When set and less than blockDurationMs, the last block in a multi-block slot gets a shorter window, causing the checkpoint to broadcast earlier. This gives the next proposer more usable early-start time.
63f38ed to
df9a22b
Compare
dea8538 to
3009e59
Compare
spalladino
left a comment
There was a problem hiding this comment.
Reading the PR I'm not sure I understand the rationale for this. Why do we need to shorten specifically the last block? If we want to allow more time at the end of the slot for assembling the checkpoint, we can bump the CHECKPOINT_ASSEMBLE_TIME, and reduce the time for all blocks proportionally (or the number of blocks for that matter), so we don't have an edge case when handling the very last block.
| const pendingCheckpoint = await this.getPendingCheckpoint(); | ||
| const pendingCheckpointNumber = | ||
| pendingCheckpoint?.checkpointNumber ?? CheckpointNumber(INITIAL_CHECKPOINT_NUMBER - 1); |
There was a problem hiding this comment.
Why this change? Do we need to deserialize an entire checkpoint (which iirc includes its blocks and its tx effects) just to get its number?
| enableProposerPipelining: true, // <- yehaw | ||
| mockGossipSubNetwork: true, | ||
| mockGossipSubNetworkLatency: 500, // 200 ms delay in message prop - adverse network conditions | ||
| mockGossipSubNetworkLatency: 200, // 200 ms delay in message prop - adverse network conditions |
| blockDurationMs: 5800, | ||
| lastBlockDurationMs: 3000, | ||
| maxTxsPerCheckpoint: 24, |
There was a problem hiding this comment.
I'd appreciate a comment on why these values, 5800 looks odd

Overview
Small compromise to smoothen checkpoint construction, the last block should really be shorter. Palla's pr's with the multiplier also address this, however
I think that realistically we are only concerned with the last block being shorter.