27 ms to verify? Hazync’s tiny receipt and the 17 GPU-years behind it

Short version: a research project called Hazync showed a tiny verifier can check a compact proof of some early Bitcoin blocks in about 27 milliseconds. But don’t be fooled by the speed demo — building a full historic proof from genesis to the present is estimated to need the equivalent of roughly 17 GPU-years of work, plus ongoing GPU capacity to keep up with new blocks. Fast checks for users, slow and expensive proving up front for specialists.

How Hazync’s trick works (the engineer-friendly elevator pitch)

Hazync is a prototype that runs Bitcoin’s consensus code inside a zero-knowledge virtual machine. The VM executes validation and produces a cryptographic receipt that anyone else can quickly verify. Think of it like a chef making a sealed taste-test box: the chef does all the slow cooking, then packages a tiny verification card that proves the meal is legit — customers just glance at the card and get confident.

The developer built a guest program from pieces of Bitcoin Core’s consensus logic and related crypto, compiled for a lightweight RISC-V environment. That reuse means less “reinvent the rules” work inside the VM. In Hazync’s reported test, a 226 KB receipt covering blocks 1–1,789 checked in about 27 ms on the verifier side.

Why verification can be tiny but proving is a monster

Verification and proof generation are very different beasts. Verifiers only need to run a compact check on the receipt — cheap and fast. Provers must re-execute potentially decades of chain history, build cryptographic proofs, and aggregate them. Those proving steps chew GPU time and memory.

Concrete example: the team benchmarked a much more recent block (around block 741,000). That block needed 670 inputs and touched 394 UTXO leaves; generating its proof in 16 chunks across two high-end GPUs took roughly 55 minutes total, including about 27 minutes for aggregation. Extrapolating from such measurements is imprecise, but the developer’s ballpark for a full genesis-to-tip backfill came out near 17 GPU-years. After that heavy upfront work, keeping up with new blocks was estimated at a steady capacity of a few high-end GPUs.

There are also practical fragilities: each receipt commits to the exact compiled guest program fingerprint. If the guest is rebuilt or fixed after a security review, old receipts don’t match the new fingerprint, and the expensive proving work may have to be re-done from that new baseline. The project already restarted its genesis proof earlier after an internal audit forced a new baseline — imagine re-baking the cake because you changed the recipe halfway through.

Another limitation: archive nodes still need to supply raw transaction data and signatures. Receipts compress validity checking, but they don’t replace archival storage for the data you’d need to re-prove the chain under a new guest build.

Finally, the system design includes trust and availability considerations. Receipts include cumulative-work data so a verifier can compare competing tips, but a malicious archive or bridge could feed provers bad inputs and waste their GPU time. The guest and the VM proof system introduce cryptographic and software assumptions that must be audited carefully.

In short: the user experience — a millisecond-scale verification — is enticing, but the heavy-lift proving behind that experience currently looks expensive, time-consuming, and sensitive to software changes. If a stable guest, abundant compute, and rigorous external audits all line up, this approach could cut repeated full-node validation work in the future. For now, it’s an impressive technical demo with an unfinished, costly path to full-chain coverage.