Risici ved smartkontrakter: kode, orakler, styring og opgraderingsnøgler

Et kontrolpanel kan få risici ved smartkontrakter til at ligne én enkelt hændelse. Bag kulissen er fastlæggelse af rettigheder og invarianter, revision af det implementerede system samt håndtering og styring separate tilstandsændringer, der varetages af forskellige deltagere. Det er i disse skjulte overleveringer, at tid, omkostninger og risici opstår.

Risici ved smartkontrakter er muligheden for, at kode, afhængigheder eller styring fører til et økonomisk resultat, der afviger fra brugernes forventninger. Angrebsfladen omfatter forretningslogik, adgangskontrol, aritmetik og regnskabsføring, orakler, tokens, komposérbarhed, brugergrænseflader, private nøgler, opgraderinger og de juridiske løfter, der omgiver koden.

En revision er dokumentation fra en afgrænset gennemgang, ikke en garanti. Korrekt kildekode kan implementeres med andre parametre, opgraderes senere eller interagere med et manipuleret orakel. Uforanderlig kode mindsker kun risikoen for ændringer, hvis den uforanderlige adfærd og dens afhængigheder i sig selv er sikre.

Hvis du vil sætte risici ved smartkontrakter ind i Securities.io’s bredere dækning, kan du sammenligne Referencemodel for DeFi-stakken, Virksomheder, der reviderer smartkontrakter og Smartkontraktsikkerhed og AI. Tilsammen viser vejledningerne, hvordan spørgsmålet om infrastrukturen for digitale aktiver ændrer sig, når udstederen, aktivet, investorens rettigheder eller driftsinfrastrukturen ændres.

Fra fastlæggelse af rettigheder og invarianter til håndtering og styring: kæden af risici ved smartkontrakter

Fastlæggelse af rettigheder og invarianter indebærer, at saldi, beføjelser, grænser og betingelser, som altid skal være opfyldt, defineres. Resultatet bliver derefter input til implementering og test, hvor der bruges gennemgåede komponenter samt enheds-, integrations-, egenskabsbaserede og adversarielle tests. Denne overlevering er det første sted, hvor risici ved smartkontrakter skal testes: Modtageren skal kunne skelne en gennemført tilstandsændring fra en meddelelse, et estimat eller en foreløbig registrering. Den samme test gælder ved hver efterfølgende pil, indtil håndtering og styring fører til et resultat, der uafhængigt kan afstemmes.

Læs diagrammet baglæns fra håndtering og styring. Sluttilstanden bør føre tilbage til specifikationen, den implementerede kildekode og bytekode, test og revisioner, parametre og administratorroller, kortlægningen af orakler og afhængigheder, overvågede hændelser, hændelseshåndtering og fordeling af tab. Derfra går kæden videre til de beføjelser, der bruges under drift og overvågning, den eksponering, der opstår ved revision af det implementerede system, og de input, der accepteres ved fastlæggelsen af rettigheder og invarianter. Hvis kæden brydes, kan en fejl i adgangskontrollen ligne en gennemført transaktion, selv når en uvedkommende aktør får beføjelse til at præge tokens, hæve midler, sætte systemet på pause eller opgradere det. Denne baglæns sporing holder analysen fokuseret på den lovede finansielle invariant og alle de kode-, data- og styringsafhængigheder, der kan ændre den, frem for på en udbyders betegnelse eller grænsefladens status.

Hvem kontrollerer de kritiske oplysninger ved risici ved smartkontrakter?

Protokoludvikleren og auditoren befinder sig på hver sin side af driftskæden. Protokoludvikleren designer og implementerer den økonomiske og tekniske logik, mens auditoren gennemgår en afgrænset version og rapporterer sine fund. Deres dokumentation – specifikation, kode, tests, commits, afhængigheder og udrulning for den ene part samt afgrænsning, metoder, antagelser, alvorlighedsgrad, rettelser og resterende risiko for den anden – bør stemme overens om den samme hændelse uden at være kopier af én leverandørs database. Orakler eller eksterne protokoller, styring og nøgleindehavere samt brugere eller integratorer bidrager med særskilte beslutninger eller dokumentation; hvis man behandler disse funktioner som indbyrdes udskiftelige, bliver det uklart, hvor skøn, likviditet eller juridisk ansvar kommer ind i billedet.

