SIMD-0337: Markers for Alpenglow Fast Leader Handover

[ksn6]

We propose augmenting BlockMarkerV1, introduced in SIMD-0307, to include BlockHeader and UpdateParent variants. BlockHeader, placed at the beginning of a block, indicates the parent of the block. UpdateParent signals that the intended parent is different from what was initially indicated, paving the way for Fast Leader Handover support in Alpenglow (section 2.7 of https://www.anza.xyz/alpenglow-1-1).

Fast Leader Handover will minimize the synchronization delay between consecutive leaders, increasing throughput.

This SIMD purely introduces the types required for Fast Leader Handover - the algorithmic details of Fast Leader Handover itself are outlined in SIMD-0326.

NOTE: Fast Leader Handover may also be referred to as "optimistic block production."

[rogerANZA]

Can we please not call it ParentReadyUpdate? ParentReady is an internal event, so it might be confusing to use the same name here. We just communicate the parent again... so the same as the regular parent announcement in the first slice? Also, why blockmarker?

[ksn6]

We just communicate the parent again... so the same as the regular parent announcement in the first slice?

Right now, the initial parent specification for a block is disseminated in the first shred of a block. In contrast, we will be using the recently introduced BlockComponent type to disseminate the special marker required for a parent switch in optimistic block packing. In a separate SIMD, post-Alpenglow launch, we'll eventually disseminate the initial block parent via a BlockComponent type as well.

This being said, I'm strongly in favor of having separate marker types for (1) the initial parent and (2) the parent switch for optimistic block packing, despite the high likelihood of these two types essentially doing the same thing.

This is because maintaining code is far easier (e.g., we can easily upgrade each type separately) + reading code is much easier and less error-prone.

Can we please not call it ParentReadyUpdate? ParentReady is an internal event, so it might be confusing to use the same name here.

How about UpdateParent?

Also, why _block_marker?

What do you mean?

[rogerANZA]

I was only worried about language. UpdateParent I like.

nit:

first shred of a block

first slice?

[kobi-lizard]

I think we have to change how the parent is initially indicated for correctness. I mean before Alpenglow.

[ksn6]

I think we have to change how the parent is initially indicated for correctness. I mean before Alpenglow.

This doesn't seem necessary for correctness. Agreed that the current design isn't optimal, though we can look into changing this after Alpenglow launches.

[rogerANZA]

why is it called "Alpenglow Optimistic Block Packing". To me this sounds a bit like greedily pack Txs into a block. something like "Alpenglow Fast Leader Handover" would make more sense.

[rogerANZA]

maybe add a reference to the section 2.7 in the whitepaper in the SIMD?

[ksn6]

why is it called "Alpenglow Optimistic Block Packing". To me this sounds a bit like greedily pack Txs into a block. something like "Alpenglow Fast Leader Handover" would make more sense.

it's because the next leader is optimistically packing a block, in the hopes that ParentReady doesn't switch to an earlier parent; "optimistic" != "optimal" which is what greedy typically refers to in the context of approximation algorithms for packing

that being said - don't feel too strongly about this; let me know if you'd really like to change this

maybe add a reference to the section 2.7 in the whitepaper in the SIMD?

we make the reference to the paper here in the SIMD:

https://github.com/solana-foundation/solana-improvement-documents/pull/337/files#diff-631937531eeb51a129767f8899e4398615b51d0c411e73c05885dcd190fea4e0R38-R40

[rogerANZA]

why is it called "Alpenglow Optimistic Block Packing". To me this sounds a bit like greedily pack Txs into a block. something like "Alpenglow Fast Leader Handover" would make more sense.

it's because the next leader is optimistically packing a block, in the hopes that ParentReady doesn't switch to an earlier parent; "optimistic" != "optimal" which is what greedy typically refers to in the context of approximation algorithms for packing

Mh. I probably would call it "Alpenglow Fast [Leader] Handover". Packing (e.g., bin packing) means something very different in CS and Math. And since since packing a block actually makes a lot of sense even for Solana, it's just very misleading in this context.

that being said - don't feel too strongly about this; let me know if you'd really like to change this

Yes, I would. Otherwise we have another thing where the naming is not optimal in the future.

[bw-solana]

why is it called "Alpenglow Optimistic Block Packing". To me this sounds a bit like greedily pack Txs into a block. something like "Alpenglow Fast Leader Handover" would make more sense.

it's because the next leader is optimistically packing a block, in the hopes that ParentReady doesn't switch to an earlier parent; "optimistic" != "optimal" which is what greedy typically refers to in the context of approximation algorithms for packing

Mh. I probably would call it "Alpenglow Fast [Leader] Handover". Packing (e.g., bin packing) means something very different in CS and Math. And since since packing a block actually makes a lot of sense even for Solana, it's just very misleading in this context.

that being said - don't feel too strongly about this; let me know if you'd really like to change this

Yes, I would. Otherwise we have another thing where the naming is not optimal in the future.

Another alternative: "Alpenglow Optimistic Parent Selection" ?

We're being optimistic that we know the right parent block to build off of.

Agree that "Optimistic Block Packing" could easily confuse a casual reader.

Edit: Just noticed title was already changed (weeks ago, ha!). I'm fine with it as is

[rogerANZA]

Another alternative: "Alpenglow Optimistic Parent Selection" ?

Also good. I would still say that handover is a bit more explicit since this problem only appears during a leader handover.

[lidatong]

sorry for the delay -- lgtm seems my questions were already addressed by others in PR comments

[bw-solana]

Holding off on approving from Anza side.

We've discussed potential issues w/ observing the parent switch in replay execution that are triggering new ideas on how to communicate this information

[kobi-lizard]

My demands have been satisfied and I support the current form of this SIMD 🐸

[ksn6]

Holding off on approving from Anza side.

We've discussed potential issues w/ observing the parent switch in replay execution that are triggering new ideas on how to communicate this information

My demands have been satisfied and I support the current form of this SIMD 🐸

For more context, a few folks came up with a scenario that leads to liveness issues if we are only able to detect UpdateParent messages during replay.

To address this, we enable UpdateParent detection on shred ingest as discussed in the "DATA_COMPLETE_SHRED Placement Rules" section.

[bw-solana]

Approving from Anza side

[Benhawkins18]

I see the right approvers from Anza and Jump