New Target for BeaconVote Decode Encode #41

armaganyildirak · 2025-09-05T16:12:00Z

This PR adds a new fuzzing target for BeaconVote encode/decode.

The goal is to increase code coverage for SSV clients by testing how BeaconVote data is serialized and deserialized in Rust and Go.

The fuzzer must explore many BeaconVote scenarios to check that encoding and decoding are consistent across implementations.
The inputs are valid BeaconVotes, malformed cases, and SSZ structure edge cases.
Corpus generator for these inputs, plus the registration of the new target in the fuzzing pipeline.

Copilot

Pull Request Overview

Adds a new differential fuzzing target for BeaconVote SSZ encoding/decoding to compare Go and Rust implementations for potential network consensus issues.

Implements diff_fuzz_beacon_vote_decode_encode target with Rust fuzzing harness and Go FFI integration
Adds comprehensive corpus generation with valid BeaconVotes, malformed cases, and SSZ structure edge cases
Integrates the new target into the fuzzing infrastructure with proper categorization as high-priority

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
run_fuzzer.sh	Adds beacon vote target to high-priority differential fuzzing list
fuzz/fuzz_targets/differential/diff_fuzz_beacon_vote_decode_encode.rs	Implements Rust side of differential fuzzing for BeaconVote encode/decode
fuzz/Cargo.toml	Registers the new beacon vote fuzzing target binary
diff_fuzzing/src/lib.rs	Adds Go FFI wrapper for beacon vote decode/encode operations
diff_fuzzing/sfuzz.go	Implements Go-side BeaconVote SSZ decode/encode with FFI export
corpus_generator/src/main.rs	Registers beacon vote generator in the main corpus generator registry
corpus_generator/src/generators/mod.rs	Exports BeaconVote generator module
corpus_generator/src/generators/beacon_vote.rs	Implements comprehensive corpus generation for BeaconVote fuzzing scenarios

Comments suppressed due to low confidence (1)

diff_fuzzing/sfuzz.go:415

[nitpick] This appears to be only indentation/formatting changes to existing code. These formatting changes are not directly related to the BeaconVote feature and should be separated into a different commit.

	message, err := specqbft.NewProcessingMessage(msg)
	if err != nil {
		panic(err.Error())
	}

	var log = zap.NewNop()
	if fInst.debug {
		log, _ = zap.NewDevelopment()
	}
	_, _, _, err = fInst.instance.ProcessMsg(context.TODO(), log, message)
	if err != nil {
		println(err.Error())
		// Do not return an error, as this error might be appropriate for input message.
		// Just compare the outputted messages in the harness.
	}

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

Copilot · 2025-09-12T10:52:51Z

diff_fuzzing/sfuzz.go

+
+	ssvtypes "github.com/ssvlabs/ssv/protocol/v2/types"
+	"go.uber.org/zap"

 	"github.com/herumi/bls-eth-go-binary/bls"
 	specqbft "github.com/ssvlabs/ssv-spec/qbft"
 	spectypes "github.com/ssvlabs/ssv-spec/types"
-	"github.com/ssvlabs/ssv/utils/threshold"
 	qbft "github.com/ssvlabs/ssv/protocol/v2/qbft"
 	instance "github.com/ssvlabs/ssv/protocol/v2/qbft/instance"
-
+	"github.com/ssvlabs/ssv/utils/threshold"
+
 	// Import the actual validation package


[nitpick] The import reordering appears unnecessary and makes the diff harder to read. Consider keeping imports in their original order unless there's a specific reason for the change.

Copilot · 2025-09-12T10:52:51Z

diff_fuzzing/sfuzz.go

+		doReceive(fInst, fInst.messageBuffer.messages[msgIdx])
+		msgIdx++


[nitpick] This formatting change from msgIdx++; to msgIdx++ is unrelated to the BeaconVote functionality and should be separated into a different commit.

Copilot · 2025-09-12T10:52:52Z

diff_fuzzing/sfuzz.go

