De Deplorabele Staat van Web3 Auditing en Wat Eraan Gedaan Kan Worden

Balancer, een oud en goed geaudit protocol, werd onlangs "gehackt." Het eveneens goed geaudite Yearn Finance ook. Jaren geleden werd Euler Finance "gehackt" via een functie die was geïntroduceerd als reactie op een eerdere audit. USPD werd voor deployment geaudit en vervolgens werd het niet-geaudite deploymentproces zelf gehackt, wat leidde tot een totale afschrijving binnen ongeveer 3 maanden na lancering. Niemand die oplettend is geweest gelooft dat audits een garantie zijn dat iets veilig is. Velen vragen zich af of ze überhaupt iets waard zijn.

Dit is niet nieuw. Dit is geen web3-probleem. En eigenlijk is dit geen bijzonder diepgaande observatie. Maar audits zijn nog steeds zeer belangrijk. Projecten betalen voor audits. Projecten pochen met audits. Mensen doen alsof ze audits lezen. Vaak wanneer een geaudit product wordt geëxploiteerd, vragen mensen waarom en hoe dat gebeurde.

In plaats van daar direct op te antwoorden, gaan we een paar recente audits doornemen van onlangs gelanceerde producten. Het doel hier is niet om iemand belachelijk te maken of te bekritiseren. Deze zijn willekeurig geselecteerd, voornamelijk vanwege de focus op recente zaken. Dat betekent niet dat ze bijzonder slecht zijn. Ze zijn niet eens zo slecht!

Ons punt hier is niet dat de auditors iets verkeerd doen. De auditors doen wat de projecten die hen inschakelen vragen. De auditscope wordt bepaald door het project. Als slechts één extreem voorbeeld: als Do Kwon auditors had ingeschakeld voor zijn stablecoin-schema, zouden ze hebben opgemerkt dat het mogelijk instabiel was. Het probleem zou zijn gemarkeerd als "erkend" en er zou niets zijn gedaan of veranderd.

Dit probleem heeft absoluut niets te maken met studies zoals die beweerden dat Do's Terra-LUNA ecosysteem zeer robuust was. Het is moeilijk om de toekomst te voorspellen en dat soort studies worden terecht gezien als zelfzuchtige marketing die, in de limiet, de kernproblemen erkent. Van door projecten gesponsord onderzoek wordt verwacht dat het dingen in een positief daglicht stelt. Het hele punt van audits is om een objectief perspectief van derden te bieden. Opschepperij moet niet worden vertrouwd en audits zijn geen garanties of verzekering. Zo is het leven.

Het punt van dit overzicht is om te benadrukken dat het echte probleem hier niet basale programmeerfouten zijn van het type dat auditors goed kunnen identificeren en dat het auditproces goed is ontworpen om op te lossen. Auditors zijn behoorlijk goed in het vangen daarvan. Dat zijn trouwens ook de programmeurs die deze dingen in de eerste plaats bouwen. Empirisch gezien bereikt dit soort feedback de juiste mensen en worden beperkte problemen opgelost.

Nee, het echte probleem zijn producten die precies werken zoals bedoeld en waar een bekend "risico" zich materialiseert om alles neer te halen. Wat je nu gaat zien zijn auditors die proberen zichzelf te beschermen tegen alle toekomstige known-unknown problemen. Als een bescherming-tegen-aansprakelijkheid-en-spot-oefening is dit misschien waardevol. Maar in algemene zin helpt het niemand.

En aan het einde gaan we bespreken wat een reeks partijen kan doen dat zowel zou helpen als hun eigen beperkte eigenbelang zou dienen. Als je voorschrift voor hoe audits te verbeteren altruïsme inhoudt, dan is het, nou ja, niet erg nuttig.

Jovay

Jovay is een L2 geassocieerd met Ant Financial of Alibaba of iets in die algemene sfeer. Maar het maakt niet echt uit wat Jovay doet. Het is iets gebouwd van software uit een grote en goed gefinancierde organisatie. Deze audit somt acht problemen op:

