Zero-knowledge-bevis har blitt ryggraden i moderne blokkjede-skalering. Rollups som zkSync, Scroll og Polygon zkEVM flytter beregning bort fra Ethereums hovedkjede, men beviser fortsatt at alt gikk riktig for seg gjennom kryptografiske attester kjent som zk-SNARK. To bevissystemer dominerer i praksis: Groth16 og PLONK.

Groth16 kom først. Jens Groth publiserte konstruksjonen i 2016, og den er fortsatt den mest kompakte SNARK-en som finnes: bare tre gruppeelementer, uansett hvor stor kretsen er. PLONK fulgte i 2019, bygget av Ariel Gabizon, Zachary Williamson og Oana Ciobotaru, med et løfte Groth16 aldri kunne gi: et universelt oppsett som dekker mange forskjellige kretser fra samme seremoni.

Valget mellom de to handler ikke om hvilken som er best i abstrakt forstand. Det handler om hva et prosjekt prioriterer. Noen vil ha lavest mulig gasskostnad og minst mulig bevis. Andre vil ha fleksibilitet og enklere drift over tid. Denne artikkelen går gjennom tallene: bevisstørrelse i byte, verifiseringskostnad i gass og dollar, bevistid fra tre uavhengige benchmarker, og hvilke prosjekter som faktisk har valgt hva i 2026.

Begge systemene tilhører familien av parringsbaserte zk-SNARK, altså bevis som lener seg på elliptiske kurver med en bilineær parringsoperasjon. Det skiller dem fra transparente systemer som zk-STARK, der man slipper trusted setup helt, men til gjengjeld får langt større bevis. For norske og nordiske utviklerteam som allerede jobber med Ethereum-baserte rollups eller personvernprotokoller, er spørsmålet sjelden «Groth16 eller STARK», men nettopp «Groth16 eller PLONK», siden begge målretter samme kurver, samme verktøykjeder og samme on-chain-verifikatorer.

Groth16: den kompakte pioneren

Groth16 bygger på det som kalles et Quadratic Arithmetic Program, forkortet QAP. Kretsen som skal bevises, altså selve beregningen, oversettes til et sett polynomiske likninger. Beviseren viser at likningene stemmer ved å evaluere spesialkonstruerte polynomer i et hemmelig punkt, uten å avsløre selve inputen som ligger til grunn.

Resultatet er strukturelt enkelt. Et Groth16-bevis består alltid av nøyaktig tre elliptisk kurve-elementer, typisk to punkter i gruppen G1 og ett i G2. Antall begrensninger i kretsen spiller ingen rolle for bevisstørrelsen. En krets med ti tusen begrensninger og en krets med ti millioner gir samme byte-tall ut, ifølge Alin Tomescus tekniske gjennomgang av Groth16.

Prisen for denne kompaktheten er oppsettet. Hver krets trenger sin egen strukturerte referansestreng (SRS), generert gjennom en flerparts-seremoni der minst én deltaker må destruere sin del av hemmeligheten, det såkalte giftavfallet. Endrer et team kretsen, må de kjøre seremonien på nytt. Det er derfor Zcash, Tornado Cash og Filecoin, alle med relativt stabile og veldefinerte kretser, valgte Groth16 fra starten av.

PLONK: universelt oppsett, fleksibel krets

PLONK bruker en annen arkitektur. I stedet for et QAP bruker PLONK gate-begrensninger organisert i tabeller, en arithmetisering som gjør det mulig å legge til egendefinerte porter og oppslagstabeller uten å bygge om hele bevissystemet fra bunnen.

Den store forskjellen ligger i oppsettet. PLONK, i sin vanligste form med KZG-polynomielle forpliktelser, bruker en universell strukturert referansestreng, ofte kalt Powers of Tau. Samme seremoni kan gjenbrukes av et ubegrenset antall kretser, så lenge de holder seg under en øvre grense for antall begrensninger. Det gjør PLONK langt mer praktisk for team som endrer kretsen ofte, typisk zkEVM-er under aktiv utvikling.

Prisen er et større bevis. Der Groth16 er låst til tre gruppeelementer, må PLONK inkludere flere forpliktelser og et åpningsbevis for polynomene. Det gir et bevis på typisk 512 til 800 byte i produksjonsimplementasjoner over kurvene BN254 eller BLS12-381, ifølge ConsenSys’ gnark-dokumentasjon.

Sikkerhetsantagelser: hva som faktisk må holde

Begge systemene beviser sikkerhet i det som kalles den generiske gruppemodellen, en teoretisk ramme der angriperen bare kan gjøre gruppeoperasjoner, ikke utnytte konkret struktur i kurven. Groth16 er dessuten avhengig av en knowledge-of-exponent-antagelse: gitt bevismaterialet, må det være beregningsmessig umulig å konstruere et gyldig bevis uten faktisk å kjenne vitnet, altså inputen beviset skal skjule. Dette holder så lenge den krets-spesifikke SRS-en ble generert ærlig, med minst én ærlig deltaker i seremonien.

