Merkle-tre vs Verkle-tre: 23x Mindre Bevis [2026]

Ethereum har lenge lovet noe kalt «statsløse klienter» – noder som kan verifisere blokker uten å lagre hele tilstanden til kjeden lokalt. Løsningen som skulle gjøre det mulig heter Verkle-trær, og de er bygget for å erstatte den 12 år gamle arbeidshesten Merkle-treet i deler av Ethereums datastruktur. Forskjellen handler om bevisstørrelse: der et Merkle-bevis for én Ethereum-konto i dag veier rundt 3 kilobyte, kan et tilsvarende Verkle-bevis komme ned mot 150–200 byte, ifølge Ethereum.org sin egen veikart-dokumentasjon. For 1000 kontoer i en vitne-transaksjon blir forskjellen enda tydeligere: rundt 3,5 megabyte med Merkle-bevis mot omtrent 150 kilobyte med Verkle-bevis, en reduksjon på over 23 ganger.

Men Verkle-trær er ikke en gratis oppgradering. De bytter bort noe Merkle-trær har hatt siden Ralph Merkle patenterte konseptet i 1979: motstand mot kvantedatamaskiner. Verkle-trær bygger på KZG-forpliktelser (Kate-Zaverucha-Goldberg), som lener seg på elliptisk kurve-paring og dermed er sårbare for Shors algoritme på samme måte som RSA og ECC. I denne sammenligningen går vi gjennom hva hver struktur faktisk gjør, hvilke tall som ligger bak påstandene om bevisstørrelse, hvor Ethereums «The Verge»-fase står i 2026, og hvem som fortsatt bør holde seg til gammeldagse Merkle-trær.

Sammenligningen er mer enn en akademisk øvelse for utviklere langt fra blokkjede-verdenen. Merkle-trær dukker opp overalt i moderne infrastruktur – fra Git-repositoriet på laptopen din til TLS-sertifikatet som sikrer denne siden – og valget mellom hash-basert og vektor-forpliktelsesbasert autentisering er relevant for alle som designer et system der noen skal kunne bevise at data er inkludert uten å laste ned alt sammen. Vi går gjennom tallene med kildehenvisning gjennomgående, siden dette er et område der teoretiske idealtall og reell produksjonsytelse ofte spriker mye.

Hva er et Merkle-tre?

Et Merkle-tre er en hierarkisk hash-struktur. Bunnivået (bladene) er hasher av de faktiske dataene – en transaksjon, en kontotilstand, en fil. Hvert nivå over hasher sammen parene av barn under seg, helt til man ender opp med én enkelt hash på toppen: rot-hashen. Endrer man ett eneste bit i ett blad, endrer hele veien opp til roten seg, noe som gjør treet ideelt til å bevise at data ikke har blitt tuklet med.

Det som gjør Merkle-trær nyttige i praksis, er at man ikke trenger å laste ned hele treet for å bevise at én bit av data er med. Et såkalt inkluderingsbevis («Merkle-bevis») består bare av søsken-hashene langs stien fra bladet til roten. For et tre med n blader vokser dette beviset med O(log n) – det vil si logaritmisk, ikke lineært. Det er derfor Bitcoin kan la en lommebok-app verifisere at en transaksjon er inkludert i en blokk uten å laste ned hele blokkjeden (såkalt SPV – Simplified Payment Verification).

Selve hash-funksjonen som brukes varierer: Bitcoin bruker dobbel SHA-256, Ethereum bruker Keccak-256, Git bruker SHA-1 (og migrerer gradvis til SHA-256). Sikkerheten i et Merkle-tre hviler utelukkende på kollisjonsmotstanden til den underliggende hash-funksjonen – det finnes ingen algebraisk struktur å angripe med en kvantealgoritme utover Grovers algoritme, som bare gir en kvadratrot-forbedring og dermed ikke bryter treet i praksis selv med store kvantedatamaskiner.

Hva er et Verkle-tre?

Verkle-tre er en sammentrekning av «vektor-forpliktelse» (vector commitment) og «Merkle-tre». Konseptet ble formalisert av Ethereum-grunnlegger Vitalik Buterin i et blogginnlegg fra juni 2021, og siden da har det vært en kjernebrikke i Ethereums langsiktige veikart under fasen kalt «The Verge». I stedet for å hashe barn-noder sammen, forplikter hver node seg til en hel vektor av barneverdier ved hjelp av en polynomisk forpliktelse – som regel en KZG-forpliktelse (Kate-Zaverucha-Goldberg).

Praktisk betyr det at ett enkelt polynom kan representere hundrevis av barn-noder samtidig, og et bevis for at en bestemt verdi finnes i det polynomet («en åpning») kan komprimeres til en konstant størrelse – uavhengig av hvor mange barn noden har. Det er dette som gjør at Verkle-bevis ikke vokser logaritmisk som Merkle-bevis, men holder seg nær konstant selv når treet blir bredere. Ethereums referanseimplementasjon bruker en forgreningsfaktor på 256, og en enkelt KZG-forpliktelse er typisk 48 byte, ifølge Ethereum.org sin tekniske dokumentasjon om Verkle-trær.