1. Een legitieme programmeerfout die vervolgens werd opgelost.
2. Dat het protocol niet trustless is. Dit is een soort probleem, maar het is ook een kernonderdeel van het ontwerp.
3. De "fake-recharge" aanval die van toepassing is op een breed deel van het ecosysteem en niet specifiek is voor het project.
4. De RPC-servers gebruiken HTTP in plaats van HTTPS. Deze interfaces verwerken geen geheime informatie. Dit geldt voor miljarden volkomen veilige alleen-lezen websites.
5. Quantum computing vormt een risico voor Ethereum. Oké. Erg ter zake dat.
6. EVM smart contracts kunnen kwetsbaar zijn. Nee serieus. Er staat "Evm smart contracts zijn vatbaar voor verschillende aanvalsvectoren vanwege onveranderlijke code-implementatie en complexe interacties, wat mogelijk kan leiden tot diefstal van fondsen,.." Oké. Wederom echt respect voor de nauwe focus van deze audit.
7. Het sequencer-ontwerp is onderhevig aan MEV. Net als de rest van het Ethereum-ecosysteem. Het is ook te donker 's nachts.
8. De codekwaliteit zou kunnen worden verbeterd. In tegenstelling tot de meeste andere code die sinds het begin van het computergebruik is geschreven.

Slechts één hiervan is een echt probleem. Ja, het is de moeite waard om op te merken dat het product zelf niet trustless is als de documentatie anders stelt dat het trustless is. Maar dit product is redelijk goed op dat vlak. Opmerken dat quantum computing mogelijk een toekomstig risico vormt en smart contracts risicovol kunnen zijn... dat zijn pogingen om het rapport langer te maken door verzonnen problemen te vinden of het zijn pogingen om een soort "het is niet onze schuld" te bieden als er uiteindelijk iets wordt gehackt. Waarschijnlijk een mix van beide.

In de geest van die punten stellen we als een negende probleem voor dat het netwerk uitvalt wanneer de zon sterft, tenzij we een interstellaire soort worden en op de een of andere manier sneller-dan-licht communicatie uitvinden. Anders beperkt de relativiteit de bruikbare levensduur van dit systeem tot ongeveer 5 miljard jaar. Eerlijk gezegd is dat nuttiger dan te vermelden dat de codekwaliteit zou kunnen worden verbeterd, omdat zelfs nadat de zon sterft er nog steeds slechte code ergens zal draaien. Maar we maken een grapje.

Hyperliquid

Hyperliquid heeft een paar auditrapporten gepubliceerd. Het eerste auditrapport vond zes problemen en het tweede rapport bevestigde dat deze waren opgelost. Maar de scope van de audit sloot uit:

1. Andere smart contracts die deel uitmaken van het Hyperliquid-systeem
2. Off-chain componenten, zoals validators
3. Front-end componenten
4. Infrastructuur met betrekking tot het project
5. Sleutelbeheer

Die lijken op potentiële probleemgebieden! Al wat werd geaudit was een enkel bridge-contract. Maar het systeem is, nou ja, het is veel gecompliceerder dan dat.

Het auditeren van één klein hoekje van het systeem dat slechts een paar nauw gedefinieerde dingen doet, is vrij nutteloos. De manier waarop Hyperliquid is ontworpen, is het geaudite contract het externe ingangs- en uitgangspunt voor iedereen. Dus het zou een ernstig probleem zijn als dat contract vol fouten zat. Maar bevestigen dat het contract werkt biedt weinig tot geen troost.

Ondo

Deze audit benadrukt "CENTRALISATIERISICO VOOR VERTROUWDE ENTITEITEN EN ROLLEN" wat het team erkende. Het staat zo met hoofdletters in het rapport. Juist.

Deze audit merkt op dat het systeem zou kunnen instorten als een betrokken stablecoin te hard depegt. Ze formuleren dat als het systeem "zal buitensporige OUSG token-mining toestaan tijdens USDC depeg-gebeurtenis." Uiteindelijk was de "oplossing" die ze implementeerden een verwijzing naar een Chainlink-oracle en een uitschakelknop voor het geval de prijs te laag wordt gerapporteerd. Dus in plaats van in te storten met de waarde die crasht, zal het protocol stoppen met de waarde die crasht. Juist. Dit is geen oplosbaar probleem in die zin dat er geen mechanisme is om een waardeverliezende uitkomst te vermijden als USDC explodeert. En in lijn met dat feit, lost de oplossing eigenlijk niets op.

