Opłakany stan audytów Web3 i co można z tym zrobić

Balancer, stary i dobrze sprawdzony protokół, został niedawno „zhakowany". Podobnie dobrze audytowany Yearn Finance również. Lata temu Euler Finance został „zhakowany" za pomocą funkcji wprowadzonej w odpowiedzi na wcześniejszy audyt. USPD został sprawdzony przed wdrożeniem, a następnie sam nieaudytowany proces wdrożenia został zhakowany, co doprowadziło do całkowitego odpisu w ciągu około 3 miesięcy od uruchomienia. Nikt, kto zwraca uwagę, nie wierzy, że audyty gwarantują bezpieczeństwo. Wielu kwestionuje, czy w ogóle mają jakąkolwiek wartość.

To nie jest nic nowego. To nie jest problem web3. I tak naprawdę nie jest to szczególnie głęboka obserwacja. Ale audyty nadal są bardzo istotne. Projekty płacą za audyty. Projekty chwalą się audytami. Ludzie udają, że czytają audyty. Często gdy audytowany produkt zostaje wykorzystany, ludzie pytają dlaczego i jak do tego doszło.

Zamiast odpowiadać na to bezpośrednio, przejrzymy kilka ostatnich audytów niedawno uruchomionych produktów. Celem nie jest wyśmiewanie ani krytykowanie kogokolwiek. Zostały wybrane losowo, głównie ze względu na skupienie się na najnowszych rzeczach. Nie oznacza to, że są szczególnie złe. Nawet nie są takie złe!

Naszym punktem nie jest to, że audytorzy robią coś złego. Audytorzy robią to, o co proszą ich projekty, które ich angażują. Zakres audytu jest ustalany przez projekt. Jako jeden skrajny przykład: gdyby Do Kwon zaangażował audytorów do swojego schematu stablecoina, zauważyliby oni, że jest potencjalnie niestabilny. Problem zostałby oznaczony jako „potwierdzony" i nic nie zostałoby zrobione ani zmienione.

Ten problem nie ma absolutnie nic wspólnego z badaniami takimi jak te, które twierdziły, że ekosystem Terra-LUNA Do był bardzo solidny. Trudno jest przewidzieć przyszłość, a tego rodzaju badania są słusznie postrzegane jako egoistyczny marketing, który w ostatecznym rozrachunku przyznaje się do głównych problemów. Oczekuje się, że badania sponsorowane przez projekt przedstawią rzeczy w pozytywnym świetle. Całym celem audytów jest zapewnienie obiektywnej perspektywy strony trzeciej. Nie można ufać reklamom, a audyty nie są gwarancjami ani ubezpieczeniem. Takie jest życie.

Celem tego przeglądu jest podkreślenie, że prawdziwym problemem nie są podstawowe błędy programistyczne, które audytorzy są w stanie zidentyfikować, a proces audytu jest dobrze zaprojektowany do rozwiązania. Audytorzy są całkiem dobrzy w ich wychwytywaniu. Tak samo zresztą są programiści budujący te rzeczy. Empirycznie tego rodzaju informacje zwrotne docierają do właściwych osób i wąskie problemy są naprawiane.

Nie, prawdziwym problemem są produkty, które działają dokładnie zgodnie z zamierzeniami i gdzie znane „ryzyko" materializuje się, by wszystko zniszczyć. To, co teraz zobaczysz, to audytorzy próbujący chronić się przed wszystkimi przyszłymi znanymi-nieznanymi problemami. Jako ćwiczenie ochrony przed odpowiedzialnością i krytyką może to być wartościowe. Ale w ogólnym sensie nie pomaga to nikomu.

A następnie na końcu omówimy, co mogą zrobić różne strony, co zarówno pomogłoby, jak i służyło ich własnym wąskim interesom. Jeśli twoja recepta na poprawę audytów wymaga altruizmu, cóż, nie jest zbyt użyteczna.

Jovay

Jovay to L2 związany z Ant Financial lub Alibaba lub czymś w tym ogólnym obszarze. Ale tak naprawdę nie ma znaczenia, co robi Jovay. To rzecz zbudowana z oprogramowania z dużej i dobrze finansowanej organizacji. Ten audyt wymienia osiem problemów:

1. Prawdziwy błąd programistyczny, który został następnie naprawiony.
2. Że protokół nie jest bez zaufania. To jest problem w pewnym sensie, ale jest również główną częścią projektu.
3. Atak „fałszywego doładowania", który dotyczy szerokiego obszaru ekosystemu i nie jest specyficzny dla projektu.
4. Serwery RPC używają HTTP zamiast HTTPS. Te interfejsy nie przetwarzają poufnych informacji. Dotyczy to miliardów całkowicie bezpiecznych stron internetowych tylko do odczytu.
5. Obliczenia kwantowe stanowią zagrożenie dla Ethereum. OK. Bardzo na temat.
6. Inteligentne kontrakty EVM mogą być podatne na ataki. Nie, poważnie. Mówi „Inteligentne kontrakty Evm są podatne na różne wektory ataków ze względu na niezmienne wdrażanie kodu i złożone interakcje, potencjalnie prowadzące do kradzieży funduszy,.." OK. Ponownie naprawdę szanuję wąskie skupienie tego audytu.
7. Projekt sekwencera podlega MEV. Jak cała reszta ekosystemu Ethereum. Jest też zbyt ciemno w nocy.
8. Jakość kodu mogłaby zostać poprawiona. W przeciwieństwie do większości innego kodu napisanego od zarania informatyki.

Tylko jeden z nich jest prawdziwym problemem. Tak, warto zauważyć, że sam produkt nie jest bez zaufania, jeśli dokumentacja stwierdza inaczej. Ale ten produkt jest w tym zakresie całkiem w porządku. Zauważanie, że obliczenia kwantowe potencjalnie stanowią przyszłe ryzyko, a inteligentne kontrakty mogą być ryzykowne... to albo próby wydłużenia raportu przez znalezienie wymyślonych problemów, albo próba zapewnienia jakiegoś „to nie nasza wina", jeśli coś w końcu zostanie zhakowane. Prawdopodobnie mieszanka obu.

W duchu tych punktów proponujemy jako dziewiąty problem, że sieć upadnie, gdy słońce umrze, chyba że staniemy się gatunkiem międzygwiezdnym i jakoś odkryjemy komunikację szybszą niż światło. W przeciwnym razie względność ogranicza żywotność tego systemu do około 5 miliardów lat. Szczerze mówiąc, jest to bardziej użyteczne niż stwierdzenie, że jakość kodu mogłaby zostać poprawiona, ponieważ nawet po śmierci Słońca gdzieś nadal będzie wykonywany zły kod. Ale żartujemy.

Hyperliquid

Hyperliquid opublikował kilka raportów z audytów. Pierwszy raport z audytu znalazł sześć problemów, a drugi raport potwierdził, że zostały rozwiązane. Ale zakres audytu wykluczał:

1. Inne inteligentne kontrakty będące częścią systemu Hyperliquid
2. Komponenty off-chain, takie jak walidatory
3. Komponenty front-end
4. Infrastrukturę związaną z projektem
5. Przechowywanie kluczy

To wydają się być potencjalnymi obszarami problemów! Wszystko, co zostało sprawdzone, to pojedynczy kontrakt mostka. Ale system jest, cóż, znacznie bardziej skomplikowany niż to.

Audytowanie jednego małego zakątka systemu, który robi tylko kilka ściśle określonych rzeczy, jest dość bezużyteczne. Sposób, w jaki zaprojektowano Hyperliquid, sprawia, że audytowany kontrakt jest zewnętrznym punktem wejścia i wyjścia dla wszystkich. Byłby to więc poważny problem, gdyby ten kontrakt był pełen błędów. Ale potwierdzenie, że kontrakt działa, zapewnia niewielki lub żaden komfort.

Ondo

Ten audyt podkreśla „RYZYKO CENTRALIZACJI DLA ZAUFANYCH PODMIOTÓW I RÓL", co zespół potwierdził. Jest napisane wielkimi literami w raporcie. Tak.

Ten audyt zauważa, że system może się załamać, jeśli zaangażowany stablecoin zbyt mocno się odpręży. Formułują to jako system „pozwoli na nadmierne bicie tokenów OUSG podczas zdarzenia odprzęgnięcia USDC". W końcu „rozwiązanie", które wprowadzili, było odniesieniem do wyroczni Chainlink i wyłącznikiem na wypadek, gdyby cena została zgłoszona jako zbyt niska. Więc zamiast implodować z załamującą się wartością, protokół zatrzyma się z załamującą się wartością. Tak. To nie jest problem, który można rozwiązać, ponieważ nie ma mechanizmu unikania wyniku utraty wartości, jeśli USDC eksploduje. I zgodnie z tym faktem rozwiązanie tak naprawdę niczego nie naprawia.