Prisen for denne komprimeringen er beregningskraft. Å konstruere et Verkle-bevis krever multi-skalar-multiplikasjon over en parings-vennlig elliptisk kurve (Ethereum bruker BLS12-381), og ifølge åpen kildekode-implementasjoner av Verkle-protokollen kreves det omtrent K × 257 elliptiske kurve-operasjoner der K er antall noder i beviset. Det er flere størrelsesordener tyngre enn å hashe noen byte sammen, som er alt et Merkle-tre krever.

Kort historie: fra et patent i 1979 til Buterins forslag i 2021

Merkle-treet er oppkalt etter kryptografen Ralph Merkle, som beskrev strukturen i sin doktorgradsavhandling og patenterte den i 1979 – lenge før noen hadde hørt om blokkjeder. Ideen var opprinnelig et svar på et helt annet problem: hvordan man kan bygge digitale signaturer fra ren hash-basert kryptografi, uten å stole på tallteoretiske antakelser som primtallsfaktorisering. Det tok flere tiår før strukturen fikk sitt store gjennombrudd, da Satoshi Nakamoto brukte den til å forplikte transaksjoner i Bitcoins blokkheader i 2009. Siden den gang har Merkle-treet blitt en av de mest gjenbrukte datastrukturene i hele informatikkfaget, langt utenfor kryptovaluta.

Verkle-treet er langt yngre. Vitalik Buterin publiserte det opprinnelige forslaget på sin personlige blogg i juni 2021, og navnet er hans egen sammentrekning av «vector commitment» og «Merkle tree». Motivasjonen var spesifikk: Ethereums tilstandstre hadde vokst så mye at et fullt Merkle-bevis for statsløs verifisering ble upraktisk stort, og teamet lette etter en kryptografisk primitiv som kunne gi samme sikkerhetsgaranti med et brøkdels bevis. KZG-forpliktelser, som selv stammer fra et akademisk papir av Aniket Kate, Gregory Zaverucha og Ian Goldberg fra 2010, viste seg å passe godt til formålet fordi de allerede var i bruk i andre deler av Ethereums økosystem, blant annet i danksharding-designet for datatilgjengelighet.

Det er verdt å merke seg at Verkle-treet ikke er en konkurrent til Merkle-treet i vanlig forstand – det er designet som en direkte erstatning for én spesifikk jobb: Ethereums statstre. Det finnes ingen ambisjon om at Verkle-trær skal erstatte Merkle-trær i Bitcoin, Git eller Certificate Transparency, siden disse systemene ikke har det samme presset for å redusere statsløse bevis til minimum. Det gjør sammenligningen litt asymmetrisk: den ene strukturen er en generell, moden løsning brukt overalt, den andre er en spesialisert løsning bygget for ett bestemt problem i ett bestemt nettverk.

Merkle-tre vs Verkle-tre: full spesifikasjonstabell

Under følger en direkte sammenligning av de to strukturene på de metrikkene som faktisk avgjør hvilken som passer til et gitt system. Tallene for Ethereum-konteksten er hentet fra Ethereum.org sin Verkle-dokumentasjon og fra AntChain Open Labs’ analyse av Verkle-implementasjoner ved forgreningsfaktor 256.

Egenskap	Merkle-tre	Verkle-tre
Underliggende primitiv	Kryptografisk hash-funksjon (SHA-256, Keccak-256)	Polynomisk/vektor-forpliktelse (KZG)
Bevisstørrelse (skalering)	O(log n) – vokser med treets dybde	~O(1) – nær konstant størrelse
Bevis per Ethereum-konto	~3 KB (Merkle Patricia Trie)	~150–200 byte
Vitne for 1000 kontoer	~3,5 MB	~150 KB
Statsløst blokk-vitne	~10 MB	~200 KB (rundt 98 % reduksjon)
Enkelt-forpliktelsesstørrelse	32 byte (hash)	48 byte (KZG-forpliktelse)
Verifiseringskostnad	O(log n) hash-operasjoner (billig)	Elliptisk kurve-paring per bevis (tyngre)
Krever trusted setup	Nei	Ja, for KZG-parametrene
Kvantesikker	Ja (kun sårbar for Grovers algoritme)	Nei (sårbar for Shors algoritme)
Typisk forgreningsfaktor	2 (binær) eller 16 (Ethereum MPT)	256
Modenhet / produksjonsstatus	Produksjonsklar siden 2009 (Bitcoin), 2015 (Ethereum)	Under aktiv utvikling, ikke på mainnet per august 2026
Reelle implementasjoner i dag	Bitcoin, Ethereum, Git, Certificate Transparency	Ethereum testnett, forskningsprototyper

