SIMD-0366: Enforce DATA_COMPLETE_SHRED Placement only on Last Data Shreds in FEC Sets

[ksn6]

Summary

This SIMD enforces that the DATA_COMPLETE_SHRED flag can only be set on the final data shred within an FEC (Forward Error Correction) set. One key use-case for this SIMD: this restriction enables efficient detection of soon-to-be-introduced BlockComponents at shred ingestion time, providing performance improvements for critical consensus operations. The alternative to this SIMD would be to detect BlockComponents during replay, which would be substantially slower. One key example is UpdateParent detection in Alpenglow's fast leader handover; detection during replay would not be ideal, as malicious leaders could intentionally misplace DATA_COMPLETE_SHRED flags to force validators into expensive search operations, creating DoS attack vectors and delaying block repairs.

Motivation

Currently, the DATA_COMPLETE_SHRED flag can theoretically be set on any data shred within an FEC set, though in practice it marks FEC set boundaries. This ambiguity creates significant performance challenges:

1. Expensive BlockComponent Detection: Without guaranteed placement, detecting BlockComponents requires expensive searches across multiple shreds and FEC sets.

2. Performance Impact: alternative BlockComponent methods require either complex inference algorithms or expensive replay operations.

3. Security Vulnerabilities: Malicious leaders could intentionally misplace DATA_COMPLETE_SHRED flags to force validators into expensive search operations, creating DoS attack vectors; for certain proposed BlockComponents (specifically, UpdateParent), malicious leaders could delay block repairs for following leaders.

By enforcing DATA_COMPLETE_SHRED placement only on the last data shred in each FEC set, validators can efficiently detect BlockComponent boundaries during online shred ingestion.

[AshwinSekar]

I think it's easier to just drop the shred, we don't need to explicitly mark the block as dead - it will fail to replay anyway.

[ksn6]

True, although - wouldn't enforcing this condition allow us to skip a block with this specific type of bad shred faster?

[AshwinSekar]

Yeah that's fair, just harder to wire up in the implementation

[ksn6]

Closing this PR, whose contents are largely moving to #337.