Te audyty są stosunkowo niedawne. Ale dla kontekstu ten audyt z października 2022 roku identyfikuje wiele prawdziwych problemów. Prawie 200 z nich. Większość została naprawiona, niektóre były podobne do powyższych i po prostu potwierdzone. Chodzi o to, że audytowanie kiedyś robiło coś konkretnego i merytorycznego: szukało błędów programistycznych, które nie mogły być intencją programisty. Programiści naprawiali te błędy, ponieważ były, no wiesz, prawdziwymi błędami, a nie tylko wątpliwymi decyzjami projektowymi wbudowanymi w produkt.

A potem do 2024 roku widzimy audyty, które znajdują stosunkowo niewiele problemów technicznych i deklarują jako wykraczające poza zakres ataki związane z finansami. Jedynym sensownym sposobem interpretacji tej zmiany w czasie jest to, że programiści i programiści-jako-audytorzy rozpoznali, że działający kod nie był jedynym ryzykiem. Oczywiście błędy programistyczne były od czasu do czasu wykorzystywane. Ale do połowy 2024 roku wszyscy mogli zobaczyć, że wadliwe mechanizmy ekonomiczne były również ogromnym ryzykiem. Były największym ryzykiem.

Projekty, które działały dokładnie zgodnie z zamierzeniami – nie jak wymarzono, zgodnie z rzeczywistymi zamierzeniami – od czasu do czasu eksplodują, ponieważ marzenia projektantów o stabilności załamują się, gdy stają w obliczu rzeczywistości.

Możesz zobaczyć tę ewolucję w audytach tego jednego projektu.

Mutuum Finance

Teraz mamy reductio ad absurdum audytów. Ten identyfikuje jeden problem:

Problem polega na braku przejrzystości wokół początkowej dystrybucji tokenów i tym, jak może to być związane z problemami centralizacji. Został „złagodzony", ponieważ:

Następnie jest wiele szczegółów dotyczących multisig. I wreszcie odpowiedź audytora:

Więc ryzyko związane z projektem polega na tym, że mały zespół kontroluje wszystko, a sposób, w jaki ta kontrola będzie lub może nie być rozproszona, jest całkowicie nieprzejrzysty. A zaproponowane przez zespół rozwiązanie napisania wpisu na blogu w celu wyjaśnienia ich intencji nie naprawia tego w żadnym ścisłym sensie.

Dla jasności zespół opublikował szczegółową listę tego, gdzie i kiedy pojawią się tokeny. I przyznają, że jest to niekompletne, z komentarzami takimi jak „Rozważamy model dystrybucji blok po bloku lub tygodniowy". Przyznają również, że wszystko będzie zarządzane ręcznie z multisig. Więc są uczciwi. Po prostu uczciwość sprowadza się do „tak, nadal możemy robić, co chcemy, a wy musicie nam zaufać".

Jaki jest cel tego audytu? Jeśli kod nie miał identyfikowalnych błędów, audytor mógłby po prostu to napisać. Czasami wizyta u lekarza lub mechanika kończy się czystym świadectwem zdrowia. Więc zastanawiamy się, czy sprawdzono tylko trywialną ilość kodu? A może sam projekt to tylko trywialna ilość kodu? Czy audytor czuł potrzebę umieszczenia czegoś w raporcie, ponieważ w przeciwnym razie byłoby to zbyt puste? Po co ktokolwiek się tym przejmował?

Znowu tak naprawdę nie obwiniamy tu audytorów. W zakresie, w jakim ktoś robi coś złego, jest to prawie na pewno problem motywacji osoby zlecającej audyt. I fakt, że wydają pieniądze inwestorów na stworzenie w większości bezużytecznego dokumentu w celach marketingowych. To nie wina audytora!

Ulepszenia

To jednoznacznie dobra rzecz, że więcej błędów jest wychwytywanych, mniej wadliwego kodu jest publikowanych do produkcji i więcej proponowanych poprawek jest wdrażanych. I nie jesteśmy na tyle niedojrzali, by sugerować, że problem polega na tym, że użytkownicy i inwestorzy troszczą się o niewłaściwe rzeczy, takie jak na przykład pokładanie wartości i zaufania w audytach, które niewiele znaczą. Ludzie troszczą się o to, o co się troszczą, a próba zmiany tego to zadanie skazane na niepowodzenie.