Bevisstørrelse: fra kilobyte til byte

Tallene i tabellen over kommer ikke fra ett enkelt sted, og det er verdt å understreke at de spriker litt avhengig av hvem som måler. Ethereum.org sin offisielle Verkle-side oppgir at et vitne som dekker 1000 blader krever rundt 3,5 megabyte med den nåværende Merkle Patricia Trie-strukturen (som har syv nivåer), mot omtrent 150 kilobyte med et Verkle-tre (fire nivåer) – en forskjell på over 23 ganger. AntChain Open Labs har gjort en uavhengig analyse og kommer fram til at Merkle-bevis for datamengder i milliardklassen ligger rundt 1 kilobyte, mens tilsvarende Verkle-bevis med en forgreningsfaktor på 256 kommer under 150 byte.

En tredje datakilde – forskningspapiret «Towards Stateless Clients in Ethereum» fra 2025–2026 – tegner et mer nyansert bilde. Der de teoretiske tallene fra Ethereum.org peker mot bevis ned mot 150 byte, viser faktiske Verkle-implementasjoner som er testet i praksis proof-størrelser opp mot én megabyte og vitne-størrelser rundt 0,8 megabyte per blokk, med enkelte konfigurasjoner som når 2,6 megabyte når man inkluderer bladdata og SNARK-bevis. Konklusjonen er at de ideelle tallene på 150–200 byte gjelder den rene KZG-åpningen, ikke det fulle vitnet som en klient faktisk må laste ned og verifisere i en ekte implementasjon.

Dette betyr ikke at gevinsten er fiktiv – selv de mer konservative benchmarkene viser en klar reduksjon sammenlignet med dagens Merkle Patricia Trie. Men det er en påminnelse om at «23x mindre» er et teoretisk beste-tilfelle-tall, og at ingeniørarbeidet med å komprimere reelle vitner ned mot de teoretiske grensene fortsatt pågår i 2026.

Uavhengige benchmarks: tre kilder, tre ulike tall

Fordi Verkle-trær ennå ikke kjører i produksjon, finnes det ikke ett offisielt, autoritativt benchmarktall slik man for eksempel har for TLS-håndtrykk eller hash-hastighet. I stedet må man sammenholde flere uavhengige kilder som måler forskjellige ting under forskjellige forutsetninger. Tabellen under stiller opp de tre kildene som oftest siteres i 2025–2026-diskusjonen om Verkle-ytelse, side om side.

Kilde	Målemetode	Resultat for Verkle-bevis
Ethereum.org (offisiell veikart-dokumentasjon)	Teoretisk beregning ved forgreningsfaktor 256	~150 KB for 1000-blad-vitne (mot ~3,5 MB for Merkle)
AntChain Open Labs	Analyse av KZG-baserte Verkle-implementasjoner i milliard-element-skala	<150 byte per bevis (mot ~1 KB for Merkle)
«Towards Stateless Clients in Ethereum» (forskningspapir 2025–2026)	Faktisk kjørende Verkle-klient, målt per blokk	~0,8–2,6 MB per blokk, avhengig av konfigurasjon

Spennet mellom disse tallene er ikke en motsigelse, men et resultat av at de måler forskjellige ting. Ethereum.org og AntChain Open Labs regner på den rene, matematiske KZG-åpningen – det minste mulige beviset gitt idealiserte forutsetninger. Forskningspapiret om statsløse klienter måler derimot hele blokkens vitne slik en ekte klient faktisk må laste ned og verifisere, inkludert bladdata, metadata og eventuelle SNARK-tillegg som brukes for å komprimere selve KZG-bevisene ytterligere. Det er denne typen gap mellom teori og produksjonskode som forklarer hvorfor Ethereum-teamet fortsatt ikke har satt en mainnet-dato: de siste 80–90 prosentene av optimaliseringen er ofte den vanskeligste delen av en slik migrering.

Ytelse og beregningskostnad

Mindre bevis er ikke gratis. Et Merkle-bevis verifiseres ved å hashe et lite antall byte sammen langs en sti – noe en vanlig CPU-kjerne gjør på mikrosekunder selv for tusenvis av verifiseringer i sekundet. Et Verkle-bevis verifiseres derimot med elliptisk kurve-paring, en operasjon som er flere størrelsesordener tyngre enn en hash-beregning. Utviklerdokumentasjon for KZG-baserte systemer peker på at selve forpliktelsen er liten (48 byte), men at det ligger FFT-beregninger (Fast Fourier Transform) og parings-operasjoner bak både generering og verifisering.

På konstruksjonssiden er kostnaden enda tydeligere. Åpne implementasjoner av Verkle-protokollen viser at det kreves rundt K × 257 elliptiske kurve-operasjoner for å bygge et bevis, der K er antall noder som inngår. For en full blokk med tusenvis av kontoendringer legger dette seg oppå den vanlige blokkbehandlingstiden til en validator. Merkle-trær har ikke dette problemet: hashing er en av de billigste operasjonene en moderne CPU kan gjøre, og det er nettopp derfor Bitcoin og Ethereum har klart seg med Merkle-baserte strukturer i over et tiår uten at verifiseringskostnaden har vært en flaskehals.

