bug: block proofs are never cryptographically verified in `apply_proof`

[Sertug17]

Summary

verify_block_proof in crates/store/src/state/apply_proof.rs only deserializes the proof bytes it never performs cryptographic verification. Any byte sequence that parses as a valid BlockProof struct is accepted and written to disk.

Code

// crates/store/src/state/apply_proof.rs
fn verify_block_proof(_block_num: BlockNumber, proof_bytes: &[u8]) -> anyhow::Result<()> {
    let _proof =
        BlockProof::read_from_bytes(proof_bytes).context("failed to deserialize block proof")?;

    // TODO: perform verification.
    Ok(())
}

Impact

• This function is called from apply_proof, which is used by both the sequencer's ProofScheduler and the full-node's ProofSync
• Unverified proofs are persisted to disk and broadcast to all replica subscribers via proof_cache
• An attacker can submit a structurally valid but cryptographically invalid proof and it will be accepted

Expected behavior

The proof should be cryptographically verified before returning Ok(()).

[Sertug17]

I've identified the fix for this and would be happy to open a PR. Would that be welcome?

[quby1845]

I traced this through both the current node code and 0xMiden/protocol:next. The blocker is upstream: BlockProof is still an empty placeholder, LocalBlockProver::prove returns that placeholder, and the protocol does not expose a block-proof verifier. A node-only PR therefore cannot honestly add cryptographic verification yet.

I prepared a separate, tested hardening change that uses budgeted exact decoding and rejects trailing payload bytes before they can be persisted or re-broadcast:

https://github.com/quby1845/node/tree/harden-block-proof-decoding

This closes the current arbitrary-suffix acceptance gap, but it deliberately does not claim to resolve this issue. The full fix needs the protocol proof representation, prover, public inputs, and verifier API first.

Would maintainers prefer the decoding hardening as a separate PR, or should this issue wait for the protocol block-proof design to land?

[Sertug17]

@quby1845 Great analysis! The decoding hardening PR looks like a solid interim step. I had identified this issue and was planning to work on .

[quby1845]

Thanks! I’d be happy to collaborate. The branch is complete for its intentionally limited
decoding-hardening scope, and I’ve opened it as a draft PR here:

#2459

I’d appreciate your review. If you spot additional malformed-encoding cases or useful regression
tests, please add them on the PR. I kept it explicitly scoped as an interim hardening change and
referenced this issue without claiming to close the full cryptographic-verification gap.