feat: add 34-slot TTL for ValidatorRegistration and VoluntaryExit messages

[diegomrsantos]

Issue Addressed

Related to #692

Proposed Changes

Adds time-to-live validation for ValidatorRegistration and VoluntaryExit messages, which previously had no lateness checks. These messages now use the same 34-slot TTL as Committee and Aggregator roles.

This enables more resilient operator doppelgänger protection by:

• Preventing replay attacks from malicious nodes
• Bounding the acceptance window for stale messages
• Working seamlessly with the doppelgänger grace period

Additional Info

The 34-slot window sets the stage for a longer doppelgänger protection grace period, ensuring no vulnerability gaps between restart and validation.

[claude-code-actions-sigp]

Claude encountered an error —— View job

---

Code Review in Progress

Tasks

• Read the changed file and understand the implementation
• Review git diff to see exact changes
• Check for related test files
• Analyze code quality, security, and correctness
• Provide comprehensive review feedback

[diegomrsantos]

Claude will probably and rightfully complain about the lack of tests. I'll make sure to add it later.

[diegomrsantos]

cc @nkryuchkov

[claude-code-actions-sigp]

Claude finished @diegomrsantos's task —— View job

---

Code Review Complete

Summary

This PR adds 34-slot TTL (Time-To-Live) validation for ValidatorRegistration and VoluntaryExit messages, which previously had no lateness checks. The implementation is clean and well-tested.

Changes Overview

lib.rs (anchor/message_validator/src/lib.rs:634-636)

• Modified message_lateness() function to apply the same TTL as Committee and Aggregator roles (slots_per_epoch + 2 slots = 34 slots)
• Removed the early return that bypassed lateness checks for these roles

partial_signature.rs (anchor/message_validator/src/partial_signature.rs:834-1049)

• Added comprehensive test coverage with 4 new tests validating TTL behavior
• Tests cover both acceptance within TTL and rejection beyond TTL for both roles

---

Review Findings

Code Quality: ✅ Excellent

Strengths:

• Clean, minimal change to existing logic following the DRY principle
• Consistent with existing role TTL patterns in the codebase
• Well-structured test helpers for creating TTL validation contexts
• Test constants are clearly documented with explanatory comments

Minor Observations:

• The test helper create_ttl_validation_context() simulates time advancement cleanly
• Test structure follows existing patterns in the file (Setup/Execute/Assert comments)

Security: ✅ Good

Positive Security Impact:

• Prevents replay attacks on ValidatorRegistration and VoluntaryExit messages
• Bounds the acceptance window for stale messages as described in PR description
• Aligns with the doppelgänger protection strategy mentioned in issue feat: operator doppelgänger protection with slot-based detection #692

No Security Concerns Identified:

• The 34-slot window (32 + 2) provides reasonable protection without being overly restrictive
• Consistent with other duty types that have similar timing requirements

Testing: ✅ Comprehensive

Test Coverage Added:

1. test_validator_registration_within_ttl_accepted() - Validates acceptance at TTL boundary
2. test_validator_registration_beyond_ttl_rejected() - Validates rejection beyond TTL
3. test_voluntary_exit_within_ttl_accepted() - Validates acceptance at TTL boundary
4. test_voluntary_exit_beyond_ttl_rejected() - Validates rejection beyond TTL

Test Quality:

• Tests properly simulate time advancement using ManualSlotClock
• Both positive (acceptance) and negative (rejection) cases covered
• Clear test constants: TTL_SLOTS = 34 and BEYOND_TTL_SLOTS = 40
• Uses existing test infrastructure and patterns consistently

Note: The author acknowledged in comments that tests were missing initially and added them in commit 07efaa7.

Performance: ✅ No Impact

• No additional computational overhead introduced
• Simply applies existing validation logic to additional roles
• Same message_lateness() calculation path as other roles

Documentation: ⚠️ Could Be Enhanced

What's Good:

• PR description clearly explains the motivation and security benefits
• Test constants include inline comments explaining the TTL calculation

Suggestions for Improvement:

• Consider adding a brief comment in lib.rs explaining why ValidatorRegistration and VoluntaryExit use the 34-slot TTL (e.g., "// Use epoch-based TTL for non-time-critical messages")
• The CLAUDE.md file mentions documentation requirements for complex logic

---

Recommendations

Optional Enhancements

1. Add inline comment (lib.rs:634):

   // Committee, Aggregator, ValidatorRegistration, and VoluntaryExit use epoch-based TTL
   // as they are not time-critical like block proposals or sync committee duties
   Role::Committee | Role::Aggregator | Role::ValidatorRegistration | Role::VoluntaryExit => {

2. Consider adding edge case test: A test validating behavior exactly at the deadline (not before or after) could strengthen coverage, though current tests are sufficient.

Questions for Author

1. Was the 34-slot TTL (slots_per_epoch + 2) chosen to align with Committee/Aggregator for consistency, or is there a specific operational reason for this duration?

2. Does this change require any updates to operator documentation or deployment guides regarding message timing expectations?

---

Conclusion

This is a well-implemented security improvement. The code changes are minimal, focused, and correctly implemented. The test coverage is comprehensive and follows existing patterns. The PR successfully addresses the security goal of preventing replay attacks while working within the doppelgänger protection framework.

Recommendation: Approve (pending any responses to optional questions above)

The implementation is production-ready. The only suggestion is adding a brief explanatory comment for future maintainability.

---