Det er verdt å nevne at «tyngre» ikke betyr «uholdbart». Ethereums validator-maskinvare i 2026 håndterer allerede krevende signaturverifisering (BLS-signaturer for konsensus), så ekstra parings-operasjoner for statstilgang er et beregnet bytte, ikke en showstopper. Men det er en reell kostnad som må veies mot båndbredde- og lagringsgevinsten, spesielt for lette klienter og mobilbaserte lommebøker med begrenset prosessorkraft.

Alternativer til KZG: IPA-forpliktelser og binære hash-trær

KZG er ikke den eneste veien til et vektor-forpliktelsesbasert tre, og det er verdt å nevne alternativene siden de påvirker hvor mye av Verkle-diskusjonen som faktisk handler om quantum-sårbarhet spesifikt versus vektorforpliktelser generelt. Et alternativ som har vært diskutert i Ethereums forskningsmiljø er IPA-forpliktelser (Inner Product Argument), som ikke krever en trusted setup-seremoni slik KZG gjør, men til gjengjeld gir større bevis og tregere verifisering. Poenget med IPA er å fjerne behovet for at noen må generere og deretter «glemme» et hemmelig tall under oppsettet – noe som eliminerer en hel kategori av tillitsantakelser, men på bekostning av effektivitet.

Det andre sporet er de binære hash-trærne som core dev-miljøet har begynt å utforske parallelt med Verkle. Tanken her er enklere: i stedet for å bytte til en helt ny kryptografisk primitiv, kan man omstrukturere det eksisterende Merkle Patricia-treet til en binær form med lavere forgreningsfaktor, som reduserer bevisstørrelsen noe uten å innføre elliptisk kurve-paring eller trusted setup i det hele tatt. Gevinsten er mindre enn med full Verkle-KZG, men risikoen og kompleksiteten er også vesentlig lavere – og strukturen forblir kvanteresistent, siden den fortsatt bare er hashing.

Dette er grunnen til at «Verkle vs Merkle»-debatten i praksis er tre veier, ikke to: ren Merkle (i dag), KZG-basert Verkle (Ethereums opprinnelige plan) og binære hash-trær eller IPA-Verkle (kompromissene som utforskes hvis KZG-kompleksiteten viser seg for høy). Hvilken vei Ethereum til slutt lander på, avgjør om nettverket beholder kvanteresistens på bekostning av noe av komprimeringsgevinsten, eller om det aksepterer kvante-sårbarhet for å få den fulle 23x-reduksjonen KZG lover på papiret.

Kvantesikkerhet: hvorfor Verkle-trær er sårbare

Dette er kanskje det viktigste punktet for lesere som følger med på kvantesikker kryptografi. KZG-forpliktelser hviler på den diskrete logaritme-antakelsen over parings-vennlige elliptiske kurver som BLS12-381 – samme type matematisk problem som RSA og ECC er bygget på. En tilstrekkelig stor kvantedatamaskin som kjører Shors algoritme ville kunne bryte denne antakelsen og dermed forfalske Verkle-bevis. NIST har allerede satt deprecation-tidslinjer for tilsvarende klassisk kryptografi: 112-bit RSA-styrke skal fases ut etter 2030 og forbys helt etter 2035, ifølge NIST IR 8547.

Merkle-trær har motsatt egenskap. Fordi sikkerheten kun avhenger av kollisjonsmotstanden til en hash-funksjon, og ikke av noen algebraisk struktur, regnes de som kvanteresistente i praksis – den eneste kjente kvantefordelen er Grovers algoritme, som i beste fall gir en kvadratrot-akselerasjon mot en brute-force hash-kollisjon, noe som enkelt kompenseres ved å bruke en litt lengre hash (for eksempel SHA-256 i stedet for kortere alternativer).

Forskningsmiljøet er klar over problemet. Det pågår aktivt arbeid med post-kvante Verkle-lignende strukturer, blant annet en konstruksjon kalt VERKLE-FRI som kombinerer vektor-forpliktelser med gitterbaserte skjema og FRI (Fast Reed-Solomon IOP). Et 2026-forskningspapir rapporterer bevisstørrelser på rundt 180 kilobyte for å autentisere 2^26 elementer i et slikt oppsett, sammenlignet med rundt 0,8 kilobyte for et tradisjonelt Merkle-bevis i samme kontekst. Det illustrerer godt hva kvantesikkerhet koster: du bytter bort mesteparten av komprimeringsgevinsten Verkle-trær var designet for å gi.