Et driftsstop hos styringen og nøgleindehaverne er en praktisk prøve på ansvarlighed, når det gælder risiko ved smartkontrakter. De kan ændre parametre, sætte systemet på pause, opgradere det eller flytte aktiver. Spørgsmålet er, om protokoludvikleren og auditoren stadig kan rekonstruere situationen ud fra roller, quorum, tidslås, afstemninger, opbevaring af nøgler og hændelseshistorik. Kontrakter kan fordele opgaver, men den part, der står inde for kundeløftet, aktivet eller forpligtelsen, kan ikke erstatte dokumentation med en klausul om outsourcing. Et modstandsdygtigt design angiver, hvilken dokumentation der skal bruges som reserve, og hvem der har bemyndigelse til at løse en uoverensstemmelse.

Hvordan risikoen ved smartkontrakter ændrer sig i praksis

1. Fastlæg rettigheder og invarianter: Definér udgangstilstanden for risiko ved smartkontrakter

Definér saldi, beføjelser, grænser og betingelser, der altid skal være opfyldt. I denne del af arbejdet med risiko ved smartkontrakter fastlægger trinnet de betingelser, som implementering og test kan bygge på. Protokoludvikleren er central, fordi vedkommende designer og implementerer den økonomiske og tekniske logik. Dokumentationen bør omfatte specifikation, kode, tests, commits, afhængigheder og udrulning.

Den fejl, man skal være opmærksom på her, er en fejl i adgangskontrollen: En uvedkommende aktør får beføjelse til at udstede, hæve midler, sætte systemet på pause eller opgradere det. For at teste dette trin skal resultatet registreres med samme tidspunkt, afgrænsning og gældende vilkår, hvorefter én antagelse ændres inden implementering og test. Når det gælder risiko ved smartkontrakter, angiver en forsvarlig overdragelse, hvem der godkendte resultatet, hvilken dokumentation der blev ændret, hvad der stadig kan omgøres, og hvem der bærer tabet, hvis den næste part afviser dokumentationen.

2. Implementér og test: Find beslutningsreglen for risiko ved smartkontrakter

Brug gennemgåede komponenter samt enheds-, integrations-, egenskabs- og adversarielle tests. I denne del af arbejdet med risiko ved smartkontrakter afprøver trinnet de betingelser, som revisionen af det udrullede system kan bygge på. Auditoren er central, fordi vedkommende gennemgår en afgrænset version og rapporterer sine fund. Dokumentationen bør omfatte afgrænsning, metoder, antagelser, alvorlighedsgrad, rettelser og resterende risiko.

Den fejl, man skal være opmærksom på her, er et regnskabsbaseret angreb: Afrunding, reentrancy, prissætning af andele eller rækkefølgen af tilstande skaber værdi ud af ingenting. For at teste dette trin skal resultatet genberegnes med samme tidspunkt, afgrænsning og gældende vilkår, hvorefter én antagelse ændres inden revisionen af det udrullede system. Når det gælder risiko ved smartkontrakter, angiver en forsvarlig overdragelse, hvem der godkendte resultatet, hvilken dokumentation der blev ændret, hvad der stadig kan omgøres, og hvem der bærer tabet, hvis den næste part afviser dokumentationen.

3. Revidér det udrullede system: Mål risikofordelingen ved smartkontrakter

Kontrollér kildekode, bytekode, parametre, afhængigheder, nøgler og driftskontroller. I denne del af arbejdet med risiko ved smartkontrakter omfordeler trinnet de betingelser, som drift og overvågning kan bygge på. Orakler eller eksterne protokoller er centrale, fordi de leverer priser, beskeder, tokens eller likviditet. Dokumentationen bør omfatte kilder, opdateringer, modstandsdygtighed over for manipulation, administratorrettigheder og hændelser.

Den fejl, man skal være opmærksom på her, er orakelmanipulation: En midlertidig eller illikvid pris styrer lånoptagelse, swaps eller likvidation. For at teste dette trin skal resultatet stresstestes med samme tidspunkt, afgrænsning og gældende vilkår, hvorefter én antagelse ændres inden drift og overvågning. Når det gælder risiko ved smartkontrakter, angiver en forsvarlig overdragelse, hvem der godkendte resultatet, hvilken dokumentation der blev ændret, hvad der stadig kan omgøres, og hvem der bærer tabet, hvis den næste part afviser dokumentationen.

4. Driv og overvåg: Afstem den autoritative dokumentation for risiko ved smartkontrakter

