Bitcoin-proof gecheckt in 27 milliseconden, maar GPU-rekening blijft enorm
27 milliseconden. Zo snel werd een cryptografisch bewijs over de eerste 1.789 Bitcoin-blokken gecontroleerd.
Daarachter zit alleen een veel zwaardere rekening. Hazync schat dat een proof van de volledige Bitcoin-geschiedenis ongeveer 17 GPU-jaren aan rekenwerk vraagt.
De 27 milliseconden zeggen dus iets over controleren. Niet over het maken van het bewijs.
Hazync stopt echte Bitcoin Core-code in een zkVM
Hazync probeert een oud probleem van Bitcoin anders aan te pakken.
Een nieuwe full node haalt historische blocks binnen en controleert zelf de regels van het netwerk. Bitcoin Core omschrijft zichzelf ook als software die blocks en transacties downloadt en volledig valideert.
Daarmee hoeft een node een ander niet op zijn woord te geloven.
Hazync vraagt iets anders: moet iedere nieuwe node al dat historische werk opnieuw uitvoeren?
De ontwikkelaar heeft daarvoor delen van Bitcoin Core v28 gecompileerd naar riscv32im. Die code draait vervolgens binnen de zkVM van RISC Zero.
De technische uitleg van de ontwikkelaar noemt onder meer VerifyScript, SignatureHash, transactieregels, Merkle-berekeningen en difficulty-aanpassingen.
Ook libsecp256k1 draait mee voor ECDSA- en Schnorr-handtekeningen.
Dat is belangrijk omdat Bitcoin-regels vol uitzonderingen zitten
Je kunt voor een cryptografische proof ook zelf een nieuwe versie van Bitcoins regels schrijven.
Daar zit risico.
Bitcoin heeft door de jaren heen allerlei uitzonderingen, activatiehoogtes en historische randgevallen verzameld. Eén afwijking kan ertoe leiden dat een perfect werkende proof het verkeerde programma bewijst.
Hazync probeert dat probleem kleiner te maken door zoveel mogelijk echte Core-code te gebruiken.
De open Hazync-repository maakt daar wel een belangrijke nuance bij.
Niet alles komt rechtstreeks uit Bitcoin Core.
Onder meer de UTXO-accumulator is projectcode. Ook bestaan er kleine aanpassingslagen om Core binnen de zkVM te laten draaien.
De aanpak voorkomt dus geen nieuwe code.
Hij verkleint vooral het deel waarin Bitcoins consensusregels opnieuw moeten worden vertaald.
1.789 blokken werden samengevouwen tot 226 kilobyte
De bekendste benchmark komt uit de genesis-anchored spine.
Dat is één samengevoegd bewijs dat vanaf het begin van Bitcoin naar een bepaald block loopt.
De ontwikkelaar testte een receipt van 226.434 bytes voor blocks 1 tot en met 1.789.
Een standalone verifier van ongeveer 1,7 MB controleerde dat bestand in 27 milliseconden.
Daarvoor was geen GPU nodig.
Ook hoefde de verifier geen Bitcoin-node te draaien of de onderliggende blocks opnieuw te downloaden.
De zware berekening gebeurt aan de voorkant. De uiteindelijke controle wordt juist extreem licht.
Dat is de hele rekensom achter Hazync.
Live proof is alweer verder dan de oorspronkelijke benchmark
De proof van 1.789 blocks was een momentopname uit de publicatie van 15 augustus.
Het live Hazync-endpoint laat op 23 augustus een genesis-anchored proof zien die loopt van block 1 tot block 11.580.
Die actuele receipt is ongeveer 226,7 kB groot.
Dat betekent niet automatisch dat ook deze versie exact in 27 milliseconden wordt geverifieerd.
De 27 ms is de gepubliceerde benchmark van de eerdere proof.
Wel laat het zien waarom recursieve proofs interessant zijn. Het aantal bewezen blocks kan sterk stijgen zonder dat het uiteindelijke bestand evenredig groter wordt.
Zero-knowledge klinkt hier ingewikkelder dan het is
Hazync gebruikt RISC Zero, een zogenoemde zero-knowledge virtual machine.
Een zero-knowledge proof maakt het mogelijk om cryptografisch iets over een berekening aan te tonen zonder dat de controleur die berekening opnieuw hoeft uit te voeren.
Bij Hazync draait het vooral om die tweede eigenschap.
De zkVM voert het Bitcoin-validatieprogramma uit en produceert een cryptografische receipt.
De verifier controleert vervolgens dat die receipt hoort bij de verwachte programmaversie en geldige uitvoering.
RISC Zero beschrijft dezelfde werkwijze: een receipt koppelt de uitkomst aan de code die via een specifieke ImageID is uitgevoerd.
Daarom kan controleren zo veel goedkoper zijn dan bewijzen.
Proof maken is een totaal ander verhaal
Hier verdwijnt het magische gevoel snel.
Hazync testte bijvoorbeeld Bitcoin-block 741.000.
Dat block bevatte 670 inputs en vereiste 394 UTXO-leaves binnen het systeem.
De proof werd verdeeld over zestien stukken en met twee Nvidia L40S-GPU's verwerkt.
Totale tijd: ongeveer 55 minuten.
Alleen het samenvoegen van de zestien delen kostte al ongeveer 27 minuten.
Dat is een veel eerlijkere indicatie van de kosten bij moderne Bitcoin-data dan de piepkleine vroege blocks.
Volledige geschiedenis wordt op 17 GPU-jaren geschat
Vanuit zulke metingen komt de opvallendste raming.
De ontwikkelaar schat een volledige backfill vanaf genesis tot de huidige chain-tip op ongeveer 17 GPU-jaren.
Dat betekent niet dat één videokaart letterlijk zeventien jaar moet wachten.
Het werk kan sterk worden verdeeld.
Zeventien GPU's zouden dezelfde totale hoeveelheid rekenwerk theoretisch in ongeveer één jaar kunnen uitvoeren. Meer hardware kan de kalenderduur verder verkorten.
Maar de hoeveelheid rekenwerk verdwijnt daarmee niet.
De 17 GPU-jaren zijn bovendien een schatting, geen afgeronde meting van de volledige Bitcoin-geschiedenis.
Die complete proof is nog niet gemaakt.
Daarna zijn nog ongeveer zes L40S-GPU's nodig
Een eenmalige historische proof is ook niet genoeg.
Bitcoin produceert voortdurend nieuwe blocks.
Hazync schat dat rekenkracht gelijk aan ongeveer zes Nvidia L40S-GPU's nodig is om daarna ongeveer met de nieuwe chain-tip mee te blijven lopen.
Dat creëert een vreemde asymmetrie.
Miljoenen gebruikers zouden een proof goedkoop kunnen controleren.
Maar een veel kleinere groep gespecialiseerde partijen moet het zware provingwerk blijven doen.
Dat hoeft op zichzelf geen vertrouwensprobleem te zijn. Iedereen kan een correct bewijs verifiëren.
Het creëert wel een economische concentratie aan de kant van het rekenwerk.
Waarom zou je die enorme GPU-rekening accepteren?
Omdat dezelfde proof opnieuw kan worden gebruikt.
Bij het huidige model voert iedere nieuwe node zelf een groot deel van de historische controle uit.
Bitcoin Core vraagt momenteel om een eenmalige download van ongeveer 600 GB. Daarna groeit die hoeveelheid maandelijks verder. Dat staat op de officiële downloadpagina van Bitcoin Core.
Core gebruikt al technieken om synchronisatie praktischer te maken.
Zo kan assumevalid bepaalde oude scriptcontroles overslaan wanneer een bekend block in de chain zit. De Bitcoin Core-code maakt die keuze expliciet configureerbaar.
Hazync gaat conceptueel verder.
Het wil historische geldigheid in één herbruikbaar bewijs stoppen.
Dan hoeft niet iedere nieuwe machine dezelfde berekening nogmaals te betalen.
Een browser kan de proof lokaal controleren
Dat maakt kleine apparaten interessant.
Hazync heeft naast de standalone verifier ook een WebAssembly-versie gebouwd.
Volgens het project is die ongeveer 295 kB gecomprimeerd en gebruikt hij rond 1,9 MiB geheugen.
Daardoor kan de controle lokaal in een browser plaatsvinden.
Dat onderscheid is belangrijk voor lichte clients.
Een gebruiker hoeft dan niet aan een externe server te vragen: “Is deze Bitcoin-chain geldig?”
De gebruiker kan zelf de cryptografische receipt controleren.
Dat komt dichter bij Bitcoins oude principe van zelf verifiëren, maar met een heel andere verdeling van rekenwerk.
Toch vervangt dit vandaag geen Bitcoin-node
Hier moet een harde streep staan.
Hazync is een onderzoeksproject.
Het heeft geen volledige genesis-tot-tip proof geproduceerd. De software heeft ook nog geen professionele onafhankelijke audit afgerond.
De ontwikkelaar meldt wel meerdere interne reviews en twee externe AI-ondersteunde reviews.
Die vonden geen route waarmee een ongeldige chain als geldig werd geaccepteerd.
Dat is geen vervanging voor een volledige securityaudit.
De Hazync-repository noemt vooral de C++-aanpassingslaag en de UTXO-accumulator als onderdelen die extra onderzoek verdienen.
De proof weet ook niet automatisch welke Bitcoin-chain wint
Een tweede beperking zit in proof-of-work.
Een validity proof kan aantonen dat een reeks blocks voldoet aan de bewezen regels.
Maar stel dat er twee geldige ketens bestaan.
Welke is dan Bitcoin?
Hazync lost dat niet magisch op.
De proof legt cumulatieve proof-of-work vast. Een node moet daarna nog steeds concurrerende ketens vergelijken.
Bij Bitcoin wint volgens de bestaande regels de geldige keten met het meeste opgebouwde werk.
De oorspronkelijke Bitcoin-paper beschrijft dat principe al.
Hazync comprimeert validatie.
Het vervangt de chainselectie niet.
Historische transactiedata blijft ergens nodig
Ook opslag verdwijnt niet volledig.
Een proof is niet hetzelfde als de data waarover hij iets bewijst.
Oude transacties, signatures en andere witnesses moeten ergens beschikbaar blijven.
Dat wordt extra belangrijk wanneer Hazync zelf verandert.
Iedere programmaversie heeft een eigen METHOD_ID. Dat is de cryptografische vingerafdruk van de code waarop de proof rust.
Verandert die code, dan krijgen nieuwe proofs een andere identiteit.
Oude historische data kan dan nodig zijn om de Bitcoin-geschiedenis opnieuw te bewijzen.
Archive nodes blijven daardoor een rol houden.
Het project heeft zijn historische proof al meerdere keren moeten resetten
Dat is niet alleen theoretisch.
Hazync startte zijn genesis-board op 4 augustus 2026 opnieuw nadat een interne controle tot een nieuwe programmaversie leidde.
Volgens de ontwikkelaar was dat op dat moment zelfs de vierde reset in drie dagen.
Dat laat zien waarom het project nog niet simpelweg honderden GPU's op de volledige chain zet.
Een nieuwe fout die een codewijziging vereist, kan enorme hoeveelheden reeds uitgevoerd provingwerk waardeloos maken.
Eerst moet de basis stabiel worden.
Dan pas wordt brute rekenkracht rationeel.
Dit raakt een fundamenteel Bitcoin-principe
Het interessante aan Hazync is daarom niet de spectaculaire 27 milliseconden.
Het experiment raakt een veel oudere vraag.
Moet iedere nieuwe Bitcoin-gebruiker historische berekeningen zelf opnieuw uitvoeren om onafhankelijk te kunnen verifiëren?
Of kan één groep het zware rekenwerk doen, waarna iedereen de uitkomst cryptografisch controleert zonder die groep te vertrouwen?
Voor een klassieke blockchain klinkt dat bijna tegenstrijdig.
Zelf controleren is juist een kernpunt van het model.
Hazync probeert alleen te veranderen wat een gebruiker zelf controleert.
Niet meer ieder historisch script opnieuw.
Wel het cryptografische bewijs dat die scripts onder de vastgelegde regels zijn uitgevoerd.
27 milliseconden is dus de verkeerde headline én de juiste
De benchmark is echt.
Een proof over blocks 1 tot en met 1.789 werd volgens de ontwikkelaar in 27 milliseconden gecontroleerd.
Maar niemand heeft Bitcoins volledige geschiedenis in 27 milliseconden gesynchroniseerd.
Aan de voorkant staat een geschatte rekening van 17 GPU-jaren. Daarna is blijvend GPU-vermogen nodig om nieuwe blocks te bewijzen.
Daarbovenop komen audits, dataopslag en mogelijke nieuwe resets van de proofgeschiedenis.
Toch laat Hazync iets zien wat technisch moeilijk te negeren is.
De zware Bitcoin-validatie en de uiteindelijke controle daarvan hoeven niet even duur te zijn.
De proof kan in milliseconden worden gecheckt. Het bewijzen van Bitcoin zelf blijft voorlopig een klus voor een stapel GPU's.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
