Hazync verifier checks 1,789 Bitcoin blocks in 27 ms

Hazync’s 1.7 MB verifier validated a 226,434-byte receipt for Bitcoin’s first 1,789 blocks in 27 ms; project disclosures estimate a full genesis-to-tip proof would need about 17 GPU-years.

Project disclosures show a 1.7 MB standalone verifier checked a 226,434-byte cryptographic receipt that covers Bitcoin’s first 1,789 blocks in 27 milliseconds. The prototype runs Bitcoin consensus code inside RISC Zero’s zero-knowledge virtual machine and produces a compact receipt that other users can verify quickly. The guest program is built from portions of Bitcoin Core v28 and libsecp256k1, compiled for 32-bit RISC-V, and the project folds block proofs recursively into a single output that includes cumulative work for best-chain comparison.

Verification and proof generation use different resources. The project reports a benchmark on block 741,000, which had 670 inputs and required 394 UTXO leaves. Proving that block as 16 chunks across two Nvidia L40S GPUs took about 55 minutes, including 27 minutes for aggregation. Using such measurements, the project estimates roughly 17 GPU-years to backfill the chain from genesis to the current tip, and an ongoing capacity roughly equivalent to six L40S GPUs to keep up with new blocks. The full genesis-to-tip campaign is not yet complete, so the 17 GPU-year figure is an estimate based on representative benchmarks rather than a finished run across every era of Bitcoin history.

Each Hazync receipt commits to a METHOD_ID, a fingerprint of the compiled guest program. Any change to the guest produces a new identifier and ties earlier receipts to the prior build. The project restarted its genesis proving on Aug. 4 after an internal audit required a new baseline and notes that later soundness fixes could force another reset after more GPU time has been spent. These constraints mean the proving budget must cover stable code, the historic backfill and continuous capacity at the tip.

A Hazync receipt proves that the covered segment followed the project’s interpretation of Bitcoin rules but does not replace archive operators or node duties. Archive operators must continue to supply historic transaction, witness and signature data for future proving. Hazync includes cumulative-work values in receipts so verifiers can compare competing tips by most work. The project also highlights an availability risk: a hostile archive bridge could serve unusable inputs and consume a prover’s GPU time, creating an economic denial-of-service vector.

The system’s trust boundary includes the guest code, a C++ portability layer, a non-Core Utreexo accumulator for UTXO commitments, and cryptographic components including RISC Zero’s proof system, SHA-256 and secp256k1. The project identified the portability shims and accumulator as priority review targets. The repository records two AI-assisted external reviews in August that did not find a path for the guest to accept an invalid chain; a commissioned professional audit has not yet been completed. Public code is available for outside scrutiny, and the project frames production assurance as dependent on adversarial review of every component inside the proof boundary.

At its current stage, the project demonstrates millisecond-scale verification for a limited spine of Bitcoin history while the resource-intensive work of proving the full chain continues. The project divides responsibilities among provers, archive operators, verifiers and auditors, with fast receipt checks available to end users once upstream proving and external review work are finished.

Articles by this author