To bevissystemer kjemper om å bli standarden for personvern og skalering i blokkjede-verdenen, og valget mellom dem koster utviklere ekte penger hver eneste dag. zk-SNARK og zk-STARK løser det samme grunnleggende problemet, nemlig å bevise at en beregning er riktig uten å avsløre inndataene, men de gjør det med helt ulike matematiske verktøy og helt ulike kostnadsprofiler. Et 2025-benchmark fra flere enheter viste at SNARK-bevis kan være 384 byte mot 68,56 KB for STARK-bevis på samme krets, en forskjell på over 178 ganger. Samtidig genererte SNARK-proveren beviset sitt på 55,47 millisekunder på en Apple M1, mens STARK-proveren brukte 3.809,64 millisekunder, altså 68 ganger tregere. Tallene forklarer hvorfor StarkWare, Matter Labs, Polygon Labs og Zcash Foundation har tatt helt ulike veier for sine rollup- og personvernsystemer.

Denne artikkelen går gjennom hva som faktisk skiller zk-SNARK fra zk-STARK i 2026: bevisstørrelse, genereringstid, gasskostnad på Ethereum, behovet for en tiltrodd oppsett-seremoni og hvem som tåler et angrep fra en fremtidig kvantedatamaskin. Vi ser også på hvilke ekte prosjekter som har valgt hvilken teknologi, og hvorfor.

Hva er zero-knowledge proofs egentlig?

Et zero-knowledge proof (ZKP) lar én part, “proveren”, overbevise en annen part, “verifisereren”, om at en påstand er sann uten å røpe noe annet enn selve sannheten. Ideen ble først beskrevet av Shafi Goldwasser, Silvio Micali og Charles Rackoff i en akademisk artikkel fra 1985, lenge før det fantes noen praktisk bruk for teknologien utenfor teoretisk kryptografi. I praksis brukes dette i dag til å bevise at en transaksjon er gyldig, at en kontosaldo er korrekt oppdatert, eller at en beregning har skjedd riktig, uten å legge ut rådataene på en offentlig blokkjede. Ethereum-dokumentasjonen beskriver ZK-rollups som løsninger der en operatør sender inn gyldighetsbevis sammen med hver batch av transaksjoner, noe som lar kjeden verifisere tusenvis av transaksjoner med kostnaden av ett enkelt bevis.

Begge familiene, SNARK og STARK, bygger på denne ideen, men de skiller seg i hvilken kryptografi de stoler på. SNARK-systemer som Groth16 og PLONK bruker elliptisk kurve-paringer og krever ofte en strukturert referansestreng fra en oppsett-seremoni. STARK-systemer, utviklet av teamet bak StarkWare, bruker i stedet hashfunksjoner og en teknikk kalt FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity), noe som fjerner behovet for tiltrodd oppsett helt. Denne forskjellen i grunnlag er roten til nesten alle praktiske forskjeller lenger ned i artikkelen.

Kort historie: fra Zcash i 2016 til StarkNet i dag

zk-SNARK fikk sitt store gjennombrudd da Zcash lanserte i 2016 med Sprout-protokollen, bygget på en tidlig SNARK-konstruksjon kalt Pinocchio. Det var første gang teknologien ble brukt til å flytte reelle verdier i produksjon, ikke bare i akademiske artikler. Sapling-oppgraderingen i 2018 byttet til Groth16 og kuttet bevistiden fra minutter til sekunder, noe som gjorde personvernoverføringer praktisk mulig på vanlig maskinvare for første gang.

STARK kom noe senere. Konseptet ble beskrevet i en akademisk artikkel i 2018, og StarkWare Industries ble grunnlagt samme år for å kommersialisere teknologien. StarkEx, StarkWares første produkt, gikk i produksjon i 2020 og håndterte handel og overføringer for børser som dYdX før teamet siden bygde StarkNet som et fullverdig, generelt Ethereum-rollup. Ethereum-økosystemet har dermed hatt SNARK i produksjon i nesten et tiår lenger enn STARK, noe som forklarer hvorfor SNARK-verktøykjeden fortsatt er mer moden i 2026, selv om STARK har tatt igjen mye av forspranget de siste årene.

Slik fungerer trusted setup og FRI under panseret

For å forstå hvorfor kostnadene er så ulike, hjelper det å se litt på mekanikken. En Groth16-seremoni produserer to hemmelige tall som brukes til å konstruere et sett med kryptografiske «toksiske avfallsprodukter». Disse brukes til å bygge referansestrengen, og deltakerne må deretter destruere sin del av hemmeligheten permanent. Zcash sin Sapling-seremoni i 2018 samlet over 90 deltakere fra hele verden, hver med sin egen maskinvare og sitt eget nettverk, nettopp for å gjøre det praktisk umulig for en enkelt aktør å beholde nok informasjon til å forfalske et bevis. PLONK reduserte dette problemet ved å innføre et universelt oppsett som kan brukes på tvers av vilkårlig mange kretser, slik at man i teorien bare trenger én stor seremoni for et helt økosystem.

