At knække koden for DeFi Sårbarheder: Alp Bassas dybe dyk i smart kontraktsikkerhed
Kort sagt
Alp Bassa, en forsker hos Veridise, diskuterer innovative værktøjer, nul-viden bevis revisioner og blockchain sikkerhed fremtid.
I dette eksklusive interview, taget under Hack Seasons Conference, Alp Bassa, en forsker ved Bekræft, deler indsigt i Veridises innovative værktøjer, forviklingerne ved nul-viden bevis revisioner og fremtiden for blockchain sikkerhed. Under diskussionen vil vi udforske krydsfeltet mellem matematik, kryptografi og blockchain-teknologi gennem øjnene af en af branchens førende eksperter.
Mange iværksættere bliver tiltrukket af deres felt af et bestemt øjeblik eller begivenhed. Hvad var din rejse til Web3?
Jeg kommer fra en akademisk baggrund. Jeg er en matematiker, der forskede i talteori, med fokus på kurver over begrænsede felter, elliptiske kurver og deres anvendelser i kodningsteori og kryptografi. Disse værktøjer er flittigt brugt, især nu med nul-viden kryptografi, der har en større indflydelse i Web3 plads.
Jeg så, at der skete en masse interessante ting der. Så begyndte jeg at arbejde hos Veridise, hvor de laver sikkerhedsrevisioner og specialiserer sig især i ZK-domænet, hvor min ekspertise passer rigtig fint ind.
Hvorfor har vi overhovedet brug for sikkerhedsrevisioner? Kan udviklere fungere uden dem, eller er de obligatoriske?
Sikkerheden i systemerne kræver en anden tankegang, som man skal tage allerede på udviklingsstadiet. Ikke alle udviklere kan fokusere på alle aspekter af udviklingsprocessen samtidigt - at sikre de rigtige specifikationer, adfærd, effektivitet, integration i et større setup og sikkerhed. Det meste af tiden er sikkerhed et aspekt, der ikke er dækket godt igennem hele udviklingsprocessen.
Det er blevet næsten umuligt for en udvikler at være sikker nok med forskellige komplekse værktøjer til at garantere, at de bliver brugt korrekt, og at der ikke er nogen sårbarheder. Det er bare en anden tankegang, der skal anvendes. Derfor er revisioner nyttige.
Kan du uddybe de interne værktøjer, Veridise har udviklet, og hvordan de forbedrer revisionskvaliteten?
Der er et bredt spektrum af værktøjer, der kan bruges. Nogle er mere primitive, men kræver ikke for meget baggrund og er let tilgængelige, som fuzzers. Nogle er i midten, som statiske analyseværktøjer. De er ret hurtige, men ikke for præcise – de kan give nogle falske positiver.
Så er der værktøjer, der er stærkt understøttet af matematik, baseret på SMT-løsere og anden matematisk baggrund. Disse er meget præcise, men beregningsmæssigt tunge. Vi bruger en kombination af alle disse værktøjer, hver med deres fordele og ulemper, til at fange fejl og sårbarheder.
Hvad er nogle af de unikke sikkerhedsovervejelser, som Veridise adresserer DeFi protokoller?
Til DeFi protokoller, har vi et statisk analyseværktøj, hvor man på forhånd fortæller systemet, hvilken slags sårbarheder man skal kigge efter, eller hvilke strukturer man skal sigte efter. Der er mange af dem. For eksempel var reentrancy-angreb ansvarlige for DAO-hacket i 2016. Flash-lånsangreb blev udnyttet i angrebet på Cream Finance, som fik omkring 130 millioner dollars til at blive stjålet.
Gennem vores erfaring gennem årene med revision har vi et godt overblik over, hvad sårbarhederne er, og vores værktøjer er lavet til at tjekke for alle disse. Under vores revisioner ser vi på dem én efter én i detaljer for at se, om sådanne risici opstår.
Uddyb venligst mere om, hvordan du bruger ZK-teknologi, og hvorfor ZK-revisioner er din hovedprioritet?
ZK er særligt interessant fra et formelt verifikationsperspektiv, fordi det udmønter sig meget godt i brugen af værktøjer. Vi har værktøjer, der er særligt rettet mod at tjekke ZK-applikationer. Fordi det er så velegnet til vores metoder, er det det område, vi har fokuseret meget på.
Vi har identificeret kritiske sårbarheder i kernekredsløbsbiblioteker. Vores team er meget stærkt på det felt, så vi besluttede at være meget nærværende og på grænsen til ZK revision. Det meste af vores forskning er også motiveret af behov og krav fra en revisors perspektiv på ZK-domænet.
Hvordan adskiller din ekspertise i ZK-kredsløb sig fra andre virksomheder?
Jeg vil sige, at vores værktøjer er det, der adskiller os meget, fordi vi kommer fra en formel verifikationsbaggrund. Vi har meget stærke værktøjer, og efterhånden er omfanget af projekterne blevet så stort, at menneskelig indsats alene ikke er tilstrækkelig til at have en god dækning af kodebasen. Det er nødvendigt, men i sig selv er det ikke nok.
Hvordan balancerer Veridise manuel kodegennemgang med automatiseret værktøjsanalyse i sin revisionsproces?
Der er brug for dem begge. Det mærker vi også i revisionerne. Det meste af tiden, når vi laver meget streng menneskelig auditering og derefter kører værktøjerne bagefter på kodebasen, finder vi nogle sårbarheder, der er undsluppet vores opmærksomhed. Nogle gange kører vi værktøjerne først, men værktøjerne kan kun registrere bestemte slags strukturer.
Da der er så mange lag af komplikationer og abstraktion i disse systemer, er det heller ikke nok at stole på værktøjerne. Jeg føler, at man ikke kan undvære nogen af dem, og jeg tror ikke, det vil ændre sig i fremtiden.
Hvad er nøglefunktionerne i Veridises Vanguard-værktøj, og hvordan forbedrer det smart kontraktsikkerhed?
Vanguard er et af vores vigtigste værktøjer. Det bruges til statisk analyse. I statisk analyse giver du en bestemt specifikation af den tilsigtede adfærd og kontrollerer derefter, om den er opfyldt - om visse egenskaber holder uden at køre koden. Det er ikke dynamisk; du udfører ikke koden, men du forsøger statisk at vurdere, om der er bestemte mønstre, som kan forårsage sårbarheder.
Vanguard kommer i mange smagsvarianter. Vi har dele af det, der er ret gode til forbedret smart kontraktsikkerhed, og dele med fokus på zk-applikationer.
Kan du uddybe mere om sårbarheder, du er stødt på i smarte kontrakter og ZK-kredsløb?
I ZK-kredsløb, som jeg arbejder mere på, vil en af de mest almindelige sårbarheder være under-begrænsede kredsløb. I en ZK-applikation består din kodebase af to dele: selve programmet (den normale udførelse) og begrænsningerne. Du kræver, at begrænsningerne afspejler opførselen af programafviklingen på en en-til-en måde.
Ifølge en nyligt papir95% af alle sårbarheder i ZK-kredsløb er forårsaget af under-begrænsede kredsløb. Vi har værktøjer, såsom PICUS, som er særligt rettet mod at detektere disse under-begrænsede kredsløb.
Hvordan forholder Veridise sig til offentliggørelsesprocessen for sårbarheder opdaget under revisioner?
Selvfølgelig offentliggør vi ikke sårbarheder på noget tidspunkt, fordi en anden kan udnytte fejlen, før den er rettet, især hvis kodebasen allerede er i brug. I slutningen af revisionsprocessen leverer vi en revisionsrapport, hvor vi giver kunden en liste over alle fejl og sårbarheder, vi har opdaget.
Vi giver kunden lidt tid til at rette dem, og så sender de os deres rettelser, som vi gennemgår for at tjekke, om de virkelig løser alle de problemer, vi rejste. Vi har samlet det hele i en endelig rapport. Rapporten er kundens ejendom. Vi offentliggør det ikke, medmindre kunden er indforstået.
Hvis du går til Veridise-websiden, kan du se en liste over alle de revisionsrapporter, som kunderne accepterede at offentliggøre. I de fleste tilfælde er de okay med, at vi offentliggør det. Faktisk vil de have det som et certifikat, at koden er blevet revideret og er så fri for fejl, som den kan være efter en revision.
Hvordan tilpasser Veridise sine revisionsprocesser til forskellige blockchain-platforme og -sprog?
Som du ved, er feltet meget levende, og hver dag er der nye kæder, nye sprog og nye måder at udtrykke ZK-kredsløb på. Det ser vi også med de indkommende projekter og anmodninger om revisioner, der er baseret på forskellige miljøer eller sprog. Vi går med strømmen, ser, hvor forespørgslerne kommer fra, og har en fornemmelse af, hvilken retning feltet vil udvikle sig i den nærmeste fremtid.
Vi forsøger at tilpasse vores værktøjer til at imødekomme behovene fra samfundet. Dette vil fortsætte i fremtiden, hvor vi vil ændre tingene dynamisk alt efter, hvordan feltet udvikler sig.
Kan du uddybe mere om de værktøjer, du planlægger at implementere i fremtiden?
En retning, som værktøjerne vil ændre sig i den nærmeste fremtid, er, at vi vil tilbyde sikkerhed som en service. Det kaldes vores SaaS-platform, hvor vi vil gøre værktøjerne tilgængelige for folk at bruge under udviklingsprocessen.
I stedet for først at afslutte hele projektet og derefter foretage en revision, vil vi gøre vores værktøjer nyttige i et setup, hvor udviklere kan bruge dem, mens de udvikler for at sikre, at den kode, de udvikler, er sikker og ikke indeholder nogen sårbarheder. SaaS skulle være tilgængeligt i den nærmeste fremtid.
Ansvarsfraskrivelse
I tråd med den Trust Project retningslinjer, bemærk venligst, at oplysningerne på denne side ikke er beregnet til at være og ikke skal fortolkes som juridiske, skattemæssige, investeringsmæssige, finansielle eller nogen anden form for rådgivning. Det er vigtigt kun at investere, hvad du har råd til at tabe, og at søge uafhængig finansiel rådgivning, hvis du er i tvivl. For yderligere information foreslår vi at henvise til vilkårene og betingelserne samt hjælpe- og supportsiderne fra udstederen eller annoncøren. MetaversePost er forpligtet til nøjagtig, objektiv rapportering, men markedsforholdene kan ændres uden varsel.
Om forfatteren
Victoria er en forfatter om en række teknologiske emner, herunder Web3.0, AI og kryptovalutaer. Hendes store erfaring giver hende mulighed for at skrive indsigtsfulde artikler til et bredere publikum.
Flere artikler
Victoria er en forfatter om en række teknologiske emner, herunder Web3.0, AI og kryptovalutaer. Hendes store erfaring giver hende mulighed for at skrive indsigtsfulde artikler til et bredere publikum.