PLONK bygger på en litt annen kombinasjon: polynomiell forpliktelse (KZG eller IPA) pluss Fiat-Shamir-heuristikken, som gjør et opprinnelig interaktivt bevis om til et ikke-interaktivt ett ved å erstatte verifikatorens tilfeldige utfordringer med en hash-funksjon. Svakheter i Fiat-Shamir-implementasjonen har vært en reell kilde til sårbarheter i flere zk-SNARK-biblioteker de siste årene, uavhengig av om selve protokollen er Groth16 eller PLONK. Det er et av argumentene for at seriøse prosjekter, uansett systemvalg, bør kjøre en uavhengig sikkerhetsrevisjon av selve implementasjonen, ikke bare stole på at det matematiske beviset for protokollen er korrekt.

I praksis betyr dette at valget mellom Groth16 og PLONK sjelden bør stå alene som en sikkerhetsvurdering. Begge protokollene regnes som modne og godt granskede i den akademiske litteraturen, men den konkrete koden som implementerer kretsen, seremonien og verifikatoren er der de fleste alvorlige feilene historisk har oppstått. En revisjon bør derfor dekke hele kjeden, fra kretsdefinisjon via seremonigjennomføring til den on-chain-verifikatoren som til slutt avgjør om et bevis godtas eller avvises.

Spesifikasjonstabell: Groth16 mot PLONK

Tabellen under samler nøkkeltallene fra flere uavhengige kilder. Tallene varierer noe mellom implementasjoner, men rekkefølgen er konsistent: Groth16 vinner på størrelse og gass, PLONK vinner på fleksibilitet og seremonigjenbruk. Bruk tabellen som et oppslagsverk gjennom resten av artikkelen, og gå videre til det enkelte avsnittet for kildehenvisninger og kontekst rundt hvert enkelt tall.

EgenskapGroth16PLONK
Bevisstørrelse~192 byte (3 gruppeelementer)~512-800 byte (variantavhengig)
Antall gruppeelementer3 (2×G1, 1×G2)7-9+ elementer og skalarer
Verifiseringstid off-chain~1,2-3,1 ms~5,2 ms
Verifiseringsgass, Ethereum (BN254)~200 000-230 000 + ~7 160/offentlig input~300 000-350 000
Bevistid (SHA-256-krets)3,2 sekunder4,8 sekunder
Trusted setupKrets-spesifikk seremoniUniversell/oppdaterbar (KZG) eller transparent (IPA)
Seremoni-eksempelEgen MPC per kretsPerpetual Powers of Tau, Aztec Ignition
Polynomiell forpliktelseIngen, parvis pairing-sjekkKZG (universell) eller IPA (transparent)
KretsfleksibilitetLav, ny seremoni per endringHøy, samme SRS for mange kretser
Rekursjon (bevis-i-bevis)Krevende, ikke naturlig støttetNaturlig støttet i Halo2 og Plonky2
Vanlige bibliotekersnarkjs, circom, gnark, arkworksHalo2, Plonky2, gnark, o1js
Brukt av (eksempler)Zcash (historisk), Tornado Cash, Filecoin, LoopringzkSync, Aztec, Scroll, Polygon zkEVM, Mina

Bevisstørrelse i praksis: hvorfor tallene spriker

Se man på flere kilder samtidig, spriker de konkrete byte-tallene mer enn man skulle tro. En 2026-benchmark fra StealthCloud måler Groth16 i snarkjs og circom til 192 byte mot PLONK i en Halo2-fork (PSE) til 576 byte for samme SHA-256-krets. Aztecs egen MiMC-benchmark oppgir 0,13 kB for Groth16 og 0,51 kB for PLONK, altså samme forhold på rundt fire ganger.

En akademisk studie publisert på arXiv, Benchmarking ZK-Friendly Hash Functions and SNARK Proving Systems, kommer til andre absolutte tall: Groth16 rundt 800 byte, mot Plonk og Fflonk på rundt 2 kB, avhengig av serialiseringsformat. Forskjellen mellom studiene handler stort sett om hvorvidt man måler rå binærkodede kurve-elementer eller en full JSON-container med metadata.

Mønsteret holder likevel uansett målemetode: Groth16 ligger konsekvent to til fire ganger under PLONK i bevisstørrelse. De mest optimaliserte variantene, som FFLONK, presser tallet enda lenger ned, med rapporterte 100-200 byte i spesialiserte zkEVM-oppsett, mens sublineære prover-varianter som SublonK går motsatt vei og lander på rundt 2,4 kB for å vinne på annen ytelse.

