Starea deplorabilă a auditării Web3 și ce se poate face

Balancer, un protocol vechi și bine auditat, a fost recent „atacat". La fel și Yearn Finance, de asemenea bine auditat. Cu ani în urmă, Euler Finance a fost „atacat" printr-o funcție introdusă ca răspuns la un audit anterior. USPD a fost auditat înainte de implementare, iar apoi procesul neauditat de implementare în sine a fost atacat,ducând la o pierdere totală în aproximativ 3 luni de la lansare. Nimeni care a fost atent nu crede că auditurile sunt o garanție că ceva este sigur. Mulți se întreabă dacă mai au vreo valoare.

Acest lucru nu este nou. Nu este o problemă web3. Și, în realitate, aceasta nu este o observație deosebit de profundă. Dar auditurile sunt încă foarte relevante. Proiectele plătesc pentru audituri. Proiectele promovează auditurile. Oamenii pretind că citesc auditurile. Adesea, când un produs auditat este exploatat, oamenii întreabă de ce și cum s-a întâmplat asta.

În loc să răspundem direct la oricare dintre acestea, vom analiza câteva audituri recente pentru produse lansate recent. Scopul aici nu este să ne batem joc de cineva sau să criticăm pe cineva. Acestea sunt selectate aleatoriu, în principal din cauza concentrării pe lucruri recente. Asta nu înseamnă că sunt deosebit de rele. Nici măcar nu sunt chiar atât de rele!

Punctul nostru aici nu este că auditorii fac ceva greșit. Auditorii fac ceea ce proiectele care îi angajează le cer. Domeniul de aplicare al auditului este stabilit de proiect. Ca un exemplu extrem: dacă Do Kwon ar fi angajat auditori pentru schema sa de stablecoin, aceștia ar fi observat că era potențial instabilă. Problema ar fi fost marcată „recunoscută" și nimic nu s-ar fi făcut sau schimbat.

Această problemă nu are absolut nimic de-a face cu studii ca acelea care au afirmat că ecosistemul Terra-LUNA al lui Do era extrem de robust. Este greu să prezici viitorul și astfel de studii sunt văzute pe bună dreptate ca marketing auto-servitor care, în limită, recunoaște problemele fundamentale. Cercetarea sponsorizată de proiect este de așteptat să prezinte lucrurile într-o lumină pozitivă. Întregul scop al auditurilor este să ofere o perspectivă obiectivă din partea unei terțe părți. Exagerările publicitare nu trebuie să fie de încredere, iar auditurile nu sunt garanții sau asigurări. Așa este viața.

Scopul acestui sondaj este să sublinieze că problema reală aici nu sunt erorile de programare de bază de tipul pe care auditorii sunt bine plasați să le identifice și pentru care procesul de audit este bine conceput să le rezolve. Auditorii sunt destul de buni la detectarea acestora. De asemenea, și programatorii care construiesc aceste lucruri în primul rând. Din punct de vedere empiric, acest tip de feedback ajunge la persoanele potrivite și problemele înguste sunt rezolvate.

Nu, problema reală sunt produsele care funcționează exact așa cum au fost concepute și unde un „risc" cunoscut se materializează pentru a distruge totul. Ceea ce veți vedea acum sunt auditori care încearcă să se protejeze împotriva tuturor problemelor viitoare cunoscute-necunoscute. Ca un exercițiu de protecție împotriva răspunderii și a batjocurii, poate că acest lucru este valoros. Dar, în sens general, nu ajută pe nimeni.

Și apoi, la final, vom discuta ce poate face o serie de părți care ar ajuta și ar servi propriile lor interese înguste. Dacă rețeta ta pentru îmbunătățirea auditurilor implică altruism, atunci, ei bine, nu este foarte utilă.

Jovay

Jovay este un L2 asociat cu Ant Financial sau Alibaba sau ceva în zona aia generală. Dar nu contează cu adevărat ce face Jovay. Este un lucru construit din software dintr-o organizație mare și bine finanțată. Acest audit listează opt probleme:

1. O greșeală legitimă de programare care a fost ulterior corectată.
2. Că protocolul nu este fără încredere. Aceasta este o problemă în felul ei, dar este și o parte fundamentală a designului.
3. Atacul „fake-recharge" care se aplică unei mari părți a ecosistemului și nu este specific proiectului.
4. Serverele RPC folosesc HTTP în loc de HTTPS. Aceste interfețe nu procesează informații secrete. Acest lucru se aplică miliardelor de site-uri web perfect sigure doar pentru citire.
5. Calculul cuantic reprezintă un risc pentru Ethereum. OK. Foarte pe subiect acesta.
6. Contractele inteligente EVM pot fi vulnerabile. Nu serios. Spune „Contractele inteligente Evm sunt susceptibile la diverse vectori de atac din cauza implementării de cod imuabil și a interacțiunilor complexe, conducând potențial la furtul de fonduri,.." Ok. Din nou, respectând cu adevărat concentrarea îngustă a acestui audit.
7. Designul sequencer-ului este supus MEV. Ca tot restul ecosistemului Ethereum. Este, de asemenea, prea întunecat noaptea.
8. Calitatea codului ar putea fi îmbunătățită. Spre deosebire de majoritatea celorlalte coduri scrise de la începutul calculatoarelor.

Doar una dintre acestea este o problemă reală. Da, merită menționat că produsul în sine nu este fără încredere dacă documentația afirmă altfel că este fără încredere. Dar acest produs este destul de bine în privința asta. A menționa că calculul cuantic poate reprezenta un risc viitor și că contractele inteligente pot fi riscante...acestea sunt fie încercări de a face raportul mai lung găsind probleme inventate, fie sunt o încercare de a oferi un fel de „nu este vina noastră" dacă ceva este eventual atacat. Probabil un amestec al celor două.

În spiritul acelui punct, propunem ca a noua problemă că rețeaua se va opri când soarele moare dacă nu devenim o specie interstellară și cumva descoperim comunicarea mai rapidă decât lumina. Altfel, relativitatea limitează durata de viață utilă a acestui sistem la aproximativ 5 miliarde de ani. Sincer, aceasta este mai utilă decât să afirmi că calitatea codului ar putea fi îmbunătățită, deoarece chiar și după ce Soarele moare, va fi încă cod rău care se execută undeva. Dar glumim.

Hyperliquid

Hyperliquid a publicat câteva rapoarte de audit. Primul raport de audit a găsit șase probleme, iar al doilea raport a confirmat că acestea au fost rezolvate. Dar domeniul de aplicare al auditului a exclus:

1. Alte contracte inteligente parte a sistemului Hyperliquid
2. Componente off-chain, precum validatorii
3. Componente front-end
4. Infrastructura legată de proiect
5. Custodia cheilor

Acestea par zone problematice potențiale! Tot ce a fost auditat a fost un singur contract bridge. Dar sistemul este, ei bine, mult mai complicat decât atât.

Auditarea unui colț minuscul al sistemului care face doar câteva lucruri strâns definite este destul de inutilă. Modul în care Hyperliquid este proiectat, contractul auditat este punctul extern de intrare și ieșire pentru toată lumea. Deci ar fi o problemă gravă dacă acel contract ar fi plin de erori. Dar confirmarea că contractul funcționează oferă puțin sau deloc confort.

Ondo

Acest audit evidențiază „RISCUL DE CENTRALIZARE PENTRU ENTITĂȚI ȘI ROLURI DE ÎNCREDERE" pe care echipa l-a recunoscut. Este scris cu majuscule astfel în raport. Corect.

Acest audit notează că sistemul ar putea colапsa dacă un stablecoin implicat se depeg-uiește prea tare. Ei formulează asta ca sistemul „va permite mintarea excesivă de token-uri OUSG în timpul evenimentului de depeg USDC". În cele din urmă, „soluția" pe care au pus-o a fost o referință la un oracle Chainlink și un întrerupător în caz că prețul este raportat ca fiind prea scăzut. Deci, în loc să implodeze cu prețul care se prăbușește, protocolul se va opri cu prețul care se prăbușește. Corect. Aceasta nu este o problemă rezolvabilă în sensul că nu există niciun mecanism pentru a evita un rezultat care pierde valoare dacă USDC explodează. Și, în concordanță cu acest fapt, soluția nu rezolvă cu adevărat nimic.