Die audits zijn relatief recent. Maar om wat context te geven, identificeert deze audit van oktober 2022 veel echte problemen. Bijna 200 ervan. De meeste werden opgelost, sommige waren vergelijkbaar met het bovenstaande en werden gewoon erkend. Het punt is dat auditing vroeger iets concreets en substantieels deed: zoeken naar programmeerfouten die niet de bedoeling van de programmeur kunnen zijn geweest. De programmeurs plachten deze fouten te herstellen omdat het, je weet wel, oprechte fouten waren en niet alleen twijfelachtige ontwerpbeslissingen die in het product zijn ingebouwd.

En tegen 2024 zien we audits die relatief weinig technische problemen vinden en financiële aanvallen als buiten scope verklaren. De enige verstandige manier om deze verandering in de loop van de tijd te interpreteren is dat de programmeurs, en programmeurs-als-auditors, erkenden dat functionerende code niet het enige risico was. Zeker, programmeerbugs werden van tijd tot tijd geëxploiteerd. Maar tegen midden 2024 kon iedereen zien dat defecte economische mechanismen ook een enorm risico waren. Ze waren het grootste risico.

Projecten die precies werkten zoals bedoeld – niet zoals gedroomd, zoals bedoeld in werkelijkheid – exploderen van tijd tot tijd omdat de dromen van stabiliteit van de ontwerpers breken wanneer ze met de echte wereld worden geconfronteerd.

Je kunt deze evolutie zien in de audits van dit ene project.

Mutuum Finance

Nu hebben we de reductio ad absurdum van audits. Deze identificeert één enkel probleem:

Het probleem is het gebrek aan transparantie rond de initiële tokendistributie en hoe dat zou kunnen samenhangen met centralisatieproblemen. Het is "gemitigeerd" omdat:

Dan zijn er veel multisig-details. En ten slotte de reactie van de auditor:

Dus het risico met het project is dat een klein team alles controleert en de manier waarop die controle zal, of misschien niet zal, worden verspreid is volledig niet-transparant. En de voorgestelde oplossing van het team om een blogpost te schrijven om hun intentie te verduidelijken, lost dit in strikte zin niet op.

Voor de duidelijkheid heeft het team een gedetailleerde lijst gepubliceerd van welke tokens waar en wanneer naartoe gaan. En ze erkennen dat dit onvolledig is met opmerkingen als "We overwegen ofwel een blok-voor-blok of een wekelijks distributiemodel." Ze erkennen ook dat alles zal worden beheerd via handmatige multisigs. Dus ze zijn eerlijk. Het is alleen dat de eerlijkheid neerkomt op "ja, we kunnen nog steeds doen wat we willen en je moet ons vertrouwen."

Wat is het doel van deze audit? Als de code geen identificeerbare bugs had, kon de auditor dat gewoon schrijven. Soms levert een bezoek aan de dokter of monteur een schone gezondheidstoestand op. Dus blijven we ons afvragen of er slechts een triviale hoeveelheid code werd geaudit? Of misschien is het project zelf gewoon een triviale hoeveelheid code? Voelde de auditor de behoefte om iets in het rapport te zetten omdat het anders allemaal te leeg was? Waarom heeft iemand zich hier überhaupt mee bemoeid?

Nogmaals, we geven de auditors hier niet echt de schuld. Voor zover iemand hier iets verkeerd doet, is het vrijwel zeker een incentivesprobleem met degene die de audit heeft opdracht gegeven. En het feit dat ze geld van beleggers besteden aan het produceren van een grotendeels nutteloos document voor marketingdoeleinden. Dat is niet de schuld van de auditor!

Verbeteringen

Het is ondubbelzinnig een goede zaak dat er meer bugs worden gevangen, minder kapotte code wordt vrijgegeven voor productie en meer voorgestelde fixes worden geïmplementeerd. En we zijn niet onvolwassen genoeg om te suggereren dat het probleem is dat gebruikers en beleggers om de verkeerde dingen geven, zoals bijvoorbeeld waarde en vertrouwen hechten aan audits die niet veel betekenen. Mensen geven om waar ze om geven en proberen dat te veranderen is een zinloze onderneming.

