Fuzzing
Coverage-guided fuzzing uses libFuzzer via cargo-fuzz on unstructured byte inputs. It complements spec-lock, unit tests, and property tests; it does not replace them.
Source of truth
Harness names and crate wiring live in each repo’s fuzz/Cargo.toml ([[bin]] entries). Implementation sources are under fuzz/fuzz_targets/. Do not treat prose (here or in READMEs) as an inventory—it goes stale.
| Crate | Location |
|---|---|
| blvm-consensus | blvm-consensus/fuzz |
| blvm-protocol | blvm-protocol/fuzz |
| blvm-node | blvm-node/fuzz |
| blvm-sdk | blvm-sdk/fuzz |
Local monorepo checkouts often use [patch.crates-io] in fuzz/Cargo.toml so fuzz crates resolve path dependencies; continuous integration may build fuzz targets against crates.io instead (see comments in each repo’s fuzz/Cargo.toml—for example blvm-consensus/fuzz and blvm-protocol/fuzz).
Quick start (consensus)
cd blvm-consensus/fuzz
./init_corpus.sh # optional: seed corpora
cargo +nightly fuzz run <target_name>
Pick <target_name> from fuzz/Cargo.toml. The fuzz/ directory also contains scripts (e.g. campaign runners, corpus helpers, sanitizer build helpers)—use what matches your workflow.
CI
Fuzz jobs are defined in the relevant repository’s GitHub Actions. Matrix steps and timeouts may not exercise every harness on every run; read the workflow for actual behavior.
See also
- Testing — how techniques fit together
- Differential testing — cross-implementation checks
- Formal verification — spec-lock scope