Acele audituri sunt relativ recente. Dar pentru a oferi context, acest audit din octombrie 2022 identifică o mulțime de probleme reale. Aproape 200 dintre ele. Majoritatea au fost remediate, unele au fost similare cu cele de mai sus și doar recunoscute. Punctul este că auditarea obișnuia să facă ceva concret și substanțial: să caute erori de programare care nu ar fi putut fi intenția programatorului. Programatorii obișnuiau să remedieze aceste erori pentru că erau, știi, greșeli autentice, nu doar decizii de design discutabile încorporate în produs.

Și apoi, până în 2024, vedem audituri care găsesc relativ puține probleme tehnice și declară ca fiind în afara domeniului de aplicare atacuri legate de finanțe. Singura modalitate sensibilă de a interpreta această schimbare în timp este că programatorii, și programatorii ca auditori, au recunoscut că codul funcțional nu era singurul risc. Sigur, bug-urile de programare au fost exploatate din când în când. Dar până la mijlocul anului 2024, toată lumea putea vedea că mecanismele economice defecte erau, de asemenea, un risc masiv. Erau cel mai mare risc.

Proiecte care funcționau exact așa cum au fost concepute – nu așa cum au visat, ci așa cum au fost concepute în realitate – explodează din când în când pentru că visurile proiectanților de stabilitate se sparg când se confruntă cu lumea reală.

Puteți vedea această evoluție în auditurile acestui singur proiect.

Mutuum Finance

Acum avem reductio ad absurdum al auditurilor. Acesta identifică o singură problemă:

Problema este lipsa de transparență în jurul distribuției inițiale a token-urilor și cum ar putea fi aceasta legată de probleme de centralizare. A fost „atenuată" deoarece:

Apoi există o mulțime de detalii multisig. Și, în cele din urmă, răspunsul auditorului:

Deci riscul cu proiectul este că o echipă mică controlează totul și modul în care acel control va fi, sau poate nu va fi, dispersat este complet netransparent. Iar soluția propusă de echipă de a scrie o postare pe blog pentru a clarifica intenția lor nu rezolvă acest lucru în niciun sens strict.

Pentru informare, echipa a publicat o listă detaliată a ceea ce vor merge token-urile unde și când. Și recunosc că acest lucru este incomplet cu comentarii precum „Luăm în considerare fie un model de distribuție bloc cu bloc, fie săptămânal". De asemenea, recunosc că totul va fi gestionat din multisig-uri manuale. Deci sunt sinceri. Doar că sinceritatea se rezumă la „da, încă putem face ce vrem și trebuie să aveți încredere în noi".

Care este scopul acestui audit? Dacă codul nu avea bug-uri identificabile, auditorul putea doar să scrie asta. Uneori, o vizită la medic sau mecanic produce un verdict curat de sănătate. Deci ne întrebăm dacă a fost auditat doar o cantitate trivială de cod? Sau poate proiectul în sine este doar o cantitate trivială de cod? A simțit auditorul nevoia să pună ceva în raport pentru că altfel era totul prea gol? De ce s-a deranjat cineva cu oricare dintre acestea?

Din nou, nu învinuim cu adevărat auditorii aici. În măsura în care cineva face ceva greșit aici, este aproape sigur o problemă de stimulente cu cel care a comandat auditul. Și faptul că cheltuiesc banii investitorilor pentru a produce un document în mare parte inutil în scopuri de marketing. Asta nu e treaba auditorului!

Îmbunătățiri

Este un lucru neechivoc bun că mai multe bug-uri sunt prinse, mai puțin cod defect este lansat în producție și mai multe corecții propuse sunt implementate. Și nu suntem suficient de immaturi pentru a sugera că problema este că utilizatorii și investitorii acordă atenție lucrurilor greșite, cum ar fi, de exemplu, plasarea valorii și încrederii în audituri care nu înseamnă prea mult. Oamenii acordă atenție la ceea ce le pasă și încercarea de a schimba asta este o pierdere de timp.