For et prosjekt som skal lagre bevis on-chain, betyr forskjellen på 192 og 800 byte konkrete kalldata-kostnader hver eneste transaksjon. Ethereum priser kalldata per byte, så et Groth16-bevis kan koste under en tidel av et PLONK-bevis bare i ren lagringskostnad, før selve verifiseringsberegningen er tatt med. Det er en av grunnene til at rollups som håndterer svært mange transaksjoner per dag, ofte lander på Groth16 eller FFLONK for det aller siste steget i bevisstrømmen, selv når resten av pipelinen kjører PLONK internt.

Verifiseringskostnad on-chain: gass og dollar

På Ethereum koster verifisering av begge bevistyper ekte penger, fordi hver transaksjon betaler for CPU-syklene noden bruker. Groth16 og de fleste PLONK-implementasjoner over BN254 bruker parrings-presompilen på adresse 0x08, priset til 45 000 + 34 000 × k gass, der k er antall par som sjekkes samtidig.

Ifølge undervisningsmateriell fra IIT Bombays Trust Lab koster en Groth16-verifisering med tre offentlige input rundt 181 000 + 6 150 × 3, altså cirka 199 450 gass. Ved 20 gwei gasspris og en ETH-kurs på 3 000 dollar tilsvarer det omtrent 12 dollar per verifisering. PLONK-verifikatorer, som gjør flere multi-skalar-multiplikasjoner og minst én KZG-åpning, lander typisk på 300 000-350 000 gass for et tilsvarende SHA-256-krets, ifølge samme StealthCloud-benchmark som er brukt i spesifikasjonstabellen over.

BevissystemTypisk gassforbrukKostnad ved 20 gwei / $3 000 per ETHKostnad på L2 (~1 gwei)
Groth16 (3 offentlige input)~199 450 gass~$12~$0,60
PLONK (KZG, BN254)~320 000 gass~$19~$0,96
FFLONK (optimalisert variant)~5 % under Groth16, ~30 % under PLONK~$11-12~$0,55-0,60

Forskjellen mellom 12 og 19 dollar virker liten for én enkelt transaksjon, men skaleres den opp til tusenvis av daglige rollup-bevis, blir gassvalget en reell driftskostnad. Det er hovedgrunnen til at flere rekursive systemer i praksis kjører Plonkish-kretser internt, men pakker det aller siste beviset som skal opp på L1 i Groth16, for å minimere nettopp denne regningen.

Regnestykket endrer seg på lag 2. Med en gasspris på rundt 1 gwei, typisk for en travel L2 fremfor Ethereums hovedkjede, faller kostnaden for begge systemene til under en dollar per verifisering. Da blir differansen mellom Groth16 og PLONK i praksis en avrundingsfeil for enkelttransaksjoner, men den vokser seg stor igjen så snart et prosjekt aggregerer titusenvis av bevis i en enkelt batch og skal verifisere den samlede kostnaden på L1. I det scenariet er det fortsatt Groth16-formatet, ofte som en rekursiv innpakning rundt de underliggende PLONK-bevisene, som gir lavest total regning.

Bevistid: tre benchmarker sammenlignet

Bevistid avhenger sterkt av krets, maskinvare og bibliotek, så et enkelt tall gir sjelden hele bildet. Tre uavhengige kilder viser likevel et konsistent mønster: protokollvalget alene forklarer mindre enn arithmetiseringen av selve kretsen.

StealthClouds 2026-benchmark for en SHA-256-krets gir Groth16 i snarkjs 3,2 sekunder proving-tid, mot 4,8 sekunder for PLONK i en Halo2-fork. Aztecs egen PLONK-benchmark snur derimot bildet på hodet for MiMC, en hashfunksjon designet spesifikt for å være billig i SNARK-kretser: der er PLONK 2,5 ganger raskere enn Groth16 til tross for det større beviset, fordi PLONK sin arithmetisering passer bedre til akkurat den typen krets.

En tredje kilde, en akademisk benchmark fra Lehigh University, sammenligner PLONK-variantene mot hverandre på en stor krets: standard Plonk brukte 101 sekunder, TurboPlonk 138 sekunder (37 prosent tregere) og UltraPlonk 165 sekunder (63 prosent tregere). Rikere funksjonalitet, som egendefinerte porter og oppslagstabeller, koster altså prover-tid selv innad i PLONK-familien. Konklusjonen: velg bevistid-benchmark basert på den faktiske kretsen et prosjekt skal kjøre, ikke på et generisk gjennomsnittstall.

Maskinvaren spiller også inn på en måte som sjelden kommer frem i markedsføringstall. Bevisgenerering er minnetung, og både Groth16 og PLONK skalerer proving-tiden tilnærmelig lineært med antall begrensninger i kretsen. Et team som dobler kretsstørrelsen for å legge til ny funksjonalitet, bør derfor forvente omtrent dobbel proving-tid uansett hvilket av de to systemene de har valgt, med mindre de samtidig bytter til et rammeverk med bedre GPU- eller FPGA-akselerasjon.

Trusted setup: kretsspesifikk seremoni mot universell oppsett