Hold øje med værdi, afvigelser, orakler, privilegerede handlinger og ændringer i afhængigheder. I denne del af arbejdet med risiko ved smartkontrakter afstemmer trinnet de betingelser, som indsatsen og styringen kan bygge på. Styringen og nøgleindehaverne er centrale, fordi de kan ændre parametre, sætte systemet på pause, opgradere det eller flytte aktiver. Dokumentationen bør omfatte roller, quorum, tidslås, afstemninger, opbevaring af nøgler og hændelseshistorik.

Den fejl, man skal være opmærksom på her, er en afhængighedsfejl: En token, bro, pulje eller blockchain opfører sig anderledes end antaget. For at teste dette trin skal resultatet sammenlignes med samme tidspunkt, afgrænsning og gældende vilkår, hvorefter én antagelse ændres inden indsatsen og styringen. Når det gælder risiko ved smartkontrakter, angiver en forsvarlig overdragelse, hvem der godkendte resultatet, hvilken dokumentation der blev ændret, hvad der stadig kan omgøres, og hvem der bærer tabet, hvis den næste part afviser dokumentationen.

5. Reagér og styr: Afprøv det endelige resultat af arbejdet med risiko ved smartkontrakter

Sæt på pause, opgradér, kompensér, migrér, eller acceptér uforanderlighed inden for rammerne af den offentliggjorte bemyndigelse. I denne del af risikoen ved smartkontrakter fastlægger dette trin de betingelser, som det dokumenterede udfald kan bygge på. Brugeren eller integratoren er central, fordi vedkommende accepterer risikoen ved koden og dens afhængigheder. Arbejdsdokumentationen bør bevare adressen, versionen, tilladelserne, transaktionssimuleringen, begrænsningerne og udvejen.

Den fejl, man skal være opmærksom på her, er misbrug af nødnøgler: En gendannelsesmekanisme bliver angrebsvejen eller er utilgængelig under en krise. For at afprøve dette trin skal resultatet dokumenteres med samme tidspunkt, omfang og gældende vilkår; ændr derefter én antagelse, før udfaldet registreres. For risikoen ved smartkontrakter beskriver en forsvarlig overdragelse, hvem der godkendte den, hvilken dokumentation der blev ændret, hvad der stadig kan omgøres, og hvem der bærer tabet, hvis den næste part afviser dokumentationen.

Tre tilstande, der ofte forveksles ved risikoen ved smartkontrakter

Koderisiko betyder, at implementeringen bryder med de tilsigtede invarianter eller håndterer et randtilfælde forkert. Orakel- og kompositionsrisiko betyder derimod, at korrekt kode isoleret set bygger på en forkert pris, meddelelse, tokenadfærd eller ekstern tilstand. Styrings- og opgraderingsrisiko indebærer en tredje betingelse: Aktører med særlige rettigheder kan ændre adfærd, parametre eller aktiver efter gennemgangen. Forskellene er vigtige, fordi to brugere kan se en lignende bekræftelse, men have forskellige rettigheder, stå over for forskellige tidsforløb eller være afhængige af forskellige institutioner. Ved risikoen for smartkontrakter er en nyttig sammenligning en, der angiver den autoritative dokumentation og tabsbæreren for hver tilstand.

Sammenlign koderisiko, orakel- og kompositionsrisiko samt styrings- og opgraderingsrisiko ud fra samme grundlag: beløb, tid, anvendt likviditet, mulighed for at omgøre, juridiske krav og resterende tab. Ved risikoen ved smartkontrakter er en hurtigere betegnelse ikke automatisk udtryk for en mere endelig tilstand, og et mere jævnt rapporteret afkast betyder ikke automatisk en lavere økonomisk risiko. Når man bruger samme målegrundlag, undgår man at forveksle forskelle i timing eller regnskabsføring med reelle forbedringer.

Omkostninger, incitamenter og balanceeffekter ved risikoen ved smartkontrakter

Sikkerhedsudgifterne bør stå mål med den maksimale værdi og graden af uigenkaldelighed, ikke tokenprisen eller synligheden i markedsføringen. Revisioner, formelle metoder, overvågning og belønninger for sårbarheder er supplerende lag med forskellig dækning.

Komposabilitet skaber værdi i netværket, fordi kontrakter kan genbruge likviditet og tjenester. Den skaber også korrelerede afhængigheder: Fejl i ét orakel eller én token kan sprede sig gennem mange protokoller, før styringen reagerer.