STARK løser det samme problemet på en helt annen måte. FRI-protokollen lar proveren vise at et polynom har lav grad ved å gjentatte ganger halvere problemet og committe til mellomresultater via Merkle-trær. All tilfeldighet som brukes underveis, hentes fra en offentlig, forhåndsavtalt kilde, som gjør hele prosessen etterprøvbar av hvem som helst uten adgang til noen hemmelighet. Konsekvensen er at et STARK-bevis inneholder mange flere Merkle-stier og hashverdier enn et SNARK-bevis trenger, som er hovedårsaken til at STARK-bevis vokser til titalls kilobyte mens et SNARK-bevis holder seg under en kilobyte uansett hvor stor beregningen er.

zk-SNARK forklart: liten, rask, men med en hemmelighet

SNARK står for “Succinct Non-interactive Argument of Knowledge”. Systemet komprimerer et bevis ned til noen hundre byte, uansett hvor stor beregningen bak er. Groth16, som fortsatt er en av de mest brukte variantene, produserer bevis på rundt 192 byte og koster omtrent 230.000 gass å verifisere på Ethereum. PLONK, en nyere og mer fleksibel variant som ikke krever et nytt oppsett for hver krets, gir bevis på rundt 576 byte til en kostnad på cirka 320.000 gass.

Prisen for denne kompaktheten er tilliten til oppsettet. Groth16 krever en «powers of tau»-seremoni der deltakere i fellesskap genererer hemmelige parametere og deretter må destruere sin del av hemmeligheten. Hvis én eneste ærlig deltaker sletter sin del, er systemet trygt, men hvis alle deltakerne jukser i hemmelighet, kan noen forfalske bevis uten at noen oppdager det. Zcash sin første Sprout-seremoni i 2016 og senere Sapling-seremonien er de mest kjente eksemplene på hvordan slike seremonier gjennomføres i praksis, med hundrevis av deltakere fra ulike land for å redusere risikoen for kollusjon.

zk-STARK forklart: transparent og kvantesikker, men tyngre

STARK står for “Scalable Transparent Argument of Knowledge”. Transparent er nøkkelordet, siden STARK-systemer ikke trenger noen hemmelig seremoni i det hele tatt. All tilfeldighet hentes fra offentlig verifiserbare kilder, som gjør at ingen enkeltperson eller gruppe kan forfalske et bevis gjennom et kompromittert oppsett. Det er også derfor StarkWare markedsfører sin Cairo-baserte StarkNet-stack som «trustless» fra bunnen av.

Prisen for transparensen er størrelse. Et Winterfell-basert STARK-bevis for en typisk krets lander på rundt 42 KB, og på L1 vil ren verifisering koste omtrent 2,5 millioner gass, en kostnad som flere 2026-benchmarker beskriver som «prohibitiv på L1». STARK-systemer stoler kun på hashfunksjoner og Merkle-trær i stedet for elliptiske kurve-paringer. Siden det ikke finnes noen kjent kvantealgoritme som effektivt bryter hashfunksjoner på samme måte som Shors algoritme bryter diskret logaritme, regnes STARK som postkvante-sikkert.

Spesifikasjonstabell: zk-SNARK mot zk-STARK

Tabellen under samler nøkkeltallene fra flere 2025- og 2026-benchmarker, og viser hvorfor valget mellom systemene sjelden er opplagt. Legg merke til at ingen enkeltrad avgjør saken alene: en rollup som bare ser på bevisstørrelse ville konkludert med SNARK i alle tilfeller, mens en rollup som bare ser på kvantesikkerhet ville konkludert med STARK i alle tilfeller. Det er kombinasjonen av rader som avgjør hva som faktisk passer et gitt prosjekt.

Egenskapzk-SNARK (Groth16/PLONK)zk-STARK
Typisk bevisstørrelse192–576 byte42–200 KB
Genereringstid (samme krets, Apple M1)~55 ms~3.810 ms
Verifiseringstid off-chain~10-tallsmillisekunder~18 ms
On-chain verifiseringskostnad230.000–320.000 gass~2,5 millioner gass
Tiltrodd oppsett krevesJa (SRS-seremoni)Nei, transparent
Kryptografisk grunnlagElliptisk kurve-paringerHashfunksjoner + FRI
KvantesikkerhetNeiJa, hash-basert
Modenhet i verktøykjedeCircom, snarkjs, arkworks (moden)Cairo, Winterfell (nyere)
Skalering med kretsstørrelseLineær, men oppsettbundetKvasi-lineær proving, bedre for store kretser
Ledende protokollerzkSync Era, Polygon zkEVM, Scroll, Zcash, MinaStarkNet
Programmeringsspråk for kretserCircom, Noir, Halo2-DSLCairo
Selskap/team bak referanseimplementasjonMatter Labs, Polygon Labs, o1 LabsStarkWare Industries