Maar er zijn een paar echte verbeteringen die we kunnen voorstellen. Ethena nam het voortouw door van tevoren een aantal van de vele faalwijzen van hun product uit te leggen. Het team was consistent met de boodschap dat USDe niet risicoloos was. En ze schetsten manieren waarop het problemen kon krijgen. Het product heeft overleefd, met een paar hobbels, en is vandaag behoorlijk groot. Dit geeft ons een actiepunt voor beleggers: sta erop dat projecten eerlijk zijn over eventuele "financiële aanvallen" die kunnen bestaan.

Ethena toont aan dat eerlijk zijn het project niet ten ondergang doemt! Je kunt betogen dat door eerlijker te zijn het project meer interesse trok. Eerlijkheid heeft ook het extra voordeel van meer juridische dekking te bieden als er iets misgaat. Projecten zouden dit al willen doen.

Auditors kunnen ook de manier waarop ze analyses uitvoeren herschikken om hun werk nuttiger te maken. Of in ieder geval minder nutteloos en potentieel misleidend. Zet economische incentiveproblemen of algemene zorgen zoals kwantumveiligheid niet in dezelfde sectie als bugs. Tegenwoordig worden deze normaal gesproken gelabeld op een manier die ze enigszins onderscheidt van codeerfouten. Of ze worden vermeld als "informatief" in plaats van "kritiek."

Maar dit mist het punt. Kwantumveiligheid kan wel degelijk een "kritiek" risico zijn voor een systeem – maar het heeft een volkomen ander karakter dan een slechte handtekeningcontrole of een onbedoeld minteken! Zet deze dingen in aparte secties. Evenzo is "dit stablecoin-schema is instabiel onder redelijkerwijs waarschijnlijke omstandigheden" niets zoals een logicabug in code. Het ophelderen van deze verwarring zou het uiterlijk van de auditdocumenten moeten verbeteren en de reputatie van de auditor moeten oppoetsen.

Ten slotte kunnen exchanges hierbij helpen. De grote exchanges krijgen veel kritiek voor het noteren van verschrikkelijke projecten, of wild schommelende risicovolle memecoins die mensen geld kosten, of allerlei andere manieren van verlies-toebrengende vreemde zakelijke beslissingen. Wat als exchanges zouden aandringen op redelijke audits die economische stabiliteit eerlijk behandelen en risico's zoals "smart contracts kunnen kwetsbaar zijn" niet verwarren met echte logicacontroles?

Een manier om een auditor die hun resultaten opvult met dit soort opvulling te interpreteren, is dat niemand een leeg auditresultaat serieus zal nemen. Prima dat zo'n document vragen zou oproepen. Maar als een grote exchange een token zou noteren met, laten we zeggen, twee overeenkomende "lege" auditresultaten die geen projectspecifieke problemen bevatten en het standpunt zou innemen dat dit een goede zaak was... dat zou misschien een beetje helpen om de bal vooruit te bewegen. We bevinden ons ook op een punt in de cyclus waar een meer "eerlijke" en "redelijke" exchange je meer klanten zou moeten opleveren dan het gebrek aan belachelijke to-the-moon marketing je kost.

Evenzo zou er geen stigma moeten zijn verbonden aan het auditeren van een project en zeggen dat het er goed uitziet. Deze is voor auditors. Misschien kunnen een aantal auditors gezamenlijke verklaringen op dit gebied uitgeven. Ja, we kunnen begrijpen dat auditors voorbehouden willen maken voor potentiële problemen die buiten scope werden verklaard toen de opdracht begon. Ook prima. Maar resultaten opvullen met zinloze algemene potentiële problemen is niet het antwoord. Evenmin is zeggen dat het team centralisatierisico mitigeerde door een blogpost te maken over de tokendistributie die ze handmatig willen regelen, binnenkort, volgens een schema dat nog moet worden bepaald.

Audits kunnen nuttig zijn. Audits kunnen helpen. En de waarheid is dat web3-audits echte problemen hebben gevangen en, voor een aanzienlijke periode, vol zaten met nuttige en interessante inhoud. Maar ingenieurs zijn in de loop van de tijd verbeterd omdat ze, je weet wel, ingenieurs zijn en dat is wat ze doen. Auditors moeten gelijke tred houden en, om een woord te lenen, een beetje innoveren. En veel grotere delen van het ecosysteem, zoals de exchanges, kunnen dit ook helpen bevorderen.