Hazync Achieves 27-Millisecond Bitcoin Validation, But Full Chain Proof Requires 17 GPU-Years

Hazync’s developer reports that a 1.7 MB standalone verifier checked a 226,434-byte cryptographic receipt covering the first 1,789 blocks of Bitcoin in just 27 milliseconds. This August 15 disclosure demonstrates rapid validation for an early segment of Bitcoin’s blockchain, though a complete genesis-to-tip proof system remains under development.

Hazync is a research prototype that leverages RISC Zero’s zero-knowledge virtual machine (zkVM) to enable reusable Bitcoin validation. The zkVM executes the validation program, producing a compact receipt that other users can quickly verify. The architecture separates proof generation (performed by specialized provers) from receipt verification (which can be distributed broadly), optimizing cost efficiency across the network.

These two processes have vastly different computational requirements. The developer estimates approximately 17 GPU-years of computation power would be needed to generate proofs for the entire Bitcoin blockchain history, followed by ongoing capacity equivalent to about six Nvidia L40S GPUs to maintain pace with new block production. Verification becomes efficient once provers complete the expensive work upstream.

Verification is cheap; proving is expensive

Traditional Bitcoin nodes independently replay the entire blockchain to validate it. Hazync instead runs Bitcoin’s consensus rules within the zkVM, proves that those rules accepted each covered block, and recursively combines block proofs into a single receipt. This approach dramatically reduces the verification burden for end users.

The public Hazync repository contains a guest program constructed largely from Bitcoin Core v28’s consensus code and libsecp256k1, compiled for 32-bit RISC-V. Reusing Core’s established code minimizes the consensus logic that must be restated in a separate circuit format.

Benchmarking proof generation costs

The block 741,000 benchmark measures proof-generation performance on recent Bitcoin data. The developer reports that this block contained 670 inputs and required 394 UTXO leaves. Proving it across 16 chunks using two L40S GPUs took approximately 55 minutes, including 27 minutes for aggregation.

This measurement informs the developer’s estimate of roughly 17 GPU-years for a complete genesis-to-tip backfill. The available data provides representative project benchmarks rather than audited measurements across every era of Bitcoin history, so Hazync’s full-chain performance remains an estimate until the campaign is completed.

Code changes can also invalidate completed work. Every Hazync receipt commits to a METHOD_ID, a fingerprint of the compiled guest program. When the guest receives a new build, it gets a new identifier, leaving earlier receipts tied to the previous version.

The project restarted its genesis board on August 4 after an internal audit required a new baseline. A later soundness fix could trigger the same reset after significantly more GPU time has been accumulated. The proving budget must therefore account for stable code, the historic backfill, and continuous capacity for new blocks.

Verification speed represents the user-facing outcome. The 17 GPU-year estimate measures the concentrated industrial effort required to produce that experience.

Limitations of the receipt approach

A receipt compresses validity checking, but archive operators still provide transaction availability and retain historic witness and signature bytes. Future guest revisions will need these bytes to prove the chain again, so succinct verification preserves a long-term storage role for archive infrastructure.

Best-chain selection remains governed by Bitcoin’s proof-of-work rule. Hazync places cumulative work into the receipt’s public output, giving verifiers the value needed to compare competing tips. The receipt establishes rule compliance for its chain segment, but nodes still choose which valid chain to follow.

An archive bridge also retains the power to waste prover resources. The project’s stated composition rules connect every state boundary to the genesis pin, causing forged state to fail when a receipt joins the spine. However, a hostile bridge can serve unusable inputs and consume a worker’s GPU time, turning availability into an economic denial-of-service risk.

The developer describes a proof composed from genesis as unconditional within Hazync’s software and cryptographic assumptions. A later checkpoint would enter the system as an explicit trust input.

Guest program security and review

The guest itself contains an important review boundary, as substantial Core consensus code runs inside it alongside project-maintained slices for the subsidy schedule and script-activation heights. The project states its script-flag schedule is differentially tested as a sound superset of Core’s rules, allowing extra rejection in the direction intended to preserve soundness.

A C++ portability layer adapts Core for the zkVM, and a non-Core Utreexo accumulator commits changes to Bitcoin’s unspent-transaction-output set. The disclosed assumptions also cover RISC Zero’s proof system, SHA-256, and secp256k1. Hazync identifies the portability shims and accumulator as its highest-priority residual review targets.

The repository reports two AI-assisted external reviews in August that failed to find a path for the guest to accept an invalid chain. A commissioned professional audit remains outstanding. Public code enables outside scrutiny, and production assurance still rests on adversarial examination of the exact guest and every component inside its proof boundary.

Toward scalable Bitcoin validation

Hazync splits trustless sync into several jobs with different operators and budgets. Receipt verification can reach milliseconds for a proven range. Proof generation consumes GPU capacity, archive operators retain the underlying data, nodes compare tips, and auditors assess the guest.

A stable implementation with sufficient compute and outside review could reduce repeated validation across new nodes. At the project’s current stage, the developer-reported 27-millisecond check covers a limited spine, while the 17 GPU-year estimate describes the unfinished path to Bitcoin’s tip.

Source link