Muligheden for at opgradere bevarer muligheden for at rette fejl og tilpasse sig, men brugerne betaler en risikopræmie forbundet med styringen. Tidslåse, diversitet i multisignaturer, snævert afgrænsede roller, grænser og gennemsigtige hændelser kan sænke præmien uden at foregive, at der ikke findes administratorer.

Hvor risikoen ved smartkontrakter opstår – og hvad der bør testes først

• Fejl i adgangskontrollen: En utilsigtet aktør får rettigheder til at oprette tokens, hæve midler, sætte systemet på pause eller opgradere det. Sæt arbejdet med at fastlægge rettigheder og invarianter på pause, mens protokoludvikleren bevarer sit sædvanlige ansvar; kontrollér derefter, om koderisiko stadig betyder det, der er beskrevet ovenfor.
• Regnskabsmanipulation: Afrunding, reentransangreb, prissætning af andele eller rækkefølgen af tilstande skaber værdi ud af ingenting. Sæt implementering og test på pause, mens revisoren bevarer sit sædvanlige ansvar; kontrollér derefter, om orakel- og kompositionsrisiko stadig betyder det, der er beskrevet ovenfor.
• Manipulation af orakler: En midlertidig pris eller en pris på et illikvidt marked styrer låntagning, handler eller likvidation. Sæt revisionen af det udrullede system på pause, mens oraklet eller den eksterne protokol bevarer sit sædvanlige ansvar; kontrollér derefter, om styrings- og opgraderingsrisiko stadig betyder det, der er beskrevet ovenfor.
• Fejl i en afhængighed: Et token, en bro, en pulje eller en blockchain opfører sig anderledes end antaget. Sæt driften og overvågningen på pause, mens governance-funktionen og nøgleindehaverne fortsat har deres sædvanlige forpligtelser. Kontrollér derefter, om kode risiko stadig betyder det samme som beskrevet ovenfor.
• Misbrug af en nøgle til nødsituationer: En genoprettelsesmekanisme bliver angrebsvejen eller er utilgængelig under en krise. Sæt håndtering og styring på pause, mens brugeren eller integratoren fortsat har sine sædvanlige forpligtelser. Kontrollér derefter, om risikoen ved orakler og sammensætning stadig betyder det samme som beskrevet ovenfor.

En nyttig stresstest af risikoen ved smartkontrakter kombinerer en fejl i adgangskontrollen med manipulation af et orakel i stedet for at teste dem hver for sig. Sæt gennemgangen af det implementerede system på pause eller forsink den, gør governance-funktionen og nøgleindehaverne utilgængelige, og kræv, at brugeren eller integratoren kan afstemme resultatet ud fra adresse, version, godkendelser, transaktionssimulering, grænser og mulighed for at komme ud. Designet består kun, hvis håndtering og styring fører til én forklarlig tilstand, bevarer de rettigheder, der er knyttet til risikoen ved orakler og sammensætning, og fordeler ethvert underskud efter regler, der var fastlagt før forstyrrelsen.

Gennemarbejdet eksempel: Følg en hændelse med risiko ved smartkontrakter fra start til slut

En lånekontrakt er blevet revideret, men prisen på dens sikkerhed kommer fra én likviditetssvag pulje. En angriber flytter midlertidigt prisen i puljen, låner mere end sikkerhedens reelle værdi og trækker sig ud, før oraklet korrigerer prisen. Udlånskoden virkede præcis som skrevet; systemet svigtede, fordi antagelserne om tilliden til oraklet og likviditeten var usikre. En grundig gennemgang ville kortlægge hele afhængighedsgrafen og sætte et loft over eksponeringen mod sikkerhed, hvis pris kan manipuleres.

Eksemplet kan modbevises ved at ændre den antagelse, der styres i implementerings- og testfasen, eller ved at fjerne den dokumentation, som oraklet eller den eksterne protokol leverer. Følg ændringen gennem gennemgangen af det implementerede system, drift og overvågning samt håndtering og styring; spring ikke direkte fra input til hovedresultat. Hvis det nye udfald af risikoen ved smartkontrakter ikke kan genskabes ud fra specifikationen, den implementerede kildekode og bytekode, test og revisioner, parametre og administratorroller, kortet over orakler og afhængigheder, overvågede hændelser, håndtering af hændelser og tabsfordeling, afhænger processen af en udokumenteret vurdering eller registrering.