Ytelse i praksis: hva sier benchmarkene?

Tallene over kommer ikke fra én kilde, men gjentar seg på tvers av flere uavhengige studier. En 2025-analyse som testet samme beregning på flere enheter fant SNARK-bevis på 384 byte mot STARK-bevis på 68.564 byte, altså en forskjell på rundt 178 ganger. En annen 2026-evaluering målte SNARK-bevis mellom 192 og 484 byte avhengig av implementasjon, med STARK konsekvent på topp i størrelse blant systemene som ble testet. Et tredje 2026-benchmark for Ethereum-lignende kretser satte Groth16 til 192 byte, PLONK til 576 byte, og en STARK-variant til 42 KB for en SHA-256-beregning, voksende til 85 KB og 165 KB for større kretser.

Et StarkNet-fokusert 2025-benchmark brøt ned kostnaden per operasjonstype, og forskjellen ble enda tydeligere jo mer kompleks operasjonen var:

OperasjonSNARK-bevisSTARK-bevis
Enkel overføring~287 byte~12.450 byte
Token-bytte~293 byte~23.612 byte
NFT-mynting~288 byte~18.364 byte
DeFi-sammensatt transaksjon~296 byte~45.728 byte
Batch på 100 transaksjoner~305 byte~128.546 byte

Verifiseringstiden forteller en annen historie enn bevisstørrelsen. Selv om STARK-bevis er langt større, verifiserer de ofte raskere off-chain fordi FRI-protokollen er bygget for rask kontroll av mange hashverdier parallelt. Et Winterfell-basert benchmark målte 1,8 sekunder proving-tid og bare 18,2 millisekunder verifiseringstid for en STARK. En annen 2025-studie av zk-STARK rapporterte 7.082 millisekunder proving-tid, 16,9 millisekunder verifisering, og et bevis på 55.400 byte. Mønsteret er konsistent: STARK bruker lengre tid på å generere beviset, men vinner ofte på ren verifiseringshastighet. Den totale on-chain-kostnaden blir likevel høyere, fordi dataene som må sendes og lagres er så mye større.

Det er verdt å understreke at ingen av disse tallene gjelder de mest optimaliserte produksjonssystemene direkte. StarkNet og zkSync Era bruker begge kraftig maskinvareakselerasjon, batching og rekursjon i sine faktiske prover-klynger, noe som kan bringe reell proving-tid ned til sekunder for hele batcher med tusenvis av transaksjoner. Tallene over er likevel nyttige som en ren, protokoll-til-protokoll-sammenligning, fordi de isolerer selve den kryptografiske kostnaden fra ingeniørarbeidet som er lagt i optimalisering. Uansett hvor mye man optimaliserer implementasjonen, endrer man ikke den grunnleggende forskjellen mellom en pareingsbasert konstruksjon og en hash-basert konstruksjon.

Rekursive bevis og aggregering: fremtiden for begge leire

Både SNARK- og STARK-teamene jobber nå med å angripe hverandres svakheter gjennom rekursjon. Ideen er enkel: la et bevis verifisere et annet bevis, slik at man kan komprimere titusenvis av transaksjoner ned til ett enkelt endelig bevis som sendes til Ethereum. Mina Protocol sitt Pickles-system er det mest ekstreme eksempelet, siden hele blokkjedens historikk til enhver tid kan representeres av ett konstant-størrelse SNARK-bevis, uansett hvor mange blokker som er produsert.

Nova, en nyere «folding scheme» utviklet for rekursive bevis, prøver å finne en mellomvei mellom de to leirene. Ved å slå sammen flere beregningssteg før selve SNARK-en genereres, lander Nova på en on-chain-verifiseringskostnad på rundt 800.000 gass, altså mellom Groth16/PLONK sine 230.000–320.000 gass og STARK sine 2,5 millioner gass. Samtidig utforsker StarkWare og andre STARK-team aggregering, der mange små STARK-bevis slås sammen til ett enkelt bevis før publisering på L1, nettopp for å dempe den høye on-chain-kostnaden som rammer rene STARK-verifiseringer. Trenden i 2025 og 2026 peker mot at fremtidens rollups i økende grad vil kombinere elementer fra begge familier, i stedet for å velge den ene fullstendig bort.

Gasskostnad og prising på Ethereum L2 i 2026

For utviklere som bygger en rollup handler valget sjelden bare om kryptografisk elegant. Det handler om hva sluttbrukeren betaler. Ethereums egen dokumentasjon oppgir at kalldata koster 16 gass per ikke-null byte og 4 gass per null-byte, og at verifisering av et ZK-bevis på mainnet typisk koster rundt 500.000 gass for et SNARK-basert system. Tabellen under samler estimert on-chain-kostnad og reelle batch-kostnader hentet fra 2025- og 2026-analyser av rollup-drift.

