{"id":308,"date":"2026-08-28T05:08:48","date_gmt":"2026-08-28T05:08:48","guid":{"rendered":"https:\/\/hoge.gg\/no\/formell-verifisering-beviser-koden-krypto-2026\/"},"modified":"2026-08-28T05:08:48","modified_gmt":"2026-08-28T05:08:48","slug":"formell-verifisering-beviser-koden-krypto-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/formell-verifisering-beviser-koden-krypto-2026\/","title":{"rendered":"Formell verifisering: revisoren som beviser koden, ikke tester den"},"content":{"rendered":"

Den 3. november 2025 forsvant det digitale verdier for mer enn 128 millioner dollar (rundt 1,2 milliarder kroner) ut av DeFi-protokollen Balancer i l\u00f8pet av noen f\u00e5 blokker. Det mest ubehagelige var ikke bel\u00f8pet, men at koden som ble t\u00f8mt, var blant de grundigst gjennomg\u00e5tte i hele bransjen: elleve separate revisjoner fra fire ulike selskaper, og en av dem var ikke en gjennomlesning, men et matematisk bevis. Feilen hadde ligget i koden siden juli 2021 og overlevd hver eneste kontroll, if\u00f8lge CryptoSlates gjennomgang<\/a>.<\/p>

For folk flest betyr \u00abrevidert\u00bb at noen erfarne \u00f8yne har lest koden og lett etter feil. Formell verifisering lover noe langt sterkere: et bevis, i matematisk forstand, p\u00e5 at koden oppf\u00f8rer seg slik den er spesifisert, for alle mulige inndata, ikke bare dem en tester tilfeldigvis kommer p\u00e5 \u00e5 pr\u00f8ve. Det er avstanden mellom \u00abvi fant ingen feil da vi lette\u00bb og \u00abvi har bevist at denne feilen ikke kan oppst\u00e5\u00bb. I en bransje som tapte over 1,31 milliarder dollar (rundt 12 milliarder kroner) til angrep bare i f\u00f8rste halv\u00e5r 2026, if\u00f8lge CertiKs Hack3d-rapport<\/a>, er det en forlokkende forskjell.<\/p>

Denne gjennomgangen ser p\u00e5 formell verifisering som en egen kategori kryptorevisjon: hva den faktisk beviser, hvorfor Balancer-saken viser b\u00e5de styrken og den innebygde begrensningen, hvem selskapene er (med Certora i sentrum), hva det koster, og hvorfor et bevis, selv et feilfritt et, ikke stopper de angrepene som i dag stjeler mest. Det er en s\u00f8sterartikkel til v\u00e5r gjennomgang av hva vanlige audits fanger og bommer p\u00e5<\/a>.<\/p>

Hva formell verifisering egentlig er<\/h2>

Formell verifisering (FV) er en metode fra datavitenskapen som er eldre enn kryptobransjen selv. Den brukes til \u00e5 sikre alt fra flykontrollsystemer og mikroprosessorer til operativsystemkjerner. Ideen er enkel \u00e5 beskrive og vanskelig \u00e5 gjennomf\u00f8re: i stedet for \u00e5 kj\u00f8re programmet med noen utvalgte testverdier og se om det krasjer, oversetter man b\u00e5de programmet og en presis p\u00e5stand om hva det skal gj\u00f8re til matematisk logikk, og lar en datamaskin avgj\u00f8re om p\u00e5standen kan brytes.<\/p>

Certora, som er blitt det mest kjente navnet i kryptosammenheng, formulerer det slik i sitt eget materiale: formell verifisering \u00abproduserer et matematisk bevis p\u00e5 at programmet oppf\u00f8rer seg i tr\u00e5d med spesifikasjonen p\u00e5 tvers av alle kj\u00f8ringer\u00bb, og gir \u00abfullstendig dekning av alle utf\u00f8relsesveier for en gitt spesifikasjon\u00bb. Tradisjonell testing og fuzzing, derimot, \u00abkan bare av og til oppdage feil\u00bb, og bare hvis de inndataene man velger, faktisk utl\u00f8ser feilen. Det skriver selskapet i sin egen innf\u00f8ring i formell verifisering<\/a>.<\/p>

Forskjellen er kategorisk. En test svarer p\u00e5 sp\u00f8rsm\u00e5let \u00abfeiler koden for akkurat disse verdiene?\u00bb. Et bevis svarer p\u00e5 \u00abkan koden i det hele tatt feile p\u00e5 denne m\u00e5ten, for noen verdier som helst?\u00bb. Der en tester m\u00e5 gjette hvilke tilfeller som er farlige, dekker beviset alle tilfellene p\u00e5 \u00e9n gang, inkludert dem ingen menneskelig revisor ville kommet p\u00e5.<\/p>

Et konkret eksempel Certora selv trekker fram: en usynlig regnefeil i MakerDAOs kjernematematikk, en overtredelse av selve likningen som holder DAI-systemet solvent, som hadde ligget uoppdaget siden 2018 og satte anslagsvis 10 milliarder dollar (rundt 93 milliarder kroner) i fare. Feilen ble ikke funnet av manuell gjennomlesning eller testing, men av et formelt bevis som viste at en invariant kunne brytes.<\/p>

Bevis kontra stikkpr\u00f8ve: hvordan FV skiller seg fra en vanlig audit<\/h2>

For \u00e5 forst\u00e5 hvor formell verifisering h\u00f8rer hjemme, er det nyttig \u00e5 sette de tre vanligste tiln\u00e6rmingene ved siden av hverandre. En manuell audit er erfarne sikkerhetsforskere som leser koden linje for linje. Fuzzing og eiendomstesting kaster tusenvis eller millioner av inndata p\u00e5 koden og ser hva som knekker. Formell verifisering beviser eller motbeviser en presis p\u00e5stand for alle inndata samtidig.<\/p>

Metode<\/th>Hva den gj\u00f8r<\/th>Dekning<\/th>Fanger typisk<\/th>Iboende svakhet<\/th><\/tr><\/thead>
Manuell audit<\/td>Eksperter leser koden og resonnerer om den<\/td>Det revisoren rekker og kommer p\u00e5<\/td>Logikkfeil, designsvakheter, kjente m\u00f8nstre<\/td>Menneskelig; tar slutt ved tidsfristen, misser det ingen tenkte p\u00e5<\/td><\/tr>
Fuzzing \/ eiendomstesting<\/td>Kj\u00f8rer koden med sv\u00e6rt mange inndata<\/td>Bare de inndataene som faktisk kj\u00f8res<\/td>Krasj, uventede tilstander, grensetilfeller den snubler over<\/td>Finner bare feil hvis en test tilfeldigvis treffer dem<\/td><\/tr>
Formell verifisering<\/td>Beviser at en spesifisert egenskap holder for alle inndata<\/td>Fullstendig, men bare for det som er spesifisert<\/td>Aritmetiske feil, brutte invarianter, tilstander som \u00abikke skal kunne skje\u00bb<\/td>Beviser bare det du faktisk skriver ned; sier ingenting om resten<\/td><\/tr><\/tbody><\/table><\/figure>

De tre utelukker ikke hverandre; de beste sikkerhetsprosessene bruker alle tre. Balancer hadde b\u00e5de manuelle audits, testing og formell verifisering. Men de svarer p\u00e5 forskjellige sp\u00f8rsm\u00e5l, og det er avgj\u00f8rende \u00e5 vite hvilket sp\u00f8rsm\u00e5l man har betalt for \u00e5 f\u00e5 besvart.<\/p>

Det er ogs\u00e5 verdt \u00e5 merke seg hva FV ikke er: det er ikke et stempel som sier \u00abtrygg\u00bb. Et formelt bevis er alltid et bevis om noe bestemt: \u00abfor alle inndata gir denne funksjonen aldri ut mer enn den tar inn\u00bb, eller \u00abtotalbeholdningen er alltid lik summen av de enkelte saldoene\u00bb. Verdien av beviset er n\u00f8yaktig s\u00e5 stor som verdien av p\u00e5standen man har valgt \u00e5 bevise.<\/p>

Slik fungerer Certora Prover<\/h2>

Kjernen i Certoras teknologi heter Certora Prover. En ingeni\u00f8r skriver regler i et eget spr\u00e5k, CVL (Certora Verification Language), som ligner p\u00e5 Solidity, slik at kontraktsutviklere kan lese dem. En regel kan for eksempel si at \u00absummen av alle brukersaldoer alltid er lik den totale beholdningen\u00bb, eller at \u00abingen kan ta ut mer enn de har satt inn\u00bb.<\/p>

Prover oversetter s\u00e5 b\u00e5de kontraktens bytekode og regelen til logiske betingelser og sender dem til s\u00e5kalte SMT-solvere, spesialiserte bevismotorer som Z3 (fra Microsoft Research) og CVC5. Solveren gj\u00f8r \u00e9n av to ting: enten beviser den at ingen inndata kan bryte regelen, eller s\u00e5 returnerer den et konkret moteksempel, en spesifikk transaksjonssekvens som bryter den. Moteksemplet er ofte det mest verdifulle utfallet, fordi det gir utviklerne en presis oppskrift p\u00e5 angrepet f\u00f8r noen angriper.<\/p>

Det finnes en tredje mulighet, og den er viktig for \u00e5 lese en rapport \u00e6rlig: solveren kan g\u00e5 tom for tid eller ressurser og komme tilbake som ubestemt, verken bevist eller motbevist. Kompleks kode med mange forgreninger kan gi det som kalles \u00absti-eksplosjon\u00bb, der antallet mulige utf\u00f8relsesveier vokser raskere enn noen maskin kan h\u00e5ndtere. En redelig verifiseringsrapport skiller derfor tydelig mellom egenskaper som er bevist, egenskaper som er motbevist, og egenskaper som forble ubestemte.<\/p>

Tidlig i 2025 ble Certora Prover gjort til \u00e5pen kildekode<\/a>, og verkt\u00f8yet dekker n\u00e5 ikke bare EVM-baserte kjeder, men ogs\u00e5 Solana og Stellar. At bevismotoren er \u00e5pen, betyr at hvem som helst kan inspisere hvordan bevisene faktisk f\u00f8res, noe som demper (men ikke fjerner) bekymringen for at verkt\u00f8yet selv kan ha feil.<\/p>

Certora, selskapet bak bevismaskinen<\/h2>

Certora ble grunnlagt i 2018 av Mooly Sagiv, professor og leder for programvaresystemer ved Tel Aviv-universitetet og en veteran innen formelle metoder, sammen med teknologidirekt\u00f8r Shelly Grossman. Selskapet hentet 36 millioner dollar (rundt 335 millioner kroner) i en serie B-runde i mai 2022, ledet av Jump Crypto<\/a>, med Tiger Global og Galaxy Digital blant investorene.<\/p>

Kundelisten forklarer hvorfor navnet dukker opp igjen og igjen i store DeFi-hendelser: Aave, Lido, Uniswap, Compound, MakerDAO, EigenLayer, Morpho og Safe har alle brukt Certora. Selskapet oppgir selv at teknologien har v\u00e6rt brukt til \u00e5 sikre verdier for langt over hundre milliarder dollar (godt over 900 milliarder kroner), og at det er skrevet titusener av verifiseringsregler mot kundenes kontrakter.<\/p>

Certora er ikke alene i markedet, men selskapet har v\u00e6rt flinkere enn de fleste til \u00e5 gj\u00f8re formell verifisering forst\u00e5elig for et bredere publikum, og, som vi skal se, uvanlig \u00e6rlig n\u00e5r metoden kommer til kort. Den \u00e6rligheten ble satt p\u00e5 pr\u00f8ve i november 2025.<\/p>

Balancer: da beviset ikke var sterkt nok<\/h2>

Balancer V2 var ingen tilfeldig, urevidert protokoll. Kjernekoden hadde gjennomg\u00e5tt elleve revisjoner fra fire selskaper, deriblant OpenZeppelin, Trail of Bits og Certora. Certora hadde alts\u00e5 ikke bare lest koden, men f\u00f8rt formelle bevis p\u00e5 den. Likevel, den 3. november 2025, t\u00f8mte en angriper protokollen for over 128 millioner dollar (rundt 1,2 milliarder kroner) ved \u00e5 utnytte en avrundingsfeil i funksjonen _upscale<\/code>.<\/p>

Mekanikken er l\u00e6rerik. Ved visse bytter rundet koden av et bel\u00f8p nedover der den skulle rundet oppover i protokollens fav\u00f8r. Hver enkelt avrunding var forsvinnende liten, men ved \u00e5 kj\u00f8re mange manipulerte bytter i samme blokk kunne angriperen forsterke feilen til hele bassenget var tomt. Feilen hadde da ligget i koden i over fire \u00e5r.<\/p>

Det oppsiktsvekkende er hva Certora selv skrev etterp\u00e5. I sin egen gjennomgang av angrepet<\/a> erkjenner selskapet rett ut at bevisene fra 2022 dekket solvens p\u00e5 et overordnet niv\u00e5, men, med Certoras egne ord: \u00abselv om de verifiserte egenskapene garanterte solvens p\u00e5 et h\u00f8yt niv\u00e5, var de ikke sterke nok til \u00e5 oppdage avrundingsfeilen som for\u00e5rsaket angrepet\u00bb. Og videre: \u00abde verifiserte egenskapene begrenset ikke forholdet mellom enkeltbytter eller avrundingsatferd\u00bb.<\/p>

Med andre ord: Certora hadde bevist at Balancer var solvent, og det beviset holdt. Men ingen hadde bevist at avrundingen alltid gikk i protokollens fav\u00f8r, fordi ingen hadde skrevet ned den egenskapen. Beviset var korrekt; det var bare et bevis om feil ting.<\/p>

Kontrasten til Balancer V3 gj\u00f8r poenget skarpt. P\u00e5 V3 gj\u00f8res alle bassengoperasjoner med 18-desimalers presisjon, de s\u00e5kalte composable pools er byttet ut med ERC4626-buffere, og eksplisitte avrundingsretninger er lagt inn og h\u00e5ndhevet for hver eneste utregning. Certora la til en ny regel, swappingBackAndForth<\/code>, som beviser at det \u00e5 bytte et bel\u00f8p fra \u00e9n token til en annen og tilbake igjen aldri kan gi gevinst. V3 ble ikke rammet i angrepet; der var avrundingen korrekt. Forskjellen mellom V2 og V3 var ikke et bedre bevis; det var en bedre spesifikasjon.<\/p>

Spesifikasjonen er den nye svakheten<\/h2>

Balancer illustrerer tesen som l\u00f8per gjennom hele denne kategorien: formell verifisering fjerner ikke usikkerheten, den flytter den. Med en manuell audit er sp\u00f8rsm\u00e5let \u00abvar revisoren dyktig og grundig nok?\u00bb. Med formell verifisering blir sp\u00f8rsm\u00e5let \u00abdekker spesifikasjonen det som faktisk kan g\u00e5 galt?\u00bb. Flaskehalsen forskyves fra selve beviset til p\u00e5standene man velger \u00e5 bevise.<\/p>

Certora er prisverdig tydelig p\u00e5 dette i sitt eget materiale og lister opp begrensningene metoden har. \u00abHvis spesifikasjonen ikke n\u00f8yaktig fanger programmets tiltenkte oppf\u00f8rsel, kan ikke resultatene fra den formelle verifiseringen stoles p\u00e5\u00bb. Og enda mer direkte: \u00abhvis spesifikasjonen ikke dekker en egenskap, kan ikke formell verifisering gi noen garantier\u00bb mot feil knyttet til den egenskapen. Det er, i klartekst, s\u00f8ppel inn, s\u00f8ppel ut: et feilfritt bevis av en ufullstendig p\u00e5stand gir en falsk trygghet som kan v\u00e6re farligere enn ingen trygghet.<\/p>

Det finnes flere hull metoden ikke fyller. Formell verifisering av kontraktskoden sier ingenting om \u00f8konomiske designfeil, om en oracle som mates med manipulerte priser, om verdier som lekkes gjennom MEV, eller om private n\u00f8kler som kommer p\u00e5 avveie. Beviset gjelder koden slik den er skrevet, ikke verden koden lever i. Det er en p\u00e5minnelse om at styringsangrep som det mot Term Finance<\/a> ofte handler om intensjon og insentiver, ikke om en enkelt kodelinje som er \u00abfeil\u00bb.<\/p>

Web3-utvikleren Suhail Kakar oppsummerte stemningen etter Balancer treffende. Protokollen hadde v\u00e6rt gjennom over ti revisjoner, kjernehvelvet gransket av flere uavhengige selskaper, og ble likevel t\u00f8mt. \u00abAudited by X betyr nesten ingenting\u00bb, skrev han<\/a>; \u00abkode er vanskelig, DeFi er vanskeligere\u00bb. Poenget er ikke at revisjon er verdil\u00f8st, men at et stempel aldri var det samme som en garanti.<\/p>

Landskapet: hvem andre beviser kode?<\/h2>

Certora er det mest synlige navnet, men formell verifisering er et felt med flere akt\u00f8rer og tiln\u00e6rminger. Noen selger det som en tjeneste, andre bygger \u00e5pne verkt\u00f8y utviklere kan bruke selv, og noen er bygget inn i verkt\u00f8yene folk allerede har.<\/p>

Akt\u00f8r \/ verkt\u00f8y<\/th>Type<\/th>Spesialitet<\/th>Merk<\/th><\/tr><\/thead>
Certora (Prover, CVL)<\/td>Kommersiell tjeneste + \u00e5pen motor<\/td>Egne regler i CVL, SMT-solvere; EVM, Solana, Stellar<\/td>Bransjens mest kjente; \u00e5pen kildekode fra 2025<\/td><\/tr>
Runtime Verification (Kontrol, KEVM)<\/td>Selskap + \u00e5pne verkt\u00f8y<\/td>En formell modell av EVM; bevis fra eksisterende Foundry-tester<\/td>Bygget p\u00e5 det akademiske K-rammeverket<\/td><\/tr>
Veridise (Picus)<\/td>Selskap<\/td>Zero-knowledge-kretser og underbestemte betingelser<\/td>Et omr\u00e5de der vanlige audits ofte bommer<\/td><\/tr>
Halmos (a16z)<\/td>\u00c5pent verkt\u00f8y<\/td>Symbolsk testing som gjenbruker Foundry-tester som spesifikasjon<\/td>Garantien er \u00abbounded\u00bb, begrenset av l\u00f8kkedybde<\/td><\/tr>
SMTChecker<\/td>Innebygd i Solidity-kompilatoren<\/td>Enkle egenskaper, gratis<\/td>Lav terskel, men begrenset rekkevidde<\/td><\/tr><\/tbody><\/table><\/figure>

Verkt\u00f8yene skiller seg mest i hvor spesifikasjonen kommer fra. Certora ber deg skrive reglene fra bunnen i CVL, noe som gir presisjon, men krever spesialkompetanse. Runtime Verifications Kontrol og a16z sitt Halmos gjenbruker tester utviklerne allerede har skrevet, som spesifikasjon, noe som senker terskelen, men gir svakere garantier: Halmos beskriver sin egen garanti som \u00abbounded\u00bb, alts\u00e5 begrenset av hvor dypt l\u00f8kker kj\u00f8res. Veridise har spesialisert seg p\u00e5 zero-knowledge-kretser, et omr\u00e5de der en feil kan v\u00e6re umulig \u00e5 se med det blotte \u00f8ye og der vanlige revisorer sjelden har verkt\u00f8yene.<\/p>

Det finnes ogs\u00e5 et voksende landskap av audit\u00f8rer som kombinerer formell verifisering med manuell gjennomgang og offensiv testing. For lesere som vil se hvordan dette ser ut utenfor EVM-verdenen, har vi tidligere g\u00e5tt gjennom Solana- og Move-revisorene<\/a>, og for den offensive siden, der et selskap angriper deg f\u00f8r angriperne gj\u00f8r det, hvordan red teaming fungerer i praksis<\/a>.<\/p>

Hva et bevis ikke fanger<\/h2>

Her kommer den ubehagelige delen for alle som h\u00e5per formell verifisering er en s\u00f8lvkule. Selv om man beviste all kontraktskode i hele bransjen feilfri, ville de fleste kronene fortsatt forsvinne. Grunnen er at pengene i \u00f8kende grad ikke lekker ut gjennom kodefeil, men gjennom n\u00f8kler, mennesker og infrastruktur, alt sammen ting et kodebevis ikke tar p\u00e5.<\/p>

CertiKs Hack3d-rapport for f\u00f8rste halv\u00e5r 2026 er tydelig p\u00e5 m\u00f8nsteret. Av over 1,31 milliarder dollar (rundt 12 milliarder kroner) i tap fordelte de st\u00f8rste kategoriene seg slik: kompromitterte lommeb\u00f8ker og n\u00f8kler sto for over 444 millioner dollar (rundt 4 milliarder kroner) fra bare 33 hendelser, phishing for 366 millioner dollar (rundt 3,4 milliarder kroner) fra 63 hendelser, mens kodes\u00e5rbarheter, som var den vanligste kategorien med 204 hendelser, likevel \u00abbare\u00bb sto for rundt 152 millioner dollar (rundt 1,4 milliarder kroner).<\/p>

Angrepsvektor<\/th>Antall hendelser (H1 2026)<\/th>Tap (USD)<\/th>Fanges av formell verifisering?<\/th><\/tr><\/thead>
Kompromittert lommebok \/ n\u00f8kkel<\/td>33<\/td>~444 mill.<\/td>Nei<\/td><\/tr>
Phishing \/ sosial manipulering<\/td>63<\/td>~366 mill.<\/td>Nei<\/td><\/tr>
Kodes\u00e5rbarhet<\/td>204<\/td>~152 mill.<\/td>Ofte, hvis spesifikasjonen dekker den<\/td><\/tr><\/tbody><\/table><\/figure>

Regnestykket er nedsl\u00e5ende for kode-optimister: den vanligste angrepstypen er ogs\u00e5 en av de billigste per hendelse, mens de dyreste angrepene treffer akkurat det formell verifisering ikke ser. En angriper som stjeler en n\u00f8kkel eller lurer en signerer, bryr seg ikke om at koden er bevist korrekt.<\/p>

Immunefi, som driver bransjens st\u00f8rste bug bounty-plattform, kom fram til en lignende totalsum for f\u00f8rste halv\u00e5r 2026: rundt 972 millioner dollar (vel 9 milliarder kroner) tapt over rekordmange 207 hendelser, under halvparten av tapene fra \u00e5ret f\u00f8r til tross for flere angrep. Immunefi utbetalte selv rundt 13,45 millioner dollar<\/a> (rundt 125 millioner kroner) til forskere for 837 gyldige feil de fanget f\u00f8r angriperne rakk det. Poenget er ikke at det ene laget sl\u00e5r det andre, men at et modent sikkerhetsoppsett trenger flere lag: bevis for koden, mennesker for logikken, og bounties for det alle andre bommet p\u00e5.<\/p>

AI skriver n\u00e5 kontraktene, og det endrer regnestykket<\/h2>

Den ferskeste grunnen til at formell verifisering f\u00e5r ny oppmerksomhet, er at stadig mer av koden ikke lenger skrives av mennesker. Store spr\u00e5kmodeller genererer n\u00e5 smartkontrakter p\u00e5 bestilling, ofte syntaktisk korrekte og overbevisende, men med sikkerhetsfeil under overflaten. N\u00e5r koden produseres raskere enn mennesker rekker \u00e5 granske den, blir en metode som kan bevise egenskaper automatisk plutselig mer attraktiv.<\/p>

Certora svarte p\u00e5 dette i november 2025 med Certora AI Composer, som selskapet kaller \u00abden f\u00f8rste trygge AI-kodeplattformen for smartkontrakter\u00bb. Ideen er \u00e5 bygge bevismotoren inn i selve kodegenereringen, slik at hver kodebit AI-en foresl\u00e5r, kontrolleres mot matematiske sikkerhetsregler f\u00f8r den i det hele tatt kj\u00f8res. Mooly Sagiv formulerte ambisjonen slik<\/a>: \u00abAI og formell verifisering kan jobbe sammen for \u00e5 gj\u00f8re smartkontraktutvikling p\u00e5litelig som standard\u00bb.<\/p>

Ikke alle er like optimistiske til AI som sikkerhetssnarvei. David Schwed, driftsdirekt\u00f8r i sikkerhetsselskapet SVRN, advarer mot \u00e5 forveksle et verkt\u00f8y med en prosess. \u00abClaude, revider smartkontrakten min, ikke gj\u00f8r feil, er ikke et sikkerhetsprogram\u00bb, sa han til CoinDesk<\/a>, og la til at \u00abhvis den som kj\u00f8rer verkt\u00f8yet ikke kan vurdere det som kommer tilbake, har du ikke kj\u00f8pt sikkerhet, du har kj\u00f8pt en falsk f\u00f8lelse av den\u00bb. Samtidig peker han p\u00e5 den reelle gevinsten: AI kan gi \u00abkontinuerlig revisjon med foresl\u00e5tte utbedringer til en br\u00f8kdel av kostnaden, i stedet for en engangsgjennomgang du bare har r\u00e5d til \u00e9n gang\u00bb.<\/p>

Det er nettopp her formell verifisering og AI m\u00f8tes p\u00e5 en interessant m\u00e5te. AI kan foresl\u00e5 b\u00e5de koden og et f\u00f8rste utkast til spesifikasjonen; bevismotoren kan avvise begge deler hvis de ikke henger sammen. Men, som Balancer viste, er et bevis bare s\u00e5 godt som spesifikasjonen, og en AI som skriver b\u00e5de koden og p\u00e5standene om koden, risikerer \u00e5 bevise n\u00f8yaktig det utvikleren h\u00e5pet, ikke det angriperen faktisk vil utnytte.<\/p>

S\u00e5 mye koster det, og hvem har r\u00e5d<\/h2>

Formell verifisering er dyrt, av en enkel grunn: det krever spesialister som kan b\u00e5de kontraktsspr\u00e5ket og matematisk logikk, og det tar tid \u00e5 skrive gode spesifikasjoner. En full manuell audit av en middels stor protokoll ligger typisk i st\u00f8rrelsesorden hundretusener av kroner til godt over en million; et formelt verifiseringsoppdrag p\u00e5 toppen kan koste like mye eller mer, avhengig av hvor mange egenskaper som skal bevises.<\/p>

Det skaper en skjevhet: de st\u00f8rste protokollene, med mest \u00e5 tape, har r\u00e5d til \u00e5 bevise koden sin, mens mindre prosjekter n\u00f8yer seg med en rask gjennomgang eller ingenting. Ethereum Foundation fors\u00f8kte \u00e5 b\u00f8te p\u00e5 dette i april 2026 med et tilskuddsprogram p\u00e5 rundt 1 million dollar<\/a> (rundt 9 millioner kroner), der over tjue sikkerhetsselskaper, Certora blant dem, kan dekke inntil 30 prosent av revisjonskostnaden for utvalgte prosjekter, og, avgj\u00f8rende, pengene utbetales f\u00f8rst etter at funnene er rettet, ikke bare etter at rapporten er levert.<\/p>

For institusjonene som n\u00e5 tokeniserer verdier for milliarder, endrer regnestykket seg. N\u00e5r tradisjonelle finansakt\u00f8rer legger obligasjoner og fond p\u00e5 kjeden, blir et matematisk bevis p\u00e5 at kontrakten oppf\u00f8rer seg, en langt lettere salgbar forsikring enn \u00abvi leste koden og fant ingenting\u00bb. Det er en av grunnene til at etablerte revisjonsselskaper posisjonerer seg mot de tokeniserte verdiene p\u00e5 Wall Street<\/a>, der kravene til dokumentert sikkerhet er strengere enn i det ville DeFi-landskapet.<\/p>

Finanstilsynet, MiCA og hullet ingen regulator dekker<\/h2>

For norske lesere er det en viktig nyanse her: ingen offentlig myndighet sertifiserer eller godkjenner den som reviderer en smartkontrakt. Kryptoeiendelsloven, som tr\u00e5dte i kraft 1. juli 2025 og innlemmer EUs MiCA-regelverk i norsk rett gjennom E\u00d8S-avtalen, regulerer tjenesteyterne (CASP-ene), alts\u00e5 b\u00f8rsene, vekslerne og oppbevaringstjenestene, ikke koden i protokollene de kobler seg til. Det framg\u00e5r av Finanstilsynets egen omtale av regelverket<\/a>. Finanstilsynet f\u00f8rer tilsyn med at en CASP har forsvarlig drift, ikke med at en gitt DeFi-kontrakt er matematisk bevist trygg.<\/p>

Det samme gjelder DORA, EUs regelverk for digital operasjonell motstandsdyktighet, som stiller krav til IT-sikkerhet og hendelsesh\u00e5ndtering hos de sentraliserte akt\u00f8rene, men som heller ikke rekker inn i selve kontraktskoden. Med andre ord: verken MiCA eller DORA p\u00e5legger noen \u00e5 formelt verifisere en smartkontrakt, og ingen tilsynsmyndighet stempler et verifiseringsselskap som \u00abgodkjent\u00bb. Overgangsperioden for eksisterende akt\u00f8rer under den norske loven er forlenget til 30. juni 2026, men den handler om lisensiering av tjenesteytere, ikke om kodekvalitet.<\/p>

Konsekvensen for en investor eller bruker er at ansvaret for \u00e5 vurdere om en protokolls kode er skikkelig verifisert, faller p\u00e5 en selv. Det finnes ikke et offentlig register \u00e5 sl\u00e5 opp i. Det n\u00e6rmeste man kommer, er \u00e5 lese verifiseringsrapportene direkte, og da hjelper det \u00e5 vite hva man ser etter.<\/p>

Slik leser du en verifiseringsrapport<\/h2>

En verifiseringsrapport ser annerledes ut enn en vanlig auditrapport, og den er lettere \u00e5 feiltolke. Her er tingene som er verdt \u00e5 sjekke.<\/p>

  • Hva ble faktisk bevist?<\/strong> Se etter en liste over egenskaper (regler). En rapport som beviser \u00abtotalbeholdningen er alltid korrekt\u00bb, men ikke sier noe om avrunding i enkeltbytter, forteller deg like mye med det den utelater som med det den inkluderer.<\/li>
  • Bevist, motbevist eller ubestemt?<\/strong> Egenskaper som forble ubestemte (solveren ga opp) er ikke det samme som beviste. Et \u00e6rlig selskap skiller tydelig; et mindre \u00e6rlig ett gjemmer dem bort.<\/li>
  • Hvilke antakelser ble gjort?<\/strong> Bevis hviler ofte p\u00e5 forutsetninger (\u00abvi antar at oracle-prisen er korrekt\u00bb, \u00abvi ser bort fra denne biblioteksfunksjonen\u00bb). Antakelsene er der de virkelige hullene bor.<\/li>
  • Hvor gammelt er beviset?<\/strong> Et bevis gjelder koden slik den var da beviset ble f\u00f8rt. \u00c9n oppgradering senere kan det v\u00e6re verdil\u00f8st.<\/li>
  • Hvem skrev spesifikasjonen?<\/strong> Ble reglene skrevet av et uavhengig selskap eller av teamet selv? Et team som beviser sine egne p\u00e5stander, beviser lett det de allerede trodde.<\/li><\/ul>

    Den siste linjen er verdt \u00e5 gjenta, fordi den er kjernen i alt sammen: et bevis er et svar, og svaret er bare s\u00e5 godt som sp\u00f8rsm\u00e5let. N\u00e5r du leser at en protokoll er \u00abformelt verifisert\u00bb, er det riktige oppf\u00f8lgingssp\u00f8rsm\u00e5let ikke \u00abav hvem?\u00bb, men \u00abverifisert for hva?\u00bb.<\/p>

    Bunnlinjen<\/h2>

    Formell verifisering er den sterkeste enkeltmetoden bransjen har for \u00e5 si noe sikkert om kode. Den fanger klasser av feil, aritmetiske avvik, brutte invarianter, tilstander som \u00abikke skal kunne skje\u00bb, som verken menneskelige \u00f8yne eller tilfeldig testing p\u00e5litelig oppdager. MakerDAO-saken viser at den kan avdekke feil verdt milliarder som har ligget skjult i \u00e5revis.<\/p>

    Men Balancer viser den andre halvdelen av sannheten like tydelig: et bevis dekker bare det du spesifiserer, og de dyreste angrepene i 2026 treffer ting ingen spesifikasjon ber\u00f8rer, n\u00f8kler, mennesker og infrastruktur. Formell verifisering fjerner ikke risiko; den flytter den fra koden til spesifikasjonen, og der forsvinner den ikke, den bytter bare adresse.<\/p>

    For en bruker er den praktiske l\u00e6rdommen edruelig: \u00abformelt verifisert\u00bb er et sterkere merke enn \u00abrevidert\u00bb, men det er fortsatt et merke, ikke en garanti. Sp\u00f8r alltid hva som ble bevist, hvilke antakelser som ble gjort, og hva som ble st\u00e5ende ubevist. I en bransje der selv elleve revisjoner ikke stoppet en fire \u00e5r gammel avrundingsfeil, er sunn skepsis fortsatt det billigste sikkerhetslaget som finnes.<\/p>

    Ofte stilte sp\u00f8rsm\u00e5l<\/h2>

    Hva er forskjellen p\u00e5 formell verifisering og en vanlig smartkontrakt-audit?<\/h3>

    En vanlig audit er erfarne sikkerhetsforskere som leser koden og leter etter feil; de finner det de rekker og kommer p\u00e5. Formell verifisering oversetter koden og en presis p\u00e5stand til matematisk logikk og beviser at p\u00e5standen holder for alle mulige inndata, ikke bare dem en tester pr\u00f8ver. FV gir sterkere garantier, men bare for de egenskapene som faktisk er skrevet ned.<\/p>

    Betyr \u00abformelt verifisert\u00bb at en protokoll er trygg \u00e5 bruke?<\/h3>

    Nei. Det betyr at bestemte egenskaper er bevist for koden slik den var da beviset ble f\u00f8rt. Balancer var formelt verifisert og ble likevel t\u00f8mt for over 128 millioner dollar i november 2025, fordi egenskapen som ble brutt, avrunding i enkeltbytter, ikke var blant dem som var bevist. Et bevis er bare s\u00e5 godt som spesifikasjonen bak det.<\/p>

    Hvem er de st\u00f8rste selskapene innen formell verifisering av krypto?<\/h3>

    Certora er det mest kjente, med kunder som Aave, Lido, Uniswap og MakerDAO. Andre akt\u00f8rer er Runtime Verification, som st\u00e5r bak Kontrol og en formell EVM-modell, Veridise, som er spesialisert p\u00e5 zero-knowledge-kretser, og det \u00e5pne verkt\u00f8yet Halmos fra a16z. Solidity-kompilatoren har ogs\u00e5 en enkel innebygd sjekker, SMTChecker.<\/p>

    Fanger formell verifisering alle typer hackerangrep?<\/h3>

    Nei. Formell verifisering gjelder kontraktskoden, ikke verden rundt. Den fanger ikke kompromitterte private n\u00f8kler, phishing, manipulerte oracle-priser, MEV eller \u00f8konomiske designfeil. I f\u00f8rste halv\u00e5r 2026 kom de st\u00f8rste tapene fra kompromitterte lommeb\u00f8ker og phishing, ikke fra kodefeil, og ingen av dem ville blitt stoppet av et kodebevis.<\/p>

    Regulerer Finanstilsynet dem som reviderer smartkontrakter?<\/h3>

    Nei. Finanstilsynet f\u00f8rer tilsyn med kryptotjenesteytere (CASP-er) under kryptoeiendelsloven, som innlemmer MiCA gjennom E\u00d8S-avtalen, men verken MiCA eller DORA p\u00e5legger noen \u00e5 formelt verifisere kode, og ingen myndighet sertifiserer verifiseringsselskaper. Ansvaret for \u00e5 vurdere om koden er skikkelig verifisert, ligger hos brukeren selv.<\/p>