For Ethereum spesifikt er kvante-spørsmålet delvis frikoblet fra selve statstre-strukturen. Selv om nettverket beveger seg til KZG-baserte Verkle-trær for tilstandsbevis, er det ikke det samme som at hele Ethereums sikkerhetsmodell blir kvante-sårbar over natten – validatorenes konsensussignaturer, kontoenes signaturer og selve statstreet er separate kryptografiske lag som hver for seg kan oppgraderes til post-kvante alternativer i eget tempo. Men det betyr at en fullstendig kvantesikker Ethereum-fremtid krever at også Verkle-laget til slutt erstattes eller suppleres med en post-kvante variant, noe som legger enda et lag med langsiktig migreringsarbeid oppå det som allerede diskuteres for signaturer og nøkkelutveksling.

Ethereums veikart: hvor står «The Verge» i 2026?

Verkle-trær er en del av Ethereums flerfasede veikart, spesifikt fasen kjent som «The Verge», som handler om å gjøre nettverket statsløst – det vil si at validatorer skal kunne verifisere blokker uten å lagre hele den globale tilstanden lokalt. Per august 2026 beskriver Ethereum.org sin offisielle roadmap-side Verkle-implementasjonen som «under arbeid», uten en fastsatt dato for aktivering på mainnet.

Arbeidet er ikke nytt – det har pågått med spesifikasjon og prototyping i flere år, formalisert blant annet gjennom EIP-6800, som definerer hvordan statstreet skal endres til Verkle-format. Men veien har vært lengre enn opprinnelig ventet. Benchmarking-rapporter fra 2025–2026 peker på flere årsaker til forsinkelsen: kompleksiteten i selve implementasjonen, de høyere beregningskostnadene ved bevisgenerering og -verifisering, og behovet for å koordinere en trusted setup-seremoni for KZG-parametrene – noe som krever bred deltakelse fra samfunnet for å være tillitsverdig.

Som en konsekvens har Ethereums kjerneutviklere begynt å utforske alternativer parallelt med Verkle-sporet, blant annet optimaliserte binære hash-trær som kunne gi deler av de samme fordelene uten å måtte innføre en helt ny kryptografisk primitiv. Disse diskusjonene skjer løpende i Ethereums core dev-møter og er dokumentert i forsknings- og utviklerskriv om statsløs Ethereum. Konklusjonen fra flere analytikere er at Verkle fortsatt står som det offisielle langsiktige målet, men at 2026-tidslinjen realistisk sett handler om videre testing og koordinering med andre veikart-elementer som historikk-beskjæring, snarere enn en umiddelbar mainnet-aktivering.

Kostnad og infrastrukturpåvirkning

Verken Merkle- eller Verkle-trær har en abonnementspris slik som en sky-tjeneste eller et SaaS-produkt – de er datastrukturer, ikke produkter. Den reelle «prisen» ligger i infrastrukturkostnaden: hvor mye lagringsplass, båndbredde og prosessorkraft en node må sette av. Tabellen under samler de infrastrukturrelevante tallene fra forskningen over, slik at kostnadsbildet blir konkret i stedet for abstrakt.

Ressurs	Med Merkle-tre (i dag)	Med Verkle-tre (planlagt)
Statsløst blokk-vitne å laste ned	~10 MB per blokk	~200 KB per blokk (~98 % mindre)
Vitne for 1000 kontoer	~3,5 MB	~150 KB
Bevis per konto	~3 KB	~150–200 byte
Beregning ved verifisering	Lav (hash-operasjoner)	Høy (elliptisk kurve-paring)
Engangskostnad ved oppstart	Ingen	Trusted setup-seremoni (KZG)
Krav til nodemaskinvare	Standard, uendret siden 2015	Noe høyere CPU-krav for bevisgenerering

For en enkeltbruker som kjører en Ethereum-node hjemme, er båndbredde- og lagringsgevinsten den som faktisk merkes. En statsløs klient som i dag måtte laste ned megabyte med Merkle-vitner per blokk, kan i teorien klare seg med noen hundre kilobyte under Verkle – noe som gjør det langt mer realistisk å kjøre en node på en bærbar internettforbindelse eller en Raspberry Pi, uten at man må sette av hundrevis av gigabyte til lokal tilstand.

Hvem bruker Merkle-trær i dag? Fem reelle eksempler

Merkle-trær er ikke et teoretisk konsept – de kjører produksjonssystemer som håndterer milliarder av dollar og milliarder av forespørsler daglig. Her er de mest konkrete eksemplene:

Bitcoin: Hver blokk inneholder en Merkle-rot i header som forplikter til alle transaksjonene i blokken. Dette gjør det mulig for lette lommebøker (SPV-klienter) å verifisere at en betaling er inkludert uten å laste ned hele blokken – en teknikk som har vært uendret siden Bitcoin ble lansert i 2009, og som fortsatt håndterer flere hundre tusen transaksjoner daglig uten strukturelle endringer.
Ethereums nåværende tilstandstre: Ethereum bruker i dag en Merkle Patricia Trie – en heksadesimal Merkle-variant med innebygde nøkkelstier – til å forplikte til konto- og lagringstilstand i blokkheaderen. Dette er fortsatt produksjonsstrukturen per 2025–2026, mens Verkle venter i kulissene. Selv om Ethereum har gjennomgått flere store protokolloppgraderinger de siste årene, har selve tilstandstre-strukturen stått uendret siden 2015.
Git: Hver commit, hvert tre-objekt og hver fil i et Git-repository hashes inn i en Merkle-DAG (rettet asyklisk graf). Det er derfor en commit-hash unikt identifiserer hele historikken til et repository, og hvorfor det er beregningsmessig umulig å endre en gammel commit uten at det forplanter seg til alle senere hasher.
Certificate Transparency: CT-logger, som håndheves av Chrome for alle offentlig tiltrodde TLS-sertifikater, bruker Merkle-trær til å la hvem som helst verifisere at et sertifikat er offentlig logget uten å laste ned hele loggen. Dette systemet er en direkte forsvarsmekanisme mot uredelig utstedte sertifikater, og har vært obligatorisk for nye sertifikater siden Google innførte håndhevingen.
IPFS og Filecoin: Innholdsadressering i disse systemene bygger på Merkle-DAG-er, der hver fil og mappe identifiseres av en hash som avhenger av alt innholdet under den. Det gjør det mulig å verifisere at nedlastet innhold ikke er endret, selv når det hentes fra en tilfeldig, ikke-tiltrodd node i nettverket.

Verkle-trær har foreløpig ingen tilsvarende liste av produksjonssystemer. De eksisterer i Ethereums testnett og i forskningsprototyper, men ingen stor, offentlig blokkjede kjører Verkle-trær i produksjon per august 2026.

Vanlige misforståelser om Merkle- og Verkle-trær

En vanlig misforståelse er at Verkle-trær skal erstatte Merkle-trær overalt, som en generell oppgradering av kryptografisk hashing. Det stemmer ikke. Verkle-trær er designet spesifikt for scenarioer der man trenger å bevise medlemskap i store, brede datastrukturer med minimalt bevis – som Ethereums globale kontotilstand. For et system som Bitcoin, der Merkle-treet kun forplikter til transaksjonene i én blokk (typisk et par tusen transaksjoner), gir ikke Verkle-trær noen nevneverdig fordel som oppveier kompleksiteten og kvante-sårbarheten de introduserer.

En annen misforståelse er å tro at kvante-sårbarheten til Verkle-trær er et akutt, umiddelbart problem. Det er den ikke – ingen kjent kvantedatamaskin i 2026 er i nærheten av å kunne kjøre Shors algoritme mot en 256-bit elliptisk kurve i praksis. NISTs egne tidslinjer regner med at klassisk asymmetrisk kryptografi som RSA og ECC først bør fases helt ut mot 2035. Poenget med å fremheve kvantesårbarheten er ikke at Verkle-trær er utrygge i dag, men at de introduserer en avhengighet som må håndteres før den kryptografisk relevante kvantedatamaskinen faktisk dukker opp – og at Merkle-trær slipper unna det problemet helt.

En tredje misforståelse er å anta at «mindre bevis» automatisk betyr «raskere system» totalt sett. Som benchmarkene over viser, er verifiseringskostnaden per bevis faktisk høyere for Verkle-trær enn for Merkle-trær, fordi elliptisk kurve-paring er tyngre enn hashing. Gevinsten kommer på nettverkssiden – mindre data å laste ned og lagre – ikke på ren CPU-hastighet ved verifisering. For et system med begrenset båndbredde, men rikelig med prosessorkraft, er dette et opplagt godt bytte. For et system med motsatt flaskehals kan regnestykket se annerledes ut.

Migreringsguide: slik forbereder utviklere seg på Verkle-overgangen

For team som bygger klientprogramvare, lommebøker eller smartkontrakt-verktøy på Ethereum, er det ingen grunn til å migrere i dag – men det er god grunn til å begynne å forberede seg. Her er stegene analytikere og kjerneutviklere anbefaler:

Følg EIP-6800 og de løpende referatene fra Ethereums core dev-møter for å holde deg oppdatert på spesifikasjonsendringer.
Test klientprogramvaren din mot Verkle-testnett så snart Ethereum-teamet gjør dem tilgjengelige for utviklere.
Oppgrader nodeklienten din (Geth, Nethermind, Besu, Erigon) til versjoner som annonserer Verkle-støtte når de slippes.
Revider smartkontrakter og verktøy som er avhengige av dagens gasskostnadsmodell for SLOAD/SSTORE, siden disse kan endres under overgangen.
Oppgrader lommebok- og RPC-biblioteker (ethers.js, web3.js, viem) til versjoner som kan tolke det nye bevisformatet.
Sett opp overvåkning for vitnestørrelse og synkroniseringstid i statsløs klient-konfigurasjon, slik at du kan måle den faktiske gevinsten mot de teoretiske tallene.
Avgjør om noden din skal kjøre som full node, statsløs klient eller lett klient etter overgangen – kravene endrer seg for hver kategori.
Planlegg for en periode med parallell drift der både gammelt og nytt tre eksisterer samtidig under selve migreringen.
Følg med på og om mulig delta i trusted setup-seremonien for KZG-parametrene, siden bred deltakelse styrker tilliten til oppsettet.
Ha en beredskapsplan i tilfelle Ethereum-teamet lander på et binært hash-tre-alternativ i stedet for eller i tillegg til Verkle.