Groth16 krever en ny strukturert referansestreng for hver eneste krets. Seremonien kjøres som en flerparts-beregning der hver deltaker legger til tilfeldighet og deretter destruerer sin del av hemmeligheten. Så lenge minst én deltaker faktisk gjorde det, er hele seremonien trygg. Endres kretsen, selv en liten justering, må hele prosessen gjentas fra bunnen.

PLONK med KZG-forpliktelser løser dette annerledes. Den Perpetuelle Powers of Tau-seremonien har kjørt kontinuerlig siden 2019, støtter kretser opp til 2^28 begrensninger, og har generert over 530 millioner potenser av tau gjennom stadig nye bidrag. Ifølge zkproof.org sine offisielle seremonislides har BN254-grenen av seremonien 70 registrerte deltakere og BLS12-381-grenen 18. Aztec kjørte en egen seremoni, Ignition, med et globalt relé mellom rundt 200 deltakere for sine PLONK-baserte personvernkretser.

Det finnes også en tredje vei. Halo2, slik Zcash bruker det i dag, kan instansieres med IPA-forpliktelser (inner-product argument) i stedet for KZG. Det gjør oppsettet helt transparent, altså uten noen trusted setup overhodet, men til prisen av større bevis og tregere verifisering. Flere prosjekter, blant dem Scroll og Common.fi, har derfor valgt å bytte tilbake til KZG i sine Halo2-forker for å få ned bevisstørrelsen igjen.

Tillitsmodellen i en universell seremoni skiller seg også fra Groth16 på et praktisk punkt: antall mennesker som må stole på hverandre. En krets-spesifikk Groth16-seremoni involverer gjerne et lite, koordinert team, ofte prosjektets egne kjerneutviklere pluss noen eksterne observatører. Perpetual Powers of Tau og Aztec Ignition er derimot designet for å trekke inn hundrevis av uavhengige deltakere fra hele verden nettopp for å gjøre det praktisk talt umulig at alle samarbeider om å jukse. Prisen er en lengre og mer logistikk-krevende prosess å sette i gang, men gevinsten er en seremoni som kan gjenbrukes av alle fremtidige PLONK-kretser innenfor samme størrelsesgrense.

Polynomielle forpliktelser og varianter i 2025-2026

Groth16 har ikke noe eget lag for polynomielle forpliktelser. Ordningen bygger direkte på en krets-spesifikk CRS og parrings-likninger, og kan ikke bytte mellom KZG og IPA slik PLONK kan. PLONK, derimot, er i praksis en familie av bevissystemer der valget av forpliktelsesskjema avgjør både bevisstørrelse, verifiseringstid og hvorvidt man trenger en trusted setup i det hele tatt.

De siste par årene har brakt flere nye varianter inn i produksjon. TurboPlonk og UltraPlonk legger til egendefinerte porter og oppslagstabeller for billigere hashfunksjoner og andre gjentakende operasjoner, mot en prover-kostnad på 37 til 63 prosent over standard Plonk, som vist i Lehigh-benchmarken over. HyperPlonk flytter deler av arbeidet til multivariate polynomer for å kutte prover-tid på store kretser. SublonK, presentert på POPETS 2024, prioriterer i stedet en sublineær prover og ender på et bevis rundt 2,4 kB.

En annen relevant endring kom fra selve Ethereum-protokollen. Siden Pectra-oppgraderingen 7. mai 2025 har Ethereum mainnet eksponert egne presompiler for BLS12-381 gjennom EIP-2537, priset til 37 700 + 32 600 × k gass per parringskall. Det åpner for billigere aggregerte bevis på en kurve som allerede er godt utbredt i validator-infrastrukturen, og flere zkEVM-team vurderer nå BLS12-381 som standardkurve for nye Groth16- og PLONK-verifikatorer fremover.

HyperPlonk representerer kanskje det tydeligste bruddet med den opprinnelige PLONK-designen. Der standard PLONK og dens nærmeste varianter fortsatt bruker univariate polynomer og en KZG- eller IPA-forpliktelse med lineær eller logaritmisk verifiseringskostnad, bytter HyperPlonk til multivariate polynomer og en sumsjekk-basert tilnærming. Målet er en prover som skalerer bedre på svært store kretser, på bekostning av et noe mer komplekst matematisk fundament å implementere korrekt. For de fleste team som først skal velge mellom Groth16 og PLONK i 2026, er HyperPlonk fortsatt mer relevant som fremtidig retning enn som produksjonsklart valg i dag.

Hvem bruker hva: virkelige eksempler

Teori og benchmark-tabeller forteller bare halve historien. Ser man på hvilke protokoller som faktisk kjører i produksjon i 2026, tegner det seg et tydelig mønster langs samme skillelinje tallene over allerede antyder: prosjekter med én stabil krets og høyt volum lener seg på Groth16, mens prosjekter som fortsatt utvikler kretsen aktivt, nesten uten unntak har landet på PLONK eller en Plonkish-variant.