SystemEstimert on-chain gass per verifiseringBatch-kostnad (feb–apr 2025, ETH)Endring
Groth16 (SNARK)~230.000 gass––
PLONK (SNARK)~320.000 gass––
Nova (rekursiv, komprimert)~800.000 gass––
STARK (rå, uten aggregering)~2.500.000 gass––
zkSync Era (Matter Labs, SNARK)–0,0032 → 0,0043 ETH+34,4 %
Polygon zkEVM (SNARK)–0,0028 → 0,0039 ETH+39,3 %
StarkNet (StarkWare, STARK)–0,0035 → 0,0046 ETH+31,4 %

Det interessante er at alle tre rollupene opplevde en lignende prosentvis økning i bevis-kostnad mellom februar og april 2025, uavhengig av om de kjørte SNARK eller STARK under panseret. Det tyder på at gassprisen på selve Ethereum L1 driver mer av kostnadsveksten enn valget av bevissystem. Til sammenligning lå gjennomsnittlig L1-transaksjonsgebyr på rundt 0,39 dollar i en markedsgjennomgang fra høsten 2025, mens ZK-rollups klarte å levere transaksjoner ned mot 0,03 dollar ved å slå sammen mange transaksjoner i ett bevis. Ved en gasspris på 30–50 gwei kan en enkelt rå bevisinnsending likevel koste rollup-operatøren mellom 60.000 og 120.000 dollar i total gass, et tall som har fått flere analytikere til å beskrive kostnadspresset som en pågående utfordring for mindre operatører.

Innføringen av EIP-4844 og blob-basert datatilgjengelighet har dempet noe av dette presset ved å gjøre det billigere å publisere selve transaksjonsdataene, uavhengig av om beviset som verifiserer dem er et SNARK eller et STARK.

Flere 2026-analyser har pekt på at kostnadspresset rammer rollup-operatørene ujevnt. Et team som kjører et rent STARK-basert system uten aggregering, kan i verste fall sitte igjen med en gasskostnad per batch som er ti ganger høyere enn en SNARK-konkurrent, selv om begge betjener samme antall brukere. Det er hovedgrunnen til at StarkNet i praksis aldri sender rå STARK-bevis direkte til L1 lenger, men i stedet bruker egne komprimerings- og aggregeringslag før dataene når Ethereum. For et team som vurderer hvilket system de skal bygge på, er derfor spørsmålet sjelden «hva koster et rått bevis», men heller «hvor mye ingeniørarbeid må vi legge inn for å få kostnaden ned på et konkurransedyktig nivå».

Tiltrodd oppsett: hvorfor det fortsatt bekymrer utviklere

En «trusted setup»-seremoni genererer en strukturert referansestreng (SRS) som beviset og verifiseringen bygger på. Så lenge minst én av deltakerne i seremonien sletter sin del av hemmeligheten, er systemet sikkert. Problemet er at ingen utenfor seremonien kan bevise at det faktisk skjedde. Zcash løste dette ved å samle over hundre deltakere fra ulike land til Sapling-seremonien, nettopp for å gjøre kollusjon usannsynlig. Nyere SNARK-varianter som PLONK bruker et universelt oppsett som kan gjenbrukes på tvers av kretser, noe som reduserer antall seremonier man må stole på, men fjerner ikke behovet helt.

STARK unngår hele problemstillingen. Fordi FRI-protokollen kun bruker offentlig, verifiserbar tilfeldighet og hashfunksjoner, finnes det ingen hemmelig informasjon å lekke eller misbruke. For prosjekter som håndterer store verdier, som en børs eller en storskala DeFi-protokoll, kan denne transparensen i seg selv være avgjørende for om revisorer og institusjonelle brukere er villige til å stole på systemet.

Kvantesikkerhet: hvem overlever en fremtidig kvantedatamaskin?

Dette punktet blir stadig viktigere ettersom NIST sitt postkvante-kryptografiprogram modnes og flere blokkjedeprosjekter begynner å planlegge for en fremtid med praktisk kvantedatakraft. SNARK-systemer som Groth16 og PLONK bygger på pareoperasjoner over elliptiske kurver, typisk BLS12-381. Shors algoritme, som kan kjøres effektivt på en tilstrekkelig stor kvantedatamaskin, bryter nettopp denne typen diskret logaritme-antagelser. Et 2026-benchmark merker derfor både Groth16 og PLONK med «kvanteresistent: nei».

