feat: blind all blocks before QBFT

[petarjuki7]

Issue Addressed

Addresses Issue #630

Proposed Changes

• Blind blocks before QBFT to reduce bandwidth
• Save original full block and compare after consensus
• Return full block with signature if our proposal won, otherwise return blinded block

Additional Info

The signature is valid for both blinded and full versions since they share the same block header.

[dknopik]

Nice!

Please rebase on unstable.

[dknopik]

@claude please review

[claude-code-actions-sigp]

Claude finished @dknopik's task —— View job

---

Code Review for PR #694

• Read CLAUDE.md for repository guidelines
• Read the modified file (anchor/validator_store/src/lib.rs)
• View git diff to understand the changes
• Analyze code for correctness, safety, and best practices
• Review existing comments and concerns
• Provide comprehensive review feedback

---

Job: https://github.com/sigp/anchor/actions/runs/12366854995
Branch: blind_blocks_before_qbft

[dknopik]

@petarjuki7 your sigp membership is still private, so the tag claude-recheck tag will not work

[dknopik]

Tiny nit

[claude-code-actions-sigp]

Claude finished @petarjuki7's task —— View job

---

Code Review for PR #694

Review completed successfully.

---

Summary

This PR implements bandwidth optimization by blinding blocks before QBFT consensus. The approach is architecturally sound: send only blinded blocks through consensus, preserve the original full block, and return the full block with signature if our proposal wins.

Critical Issues

1. Blob Handling (CRITICAL)

Location: anchor/validator_store/src/lib.rs:940-950

The current code discards blobs when extracting the blinded block. When checking if our proposal won (line 976), the code returns proofs_and_blobs which may be None even when the original block had blobs.

Impact: Post-Deneb blocks with blobs will fail to publish correctly if our proposal wins consensus.

Recommendation: Ensure blobs are correctly extracted and preserved throughout the consensus flow.

2. Handling Blocks from Other Clients (CRITICAL)

Location: anchor/validator_store/src/lib.rs:952-976

Per @dknopik's review comment, other SSV clients that haven't upgraded may still propose full blocks during consensus. The decide_abstract_block method correctly handles this with a fallback to decode full blocks (line 370-376), but the subsequent match statement (line 958-972) doesn't handle all possible return variants.

Issue: If another client proposes a full block and wins consensus, we'll get UnsignedBlock::Full(FullBlockContents) back, but the current code only handles Blinded and Full(BeaconBlock) variants.

Recommendation: Add a match arm to handle UnsignedBlock::Full(FullBlockContents::BlockContents(contents)).

Code Quality Issues

3. Unnecessary Signature Clone

Location: anchor/validator_store/src/lib.rs:982

The signature is cloned when reconstructing the full block. Verify if this allocation is necessary.

4. Missing Error Context

Location: anchor/validator_store/src/lib.rs:370-376

The decode error handling could provide better context about whether the failure was for blinded or full block decoding.

Positive Observations

1. ✓ Good architectural approach: Blinding before consensus is the right solution for bandwidth optimization
2. ✓ Proper error handling: New error types (DataTooLarge, ClusterLiquidated) are well-defined
3. ✓ Signature compatibility: Correctly leverages that signatures are valid for both blinded and full blocks
4. ✓ Liquidation check: Good defensive programming to filter liquidated clusters
5. ✓ Use of try_to_variable_list: Proper bounds checking for consensus data
6. ✓ Cross-client compatibility: Good fallback to handle full blocks from legacy clients

Testing Recommendations

1. Test blob preservation through the full consensus flow
2. Test cross-client compatibility when other clients send full blocks
3. Test header comparison logic for all block types
4. Test edge cases with empty/malformed blobs

Performance & Security

• Performance: The blinding optimization should significantly reduce network bandwidth ✓
• Security: No security issues identified. The signature verification remains intact ✓
• Memory: Consider the memory impact of preserving both blinded and full blocks during consensus

---

Overall Assessment: The core concept is sound and the implementation is mostly correct. However, there are critical issues with handling all variants of blocks returned from consensus that must be addressed before merge. The blob handling needs verification, and the match statement needs to handle the case where other clients send full blocks.

Detailed inline comments have been posted on specific lines for the critical issues.

---

Job: https://github.com/sigp/anchor/actions/runs/18697403373
Branch: blind_blocks_before_qbft

[dknopik]

LGTM, thanks!