Groth16 i produksjon

  • Zcash brukte Groth16 i de historiske Sprout- og Sapling-kretsene for skjermede transaksjoner. Kretsen endret seg sjelden nok til at den periodiske seremonikostnaden var overkommelig, før prosjektet senere gikk over til Halo2 for å fjerne trusted setup-kravet helt.
  • Tornado Cash bruker Groth16 over BN254 og kaller parrings-presompilen på adresse 0x08 direkte for hver innløsning. Protokollens kjernekrets, som beviser kjennskap til et hemmelig commitment i et Merkle-tre, har vært praktisk talt uendret siden lansering, noe som gjør den kretsspesifikke seremonien til en engangskostnad.
  • Filecoin bygger Proof-of-Replication og Proof-of-Spacetime på Groth16, siden kretsen for lagringsbevis er stabil og gjentas i enormt volum. Med millioner av bevis generert daglig på tvers av nettverkets lagringsleverandører, teller hver sparte byte og hver sparte gass-enhet mye i sum.
  • Loopring brukte Groth16-baserte rollup-kretser i tidlige versjoner av protokollen, i en periode da universelle PLONK-seremonier fortsatt var umodne og mindre utbredt i produksjon.
  • Flere rekursive L2-stabler pakker det siste beviset som skal verifiseres på L1 i Groth16, uavhengig av hvilket system som brukes internt, nettopp for å minimere kalldata og gass. Dette mønsteret har blitt så vanlig at flere SDK-er nå tilbyr Groth16-innpakning som et standard siste steg i bevispipelinen.

PLONK og Plonkish i produksjon

  • zkSync, bygget av Matter Labs, bruker PLONK-baserte kretser med KZG-forpliktelser for sin zkEVM. Kretsen har blitt oppdatert gjentatte ganger etter hvert som EVM-kompatibiliteten har blitt utvidet, noe som ville vært langt tyngre å håndtere med en krets-spesifikk seremoni.
  • Aztec bygger sin personvern-rollup på PLONK og UltraPlonk, sikret gjennom Ignition-seremonien nevnt over. De egendefinerte portene i UltraPlonk gjør det billigere å bevise de kryptografiske primitivene personvern-kretsene er avhengige av.
  • Scroll kjører Halo2 med KZG i stedet for standard IPA, for å holde bevisene mindre i sin EVM-ekvivalente zkEVM, samtidig som de beholder mye av Halo2s rekursjonsstøtte fra opphavet i Zcash-økosystemet.
  • Polygon zkEVM bruker et PLONK-avledet bevissystem med KZG-forpliktelser, valgt blant annet fordi teamet forventet å iterere raskt på kretsen i den tidlige fasen av zkEVM-kappløpet.
  • Mina Protocol holder hele blokkjeden på rundt 22 kB gjennom rekursive Plonkish-bevis i Pickles/Halo-stil, der hver ny blokk beviser gyldigheten til alle tidligere blokker i én og samme kompakte struktur.
  • Dagens Zcash har gått over til Halo2 med UltraPlonkish-arithmetisering og IPA-forpliktelser, og trenger dermed ingen trusted setup i det hele tatt, et bevisst valg etter kritikk av de tidligere Groth16-seremoniene.

Hva ekspertene sier om Groth16 og PLONK

ConsenSys’ egen dokumentasjon for gnark-biblioteket oppsummerer valget mellom systemene praktisk, med vekt på hva slags arbeidsmengde en applikasjon faktisk har:

“Groth16 is best suited when an application needs to generate many proofs for the same circuit … while PlonK is best suited when it needs to handle many different circuits … with reasonably fast performance.”

gnark-dokumentasjonen (ConsenSys), docs.gnark.consensys.io

Oversatt til norsk: velg Groth16 når kretsen står fast og skal bevises millioner av ganger, og velg PLONK når prosjektet skal håndtere mange ulike kretser over tid. Den samme praktiske vinklingen går igjen hos undervisningskontoen RareSkills, som peker på nøyaktig samme skille mellom oppsettene:

“Plonk has a universal trusted setup, Groth16 must create a separate trusted setup for each application.”

RareSkills, x.com/RareSkills_io

RareSkills bruker også Groth16 som inngangspunkt når de underviser i zk-SNARK, nettopp fordi konstruksjonen er enklere å resonnere om enn PLONK:

“Groth16 is simpler (albeit still a complex algorithm) compared to Plonk, which is why we teach it first.”

RareSkills, x.com/RareSkills_io

På LinkedIn har kryptografen Bill Atnapier forklart selve bevisideen bak Groth16 og hvordan den plasserer seg i familien av bevissystemer PLONK også tilhører:

“Groth16 shows that one hidden polynomial divisibility relation holds by evaluating specially structured polynomials at a toxic-waste secret point.”

Bill Atnapier, LinkedIn

“PLONK is part of the SNARK (Succinct Non-Interactive Arguments of Knowledge) family of zero-knowledge proofs.”