STARK stoler kun på kollisjonsresistente hashfunksjoner, og ingen kjent kvantealgoritme gir en tilsvarende dramatisk fordel mot hashfunksjoner slik den gjør mot elliptisk kurve-kryptografi. Grovers algoritme gir i beste fall en kvadratisk hastighetsøkning mot hashfunksjoner, noe som kan kompenseres ved å doble hash-utdataens lengde. Derfor merkes STARK konsekvent som «kvanteresistent: ja» i de samme benchmarkene. Det finnes forskning på postkvante-varianter av SNARK, basert på gitter i stedet for elliptiske kurver, men produksjonssystemene som faktisk kjører i rollups i dag, Groth16 og PLONK, er ikke kvantesikre.

Dette betyr ikke at SNARK-baserte systemer er umiddelbart truet. Ingen kjent kvantedatamaskin i dag har nærheten av kraften som trengs for å kjøre Shors algoritme mot BLS12-381 i praksis, og de fleste sikkerhetsforskere regner et slikt scenario som et spørsmål om flere tiår snarere enn år. Poenget er heller at et prosjekt som forventer å håndtere verdier langt inn i fremtiden, bør legge inn kvantesikkerhet som en del av risikovurderingen allerede nå, på samme måte som bank- og myndighetssystemer allerede har begynt å planlegge overgangen til postkvante-standarder for TLS og digitale signaturer.

Fem virkelige eksempler: hvem bruker hva

Teorien blir konkret når man ser på hvilke selskaper som faktisk har bygget produksjonssystemer på hver teknologi.

  • zkSync Era (Matter Labs): Bruker en PLONK-basert SNARK-stack med rekursjon og EVM-kompatible kretser. Matter Labs markedsfører systemet som «ZK Stack» og har prioritert lave gasskostnader for DeFi-brukere fremfor transparent oppsett. Selskapet har valgt å bygge en modulær arkitektur der andre team kan lansere egne kjeder på samme SNARK-stack, noe som har gjort ZK Stack til en av de mest kopierte rollup-arkitekturene i 2025 og 2026.
  • StarkNet (StarkWare Industries): Det klareste STARK-eksempelet i produksjon. StarkWare bygde sitt eget Cairo-språk for å skrive kretser og har satset hardt på transparens og kvantesikkerhet som salgsargument mot institusjonelle brukere. StarkWare har også lisensiert deler av STARK-teknologien til andre applikasjoner utenfor ren blokkjede, blant annet gjennom StarkEx-produktet som lenge driftet ordrebøkene til flere sentraliserte og desentraliserte børser.
  • Polygon zkEVM (Polygon Labs): Bruker en PLONK-lignende SNARK-tilnærming for å oppnå EVM-ekvivalens. Polygon har prioritert utvikleropplevelse og kompatibilitet med eksisterende Solidity-kode, slik at team kan flytte eksisterende Ethereum-applikasjoner over med minimale endringer i kildekoden.
  • Scroll: Et uavhengig team som bygger en zkEVM basert på Groth16- og PLONK-varianter, med mål om byte-for-byte-ekvivalens med Ethereums virtuelle maskin. Scroll har prioritert kompatibilitet fremfor å bygge et eget språk slik StarkWare gjorde med Cairo, og markedsfører seg spesifikt mot utviklere som ikke ønsker å lære et nytt kretsspråk.
  • Zcash (Electric Coin Company): Den opprinnelige pioneren innen SNARK i produksjon, med Sprout- og Sapling-generasjonene basert på Groth16, og nyere versjoner som beveger seg mot Halo2. Zcash bruker fortsatt SNARK-familien for private overføringer over ti år etter lanseringen, og forblir det lengst kjørende produksjonseksempelet på teknologien i hele bransjen.

Fellestrekket for SNARK-eksemplene er at alle prioriterer lav transaksjonskostnad og et modent utviklerøkosystem over transparens i oppsettet. StarkNet er fortsatt det tydeligste unntaket, og nettopp fordi det er så isolert som STARK-eksempel i stor skala, illustrerer det godt hvor konsentrert STARK-adopsjonen fortsatt er rundt ett enkelt selskap og økosystem sammenlignet med den langt mer spredte SNARK-siden.

Et sjette eksempel er verdt å nevne: Mina Protocol, bygget av O(1) Labs, bruker rekursive SNARK-er kalt «Pickles» for å holde hele blokkjeden komprimert til en konstant bevisstørrelse, uavhengig av hvor mange transaksjoner som noensinne har skjedd på kjeden. Det er trolig det mest ekstreme eksempelet på hva SNARK-familiens komprimeringsevne kan brukes til.

Utviklerøkosystem: Circom og Cairo i praksis

Valget mellom SNARK og STARK er også et valg av programmeringsspråk, og det påvirker hvor raskt et team faktisk kan levere. SNARK-siden domineres av Circom, et domenespesifikt språk designet spesifikt for å beskrive aritmetiske kretser, sammen med JavaScript-biblioteket snarkjs for å generere og verifisere bevis. Noir, utviklet av Aztec-teamet, har blitt et populært alternativ fordi syntaksen ligner mer på Rust og er lettere å lære for utviklere som ikke har jobbet med kretsdesign før.