+
+	// Check if output buffer is large enough
+	out := unsafe.Slice((*byte)(out_ptr), out_size)
+	if len(result) > int(out_size) {


The comparison should be against out_size directly since it's already an int parameter, not cast it from something else. The cast int(out_size) suggests out_size might be a different type, but the function signature shows it as int.

Suggested change

if len(result) > int(out_size) {

if len(result) > out_size {

diegomrsantos · 2025-09-24T19:50:19Z

corpus_generator/src/generators/beacon_vote.rs

+            return Ok(ValidationResult::Boundary);
+        }
+
+        if data.len() < 32 {


Should it be != 32?

I think (but I'm not sure), according to BeaconVote, an SSZ BeaconVote contains multiple 32-byte roots (block_root, source.root, target.root) plus epochs, so the minimum valid SSZ size is well above 32 bytes. The check data.len() < 32 quickly rejects obviously too-short inputs. Using != 32 would wrongly reject all valid encodings, since real BeaconVote encodings are typically much larger than exactly 32 bytes.

I don't know what the correct size is, but does it change? Apparently, it's like this (needs confirmation):

SSV BeaconVote structure:

pub struct BeaconVote { pub block_root: Hash256, // 32 bytes pub source: Checkpoint, // 40 bytes pub target: Checkpoint, // 40 bytes } Breakdown: - block_root (Hash256): 32 bytes - source (Checkpoint): 40 bytes - epoch (uint64): 8 bytes - root (Hash256): 32 bytes - target (Checkpoint): 40 bytes - epoch (uint64): 8 bytes - root (Hash256): 32 bytes Total: 32 + 40 + 40 = 112 bytes

So every size different from this should be invalid?

You're right. BeaconVote is a fixed-size SSZ container, so any size other than exactly 112 bytes is invalid. The current < 32 check is wrong, it should be != 112 since SSZ guarantees deterministic encoding for fixed structures with no size variation possible.

diegomrsantos · 2025-09-24T19:53:28Z

corpus_generator/src/generators/beacon_vote.rs

+    }
+
+    fn validate_corpus_entry(&self, data: &[u8]) -> Result<ValidationResult, Box<dyn std::error::Error>> {
+        let critical_sizes: Vec<usize> = crate::common::SizeBoundaryUtils::get_critical_size_boundaries()


Not related to this PR, but not sure get_critical_size_boundaries is a descriptive name

diegomrsantos · 2025-09-24T19:54:28Z

corpus_generator/src/generators/beacon_vote.rs

+        if critical_sizes.contains(&data.len()) {
+            return Ok(ValidationResult::Boundary);
+        }


Why do we return this here and stop validation?

My idea was, when the input length matches a critical boundary size, we don’t mark it as valid or invalid right away. Instead, we label it as ValidationResult::Boundary and keep it for testing edge cases about size. By returning at this point, we stop normal validation. This way, the input isn’t thrown away or used up, but saved in the corpus as a special boundary case.

What do you mean by critical? Why (1_000, "small_message"), would be relevant for a BeaconVote?

By critical, I mean sizes that are interesting for testing, not normal BeaconVotes. We keep very small, very large, or exact boundary sizes to check if the decoder crashes or has off-by-one bugs. That’s why we return Boundary and stop normal validation. I followed the style of previous generators, but we can change it if you have a different idea.

I checked this one

ssv-fuzz/corpus_generator/src/generators/ssv_message.rs

Line 18 in c6c55db

fn validate_corpus_entry(&self, data: &[u8]) -> Result<ValidationResult, Box<dyn std::error::Error>> {

and it doesn't seem to do that

And I'm not sure we can generalize boundaries for different types. Wouldn't they be like type_size, type_size - 1, type_size + 1?

You are right, the ssv_message generator does not use this boundary logic. I followed what I saw in some other generators, but maybe it is not the best fit here.

diegomrsantos · 2025-09-24T19:58:25Z

corpus_generator/src/generators/beacon_vote.rs

+}
+
+impl BeaconVoteGenerator {
+    fn generate_valid_beacon_votes(&self, output_dir: &Path, rng: &mut StdRng) -> Result<usize, Box<dyn std::error::Error>> {


What usize means here? What kind of error could this function return if it's supposed to generate valid beacon votes?

The usize in the return type is the count of files generated (how many valid beacon votes were written to the corpus). I just follow the previous generator implementations because all of them return the same output (

ssv-fuzz/corpus_generator/src/generators/message_id.rs

Line 61 in c4003cf

fn generate_validator_key_boundaries(&self, output_dir: &Path) -> Result<usize, Box<dyn std::error::Error>> {

)

armaganyildirak added 2 commits September 5, 2025 12:11

New Target for BeaconVote Decode Encode

576bf60

Add corpus generator for BeaconVote

f941a12

diegomrsantos requested review from Copilot and dknopik September 12, 2025 10:51

Copilot AI reviewed Sep 12, 2025

View reviewed changes

armaganyildirak and others added 3 commits September 12, 2025 11:09

Remove unnecessary integer casting and add new line

9bb6759

Revert back go fmt changes

42ba64a

Merge branch 'unstable' into diff-fuzz-beacon-vote-decode-encode

c4003cf

diegomrsantos reviewed Sep 24, 2025

View reviewed changes

change size check 32 to 112

96e3c2b

		doReceive(fInst, fInst.messageBuffer.messages[msgIdx])
		msgIdx++

New Target for BeaconVote Decode Encode #41

Are you sure you want to change the base?

New Target for BeaconVote Decode Encode #41

Uh oh!

Conversation

armaganyildirak commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

diegomrsantos Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

armaganyildirak commented Sep 5, 2025 •

edited

Loading

diegomrsantos Sep 25, 2025 •

edited

Loading