Bill Atnapier, LinkedIn

Alle fem sitatene peker mot samme praktiske konklusjon: Groth16 og PLONK løser to forskjellige problemer, og ekspertene som jobber med dem daglig, snakker om valget som et spørsmål om arbeidsmengde og drift, ikke om hvilken matematikk som er finest. Det er verdt å merke seg at ingen av kildene over anbefaler det ene systemet som et universelt riktig valg. I stedet knytter samtlige valget til konkrete egenskaper ved applikasjonen: hvor mange ganger kretsen skal kjøres, hvor ofte den endres, og hvor mye kontroll teamet har over trusted setup-prosessen.

Migreringsguide: fra Groth16 til et PLONK-basert system

Flere team som startet med Groth16 av enkelhetshensyn, vokser etter hvert ut av den kretsspesifikke seremonien. Under følger en praktisk rekkefølge for å flytte et system over til PLONK eller en Plonkish-variant uten å miste sikkerhetsgarantiene underveis.

  1. Kartlegg kretsen og tell antall begrensninger. Avgjør om den passer under den øvre grensen til en eksisterende universell seremoni, som Perpetual Powers of Taus tak på 2^28 begrensninger. En krets som ligger nær grensen, bør vurdere sirkelbytte eller kretsforenkling før migreringen starter.
  2. Velg polynomiell forpliktelse. KZG gir minst bevis og lavest gass, men krever fortsatt en universell trusted setup. IPA, som i Halo2, fjerner behovet for trusted setup helt, mot større bevis og noe tregere verifisering. Valget bør tas før noe kode skrives, siden det påvirker både verifikator-kontrakten og biblioteksvalget.
  3. Port kretsen til PLONK-arithmetisering. Oversett R1CS-begrensninger til gate- og oppslagstabeller ved hjelp av et rammeverk som gnark, snarkjs sin PLONK-modus, eller Halo2 direkte. Dette steget tar vanligvis lengst tid i praksis, fordi konstruksjoner som er trivielle i R1CS kan kreve helt andre mønstre i en Plonkish-arithmetisering.
  4. Bruk en eksisterende universell seremoni fremfor å starte en ny. Perpetual Powers of Tau eller Aztec Ignition dekker de fleste kretsstørrelser og sparer måneder med koordinering mellom deltakere sammenlignet med å organisere en egen seremoni fra bunnen.
  5. Skriv om on-chain-verifikatoren. En PLONK-verifikator gjør andre parrings- og MSM-kall enn en Groth16-verifikator, så gasskostnaden må måles på nytt for den spesifikke kretsen, og ikke antas ut fra generiske tall fra andre prosjekter.
  6. Kjør parallell bevisgenerering i en testperiode. Sammenlign bevistid, bevisstørrelse og gass mot det gamle systemet før noe rulles ut i produksjon, og kjør begge verifikatorene mot samme testsett av transaksjoner for å fange opp avvik tidlig.
  7. Vurder en hybridperiode der begge verifikatorer aksepteres on-chain samtidig, en tilnærming 7Block Labs har dokumentert for prosjekter som migrerer gradvis, slik at brukere med bevis generert under det gamle systemet fortsatt kan verifiseres.
  8. Fjern den gamle Groth16-verifikatoren og kretsspesifikke seremonien når trafikken har flyttet helt over, og publiser den nye SRS-referansen offentlig for revisjon, sammen med en logg over hvem som deltok i den universelle seremonien prosjektet nå baserer seg på.

Fordeler og ulemper

Groth16

Fordeler: minste mulig bevis uansett kretsstørrelse, lavest verifiseringsgass on-chain, rask off-chain-verifisering målt i millisekunder, moden tooling gjennom snarkjs, circom og gnark med flere års produksjonsbruk bak seg, og en enklere sikkerhetsmodell å revidere fordi konstruksjonen har færre bevegelige deler enn PLONK-familien.

Ulemper: krever en ny trusted-setup-seremoni for hver krets, ingen naturlig støtte for rekursjon eller kretsoppdateringer, mindre fleksibel for team som endrer logikken ofte, og gir ingen enkel vei til å legge til egendefinerte porter eller oppslagstabeller uten å bygge en helt ny krets fra bunnen.

PLONK

Fordeler: universell og oppdaterbar SRS dekker mange kretser fra én seremoni, egendefinerte porter og oppslagstabeller gjør kompleks logikk billigere å bevise, naturlig rekursjonsstøtte i varianter som Halo2 og Plonky2, mulighet for et helt transparent oppsett gjennom IPA, og et økosystem av verktøy som utvikler seg raskt i takt med at flere zkEVM-team investerer i det.

Ulemper: større bevis, typisk 512-800 byte og opptil 2,4 kB i enkelte varianter, høyere verifiseringsgass på rundt 30-50 prosent over Groth16, flere konkurrerende varianter (TurboPlonk, UltraPlonk, HyperPlonk) som gjør selve valget mer komplisert, og en bredere angrepsflate rett og slett fordi protokollen har flere komponenter som kan implementeres feil.

