BlockProof serialization is a silent no-op (TODO placeholder)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 75/100
Research direction
The issue is in crates/miden-protocol/src/block/block_proof.rs lines 28-37. Start by reading the Serializable and Deserializable trait implementations for BlockProof. Understand the ByteWriter and ByteReader traits to implement proper serialization/deserialization. Since the struct currently has no fields, the implementation is trivial, but you should add a panic or compile-time assertion to prevent silent data loss when fields are added. Run any existing tests related to block proof serialization to verify your changes.
Written by the indexing model from the issue text.
Description
crates/miden-protocol/src/block/block_proof.rs:28-37
BlockProof::write_into is a no-op:
impl Serializable for BlockProof {
fn write_into<W: ByteWriter>(&self, _target: &mut W) {
// TODO: Implement serialization
}
}
And read_from returns an empty struct:
impl Deserializable for BlockProof {
fn read_from<R: ByteReader>(_source: &mut R) -> Result<Self, DeserializationError> {
// TODO: Implement deserialization
Ok(Self {})
}
}
If a BlockProof is ever serialized or deserialized in production code, it will silently produce corrupt data — the bytes won't represent the actual proof, and deserialization will always return an empty BlockProof regardless of input.
The BlockProof struct has no fields currently (block_proof.rs:24-26), so serialization is technically lossless, but once fields are added (which the TODO implies is planned), the empty serialization becomes a data corruption bug. Adding a panic or compile-time assertion would prevent silent data loss when fields are added.
- Dominant language
- Rust
- Stars
- 133
- Forks
- 168
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 93
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from 0xMiden/protocol
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
objects
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
standards
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 1/5 Under an hour Newbie friendliness 80/100
All issues in 0xMiden/protocol
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100