Dar există câteva îmbunătățiri reale pe care le putem sugera. Ethena a deschis calea explicând unele dintre numeroasele moduri de eșec ale produsului lor în avans. Echipa a fost consecventă cu mesajul că USDe nu era lipsit de riscuri. Și au prezentat modalități în care ar putea avea probleme. Produsul a supraviețuit, cu câteva denivelări, și este destul de mare astăzi. Acest lucru ne oferă un punct de acțiune pentru investitori: insistați ca proiectele să fie sincere cu privire la orice „atacuri legate de finanțe" care ar putea exista.

Ethena arată că a fi sincer nu condamnă proiectul! Poți argumenta că fiind mai sincer, proiectul a atras mai mult interes. Onestitatea are, de asemenea, bonusul suplimentar de a oferi mai multă acoperire legală dacă ceva merge prost. Proiectele ar trebui să dorească să facă acest lucru deja.

Auditorii, de asemenea, pot rearanja modul în care fac analiza pentru a-și face munca mai utilă. Sau cel puțin mai puțin inutilă și potențial înșelătoare. Nu puneți probleme de stimulente economice sau preocupări generale precum siguranța cuantică în aceeași secțiune cu bug-urile. În prezent, acestea sunt în mod normal etichetate într-un mod care le diferențiază ușor de erorile de codare. Sau sunt listate ca „informative" spre deosebire de „critice".

Dar acest lucru pierde esența. Siguranța cuantică poate fi cu siguranță un risc „critic" pentru un sistem – dar este de un caracter complet diferit decât o verificare proastă a semnăturii sau un semn minus eronat! Puneți aceste lucruri în secțiuni separate. În mod similar, „această schemă de stablecoin este instabilă în condiții rezonabil probabile" nu seamănă deloc cu un bug logic în cod. Clarificarea acestei confuzii ar trebui să îmbunătățească aspectul documentelor de audit și să lustruiască reputația auditorului.

În cele din urmă, exchange-urile pot ajuta cu acest lucru. Exchange-urile mari primesc multă critică pentru listarea proiectelor teribile, sau memecoin-urilor riscante care fluctuează violent și costă oamenii bani, sau tot felul de alte decizii de afaceri ciudate care provoacă pierderi. Ce ar fi dacă exchange-urile ar insista pe audituri rezonabile care acoperă stabilitatea economică în mod sincer și nu confundă riscuri precum „contractele inteligente pot fi vulnerabile" cu verificări logice reale?

Un mod de a interpreta un auditor care își completează rezultatele cu acest fel de umplutură este că nimeni nu va lua în serios un rezultat de audit gol. Destul de corect că un astfel de document ar ridica întrebări. Dar dacă un exchange major ar lista un token cu, să zicem, două rezultate de audit „goale" potrivite care nu includeau probleme specifice proiectului și ar lua poziția că acesta este un lucru bun...asta ar putea ajuta să mute mingea puțin înainte. Suntem, de asemenea, într-un punct al ciclului în care a fi un exchange mai „sincer" și „rezonabil" ar trebui să vă aducă mai mulți clienți decât lipsa de marketing ridicol prea-la-lună vă costă.

În mod similar, nu ar trebui să existe nicio stigmă atașată auditării unui proiect și spunerii că arată bine. Aceasta este responsabilitatea auditorilor. Poate că o serie de auditori ar putea emite niște declarații comune în această zonă. Da, putem înțelege că auditorii vor dori să pună avertismente pentru probleme potențiale care au fost excluse din domeniul de aplicare când angajamentul a început. De asemenea, destul de corect. Dar completarea rezultatelor cu probleme potențiale generale fără sens nu este răspunsul. Nici să spui că echipa a atenuат riscul de centralizare făcând o postare pe blog despre distribuția de token-uri pe care intenționează să o rezolve manual, în curând, pe un program care urmează să fie determinat.

Auditurile pot fi utile. Auditurile pot ajuta. Și adevărul este că auditurile web3 au prins probleme reale și, pentru o perioadă semnificativă de timp, au fost pline de conținut util și interesant. Dar inginerii s-au îmbunătățit în timp pentru că sunt, știi, ingineri și asta fac. Auditorii trebuie să țină pasul și, pentru a împrumuta un cuvânt, să inoveze puțin. Și multe părți mai mari ale ecosistemului, precum exchange-urile, pot ajuta la accelerarea acestui lucru.