Move consensus from blinded blocks to beacon block headers (Phase 2)

[olegshmuelov]

Change the proposer flow to decide only on beacon block headers during consensus. This is Phase 2 of the optimization strategy, following Phase 1's move to blinded blocks.

Motivation
As block sizes continue to grow (especially post-Fulu with up to 21 blobs), we need minimal consensus messages:

• Blinded blocks: Still contain full beacon block body (without execution payload details)
• Beacon block headers: Only ~1KB regardless of block/blob size
• Maximum network efficiency for consensus

Prerequisites

• Phase 1 completed: Consensus on blinded blocks (see Move consensus from full blocks to blinded blocks (Phase 1) #2543)
• Requires SSV protocol fork (breaking change)

Current Behavior (After Phase 1)

• Leader converts full block to blinded block
• Consensus decides on entire blinded block
• Leader submits full block after consensus

Required Changes (Phase 2)
1. Pre-Consensus Phase

• Leader receives block from beacon node
• Extract only the beacon block header for consensus
• Store the complete block data locally for post-consensus submission

2. Consensus Phase

• All operators decide on beacon block header only
• Message size: ~1KB (compared to hundreds of KB for blinded blocks)
• Header contains all critical fields: slot, proposer_index, parent_root, state_root, body_root

3. Post-Consensus Phase

• Leader reconstructs full signed block using:
  • Decided header (with aggregated signature)
  • Locally stored block body and blobs
• Leader submits complete block to beacon chain

4. Signature Reconstruction

• Operators sign the header during consensus
• The header's body_root cryptographically commits to the entire block body
• Reconstructed signature is valid for the full block

Implementation Notes

• Requires SSV fork - this is a breaking protocol change
• Need to modify consensus data structures to support header-only mode
• Update signature aggregation logic for header signing
• Ensure backward compatibility mode during fork transition

Benefits

• 99.9% reduction in consensus message size vs full blocks
• Constant ~1KB consensus messages regardless of block/blob size
• Scales perfectly with future blob increases
• Minimal network bandwidth usage
• Faster consensus rounds

Security Considerations

• Same security model: body_root in header commits to entire block
• No additional trust assumptions
• Leader cannot modify block body without invalidating header

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. It will be closed in 30 days if there are no updates. Please comment if you would like to keep it open.