Bruksscenarier: når velge hva

  1. Personvern-mikser med fast, uforanderlig krets, i stil med Tornado Cash: velg Groth16 for lavest gass og enklest verifikator. Kretsen endrer seg sjelden nok til at ulempen med en engangsseremoni knapt merkes over protokollens levetid.
  2. zkEVM eller zkVM under aktiv utvikling der kretsen endres jevnlig: velg PLONK eller en Plonkish-variant for å unngå gjentatte seremonier hver gang teamet legger til støtte for en ny EVM-opcode eller retter en feil i kretsen.
  3. Rollup som batcher tusenvis av transaksjoner og pakker et rekursivt sluttbevis for L1: en hybrid er ofte riktig, Plonkish internt for fleksibilitet under utvikling og Groth16 som ytre wrapper for lavest kalldata og gass når beviset til slutt skal opp på hovedkjeden.
  4. Team som vil unngå trusted setup av prinsipp eller regulatoriske grunner: velg Halo2 med IPA, slik dagens Zcash gjør, og aksepter det noe større beviset og den noe tregere verifiseringen som prisen for et helt transparent oppsett.
  5. Lagringsbevis eller andre høyvolum, identiske kretser, i Filecoin-stil: velg Groth16, fordi kretsen sjelden endres og volumet gjør gassbesparelsen stor over tid, spesielt når millioner av bevis genereres daglig på tvers av et helt nettverk av deltakere.
  6. Ny startup uten eget kryptografiteam som vil komme raskt i gang: velg PLONK via gnark eller Halo2, fordi en eksisterende universell seremoni fjerner behovet for en egen seremoni fra dag én, og lar teamet fokusere ressursene på selve applikasjonslogikken.
  7. Akademisk eller pedagogisk prosjekt som skal forklare hvordan zk-SNARK fungerer fra bunnen: velg Groth16 først, slik RareSkills anbefaler, fordi konstruksjonen har færre bevegelige deler å forstå før PLONKs mer avanserte arithmetisering introduseres.

Praktisk sjekkliste før du velger

Før et team låser seg til ett av systemene, er det verdt å gå gjennom noen konkrete spørsmål. Svarene peker som regel entydig mot enten Groth16 eller PLONK, selv om det på papiret kan virke som et vanskelig valg.

  • Hvor ofte forventer teamet å endre kretsen etter første lansering? Hyppige endringer taler for PLONK.
  • Hvor mange bevis skal verifiseres on-chain per dag, og hva er budsjettet for gass? Høyt volum og stramt budsjett taler for Groth16 eller FFLONK.
  • Har prosjektet ressurser og tid til å koordinere en egen trusted-setup-seremoni, eller er det avhengig av å gjenbruke en eksisterende? Det siste taler for PLONK med KZG.
  • Er trusted setup uakseptabelt av regulatoriske eller prinsipielle grunner? Da er Halo2 med IPA det eneste alternativet av de to familiene.
  • Trenger arkitekturen rekursjon, altså bevis som beviser gyldigheten til andre bevis? Det taler for Halo2 eller Plonky2 fremfor ren Groth16.
  • Har teamet allerede kompetanse og tooling rundt ett av systemene fra et tidligere prosjekt? Gjenbruk av kunnskap er ofte undervurdert som beslutningskriterium.

Dommen: hva sier tallene

Tallene peker ikke mot én vinner, de peker mot to forskjellige jobber. Groth16 slår PLONK på hver eneste effektivitetsmåling som betyr noe on-chain: 192 byte mot 512-800 byte i bevisstørrelse, og rundt 199 450 gass mot 300 000-350 000 gass ved verifisering. For et prosjekt med én fast krets og høyt volum, som Tornado Cash eller Filecoin, er dette forskjellen mellom en billig og en dyr protokoll å drifte.

PLONK slår derimot Groth16 på det som betyr noe for et team i utvikling: én seremoni, som Perpetual Powers of Tau med sine 530 millioner-pluss potenser av tau, dekker et ubegrenset antall fremtidige kretser. Det er derfor zkSync, Aztec, Scroll, Polygon zkEVM og Mina alle har landet på PLONK eller en Plonkish-variant for sine stadig skiftende zkEVM- og rollup-kretser.

Den nøkterne konklusjonen: still spørsmålet «endrer kretsen min seg etter lansering?» før spørsmålet «hvilket system er raskest?». Svarer et prosjekt nei, er Groth16 fortsatt vanskelig å slå på ren effektivitet. Svarer det ja, betaler PLONKs universelle oppsett seg tilbake allerede ved andre kretsoppdatering.

