-
Notifications
You must be signed in to change notification settings - Fork 111
[coding] Introduce commonware-coding
#1272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Introduce the commonware-coding
crate for erasure-coded data recovery using Reed–Solomon with Merkle proofs.
- Add the new
commonware-coding
crate, including implementation, docs, tests, and benchmarks. - Update workspace manifests and top-level documentation to include the
coding
package. - Integrate CI workflows for benchmarking and publishing the new crate.
Reviewed Changes
Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
docs/index.html | Add link to new commonware-coding crate in documentation |
coding/src/reed_solomon/mod.rs | Implement Reed–Solomon encode/decode with BMT proofs |
coding/src/reed_solomon/benches/encode.rs | Add Criterion benchmark for encode |
coding/src/reed_solomon/benches/decode.rs | Add Criterion benchmark for decode |
coding/src/reed_solomon/benches/bench.rs | Define benchmark entrypoint |
coding/src/lib.rs | Declare reed_solomon module |
coding/README.md | Add crate README |
coding/Cargo.toml | Add crate manifest for commonware-coding |
README.md | Include coding in top-level README |
Cargo.toml | Add coding to workspace members |
.github/workflows/slow.yml | Add benchmarking job for commonware-coding |
.github/workflows/publish.yml | Add publish step for the coding crate |
Comments suppressed due to low confidence (2)
coding/src/reed_solomon/benches/decode.rs:27
- [nitpick] The variable
proofs
actually holds the vector ofChunk
s returned byencode
. Consider renaming it tochunks
for clarity.
let (root, proofs) = encode::<Sha256>(chunks, min, data).unwrap();
coding/src/reed_solomon/mod.rs:128
- [nitpick] The error message
"inconsistent"
is vague. It may be clearer to specify that the recomputed Merkle root did not match the provided root (e.g.,"inconsistent root: reconstructed data does not match"
).
#[error("inconsistent")]
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## main #1272 +/- ##
==========================================
+ Coverage 91.04% 91.06% +0.02%
==========================================
Files 245 246 +1
Lines 59760 60120 +360
==========================================
+ Hits 54407 54748 +341
- Misses 5353 5372 +19
Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
Related: #1267
To ensure all participants see a notarized block in consensus, the leader should send chunks to each participant. If a chunk is valid (proof verifies), participants should multicast their chunk when sending their vote. When any honest node sees 2f+1 votes, they'll be able to recover the underlying block (set to only require f+1 chunks to derive) or all will determine that the encoding was invalid (and skip it). This approach is a much more explicit defense against what is usually not considered to be a problem with the "gossip model of block dissemination".
Conveniently, this technique can also increase throughput by making broadcast of transaction data "fair"/"symmetric" (rather than relying entirely on the leader's egress capacity) for negligible latency overhead.
Related
Performance