Et svært forenklet eksempel på en Circom-krets som beviser kunnskap om et tall uten å avsløre det, ser gjerne slik ut:

template HashCheck() {
    signal input hemmelighet;
    signal output hash;

    component poseidon = Poseidon(1);
    poseidon.inputs[0] <== hemmelighet;
    hash <== poseidon.out;
}

component main = HashCheck();

STARK-siden bruker i praksis Cairo, StarkWares eget kretsspråk, som ligner mer på et vanlig programmeringsspråk med funksjoner, løkker og typesystem. Fordi Cairo er bygget spesifikt for å produsere STARK-bevis effektivt, kan utviklere skrive langt mer kompleks forretningslogikk direkte i språket, uten å måtte tenke like mye på antallet begrensninger i kretsen slik Circom-utviklere ofte må. Prisen er at Cairo-økosystemet i 2026 fortsatt har færre tredjepartsbiblioteker, færre revisorer med dyp erfaring, og en mindre brukerbase å hente hjelp fra sammenlignet med det ti år eldre Circom-økosystemet.

For et team som skal ansette utviklere raskt, betyr dette i praksis at det er enklere å finne Circom- eller Noir-kompetanse i markedet enn erfarne Cairo-utviklere, selv om gapet har krympet betydelig siden StarkNet begynte å vokse for alvor i 2023 og 2024.

Fem bruksområder: når bør du velge hva

Valget avhenger sjelden av én faktor alene. Her er konkrete anbefalinger basert på hva prosjektet faktisk skal løse, sortert etter hva som typisk veier tyngst for hvert scenario.

  • Høy gjennomstrømning med lave gasskostnader (DeFi-rollup): Velg zk-SNARK, gjerne Groth16 eller PLONK. Den lave on-chain-verifiseringskostnaden på 230.000–320.000 gass gjør en stor forskjell når du kjører tusenvis av batcher i måneden.
  • Langsiktig institusjonell tillit uten seremonirisiko: Velg zk-STARK. Fravær av tiltrodd oppsett gjør det enklere å forklare sikkerhetsmodellen til revisorer og regulerte aktører som ikke ønsker å stole på en ekstern seremoni.
  • Personvernfokusert token-overføring i Zcash-stil: Velg zk-SNARK. Den modne verktøykjeden rundt Circom, snarkjs og Halo2 gjør det raskere å bygge og revidere personvernkretser enn å starte fra bunnen med Cairo.
  • Nytt L2 bygget med utviklere som allerede kan Cairo: Velg zk-STARK via StarkNet-stacken. Du unngår å måtte konvertere logikk mellom Solidity og et SNARK-vennlig kretsspråk.
  • Prosjekt som må planlegge for et postkvante-scenario over ti år frem: Velg zk-STARK. Hash-basert sikkerhet tåler et fremtidig kvanteangrep på en måte pareingsbaserte SNARK-er ikke gjør uten en fullstendig omskriving.

Migrasjonsguide: fra ett bevissystem til et annet

Å bytte bevissystem midt i et eksisterende prosjekt er en av de dyreste beslutningene et team kan ta, og den bør aldri tas lettvint. Her er stegene et team typisk bør gå gjennom.

  1. Kartlegg dagens tillitsmodell. Dokumenter om systemet ditt i dag stoler på en SRS-seremoni, og om brukerne dine faktisk bryr seg om det.
  2. Mål reell gasskostnad over tid. Sammenlign faktisk on-chain-kostnad for din krets, ikke bare de generiske tallene i denne artikkelen, siden kretsstørrelse påvirker begge systemer ulikt.
  3. Vurder omskrivingskostnaden. Å flytte fra Circom eller Noir til Cairo (eller omvendt) betyr i praksis en fullstendig omskriving av kretslogikken, ikke en enkel konfigurasjonsendring.
  4. Test proving-infrastruktur separat. STARK-proving krever ofte mer minne og CPU-tid per batch. Sett opp en egen prover-klynge og mål faktisk gjennomstrømning før du migrerer produksjonstrafikk.
  5. Planlegg en overgangsperiode med to systemer parallelt. De fleste rollup-team kjører gammelt og nytt bevissystem side om side i flere uker for å sammenligne kostnad og pålitelighet før full utrulling.
  6. Revurder datatilgjengelighet. Siden EIP-4844 senket kostnaden for blob-data, kan den relative fordelen av liten bevisstørrelse ha blitt mindre viktig enn den var før 2025.
  7. Kommuniser endringen tydelig til brukerne. Spesielt ved bytte bort fra et transparent system til et system med tiltrodd oppsett bør prosjektet være åpent om hva det betyr for tillitsmodellen.