Ale możemy zasugerować kilka prawdziwych ulepszeń. Ethena pokazała drogę, wyjaśniając z góry niektóre z wielu trybów awarii ich produktu. Zespół konsekwentnie komunikował, że USDe nie był pozbawiony ryzyka. I nakreślili sposoby, w jakie może mieć problemy. Produkt przetrwał, z kilkoma wybojami, i jest dziś całkiem duży. To daje nam punkt działania dla inwestorów: nalegaj, aby projekty były uczciwe co do wszelkich „ataków związanych z finansami", które mogą istnieć.

Ethena pokazuje, że bycie uczciwym nie skazuje projektu! Można argumentować, że będąc bardziej uczciwym, projekt przyciągnął więcej zainteresowania. Uczciwość ma również dodatkową zaletę zapewnienia większej ochrony prawnej, jeśli coś pójdzie nie tak. Projekty powinny już tego chcieć.

Audytorzy również mogą przestawić sposób, w jaki wykonują analizę, aby ich praca była bardziej użyteczna. Lub przynajmniej mniej bezużyteczna i potencjalnie myląca. Nie umieszczaj problemów z bodźcami ekonomicznymi ani ogólnych obaw, takich jak bezpieczeństwo kwantowe, w tej samej sekcji co błędy. Obecnie są one zwykle oznaczane w sposób, który nieznacznie odróżnia je od błędów kodowania. Lub są wymieniane jako „informacyjne" w przeciwieństwie do „krytycznych".

Ale to mija się z celem. Bezpieczeństwo kwantowe może być „krytycznym" ryzykiem dla systemu – ale ma zupełnie inny charakter niż zły sprawdzanie podpisu lub błędny znak minus! Umieść te rzeczy w oddzielnych sekcjach. Podobnie „ten schemat stablecoina jest niestabilny w rozsądnie prawdopodobnych warunkach" to nic takiego jak błąd logiczny w kodzie. Wyjaśnienie tego zamieszania powinno poprawić wygląd dokumentów audytu i wypolerować reputację audytora.

Wreszcie giełdy mogą w tym pomóc. Duże giełdy są często krytykowane za notowanie okropnych projektów lub szalenie wahających się ryzykownych memecoinów, które kosztują ludzi pieniądze, lub wszelkiego rodzaju innych dziwnych decyzji biznesowych powodujących straty. A co, gdyby giełdy nalegały na rozsądne audyty, które uczciwie obejmują stabilność ekonomiczną i nie mylą ryzyk, takich jak „inteligentne kontrakty mogą być podatne na ataki" z prawdziwymi sprawdzeniami logiki?

Jednym ze sposobów interpretacji tego, że audytor wypycha swoje wyniki tym rodzajem wypełniacza, jest to, że nikt nie potraktuje poważnie pustego wyniku audytu. W porządku, taki dokument wzbudziłby pytania. Ale jeśli główna giełda wymieniłaby token z, powiedzmy, dwoma pasującymi „pustymi" wynikami audytu, które nie zawierały żadnych problemów specyficznych dla projektu i zajęła stanowisko, że to była dobra rzecz... to mogłoby nieco pomóc w posunięciu piłki do przodu. Jesteśmy również w punkcie cyklu, w którym bycie bardziej „uczciwą" i „rozsądną" giełdą powinno przynieść ci więcej klientów niż brak absurdalnego marketingu-do-księżyca kosztuje cię.

Podobnie nie powinno być stygmatu związanego z audytowaniem projektu i stwierdzeniem, że wygląda dobrze. To jest na audytorach. Może grupa audytorów mogłaby wydać wspólne oświadczenia w tym obszarze. Tak, możemy zrozumieć, że audytorzy będą chcieli umieścić zastrzeżenia dotyczące potencjalnych problemów, które zostały wykluczone z zakresu na początku zaangażowania. Również w porządku. Ale wypychanie wyników bezużytecznymi ogólnymi potencjalnymi problemami nie jest odpowiedzią. Podobnie jak mówienie, że zespół złagodził ryzyko centralizacji, publikując wpis na blogu o dystrybucji tokenów, którą zamierzają ręcznie uporządkować, wkrótce, według jakiegoś harmonogramu, który jest jeszcze do ustalenia.

Audyty mogą być użyteczne. Audyty mogą pomóc. I prawdą jest, że audyty web3 wychwytywały prawdziwe problemy i przez znaczny okres czasu były wypełnione użyteczną i interesującą treścią. Ale inżynierowie z czasem się poprawili, ponieważ są, no wiesz, inżynierami i to właśnie robią. Audytorzy muszą nadążyć i, pożyczając słowo, trochę wprowadzać innowacje. I wiele większych części ekosystemu, takich jak giełdy, może również pomóc w posuwaniu tego naprzód.