Balancer, un protocollo collaudato e ben sottoposto ad audit, è stato recentemente "hackerato". Anche Yearn Finance, altrettanto ben controllato, lo è stato. Anni fa Euler Finance è stato "hackerato" tramite una funzione introdotta in risposta a un audit precedente. USPD è stato sottoposto ad audit prima della distribuzione e poi il processo di distribuzione stesso, non controllato, è stato hackerato portando a una cancellazione totale entro circa 3 mesi dal lancio. Nessuno che abbia prestato attenzione crede che gli audit siano una garanzia che qualcosa sia sicuro. Molti si chiedono se valgano qualcosa.
Questo non è nuovo. Non è un problema web3. E, davvero, non è un'osservazione particolarmente profonda. Ma gli audit sono ancora molto presenti. I progetti pagano per gli audit. I progetti pubblicizzano gli audit. Le persone fingono di leggere gli audit. Spesso quando un prodotto controllato viene sfruttato, le persone chiedono perché e come sia successo.
Piuttosto che rispondere direttamente a tutto ciò, esamineremo alcuni audit recenti per prodotti lanciati di recente. L'obiettivo qui non è prendere in giro o criticare nessuno. Questi sono selezionati casualmente, principalmente per la concentrazione su cose recenti. Ciò non significa che siano particolarmente cattivi. Non sono nemmeno così male!
Il nostro punto qui non è che gli auditor stiano facendo qualcosa di sbagliato. Gli auditor stanno facendo ciò che i progetti che li ingaggiano chiedono. L'ambito dell'audit è stabilito dal progetto. Come esempio estremo: se Do Kwon avesse ingaggiato auditor per il suo schema di stablecoin, avrebbero notato che era potenzialmente instabile. Il problema sarebbe stato contrassegnato come "riconosciuto" e non sarebbe stato fatto o modificato nulla.
Questo problema non ha assolutamente nulla a che fare con studi come quelli che sostenevano che l'ecosistema Terra-LUNA di Do fosse altamente robusto. È difficile prevedere il futuro e quel tipo di studi sono giustamente visti come marketing autoreferenziale che, al limite, riconosce i problemi fondamentali. La ricerca sponsorizzata dai progetti dovrebbe dipingere le cose in una luce positiva. L'intero punto degli audit è fornire una prospettiva oggettiva di terza parte. L'esagerazione non è da considerare affidabile e gli audit non sono garanzie o assicurazioni. Questa è la vita.
Il punto di questa indagine è sottolineare che il vero problema qui non sono gli errori di programmazione di base del tipo che gli auditor sono ben posizionati per identificare e che il processo di audit è ben progettato per risolvere. Gli auditor sono piuttosto bravi a individuarli. Lo sono anche, del resto, i programmatori che costruiscono queste cose in primo luogo. Empiricamente questo tipo di feedback arriva alle persone giuste e i problemi ristretti vengono risolti.
No, il vero problema sono i prodotti che funzionano esattamente come previsto e dove un "rischio" noto si materializza per far crollare tutto. Quello che vedrete ora sono auditor che cercano di proteggersi contro tutti i futuri problemi noti-sconosciuti. Come esercizio di protezione dalla responsabilità e dalle prese in giro, forse questa è una cosa preziosa. Ma, in senso generale, non aiuta nessuno.
E poi alla fine discuteremo cosa una serie di parti può fare che aiuterebbe e servirebbe i loro ristretti interessi personali. Se la vostra prescrizione su come migliorare gli audit coinvolge l'altruismo, beh, non è molto utile.
Jovay è un L2 associato ad Ant Financial o Alibaba o qualcosa in quell'area generale. Ma non importa davvero cosa faccia Jovay. È una cosa costruita con software di una grande e ben finanziata organizzazione. Questo audit elenca otto problemi:
Solo uno di questi è un problema reale. Sì, vale la pena notare che il prodotto stesso non è trustless se la documentazione afferma altrimenti che è trustless. Ma questo prodotto è abbastanza a posto su quel fronte. Notare che il quantum computing rappresenta potenzialmente un rischio futuro e che gli smart contract possono essere rischiosi... sono tentativi di allungare il rapporto trovando problemi inventati o sono un tentativo di fornire una sorta di "non è colpa nostra" se qualcosa viene eventualmente hackerato. Probabilmente un mix dei due.
Nello spirito di questi punti proponiamo come nono problema che la rete si bloccherà quando il sole morirà a meno che non diventiamo una specie interstellare e in qualche modo riusciamo a capire la comunicazione più veloce della luce. Altrimenti la relatività limita la vita utile di questo sistema a circa 5 miliardi di anni. Onestamente questo è più utile che affermare che la qualità del codice potrebbe essere migliorata perché anche dopo che il Sole morirà ci sarà ancora codice difettoso in esecuzione da qualche parte. Ma scherziamo.
Hyperliquid ha pubblicato alcuni rapporti di audit di smart contract. Il primo rapporto di audit di smart contract ha trovato sei problemi e il secondo rapporto ha confermato che erano stati risolti. Ma l'ambito dell'audit escludeva:
Queste sembrano aree potenzialmente problematiche! Tutto ciò che è stato controllato era un singolo contratto bridge. Ma il sistema è, beh, molto più complicato di così.
Controllare un piccolo angolo del sistema che fa solo poche cose strettamente definite è piuttosto inutile. Il modo in cui Hyperliquid è progettato, lo smart contract controllato è il punto di ingresso e uscita esterno per tutti. Quindi sarebbe un problema serio se quel contratto fosse pieno di errori. Ma confermare che lo smart contract funziona fornisce poco o nessun conforto.
Questo audit evidenzia "RISCHIO DI CENTRALIZZAZIONE PER ENTITÀ E RUOLI FIDATI" che il team ha riconosciuto. È in maiuscolo così nel rapporto. Giusto.
Questo audit nota che il sistema potrebbe crollare se una stablecoin coinvolta si depegga troppo duramente. Lo formulano come il sistema "consentirà un'eccessiva emissione di token OUSG durante l'evento di depeg di USDC". Alla fine la "soluzione" che hanno messo è stato un riferimento a un oracolo Chainlink e un interruttore di spegnimento nel caso in cui il prezzo sia riportato come troppo basso. Quindi piuttosto che implodere con il valore che crolla, il protocollo si fermerà con il valore che crolla. Giusto. Questo non è un problema risolvibile nel senso che non c'è meccanismo per evitare un risultato di perdita di valore se USDC esplode. E, in linea con quel fatto, la soluzione non risolve davvero nulla.
Quegli audit sono relativamente recenti. Ma per dare un po' di contesto, questo audit di ottobre 2022 identifica molti problemi reali. Quasi 200 di essi. La maggior parte sono stati risolti, alcuni erano simili a quanto sopra e solo riconosciuti. Il punto è che l'auditing faceva qualcosa di concreto e sostanziale: cercare errori di programmazione che non potevano essere stati l'intenzione del programmatore. I programmatori correggevano questi errori perché erano, sai, veri errori non solo decisioni di design discutibili integrate nel prodotto.
E poi nel 2024 vediamo audit che trovano relativamente pochi problemi tecnici e dichiarano fuori ambito gli attacchi finanziari. L'unico modo sensato di interpretare questo cambiamento nel tempo è che i programmatori, e i programmatori come auditor, hanno riconosciuto che il codice funzionante non era l'unico rischio. Certo i bug di programmazione venivano sfruttati di tanto in tanto. Ma entro metà 2024 tutti potevano vedere che i meccanismi economici difettosi erano anche un rischio enorme. Erano il rischio maggiore.
I progetti che funzionavano esattamente come previsto – non come sognato, come previsto nella realtà – esplodono di tanto in tanto perché i sogni di stabilità dei progettisti si rompono quando affrontano il mondo reale.
Puoi vedere questa evoluzione negli audit di questo singolo progetto.
Ora abbiamo la reductio ad absurdum degli audit. Questo identifica un singolo problema:
Il problema è la mancanza di trasparenza sulla distribuzione iniziale dei token e come questo possa essere correlato a problemi di centralizzazione. È stato "mitigato" perché:
Poi ci sono molti dettagli multisig. E infine la risposta dell'auditor:
Quindi il rischio con il progetto è che un piccolo team controlla tutto e il modo in cui quel controllo sarà, o forse non sarà, disperso è completamente non trasparente. E la soluzione proposta dal team di scrivere un post sul blog per chiarire la loro intenzione non risolve questo in nessun senso stretto.
Per inciso il team ha pubblicato un elenco dettagliato di quali token andranno dove e quando. E riconoscono che questo è incompleto con commenti come "Stiamo considerando un modello di distribuzione blocco per blocco o settimanale". Riconoscono anche che tutto sarà gestito tramite multisig manuali. Quindi sono onesti. È solo che l'onestà equivale a "sì, possiamo ancora fare quello che vogliamo e dovete fidarvi di noi".
Qual è lo scopo di questo audit? Se il codice non aveva bug identificabili, l'auditor potrebbe semplicemente scriverlo. A volte una visita dal dottore o dal meccanico produce un certificato di buona salute. Quindi ci chiediamo se è stata controllata solo una quantità banale di codice? O forse il progetto stesso è solo una quantità banale di codice? L'auditor ha sentito il bisogno di mettere qualcosa nel rapporto perché era troppo vuoto altrimenti? Perché qualcuno si è preoccupato di tutto questo?
Ancora una volta non stiamo davvero incolpando gli auditor qui. Nella misura in cui qualcuno sta facendo qualcosa di sbagliato qui, è quasi certamente un problema di incentivi con chi ha commissionato l'audit. E il fatto che stiano spendendo soldi degli investitori per produrre un documento per lo più inutile per uno scopo di marketing. Questo non è colpa dell'auditor!
È una cosa inequivocabilmente buona che più bug vengano catturati, meno codice rotto venga rilasciato in produzione e più correzioni proposte vengano implementate. E non siamo abbastanza immaturi da suggerire che il problema sia che gli utenti e gli investitori si preoccupano delle cose sbagliate come, per esempio, dare valore e fiducia ad audit che non significano molto. Le persone si preoccupano di ciò che gli interessa e cercare di cambiare questo è un'impresa folle.
Ma ci sono alcuni veri miglioramenti che possiamo suggerire. Ethena ha aperto la strada spiegando alcune delle molte modalità di fallimento del loro prodotto in anticipo. Il team è stato coerente con il messaggio che USDe non era privo di rischi. E hanno delineato modi in cui potrebbe avere problemi. Il prodotto è sopravvissuto, con qualche difficoltà, ed è abbastanza grande oggi. Questo ci dà un punto d'azione per gli investitori: insistere che i progetti siano onesti su eventuali "attacchi finanziari" che potrebbero esistere.
Ethena mostra che essere onesti non condanna il progetto! Si può sostenere che essendo più onesto il progetto ha attirato più interesse. L'onestà ha anche il vantaggio aggiuntivo di fornire più copertura legale se qualcosa va storto. I progetti dovrebbero già voler fare questo.
Anche gli auditor possono riorganizzare il modo in cui fanno l'analisi per rendere il loro lavoro più utile. O almeno meno inutile e potenzialmente ingannevole. Non mettere i problemi di incentivi economici o preoccupazioni generali come la sicurezza quantistica nella stessa sezione dei bug. Al momento questi sono normalmente etichettati in modo da differenziarli leggermente dagli errori di codifica. O sono elencati come "informativi" invece che "critici".
Ma questo perde il punto. La sicurezza quantistica può ben essere un rischio "critico" per un sistema – ma è di carattere completamente diverso da un controllo di firma errato o un segno meno errato! Metti queste cose in sezioni separate. Allo stesso modo "questo schema di stablecoin è instabile in condizioni ragionevolmente probabili" non è nulla come un bug di logica nel codice. Chiarire questa confusione dovrebbe migliorare l'aspetto dei documenti di audit e lucidare la reputazione dell'auditor.
Infine, gli exchange possono aiutare in questo. I grandi exchange ricevono molte critiche per aver listato progetti terribili, o memecoin rischiose selvaggiamente oscillanti che costano denaro alle persone, o tutti gli altri tipi di strane decisioni aziendali che infliggono perdite. E se gli exchange insistessero su audit ragionevoli che coprono onestamente la stabilità economica e non confondono rischi come "gli smart contract possono essere vulnerabili" con veri controlli logici?
Un modo per interpretare un auditor che riempie i suoi risultati con questo tipo di riempitivo è che nessuno prenderà sul serio un risultato di audit vuoto. È giusto che un tale documento solleverebbe domande. Ma se un grande exchange listasse un token con, diciamo, due risultati di audit "vuoti" corrispondenti che non includevano problemi specifici del progetto e prendesse la posizione che questa fosse una cosa buona... questo potrebbe aiutare a far avanzare un po' la palla. Siamo anche a un punto del ciclo in cui essere un exchange più "onesto" e "ragionevole" dovrebbe procurarti più clienti di quanto ti costi la mancanza di ridicolo marketing verso-la-luna.
Allo stesso modo, non dovrebbe esserci stigma associato al controllare un progetto e dire che sembra a posto. Questo spetta agli auditor. Forse un gruppo di auditor potrebbe emettere alcune dichiarazioni congiunte in quest'area. Sì, possiamo capire che gli auditor vorranno inserire avvertenze per potenziali problemi che sono stati esclusi dall'ambito quando è iniziato l'incarico. Anche questo è giusto. Ma riempire i risultati con potenziali problemi generali inutili non è la risposta. Né lo è dire che il team ha mitigato il rischio di centralizzazione facendo un post sul blog sulla distribuzione di token che intendono sistemare manualmente, presto, secondo un programma ancora da determinare.
Gli audit possono essere utili. Gli audit possono aiutare. E la verità è che gli audit web3 hanno catturato problemi reali e, per un periodo significativo di tempo, erano pieni di contenuti utili e interessanti. Ma gli ingegneri sono migliorati nel tempo perché sono, sai, ingegneri e questo è ciò che fanno. Gli auditor devono tenere il passo e, per prendere in prestito una parola, innovare un po'. E molte parti più grandi dell'ecosistema, come gli exchange, possono aiutare a far avanzare anche questo.