I praksis tar en fullstendig migrasjon mellom bevisfamilier ofte flere måneder for et modent produksjonssystem, siden hver eneste krets må skrives om, revideres på nytt av et eksternt sikkerhetsfirma, og testes grundig mot ekte transaksjonsmønstre før den slippes løs på reelle brukermidler. De fleste team som har gjennomført et slikt bytte, anbefaler å budsjettere for minst én uavhengig revisjonsrunde i tillegg til den interne testingen, nettopp fordi feil i en ny kretsimplementasjon kan være svært kostbare å oppdage etter lansering.

Fordeler og ulemper: zk-SNARK

Fordeler: Svært kompakte bevis på under en kilobyte, lav on-chain-verifiseringskostnad på 230.000 til 320.000 gass, moden verktøykjede med Circom og snarkjs, bredt økosystem av revisorer og sikkerhetsselskaper som kjenner konstruksjonene godt, og et sporet i produksjon siden Zcash i 2016. Den lave kostnaden gjør SNARK til det klare valget for ethvert prosjekt der transaksjonsvolumet er høyt og marginene per transaksjon er tynne.

Ulemper: Krever normalt en tiltrodd oppsett-seremoni som må gjennomføres og kommuniseres riktig for at brukerne skal stole på systemet, ikke kvantesikker mot fremtidige angrep basert på Shors algoritme, og pareoperasjonene over elliptiske kurver setter en praktisk øvre grense for hvor raskt svært store kretser kan bevises uten kraftig maskinvareakselerasjon som GPU- eller FPGA-baserte provere.

Fordeler og ulemper: zk-STARK

Fordeler: Ingen tiltrodd oppsett i det hele tatt, noe som fjerner en hel kategori av tillitsspørsmål fra sikkerhetsmodellen, kvantesikker takket være en hash-basert konstruksjon som ikke er sårbar for Shors algoritme, ofte raskere ren verifiseringstid enn tilsvarende SNARK-bevis, og bedre asymptotisk skalering for svært store beregninger der proving-tiden vokser saktere enn kretsstørrelsen.

Ulemper: Bevis som er 40 til over 400 ganger større enn tilsvarende SNARK-bevis, dramatisk høyere on-chain-gasskostnad ved rå verifisering på L1 (rundt 2,5 millioner gass mot 230.000–320.000 for SNARK), tregere proving-tid for sammenlignbare kretser på samme maskinvare, og et yngre, mindre modent verktøyøkosystem rundt Cairo som gjør det vanskeligere å rekruttere erfarne utviklere raskt.

Verdikten: hvilket system bør du velge?

Det finnes ingen universell vinner, og tallene over viser hvorfor. Hvis prosjektet ditt måles i gasskostnad per transaksjon, vinner zk-SNARK klart: 230.000 til 320.000 gass slår 2,5 millioner gass hver eneste gang, og det er nøyaktig derfor zkSync Era, Polygon zkEVM og Scroll alle har landet på SNARK-varianter for sine høyvolum-rollups. Hvis prosjektet derimot måles i tillitsmodell og motstandsdyktighet mot en fremtidig kvantedatamaskin, vinner zk-STARK like klart, og det forklarer hvorfor StarkWare har bygget et helt Cairo-økosystem rundt akkurat den fordelen.

For de fleste team som bygger en vanlig DeFi- eller betalings-rollup i 2026, er zk-SNARK fortsatt det pragmatiske valget på grunn av lavere kostnad og et modnere verktøysett. For team som bygger noe som skal vare i flere tiår, håndterer ekstremt høye verdier, eller ønsker et rent transparent sikkerhetsargument uten en seremoni å forsvare, er zk-STARK investeringen verdt den ekstra gasskostnaden. Flere av de største aktørene forsøker nå å hente det beste fra begge verdener gjennom rekursive og komprimerte bevis, som Nova, som lander et sted midt imellom på rundt 800.000 gass.

Konklusjonen kan derfor ikke forkortes til én setning uten å miste noe viktig. Om målet er lavest mulig kostnad per transaksjon her og nå, er svaret zk-SNARK, med Groth16 for maksimal komprimering eller PLONK for enklere oppgraderinger. Om målet er en tillitsmodell uten svake punkter og motstandskraft mot en trussel som ennå ikke finnes, er svaret zk-STARK. De fleste team lander et sted mellom disse ytterpunktene, og det er nettopp derfor rekursjon, aggregering og hybridløsninger som «wrappet STARK i SNARK» har blitt et av de mest aktive forskningsfeltene i hele bransjen gjennom 2025 og 2026.

Ofte stilte spørsmål om zk-SNARK og zk-STARK

Hva betyr SNARK og STARK som forkortelser?

SNARK står for «Succinct Non-interactive Argument of Knowledge», altså et kortfattet, ikke-interaktivt bevis for kunnskap. STARK står for «Scalable Transparent Argument of Knowledge», et skalerbart og transparent bevis. Begge er underkategorier av zero-knowledge proofs.