Verken Groth16 eller PLONK er i ferd med å forsvinne fra produksjon med det første. Begge har over fem år med reell drift bak seg, dekket av flere uavhengige revisjoner og milliarder av dollar i verdi sikret gjennom kretsene de beviser. Det nyeste som skjer i 2025 og 2026, handler mindre om å erstatte dem, og mer om å presse dem videre: FFLONK for enda mindre bevis, HyperPlonk for raskere proving på store kretser, og BLS12-381-presompilene fra Pectra-oppgraderingen som gjør begge protokollene billigere å verifisere på Ethereum enn de var for bare et år siden.

Ofte stilte spørsmål

Er PLONK raskere enn Groth16?
Det kommer an på kretsen. På en SHA-256-krets måler StealthClouds 2026-benchmark Groth16 til 3,2 sekunder proving-tid mot 4,8 sekunder for PLONK. På en MiMC-krets, designet for å passe PLONKs arithmetisering, viser Aztecs egen benchmark at PLONK er 2,5 ganger raskere enn Groth16. Kretsvalget avgjør mer enn selve protokollen.

Hvorfor er Groth16-bevis mindre enn PLONK-bevis?
Groth16 er matematisk bevist optimal for antall gruppeelementer i denne klassen SNARK-er: nøyaktig tre, uansett kretsstørrelse. PLONK må i tillegg inkludere flere polynomforpliktelser og et åpningsbevis, noe som gir et bevis på 512-800 byte i typiske produksjonsoppsett.

Trenger PLONK fortsatt en trusted setup?
Ja, hvis PLONK bruker KZG-forpliktelser, som er den vanligste varianten. Forskjellen fra Groth16 er at seremonien er universell og kan gjenbrukes av mange kretser. Velger et prosjekt IPA-forpliktelser i stedet, som i standard Halo2, forsvinner trusted setup-kravet helt, mot større bevis og tregere verifisering.

Hvilket system bruker Ethereum-rollups mest i 2026?
De fleste større zkEVM-er, som zkSync, Scroll og Polygon zkEVM, bruker PLONK eller Plonkish-varianter internt på grunn av fleksibiliteten under utvikling. Mange av dem pakker likevel det avsluttende beviset som verifiseres på L1 i Groth16 for å holde kalldata- og gasskostnaden nede.

Kan jeg bruke Groth16 og PLONK i samme prosjekt?
Ja. Flere rollup-stabler kombinerer allerede begge, med Plonkish-bevis internt og et rekursivt Groth16-bevis som siste steg mot L1. 7Block Labs har dokumentert konkrete verifikatorer på Ethereum som aksepterer begge bevistypene side om side under en migrasjon.

Er noen av systemene kvanteresistente?
Nei. Både Groth16 og standard PLONK bygger på elliptisk kurve-kryptografi og parringer, som ikke er motstandsdyktige mot en tilstrekkelig kraftig kvantedatamaskin. Transparente varianter som Halo2 med IPA endrer ikke dette, siden IPA fortsatt hviler på diskret logaritme-problemet på elliptiske kurver.

Hva er FFLONK og SublonK?
FFLONK er en optimalisert PLONK-variant som bruker omtrent 5 prosent mindre gass enn Groth16 og rundt 30 prosent mindre enn standard PLONK ved verifisering, ifølge en sammenlignende studie på Ethereum og Hedera. SublonK, presentert på POPETS 2024, prioriterer i stedet en sublineær prover og lander på et bevis rundt 2,4 kB.

Hvilket bibliotek bør jeg starte med?
For Groth16 er snarkjs sammen med circom den mest brukte kombinasjonen for JavaScript-baserte team, mens gnark passer godt for Go. For PLONK og Plonkish er Halo2 standardvalget i Ethereum-økosystemet, mens gnark også støtter PLONK-modus for team som vil holde seg til ett bibliotek gjennom hele migreringen.

Hva skjer med en trusted setup-seremoni hvis alle deltakerne jukser?
Da kan seremonien i teorien kompromitteres, og en angriper kan forfalske gyldige bevis for falske utsagn. Både Perpetual Powers of Tau og Aztec Ignition er designet nettopp for å gjøre dette scenariet urealistisk, ved å trekke inn så mange uavhengige deltakere at det ville kreve koordinert juks fra alle samtidig. For en krets-spesifikk Groth16-seremoni er antallet deltakere ofte lavere, noe som gjør valget av hvem som inviteres inn til seremonien til en reell sikkerhetsvurdering.

Koster det noe å skifte polynomiell forpliktelse innad i PLONK, fra KZG til IPA?
Ja, både i bevisstørrelse og i verifiseringstid. IPA-baserte Halo2-oppsett fjerner trusted setup-kravet helt, men betaler for det med et bevis som vokser logaritmisk med kretsstørrelsen i stedet for å holde seg konstant, og en verifikator som gjør flere gruppeoperasjoner enn en tilsvarende KZG-basert PLONK-verifikator. Scroll og Common.fi har begge dokumentert hvorfor de valgte å bytte fra IPA til KZG i sine egne Halo2-forker, nettopp for å få ned denne kostnaden.