Jak ocenić raport z audytu smart kontraktu
Raport z audytu smart kontraktu nie jest gwarancją bezpieczeństwa. Dowiedz się, jak sprawdzić zakres, ustalenia, poprawki i wiarygodność audytora oraz jakie są sygnały ostrzegawcze fałszywych audytów.
Aby ocenić raport z audytu smart kontraktu, potwierdź, że jest autentyczny i opublikowany przez audytora, sprawdź, czy jego zakres obejmuje faktycznie wdrożone kontrakty, przeczytaj ustalenia krytyczne i o wysokiej ważności oraz sprawdź, czy każde z nich naprawiono, a także zanotuj, czego audyt wyraźnie nie obejmował. Audyt to migawka konkretnego kodu, a nie gwarancja, że projekt jest bezpieczny lub uczciwy.
Projekty często promują hasło „po audycie” jako znak zaufania. Niektóre audyty są dokładne i wartościowe, inne wąskie, nieaktualne lub fałszywe. Jeśli wiesz, jak czytać raport, odróżnisz je w około piętnaście minut.
Czym jest audyt smart kontraktu
Audyt smart kontraktu to przegląd bezpieczeństwa, w którym specjaliści czytają kod projektu, testują go i szukają podatności, takich jak reentrancy, błędy kontroli dostępu, błędy obliczeniowe i usterki logiczne. Następnie publikują raport z listą tego, co znaleźli, oceną powagi każdego problemu i opisem reakcji zespołu. Powiązana lektura: Exploity smart kontraktów.
Audyty są cenne, ponieważ smart kontrakty trudno zmienić po wdrożeniu, a często przechowują duże sumy pieniędzy. Audytorzy pracują jednak pod presją czasu, sprawdzają tylko to, co dostaną, i mogą przeoczyć subtelne problemy. Wiele zaatakowanych protokołów przeszło wcześniej audyt.
Sekcje typowego raportu z audytu
| Sekcja | Na co zwrócić uwagę |
|---|---|
| Podsumowanie | Nazwa audytora, projekt, daty, ogólny wniosek |
| Zakres | Dokładne pliki, kontrakty, hash commita lub sprawdzone wdrożone adresy |
| Metodologia | Przegląd ręczny, narzędzia automatyczne, testy, weryfikacja formalna |
| Ustalenia | Każdy problem z poziomem ważności, opisem i rekomendacją |
| Status | Czy każde ustalenie naprawiono, przyjęto do wiadomości czy zakwestionowano |
| Zastrzeżenia | Ograniczenia przeglądu |
Krok po kroku: jak ocenić raport
1. Sprawdź, czy raport jest autentyczny
Fałszywe audyty to znana taktyka oszustów. Szukaj raportu na oficjalnej stronie lub GitHubie audytora, do których dotrzesz samodzielnie. Jeśli audytor nigdy nie słyszał o projekcie albo raport istnieje tylko jako PDF na stronie projektu, traktuj go jako niezweryfikowany. Nasz poradnik o fałszywych audytach opisuje typowe sztuczki.
2. Porównaj zakres z tym, co wdrożono
Raport powinien wskazywać commit kodu lub adresy kontraktów. Sprawdź w eksploratorze bloków, czy wdrożone kontrakty się zgadzają. Typowe luki:
- Audyt dotyczył wcześniejszej wersji, a kod później się zmienił.
- Audytowi poddano tylko kontrakt tokena, a nie kontrakty stakingu, vaulta czy mostu, które przechowują środki użytkowników.
- Kontrakty można aktualizować, więc kod może zostać później podmieniony.
3. Najpierw przeczytaj poważne ustalenia
Przejdź od razu do problemów krytycznych i o wysokiej ważności. Przy każdym zapytaj:
- Czy oznaczono je jako rozwiązane i czy audytor zweryfikował poprawkę?
- Jeśli zostało „przyjęte do wiadomości” zamiast naprawione, jak uzasadnia to zespół?
- Czy dotyczy uprawnień administratora, takich jak możliwość mintowania tokenów, wstrzymywania transferów lub wypłacania środków?
Przyjęte do wiadomości problemy z centralizacją często są dla inwestorów ważniejsze niż błędy w kodzie. Właściciel, który może mintować nieograniczoną liczbę tokenów, stanowi ryzyko, nawet jeśli kod działa idealnie.
4. Sprawdź daty
Zanotuj, kiedy przeprowadzono audyt, i porównaj to z datą wdrożenia oraz późniejszymi aktualizacjami. Stary audyt często aktualizowanego protokołu niewiele mówi o dzisiejszym kodzie.
5. Oceń audytora
Szukaj audytorów z publiczną historią, szczegółowymi opublikowanymi raportami i badaczami bezpieczeństwa wymienionymi z nazwiska. Jednostronicowy raport bez szczegółów od firmy, która audytuje setki tokenów miesięcznie, ma mniejszą wagę.
6. Przeczytaj zastrzeżenia i ograniczenia
Zastrzeżenia zwykle stwierdzają, że audyt nie obejmuje projektu ekonomicznego, komponentów off-chain, wyroczni, kodu front-endu ani przyszłych zmian. To właśnie obszary, w których dochodzi do wielu rzeczywistych strat.
Jak rozumieć poziomy ważności
Większość audytorów stosuje podobną skalę, choć definicje różnią się między firmami:
| Ważność | Typowe znaczenie | Jak bardzo powinno Cię to niepokoić |
|---|---|---|
| Krytyczna | Możliwa jest bezpośrednia utrata lub kradzież środków | Musi zostać naprawiona przed startem; nierozwiązana oznacza: trzymaj się z daleka |
| Wysoka | Poważna utrata środków lub niedziałające kluczowe funkcje w pewnych warunkach | Powinna być naprawiona; sprawdź, czy audytor to potwierdził |
| Średnia | Problemy w określonych okolicznościach lub znaczna centralizacja | Czytaj uważnie, zwłaszcza ustalenia o uprawnieniach administratora |
| Niska | Drobne problemy o ograniczonym wpływie | Zwykle w porządku, jeśli przyjęte do wiadomości |
| Informacyjna | Jakość kodu, efektywność gazu, dobre praktyki | Rzadko stanowi problem dla użytkowników |
Raport z wieloma ustaleniami niekoniecznie jest złą wiadomością. Może oznaczać, że audytor był dokładny, a zespół naprawił problemy przed startem. Liczy się powaga tego, co pozostaje nierozwiązane, i to, jak zareagował zespół. Zespół, który kwestionuje każde ustalenie lub po cichu ignoruje poważne, mówi coś o swojej kulturze bezpieczeństwa.
Sygnały ostrzegawcze w raportach z audytu
- Brak szczegółów zakresu, hasha commita lub adresów kontraktów.
- Problemy krytyczne oznaczone jako „przyjęte do wiadomości” bez poprawki.
- Ustalenia dotyczące uprawnień właściciela, które projekt bagatelizuje.
- Raport hostowany wyłącznie przez projekt.
- Hasła marketingowe w rodzaju „w 100% bezpieczny” lub „w pełni zabezpieczony audytem”.
- Audyt datowany na długo przed dużymi zmianami w kodzie.
Czego audyt Ci nie powie
Nawet solidny audyt nie odpowiada na pytania:
- Czy zespół jest prawdziwy i godny zaufania – zobacz jak sprawdzić, czy zespół kryptowalutowy jest prawdziwy.
- Czy płynność jest zablokowana, czy może zostać wycofana.
- Czy podaż tokena i odblokowania są uczciwe.
- Czy projekt ekonomiczny protokołu może zawieść pod presją.
Łącz audyt z innymi kontrolami, takimi jak publiczny program bug bounty, kilka niezależnych audytów, czas działania w produkcji bez incydentów i przejrzyste uprawnienia administracyjne.
Podsumowanie
Raport z audytu jest użytecznym dowodem tylko wtedy, gdy jest autentyczny, aktualny i obejmuje kontrakty, z których faktycznie korzystasz. Zweryfikuj źródło, porównaj zakres, przeczytaj poważne ustalenia i sposób ich rozwiązania oraz zwróć uwagę na to, co pominięto. Traktuj go jako jeden z elementów swojego researchu, nigdy jako dowód, że projekt jest bezpieczny.
Najczęściej zadawane pytania
Czy audyt oznacza, że projekt kryptowalutowy jest bezpieczny?
Nie. Audyt to przegląd konkretnego kodu w konkretnym momencie, wykonany przez konkretny zespół. Może przeoczyć błędy, nic nie mówi o uczciwości zespołu ani o tokenomii i nie obejmuje kodu zmienionego po przeglądzie. Wiele zaatakowanych protokołów przeszło wcześniej audyt. Traktuj audyt jako jeden z dowodów, a nie gwarancję.
Jak sprawdzić, czy raport z audytu jest prawdziwy?
Znajdź raport na stronie internetowej lub oficjalnym GitHubie samego audytora, a nie tylko na stronie projektu. Sprawdź, czy adresy kontraktów lub commit kodu podane w raporcie zgadzają się z tym, co zostało wdrożone. Niektórzy audytorzy umożliwiają bezpośrednią weryfikację raportów. PDF, który istnieje tylko w kanałach projektu, nie wystarczy.
Co oznaczają poziomy ważności w audycie?
Audytorzy zwykle klasyfikują ustalenia jako krytyczne, wysokie, średnie, niskie i informacyjne. Problemy krytyczne i wysokie mogą prowadzić do utraty środków lub niedziałającego protokołu. Najważniejsze jest to, czy te poważne ustalenia zostały naprawione i czy audytor potwierdził poprawkę w przeglądzie uzupełniającym.
Czy jeden audyt wystarczy?
W przypadku dużych protokołów przechowujących znaczne środki użytkowników jeden audyt często uważa się za minimum. Kilka niezależnych audytów, publiczny program bug bounty, formalna weryfikacja kluczowych komponentów i długa historia bez incydentów razem stanowią znacznie mocniejszy dowód niż jakikolwiek pojedynczy raport.