Fordeler og ulemper

Merkle-tre – fordeler:

Kvanteresistent i praksis, kun sårbar for Grovers algoritme
Ingen trusted setup nødvendig
Lav beregningskostnad ved verifisering (ren hashing)
Utprøvd i produksjon siden 2009 (Bitcoin) og 2015 (Ethereum)
Enkel å implementere og revidere

Merkle-tre – ulemper:

Bevis vokser logaritmisk med treets størrelse, opp mot flere megabyte for statsløse klienter
Blir en flaskehals for båndbredde-begrensede lette klienter og mobil

Verkle-tre – fordeler:

Nær konstant bevisstørrelse uavhengig av treets bredde
Opp mot 23 ganger mindre vitner for 1000-kontobevis ifølge Ethereum.org
Muliggjør statsløse klienter og lettere synkronisering for nye noder
Drastisk redusert båndbreddebehov, opp mot 98 % reduksjon i blokk-vitner

Verkle-tre – ulemper:

Ikke kvantesikker – sårbar for Shors algoritme via KZG-forpliktelser
Krever en trusted setup-seremoni for KZG-parametrene
Vesentlig tyngre beregningskostnad ved bevisgenerering (K × 257 elliptiske kurve-operasjoner)
Umoden implementasjon – reelle benchmarks viser høyere overhead enn de teoretiske idealtallene
Ingen fastsatt mainnet-dato per august 2026

Anbefalinger etter bruksområde

Valget mellom Merkle- og Verkle-tre avhenger nesten helt av hva slags system du bygger og hvor lang tidshorisont du planlegger for. Her er konkrete anbefalinger for de vanligste scenarioene:

Lette Bitcoin-lommebøker (SPV): Bli med Merkle-tre. Det er standarden, det er modent, og det finnes ingen Verkle-erstatning på Bitcoin-horisonten. Enhver lommebok som skal bygges eller vedlikeholdes i 2026 bør fortsatt implementere klassisk Merkle-bevisverifisering.
PKI- og Certificate Transparency-systemer: Hold deg til Merkle-tre. Kvanteresistens er kritisk for sertifikatinfrastruktur med lang levetid, og CT-standarden er bygget rundt hash-trær som har vist seg robuste i over et tiår med produksjonsdrift.
Ethereum-validatorer og nodeoperatører: Følg Verkle-veikartet tett, men ikke migrer produksjonsinfrastruktur før mainnet-aktivering er offisielt bekreftet av Ethereum-kjerneteamet. Bruk ventetiden til å teste egen infrastruktur mot testnett-versjoner.
Nye Layer 2- eller rollup-prosjekter som designes fra bunnen: Vurder vektorforpliktelser (Verkle-lignende primitiver) tidlig i arkitekturen, siden mindre on-chain bevis reduserer gasskostnader direkte, og det er langt billigere å designe for dette fra start enn å migrere en eksisterende produksjonskjede senere.
Langtidsarkivering og revisjonslogger (10 år eller mer): Velg Merkle-tre. Kvanteusikkerheten rundt KZG-forpliktelser gjør Verkle uegnet for data som må forbli verifiserbar i flere tiår, spesielt i sektorer med regulatoriske krav til dokumentintegritet.
Shardede blokkjeder med behov for kryss-shard-bevis: Vektorforpliktelser kan redusere kommunikasjonskostnaden mellom shards betydelig, og er verdt å evaluere for prosjekter som allerede bygger sharding-arkitektur og har ressurser til å håndtere en trusted setup-prosess.

Dommen: hva sier tallene?

Merkle-treet vinner på modenhet, enkelhet og kvantesikkerhet. Det har kjørt produksjonssystemer i over et tiår uten en eneste strukturell sikkerhetssvikt, det krever ingen trusted setup, og det overlever i praksis et fremtidig angrep fra kvantedatamaskiner. For alt som må vare lenge – sertifikater, arkiver, Bitcoin-transaksjoner – er det fortsatt riktig valg i 2026.

Verkle-treet vinner på ren komprimering. En reduksjon fra 3,5 megabyte til 150 kilobyte for et 1000-konto-vitne, eller fra 10 megabyte til 200 kilobyte for et statsløst blokkvitne, er ikke en marginal forbedring – det er forskjellen mellom en node som krever en kraftig server og en node som kan kjøre på en mobiltelefon. Men den gevinsten er fortsatt teoretisk i stor skala: reelle implementasjoner som er testet i forskningsrapporter fra 2025–2026 viser vesentlig høyere overhead enn idealtallene, og det finnes ingen fastsatt dato for mainnet-aktivering på Ethereum per august 2026.

