ZK proof verification failure due to strict SHA-256 hashing on benign image compression

[Tenerife-Q]

Context:
While reviewing the capture-to-mint pipeline, I examined how the system currently anchors image authenticity. In hardware-camera-app/raspberry_pi_camera_app.py (specifically in _upload_and_create_claim), the hardware generates a strict cryptographic hash directly from the image buffer using hashlib.sha256. This exact hash is later verified on-chain through the RISC Zero ZK proof in contracts/src/LensMintVerifier.sol (submitMetadata).

The Problem:
Cryptographic algorithms like SHA-256 are extremely sensitive to any data modification. A single bit of change in the file structure completely alters the resulting hash output.

Impact:
In standard decentralized storage scenarios, when images are routed through Filecoin/IPFS gateways, cached by CDNs, or processed by frontend clients, they frequently undergo minor, visually lossless compression or metadata stripping. If this occurs, the SHA-256 hash will change entirely. Consequently, the ZK proof verification will fail on-chain, even if the image is visually authentic and was genuinely captured by a registered hardware device. This creates a bottleneck for real-world usability.

Proposed Solution:
To resolve this, we can introduce Perceptual Hashing (pHash) combined with a distance-based tolerance threshold in the ZK circuit, shifting the authenticity check from strict byte-matching to visual semantic matching.

1. Hardware Side (Python): Extract the pHash of the image array at the time of capture and include it in the signed metadata payload alongside the original signature.
2. ZK Circuit (RISC Zero / Rust): Implement a guest program that calculates the Hamming distance between the originally signed pHash and the pHash of the image currently being verified.
3. Validation Logic: The ZK circuit will generate a valid proof as long as the Hamming distance is below a strict, predefined threshold. This ensures the system tolerates normal image compression but firmly rejects AI-generated manipulations or structural tampering.

I am planning to address this exact architectural implementation in my GSoC 2026 proposal, focusing on integrating the pHash extraction and writing the Rust-based RISC Zero guest circuits.

I would appreciate any thoughts or feedback on whether this approach aligns with the core team's technical roadmap.

[Tenerife-Q]

To follow up with concrete data: I have submitted a benchmark script in PR #45

The simulation demonstrates that a visually identical 95% quality re-encode (standard behavior for IPFS gateways) triggers a complete SHA-256 avalanche effect, which would break the current on-chain verifier. However, the pHash Hamming distance remains at a minimal 2.

This confirms that implementing the RISC Zero ZK tolerance circuit (verifying distance <= 5) is a critical prerequisite for the camera's real-world usability and mainnet deployment.

[Tenerife-Q]

Hey everyone, just wanted to share a quick update on some side research I did regarding the ZK verification pipeline.

While finalizing my GSoC proposal, I realized I needed some statistical data to back up the Hamming Distance <= 5 threshold we discussed. So I wrote an automated script to test 100 random hi-res images. I compared standard decentralized gateway noise (like IPFS 95% JPEG compression/downscaling) against actual tampering (like cropping or deepfake artifacts).

The results are pretty interesting (attached the plot below):

1. As expected, strict SHA-256 broke 100% of the time just from standard visually lossless re-encoding.
2. pHash survived easily. Benign compression never exceeded a distance of 2, while malicious tampering spiked way past 10.

This gives me a lot of confidence that our ZK circuit can safely run with a threshold=5 without triggering false positives on mainnet, perfectly separating network noise from actual forgery.

I've pushed the raw Python scripts and markdown reports to a separate lab repo if anyone wants to reproduce the test or tweak the parameters: https://github.com/Tenerife-Q/lensmint-research-lab

[Tenerife-Q]

Hey again, a quick follow-up on the hardware feasibility side.

I know the usual concern with running ZK on edge devices (like the Pi) is the massive overhead—specifically slow proving times and OOM (Out of Memory) crashes.

To test if this is actually viable, I wrote a minimal RISC Zero circuit for the pHash + Hamming distance logic and profiled it locally. The metrics look surprisingly good:

• Cycles: 4355 (For comparison, standard SHA-256 inside zkVM easily hits 1M+ cycles. We cut the arithmetic overhead by over 99%).
• Memory Segments: 1 (This is the absolute minimum footprint, meaning virtually zero risk of OOM on a 2GB/4GB Pi).
• Proving Time: ~5s on my setup, which is more than fast enough for a background hardware daemon.

I've pushed the Rust MVP and the prover scripts to the zk-prototypes dir in my lab repo. I also set up a GitHub Action to verify it cross-compiles cleanly to aarch64.

So this pretty much closes the loop: the math works (ROC curve), and the edge hardware won't choke. Next step would be wiring this into the actual camera daemon.