Hvorfor risiko ved smartkontrakter er vigtig nu

Formel verifikation, løbende overvågning, dusører for fejl, modulær isolering og bedre simulering af tegnebogstransaktioner forbedrer sikkerheden i smartkontrakter. Samtidig øger opgraderbare proxyer og afhængigheder på tværs af kæder governance-risikoen. Den mest nyttige offentliggørelse navngiver den implementerede kode, de særlige beføjelser, orakelvejen, værdigrænserne og planen for tabsfordeling i et sprog, som brugerne kan efterprøve.

Den varige lære om risiko ved smartkontrakter er, at fastlæggelse af rettigheder og invarianter ikke er det samme som håndtering og styring. De mellemliggende beslutninger afgør den lovede finansielle invariant og alle de kode-, data- og governanceafhængigheder, der kan ændre den, mens protokoludvikleren og brugeren eller integratoren kan have adgang til forskellige dele af dokumentationen. Automatisering er værdifuld, når den gør beslutningerne billigere at efterprøve; den er farlig, når den samler dem i én status, der skjuler misbrug af en nøgle til nødsituationer.

Dokumentation bag risiko ved smartkontrakter

Den primære dokumentation for risiko ved smartkontrakter kommer fra NIST’s rammeværk for cybersikkerhed, BIS: Finansielle stabilitetsrisici ved decentraliseret finans (DeFi) og CFTC’s DeFi-rapport fra det teknologiske rådgivende udvalg. Læs dem som supplerende lag: regler og definitioner, institutionelle forhold eller markedsstruktur samt den driftsdokumentation, der skal bruges til at efterprøve en konkret påstand. Ingen af dem bør betragtes som en erstatning for de produktdokumenter, konti eller transaktionsoptegnelser, der er beskrevet ovenfor.

Spørgsmål, du bør stille, før du stoler på smartkontrakter

• Kan protokoludvikleren dokumentere specifikation, kode, test, commits, afhængigheder og implementering, før implementering og test?
• Hvilken dokumentation er afgørende, hvis revisoren og governance-funktionen og nøgleindehaverne er uenige?
• Hvem finansierer eller bærer den eksponering, der opstår ved gennemgangen af det implementerede system?
• Hvad adskiller juridisk og økonomisk risikoen ved orakler og sammensætning fra koderisiko?
• Hvordan ville systemet opdage et regnskabsbaseret angreb, før hændelsen håndteres og styres?
• Hvad sker der, når oraklet eller den eksterne protokol ikke er tilgængelig, eller dens dokumentation er forældet?
• Kan en uafhængig kontrollant afstemme resultatet med specifikationen, den implementerede kildekode og bytekode, test og revisioner, parametre og administratorroller, kortet over orakler og afhængigheder, overvågede hændelser, håndtering af hændelser og tabsfordeling?

Når det gælder risiko ved smartkontrakter, bør udtryk som »platformen håndterer det« erstattes med navngivne konti, kontrakter, tidsstempler, godkendelsesregler og ansvarlige enheder. Et fuldstændigt svar bør gøre det muligt for en kontrollant at gå fra håndtering og styring tilbage til fastlæggelse af rettigheder og invarianter, identificere ejeren af hver registrering og beregne, hvem der bærer tabet, før en undtagelse opstår.

Grundprincippet bag risiko ved smartkontrakter

Risikoen ved smartkontrakter bliver tydeligst, når analysen følger den lovede finansielle invariant og alle afhængigheder knyttet til kode, data og styring, som kan ændre den gennem de fem driftsfaser. Resultatet skal kontrolleres mod specifikationen, den implementerede kildekode og bytekode, test og revisioner, parametre og administratorroller, orakler og afhængighedskort, overvågede hændelser, håndtering af hændelser og fordeling af tab. Procesforløbet forklarer, hvad der ændres; deltageroversigten viser, hvem der kan godkende ændringen; sammenligningen af de tre tilstande forhindrer, at påstande, der ikke kan sammenlignes, blandes sammen; og fejlkortet viser, hvor tilliden bør svækkes. Tilsammen gør disse elementer det muligt at skelne en reel forbedring fra friktion eller risiko, der blot er flyttet til et mindre synligt lag.

Primære kilder om risiko ved smartkontrakter

• NIST’s ramme for cybersikkerhed
• BIS: Risici ved DeFi for den finansielle stabilitet
• CFTC’s teknologiske rådgivende udvalgs rapport om DeFi