Konklusjonen er derfor todelt. Bruk Merkle-tre i dag – det er det eneste alternativet som faktisk kjører i produksjon utenfor Ethereums testnett, og det er det trygge valget for alt som trenger å overleve en kvante-fremtid. Følg Verkle-tre som et veikart, ikke som en produksjonsavhengighet, inntil Ethereum-kjerneteamet setter en bekreftet mainnet-dato og de reelle bevisstørrelsene nærmer seg de teoretiske 150–200 byte-tallene i produksjonskode, ikke bare i forskningsbenchmarks.

Ofte stilte spørsmål

Hva er hovedforskjellen mellom Merkle-tre og Verkle-tre?
Merkle-trær hasher barn-noder sammen og gir bevis som vokser logaritmisk med treets størrelse. Verkle-trær bruker polynomiske forpliktelser (KZG) til å forplikte seg til hele vektorer av barn samtidig, noe som gir bevis med nær konstant størrelse uavhengig av treets bredde.

Er Verkle-trær kvantesikre?
Nei. KZG-forpliktelser bygger på elliptisk kurve-paring og den diskrete logaritme-antakelsen, som begge er sårbare for Shors algoritme på en tilstrekkelig kraftig kvantedatamaskin. Merkle-trær, derimot, er kvanteresistente i praksis fordi de kun avhenger av hash-funksjoners kollisjonsmotstand.

Når blir Verkle-trær lansert på Ethereum mainnet?
Det finnes ingen bekreftet dato per august 2026. Ethereum.org sin offisielle roadmap-side beskriver implementasjonen som «under arbeid», og forsinkelser knyttet til kompleksitet og trusted setup-koordinering har fått kjerneutviklere til å utforske alternativer parallelt.

Bruker Bitcoin Merkle-trær eller Verkle-trær?
Bitcoin bruker utelukkende Merkle-trær, og det finnes ingen offentlig plan om å endre dette. Merkle-roten i hver blokkheader forplikter til alle transaksjonene i blokken.

Hvorfor trenger Ethereum Verkle-trær i det hele tatt?
Målet er statsløse klienter. Dagens Merkle Patricia Trie krever at validatorer laster ned megabyte-store vitner for å verifisere blokker uten lokal tilstand, noe som er upraktisk for lette noder. Verkle-trær kan redusere dette vitnet med over 90 %, ifølge Ethereums egne tall.

Hva er en KZG-forpliktelse?
KZG (Kate-Zaverucha-Goldberg) er en polynomisk forpliktelsesordning som lar deg forplikte deg til et polynom med en liten, konstant-størrelse verdi (48 byte i Ethereums implementasjon) og senere bevise verdien av polynomet i et gitt punkt uten å avsløre hele polynomet.

Kan Merkle-trær og Verkle-trær kombineres?
Ja. Flere forskningsforslag, blant annet VERKLE-FRI, kombinerer vektor-forpliktelser med gitterbaserte eller hash-baserte teknikker for å oppnå post-kvante sikkerhet, om enn med større bevisstørrelser enn ren KZG-basert Verkle.

Påvirker overgangen til Verkle-trær gassprisen på Ethereum?
Gasskostnadsmodellen for operasjoner som SLOAD og SSTORE kan endres under overgangen, siden den nye datastrukturen har andre kostnadsegenskaper enn Merkle Patricia Trie. Utviklere som bygger smartkontrakter bør følge EIP-6800 for oppdaterte detaljer.

Er Verkle-trær bare relevant for Ethereum?
Nei, men Ethereum er i praksis det eneste store, offentlige nettverket som aktivt bygger mot produksjonsbruk av Verkle-trær per 2026. Andre blokkjeder og distribuerte systemer følger med på utviklingen, men de fleste venter på at Ethereum skal bevise konseptet i skala før de vurderer en tilsvarende migrering selv.

Hva skjer med eksisterende Merkle-baserte verktøy og biblioteker når Verkle innføres?
De fortsetter å fungere for alt som ikke er avhengig av Ethereums tilstandstre. Verktøy for Bitcoin, Git, Certificate Transparency og andre Merkle-baserte systemer påvirkes ikke av endringer i Ethereums interne datastruktur. Kun Ethereum-spesifikke biblioteker som leser eller genererer statsbevis, som eth_getProof-implementasjoner og lette klient-biblioteker, må oppdateres til å forstå det nye bevisformatet.

Relatert dekning

Kilder: Ethereum.org – Verkle trees roadmap, Vitalik Buterin – Verkle trees, Wikipedia – Merkle tree, EIP-6800, Wikipedia – Certificate Transparency.