Adding ParentReadyUpdate BlockMarker for Optimistic Block Packing in Alpenglow

[ksn6]

Adding ParentReadyUpdate BlockMarker for Optimistic Block Packing in Alpenglow

Context

The Alpenglow consensus protocol introduces an optimistic block packing mechanism that allows leaders to begin constructing blocks before their parent blocks are fully finalized. This optimization significantly reduces block production latency by enabling parallel processing of block construction and parent finalization.

In Alpenglow's optimistic block packing, a leader slot can start producing a block on a tentative parent while the network is still finalizing the actual parent through the notarization process. When the ParentReady event occurs (indicating that all necessary skip certificates have been collected and a NotarizeFallback certificate exists for a parent), the leader may need to switch to a different parent block than initially assumed. This parent switching mechanism is critical for maintaining consensus integrity while achieving the performance benefits of optimistic packing.

Problem

When a leader's optimistic block packing results in a parent switch (Algorithm 3, Line 7 in the Alpenglow protocol), there needs to be a special marker disseminated within the block to signal this parent change. Currently, the block structure lacks a standardized way to include this critical metadata that indicates when ParentReady has triggered a switch to a new parent block.

Without this marker, downstream validators and block processors cannot properly track parent switches that occur during optimistic block packing, potentially leading to consensus issues or inability to properly validate the block's construction timeline. The marker needs to contain both the new parent slot and the new parent block ID to fully specify the parent switch event.

Solution

NOTE: for context, this solution makes use of the PR here: anza-xyz/alpenglow#364 as well as the SIMD here: #307.

We propose adding a new ParentReadyUpdate variant to the BlockMarkerV2 enum in the block component system. This leverages the extensible BlockMarker framework introduced in SIMD 307, which provides a versioned, variant-based approach to adding block-level metadata.

The implementation in entry/src/block_component.rs introduces:

1. VersionedParentReadyUpdate Structure

pub enum VersionedParentReadyUpdate {
    V1(ParentReadyUpdateV1),
    Current(ParentReadyUpdateV1),
}

pub struct ParentReadyUpdateV1 {
    pub new_parent_slot: Slot,
    pub new_parent_block_id: Hash,
}

2. BlockMarkerV2 Extension

pub enum BlockMarkerV2 {
    BlockFooter(VersionedBlockFooter),
    ParentReadyUpdate(VersionedParentReadyUpdate),  // New variant
}

3. Serialization Layout

The ParentReadyUpdateV1 serializes as:

• Parent Slot (8 bytes)
• Parent Block ID (32 bytes)

This design directly builds upon SIMD 307's foundational work, which established:

• The BlockMarker concept with a 64-bit flag indicator
• Version-based extensibility (16-bit version field)
• Variant-based discrimination (8-bit variant type)
• Length-prefixed data (16-bit length field)

The key design decisions from SIMD 307 that enable this extension are:

1. Forward Compatibility: Unknown variants can be safely skipped using the length field
2. Version Evolution: The versioned enum pattern allows future improvements to the ParentReadyUpdate structure
3. Atomic Metadata: Each BlockMarker variant is self-contained and independently parseable

By utilizing BlockMarkerV2 (version 2 of the BlockMarker format), we maintain backward compatibility while adding the new ParentReadyUpdate variant. Validators running older software can still process blocks with these markers by skipping unknown variants, while updated validators can properly interpret and validate parent switch events in optimistically packed blocks.

This solution provides a clean, extensible mechanism for tracking parent switches in Alpenglow's optimistic block packing algorithm, ensuring that the consensus protocol can efficiently reduce latency while maintaining full auditability of block construction decisions.