This document tracks bugs and implementation discrepancies discovered through differential fuzzing between the Anchor (Rust) and SSV (Go) implementations.
Note: This is an ongoing effort. The issues listed here are current findings, and more discrepancies are likely to be discovered as fuzzing continues.
-
Bump round on future justified proposal (PR #529)
- Issue: Incorrect round handling when receiving justified proposals from future rounds
- Impact: Could cause validators to remain stuck in old rounds
-
Allow reaching consensus in PREPARE state (PR #527)
- Issue: Consensus logic prevented valid state transitions from PREPARE
- Impact: Potential liveness issues in certain consensus scenarios
-
Validation for prepared round changes before insertion (PR #528)
- Issue: Missing validation before inserting prepared round change messages
- Impact: Could allow invalid messages into the state machine
-
Store messages without full data (PR #538)
- Issue: Message storage logic required unnecessary full data
- Impact: Memory inefficiency and potential state inconsistencies
-
Partial roundchange quorum (PR #541)
- Issue: Incorrect quorum calculation for partial round change sets
- Impact: Could prevent or incorrectly trigger round changes
-
COMMIT and PREPARE must be of the exact current round (PR #530)
- Issue: Accepted COMMIT and PREPARE messages from incorrect rounds
- Impact: State machine could process out-of-order messages incorrectly
-
Check round change quorum disregarding root (PR #571)
- Issue: Round change quorum logic incorrectly considered root values
- Impact: Could prevent legitimate round changes from completing
-
Threshold key split validation of 0 (PR #2466)
- Issue: Missing validation for zero threshold in key splitting
- Impact: Could create invalid key shares with zero threshold
-
Redundant Round-Change message (Issue #579)
- Issue: Implementation sent redundant round change messages
- Impact: Network bandwidth waste and potential confusion in consensus
-
Comparison mismatched (Issue #580)
- Issue: Inconsistent comparison logic between implementations
- Impact: Could cause different validation results for the same input
-
Add message validation rule (Issue #582)
- Issue: Missing validation rule that Rust implementation enforced
- Impact: Could accept invalid messages that should be rejected
If you discover additional issues through fuzzing:
- Verify the discrepancy is reproducible
- Create a minimal test case
- Report to the relevant implementation team
- Submit a PR adding the issue to this trophy case