Er zk-STARK alltid tryggere enn zk-SNARK?

Ikke nødvendigvis. Begge systemene regnes som kryptografisk sikre mot klassiske angrep i dag. Forskjellen ligger i tillitsmodellen: SNARK krever normalt en tiltrodd oppsett-seremoni, mens STARK er transparent. STARK har i tillegg fordelen av å være kvantesikker, mens vanlige SNARK-varianter ikke er det.

Hvorfor er STARK-bevis så mye større enn SNARK-bevis?

STARK bygger på FRI-protokollen, som krever at flere hashverdier og Merkle-stier legges ved beviset for å bevise nærhet til et lavgrads polynom. Dette gir en hash-basert sikkerhetsmodell uten hemmeligheter, men resultatet er bevis som typisk er 40 til over 400 ganger større enn tilsvarende SNARK-bevis.

Hvilke Ethereum-rollups bruker zk-STARK i 2026?

StarkNet, bygget av StarkWare Industries, er det klareste eksempelet på et STARK-basert rollup i produksjon. StarkNet bruker sitt eget kretsspråk Cairo for å skrive og bevise smartkontraktlogikk.

Kan zk-SNARK oppgraderes til å bli kvantesikkert?

Det pågår forskning på gitterbaserte og hash-baserte SNARK-varianter som skal tåle kvanteangrep, men produksjonssystemene som brukes i rollups i dag, Groth16 og PLONK, bygger på elliptisk kurve-paringer og er ikke kvantesikre. En full overgang vil kreve nye kretsspråk og ny infrastruktur, ikke bare en oppdatering.

Hvorfor koster STARK-verifisering så mye mer gass på Ethereum?

Fordi rå STARK-verifisering krever langt flere hash- og Merkle-operasjoner enn en pareing-basert SNARK-verifisering, og fordi selve bevisdataene som må publiseres er så mye større. Estimater satte rå STARK-verifisering til rundt 2,5 millioner gass mot 230.000 til 320.000 gass for Groth16 og PLONK.

Trenger Zcash en ny tiltrodd oppsett-seremoni for hver oppgradering?

Zcash sine tidlige generasjoner, Sprout og Sapling, krevde egne seremonier basert på Groth16. Nyere versjoner beveger seg mot Halo2, en SNARK-variant designet for å redusere avhengigheten av en fersk seremoni for hver oppgradering, men prosjektet forblir innenfor SNARK-familien snarere enn å bytte til STARK.

Hva er forskjellen på Groth16 og PLONK?

Begge er zk-SNARK-varianter. Groth16 gir det minste beviset, rundt 192 byte, og lavest verifiseringskostnad på Ethereum, men krever et eget oppsett for hver unike krets. PLONK bruker et universelt oppsett som kan gjenbrukes på tvers av flere kretser, noe som gjør det enklere å oppdatere logikk uten en ny seremoni, mot et litt større bevis på rundt 576 byte.

Hva er en rollup, og hvorfor trenger den et bevis?

En rollup flytter beregning og lagring bort fra Ethereums hovedkjede, kjører tusenvis av transaksjoner i en batch, og sender deretter et sammendrag tilbake til L1. Et validity-bevis, enten SNARK eller STARK, er det som lar Ethereum stole på at sammendraget faktisk stemmer, uten at noen L1-node trenger å kjøre gjennom hver eneste transaksjon i batchen på nytt. Dette er selve mekanismen som gjør at ZK-rollups kan tilby transaksjoner ned mot noen få cent, samtidig som de arver sikkerheten til Ethereum.

Kan et prosjekt bruke både zk-SNARK og zk-STARK samtidig?

Ja, og flere prosjekter gjør nettopp det. Et vanlig mønster er å bruke STARK internt for rask, transparent bevisgenerering på store datamengder, og deretter «wrappe» det endelige STARK-beviset i et lite SNARK-bevis før det sendes til Ethereum. Dette gir mye av fordelen med transparens under selve beregningen, samtidig som L1 bare må betale den lave verifiseringskostnaden til et SNARK-bevis.

Hvor lang tid tar det å lære Cairo hvis man allerede kan Solidity?

De fleste erfarne Solidity-utviklere som har uttalt seg offentlig om overgangen, beskriver en læringskurve på noen uker til et par måneder for å bli produktiv i Cairo, avhengig av hvor mye erfaring de fra før har med lavnivå- eller systemprogrammering. Fordi Cairo håndterer minne og typer annerledes enn Solidity, tar det som regel lenger tid å bli virkelig komfortabel med å optimalisere kretser for lav proving-kostnad enn å skrive den første fungerende kontrakten.

Se også vår samleside for kryptografi for flere sammenligninger av hash-algoritmer, signatursystemer og postkvante-kryptografi, samt tidligere dekning av hvordan norske og nordiske aktører har møtt kvantetrusselen i egen infrastruktur.