Audyty Smart Contractów: Dlaczego 'Audytowany' Nie Znaczy Bezpieczny

"Nie martw się, jesteśmy audytowani przez Trail of Bits."

Słynne ostatnie słowa.

Cream Finance było audytowane. Straciło $130M. Wormhole było audytowane. Straciło $320M. Ronin było audytowane. Straciło $625M.

Audyty są konieczne. Nie są wystarczające.

Pozwól że wyjaśnię dlaczego.

---

Co audytorzy faktycznie robią

Audyt to przegląd kodu przez ekspertów bezpieczeństwa.

Oni:

• Czytają kod smart contractu
• Szukają znanych wzorców podatności
• Testują edge case'y
• Sprawdzają błędy logiczne
• Weryfikują czy kod robi to co twierdzi

Czas trwania: typowo 2-6 tygodni dla złożonych protokołów.

Koszt: $50,000 do $500,000+ dla topowych firm.

Output: Raport listujący ustalenia według ważności.

Tyle. To jednorazowy przegląd przez ludzi którzy mają ograniczony czas.

---

Co audytorzy mogą znaleźć

Znane wzorce. Reentrancy, overflow, problemy z kontrolą dostępu. Dobrze udokumentowane podatności z jasnymi sygnaturami.

Bugi logiczne. "Ta funkcja powinna wymagać X ale nie wymaga." Wymaga rozumienia intencji.

Problemy z gasem. Nieefektywności które mogą uczynić kontrakt nieużywalnym.

Ryzyka centralizacji. Klucze admina które mogą opróżnić fundusze. Mechanizmy upgrade które omijają bezpieczeństwo.

Dobrzy audytorzy znajdują prawdziwe bugi. To wartościowe.

---

Co audytorzy przegapiają

Nowatorskie wektory ataku. Jeśli nikt nie widział tego typu ataku wcześniej, audytorzy mogą o nim nie pomyśleć.

Ataki ekonomiczne. Kod działa idealnie, ale zachęty są zepsute. Manipulacja flash loan, ataki governance, exploity oracle.

Problemy integracji. Kontrakt A jest bezpieczny. Kontrakt B jest bezpieczny. A + B razem? Exploitowalne.

Zmiany po audycie. Kod zmieniony po audycie. Wprowadzone nowe bugi. Raport audytu teraz mylący.

Presja czasowa. 4 tygodnie na audyt 10,000 linii. Niektóre rzeczy są przegapiane.

Audytorzy są dobrzy. Nie są wszechwiedzący.

---

Teatr audytów

Niektóre protokoły traktują audyty jako checkboxy.

"Zdobądź audyt → wstaw badge na stronę → twierdzą że są bezpieczne"

Czerwone flagi:

• Audyt był 6+ miesięcy temu, kod się od tego czasu zmienił
• Tylko jeden audyt od nieznanej firmy
• Krytyczne ustalenia oznaczone "acknowledged" (nie naprawione)
• Zakres audytu nie obejmował wszystkich kontraktów
• Brak programu bug bounty

Badge audytu znaczy "ktoś na to raz popatrzył." Tyle.

---

Problem ekonomiczny

Topowe firmy audytowe mają kolejkę na miesiące.

Popyt > podaż oznacza:

• Pośpieszne terminy
• Juniorzy audytorzy na złożonych projektach
• Mniej dokładne przeglądy
• Wyższe ceny

Nowe protokoły uruchamiające się potrzebują audytów TERAZ. Jakość cierpi.

Tymczasem firmy audytowe konkurują na szybkość i cenę, nie tylko jakość.

Zachęty są niewyrównane z bezpieczeństwem.

---

Bug bounty: Uzupełnienie

Mądre protokoły uruchamiają bug bounty obok audytów.

"Znajdź buga, dostań zapłatę."

Immunefi hostuje bounty do $10M za krytyczne podatności.

Dlaczego bounty działają:

• Ciągłe pokrycie (nie jednorazowe)
• Globalna pula talentów
• Wyrównane zachęty (znalazca dostaje kasę, protokół unika hacka)
• Pokrywa zmiany po audycie

Dlaczego to nie wystarcza:

• Pokrywa tylko to co jest zgłoszone (atakujący mogą nie zgłaszać)
• Wypłata < profit z hacka (czasem atakujący wolą exploitować)
• Wymaga aktywnej uwagi społeczności bezpieczeństwa

Audyty + bounty razem > którekolwiek samo.

---

Czytanie raportu audytu

Jeśli faktycznie czytasz audyty (powinieneś), szukaj:

Poziomy ważności. Krytyczne/Wysokie ustalenia naprawione? Czy tylko "acknowledged"?

Zakres. Co było audytowane? Czy wszystko było pokryte?

Liczba ustaleń. Dużo ustaleń = obawy o jakość kodu.

Jakość odpowiedzi. Czy zespół naprawił problemy poprawnie? Czy szybkie łatki?

Data. Jak stary jest ten audyt? Czy kod się zmienił?

Większość ludzi nigdy nie czyta raportów audytowych. Tak scamy podszywają się pod fałszywe audyty.

---

Słynne audytowane hacki

Ronin ($625M). Audytowany bridge. Atak inżynierii społecznej na walidatorów. Audyt nie mógł złapać ludzkiego błędu.

Wormhole ($320M). Audytowany. Bug był w kodzie specyficznym dla Solany który audytorzy mogli zdepriorytetować.

Nomad ($190M). Audytowany. Podatność wprowadzona w "rutynowej" aktualizacji po audycie.

Cream Finance ($130M). Wielokrotne audyty. Atak flash loan przez manipulację oracle. Atak ekonomiczny, nie bug kodu.

Wzorzec: Audyty łapią bugi kodu. Wiele hacków nie jest bugami kodu.

---

Co faktycznie utrzymuje protokoły bezpiecznymi

Wielokrotne audyty. Różne firmy znajdują różne rzeczy.

Bug bounty. Ciągłe pokrycie.

Formalna weryfikacja. Matematyczne dowody że kod robi to co powinien. Drogie ale dokładne.

Czas. Im dłużej protokół działa bez exploita, tym bardziej możesz być pewny.

Prostota. Mniej kodu = mniejsza powierzchnia ataku.

Monitoring. Wykrywanie w czasie rzeczywistym podejrzanej aktywności.

Reagowanie na incydenty. Plan na kiedy (nie jeśli) coś pójdzie nie tak.

Bezpieczeństwo to proces, nie checkbox.

---

Jak oceniać bezpieczeństwo

Przed użyciem protokołu:

1. Czy jest audytowany? Przez kogo? Kiedy? Jaki zakres?

2. Czy krytyczne ustalenia są naprawione? Przeczytaj raport.

3. Czy jest bug bounty? Jak duże? Aktywne zgłoszenia?

4. Jak długo działa? Sprawdzone w boju > nowo uruchomione.

5. Jak złożone jest? Proste i nudne często bije sprytne i złożone.

6. Jaki jest track record zespołu? Wcześniejsze hacki? Przejrzysta komunikacja?

7. Co jest na ryzyku? Nawet "bezpieczne" protokoły mogą zawieść. Nie deponuj więcej niż możesz stracić.

---

Niewygodna prawda

Żaden protokół nie jest udowodnialnie bezpieczny.

Każdy audyt ma ograniczenia. Każde bug bounty ma luki. Każda formalna weryfikacja ma założenia.

Pytanie nie brzmi "czy to jest bezpieczne?" Brzmi "jaki jest poziom ryzyka i czy jestem z nim komfortowy?"

Audyty pomagają odpowiedzieć na to pytanie. Nie eliminują ryzyka.

Używaj audytowanych protokołów. Rozumiej co audytowany znaczy. Nie mylenie "audytowany" z "gwarantowany."

---

Następny: Rug pulle - jak je rozpoznać zanim staniesz się ofiarą.