Czym jest atak na governance w krypto i jak protokoły mogą się chronić?

Czym jest atak na governance w krypto?

Atak na governance to atak, w którym ktoś wykorzystuje proces decyzyjny DAO lub protokołu albo przejmuje go, aby wykonać (zwykle) szkodliwe działanie. DAO to organizacja, która podejmuje decyzje na podstawie zasad zapisanych w smart contracts oraz głosów uczestników.

W wielu protokołach tokeny określają, ile prawa głosu posiadasz. Kto zgromadzi wystarczającą siłę głosu, może na przykład zaproponować zmianę ustawień, dodanie nowych funkcji, aktualizację logiki kontraktu albo przeniesienie środków z treasury. Treasury to po prostu wspólna pula środków protokołu.

Nie każdy atak na governance wynika z błędu programistycznego. Czasem atakujący formalnie po prostu przestrzega zasad, ale gromadzi dość wpływu, by przeforsować propozycję szkodliwą dla innych użytkowników. Nazywa się to governance capture: proces decyzyjny trafia wtedy w praktyce w ręce jednej strony lub małej grupy.

Jednym z możliwych trików jest flash loan. To pożyczka, którą trzeba spłacić w ramach tej samej transakcji blockchain. Jeśli protokół opiera wagę głosu na aktualnej liczbie tokenów w portfelu, bez okresu oczekiwania lub historycznego punktu odniesienia, atakujący może tymczasowo uzyskać dużą siłę głosu.

Przykład: Załóżmy, że protokół przypisuje jeden token do jednego głosu. Ktoś tymczasowo pożycza bardzo dużą liczbę tokenów, głosuje za propozycją przeniesienia środków z treasury i natychmiast spłaca pożyczkę. Jeśli system uwzględnia te tymczasowe tokeny, może to wystarczyć, by wpłynąć na wynik głosowania.

Najważniejsze informacje

• Atak na governance wykorzystuje proces decyzyjny DAO lub protokołu do wykonania szkodliwego działania.
• W governance opartym na tokenach liczba tokenów często określa, ile prawa głosu ma dana osoba.
• Atak może wykorzystywać błąd techniczny, ale może też przebiegać zgodnie z istniejącymi zasadami.
• Flash loan może tymczasowo zapewnić dużą siłę głosu, jeśli protokół korzysta z bieżących sald.
• Propozycje mogą między innymi zmieniać ustawienia, aktualizować kontrakty lub przenosić aktywa z treasury.

Jak działa atak na governance?

Atak na governance zwykle polega na tym, że atakujący najpierw gromadzi wystarczającą efektywną siłę głosu, następnie doprowadza do zatwierdzenia szkodliwej propozycji, a potem ją wykonuje. Dokładny przebieg zależy od zasad danego protokołu.

Waga głosu może wynikać na przykład z posiadanych tokenów, głosów delegowanych przez innych, stakowanych tokenów albo pozycji LP. Pozycja LP to Twój udział w liquidity pool. Kluczowe pytanie brzmi: w którym momencie protokół ustala, ile prawa głosu posiadasz?

Atak zwykle wygląda mniej więcej tak:

1. Zgromadzenie prawa głosu Atakujący kupuje tokeny, zbiera delegacje, wykorzystuje już istniejącą dużą siłę głosu albo tymczasowo pożycza tokeny przez flash loan.

2. Złożenie propozycji Propozycja zawiera jedną lub więcej czynności, które smart contracts mają wykonać. Mogą to być na przykład zmiany ustawień, ale też aktualizacja lub przelew z treasury.

3. Wygranie głosowania Propozycja musi zdobyć wystarczającą liczbę głosów oraz wymagane quorum. Quorum to minimalny poziom udziału potrzebny do tego, aby głosowanie było ważne.

4. Wykonanie działania Po udanym głosowaniu governance wykonuje zaplanowane transakcje. Bez opóźnienia może to nastąpić od razu. Przy timelocku działanie musi najpierw poczekać.

Historyczny snapshot pomaga chronić przed niektórymi atakami flash-loan. Taki snapshot to w praktyce zapis praw głosu z wcześniejszego, ustalonego momentu. Voting delay, czyli okres oczekiwania przed zaliczeniem głosów, działa skutecznie tylko wtedy, gdy tymczasowo pożyczone tokeny nie znajdują się już w tym snapshotcie.

Beanstalk pokazuje, jak duży może być wpływ takiego ataku. 17 kwietnia 2022 roku protokół został zaatakowany poprzez on-chain governance. Atakujący wykorzystał flash loan, aby skompromitować ówczesny mechanizm governance i wyprowadzić aktywa z DAO.

Snapshot nie jest zresztą pełnym rozwiązaniem. Jeśli atakujący kupił tokeny albo przejął nad nimi kontrolę przed wybranym momentem, taka siła głosu po prostu się liczy.

Jakie skutki może mieć atak na governance?

Atak na governance może sprawić, że atakujący przejmie środki, uprawnienia lub ważne ustawienia protokołu. To, jak poważne będą skutki, zależy całkowicie od tego, co governance rzeczywiście może zrobić.

W niektórych protokołach governance może między innymi zmieniać ustawienia systemowe, dodawać nowe rynki lub funkcje oraz aktualizować elementy protokołu. Jeśli governance kontroluje też ważne proxy, komponenty konfiguracyjne lub kontrakty treasury, złośliwa propozycja może wyrządzić duże szkody.

Możliwe skutki to między innymi:

• utrata aktywów z treasury lub aktywów użytkowników;
• niepożądane mintowanie nowych tokenów;
• zmienione ustawienia, które działają na niekorzyść użytkowników;
• zmienione uprawnienia administracyjne;
• aktualizacja do szkodliwej logiki kontraktu;
• czasowe lub całkowite wyłączenie funkcji.

W ataku na Beanstalk 17 kwietnia 2022 roku skradziono wszystkie aktywa użytkowników inne niż BEAN, o wartości około 77 milionów dolarów. Następnie protokół został wstrzymany, usunięto on-chain governance i zmieniono strukturę governance.

Szkody często wykraczają poza samą bezpośrednią stratę. Protokół może musieć migrować do nowych kontraktów, zapłacić za audyty i prace naprawcze oraz tymczasowo przekazać więcej kontroli awaryjnej małej grupie. To może mocno nadszarpnąć zaufanie użytkowników.

Jak protokół może stracić kontrolę?

Protokół faktycznie traci kontrolę w momencie, gdy atakujący ma wystarczające uprawnienia do kontraktów wykonujących krytyczne działania. Chodzi na przykład o właściciela proxy, konto mogące wykonywać aktualizacje, rolę, która może planować propozycje w timelocku, albo kontrolera treasury.

Proxy to tutaj po prostu stały adres kontraktu, który wskazuje na określoną wersję logiki kontraktu. W protokole z możliwością aktualizacji governance może skierować ten adres na nową logikę. W ten sposób jedna zatwierdzona propozycja może znacząco zmienić działanie protokołu.

Atakujący nie zawsze musi mieć większość wszystkich posiadaczy tokenów. Przy niskiej frekwencji, niskim quorum albo silnie skoncentrowanych delegacjach stosunkowo mała grupa może mieć wystarczającą efektywną siłę głosu.

Po złośliwym wykonaniu odzyskanie kontroli może być jeszcze trudniejsze. Atakujący może zmienić uprawnienia, wyprowadzić aktywa albo nawet zmodyfikować przyszłe zasady governance. Wtedy społeczność może nie być już w stanie interweniować tą samą drogą albo zrobi to dopiero znacznie później.

Utrata kontroli może też nastąpić bez ataku. Jeśli uprawnione konta zarządzające self-governed timelockiem przestaną być dostępne, kontrakt kontrolowany przez ten timelock może utknąć na nieokreślony czas.

Jak protokoły crypto i DeFi mogą się chronić?

Protokoły crypto i DeFi mogą ograniczyć ryzyko, jeśli nie pozwolą, by siła głosu, uprawnienia i wykonanie zbyt łatwo spotkały się w jednym momencie. Nie istnieje magiczne ustawienie, które zatrzyma każdy atak, ale kilka warstw ochrony razem utrudnia nadużycie.

Najważniejsze środki to:

1. Stosowanie snapshotów i voting delay Zapisz wagę głosu z wcześniejszego momentu i wprowadź okres oczekiwania. Dzięki temu trudniej jest tuż przed głosowaniem zdobyć tokeny tylko po to, by od razu ich użyć.

2. Dobór odpowiednich progów głosowania Minimalny próg dla propozycji utrudnia spamowanie tanimi propozycjami. Quorum zapobiega sytuacji, w której decyzję podejmuje bardzo mała frekwencja. Wybór pozostaje trudny: zbyt niskie progi ułatwiają przejęcie kontroli, a zbyt wysokie mogą sprawić, że governance stanie się niewydolne.

3. Umieszczanie wrażliwych działań za timelockiem Aktualizacje, duże zmiany parametrów i działania treasury nie muszą następować od razu po głosowaniu. Timelock daje użytkownikom czas na sprawdzenie zaplanowanego działania i ewentualne zamknięcie pozycji.

4. Ograniczanie uprawnień per rola Nie dawaj governance automatycznie nieograniczonej władzy. Szczególnie uprawnienia do aktualizacji, mintingu i nieograniczonych wywołań zewnętrznych wymagają dodatkowych ograniczeń. Uprawnienia awaryjne powinny być jasno zdefiniowane.

5. Testowanie rzeczywistych działań z propozycji Nie wystarczy sprawdzić tylko modułu głosowania. Zespoły muszą też testować i symulować dokładne transakcje stojące za propozycją. Propozycja może wyglądać niewinnie na wysokim poziomie, podczas gdy konkretne wywołania robią coś zupełnie innego.

6. Monitorowanie propozycji i siły głosu Monitoring sam nie zapobiegnie atakowi, ale może sprawić, że podejrzana propozycja albo duża zmiana w delegacjach zostanie zauważona na czas. Wcześniej ustalony plan reagowania na incydenty pomaga wtedy szybciej odpowiedzieć.

Audyty pozostają przydatne, ale nie dają gwarancji. Nie każdy atak na governance wynika z błędu w kodzie. Do problemów mogą prowadzić także mylące propozycje, niska aktywność i źle ocenione transakcje.

Jak mogą pomóc timelocks i multisig-governance?

Timelocks i multisigi mogą stanowić dodatkową warstwę bezpieczeństwa, ponieważ uniemożliwiają jednemu zatwierdzonemu lub skompromitowanemu kontu natychmiastowe wykonanie wszystkiego.

Timelockcontroller wymusza minimalny czas oczekiwania między zaplanowaniem a wykonaniem ważnego działania. Jeśli timelock jest administratorem kontraktu, to takie opóźnienie dotyczy również działań, które w innym przypadku mogłyby zostać wykonane od razu z uprawnieniami administratora.

To okno reakcji jest ważne. Użytkownicy i badacze bezpieczeństwa mogą przejrzeć dokładne dane transakcji, zanim zmiana wejdzie w życie. W przypadku niebezpiecznej propozycji użytkownicy mogą na przykład zamknąć swoją pozycję, zanim działanie zostanie wykonane. Timelock nie unieważnia automatycznie szkodliwego działania, ale odbiera szybkość widocznemu atakowi.

Compound v2 korzysta na przykład z kilku etapów: dwóch dni przeglądu, trzech dni głosowania, a następnie dwóch dni timelocka. Dzięki temu zmiana protokołu trwa tam co najmniej tydzień.

Multisig działa inaczej. W tym przypadku kilka osób musi potwierdzić transakcję. W multisigu 3 z 5 potrzebne są trzy ważne podpisy. Jeden skradziony lub skompromitowany klucz nie wystarczy wtedy, by samodzielnie przenieść środki albo zmienić ustawienia.

Multisig może na przykład być jedyną stroną, która ma prawo planować działania w timelocku. Najpierw grupa podpisujących musi wyrazić zgodę, a dopiero potem zaczyna biec ustalony okres oczekiwania.

Warto jednak pamiętać, że multisig przenosi zaufanie na podpisujących. Jeśli wystarczająca liczba signerów spiskuje, jeśli zbyt wiele kluczy zostanie skradzionych albo jeśli signerzy staną się niedostępni, problemy i tak się pojawią. Uwagę trzeba też poświęcić dodatkowym modułom lub rozszerzeniom, ponieważ w pewnych warunkach mogą one wykonywać transakcje poza zwykłą kontrolą podpisów.

Jakie są ograniczenia governance w krypto?

Governance w crypto może przejrzyście i automatycznie wykonywać decyzje, ale system sam z siebie nie wie, czy dana propozycja jest też rozsądna albo uczciwa. Ważne głosowanie on-chain potwierdza jedynie, że zasady zostały zachowane.

W governance opartym na tokenach wpływ jest powiązany z wagą ekonomiczną. Duzi posiadacze, fundusze i znani delegaci mogą mieć przez to znacznie większy wpływ niż mali uczestnicy, nawet bez ataku czy błędu w kodzie. Delegowanie ułatwia głosowanie, ale może też skoncentrować władzę w rękach małej grupy.

Czas i bezpieczeństwo też czasem się ścierają. Dłuższe okresy głosowania i timelocks dają więcej czasu na ocenę propozycji i reakcję. Jednocześnie spowalniają potrzebne aktualizacje, zmiany, a czasem także odpowiedź na incydent.

Quorum i minimalne progi dla propozycji mają podobny kompromis. Jeśli są zbyt niskie, decyzje może podejmować mała, ale dobrze zorganizowana grupa. Jeśli są zbyt wysokie, zwykłe propozycje mogą utknąć, bo głosuje zbyt mało osób.

Innym problemem jest złożoność. Dokładne calldata propozycji, aktualizacja logiki kontraktu albo współdziałanie kilku smart contracts są dla wielu głosujących trudne do oceny. W efekcie propozycja może być poprawna proceduralnie, a mimo to niewiele osób naprawdę rozumie, co się dzieje.

Multisig lub guardian mogą zmniejszyć ryzyko szybkiego ataku, ale wprowadzają też ryzyko centralizacji i dostępności. Guardian to konto lub grupa z wyjątkowymi uprawnieniami awaryjnymi. Jeśli taka strona działa złośliwie, staje się niedostępna albo blokuje transakcje, sama warstwa bezpieczeństwa może stać się słabym punktem.

Governance nie jest więc ustawieniem, które konfigurujesz raz i o nim zapominasz. Podział tokenów, delegacje, uprawnienia, zachęty, kontrola propozycji i procedury awaryjne trzeba regularnie analizować na nowo.

Podsumowanie

Atak na governance to nie tylko sytuacja, w której haker znajduje błąd techniczny. Także strona, która zgodnie z zasadami zgromadzi wystarczającą siłę głosu, może wprowadzić protokół w kłopoty, jeśli governance ma zbyt szerokie uprawnienia albo wykonuje propozycje zbyt szybko.

Dobra ochrona opiera się na kilku warstwach: snapshotach, voting delay, odpowiednich progach, ograniczonych uprawnieniach, kontroli działań z propozycji i monitoringu. Timelocks i multisigi mogą do tego dodać dodatkowy czas i kontrolę. Ostatecznie najważniejsze pytanie pozostaje proste: kto może co zmienić i ile czasu ma reszta, by to zauważyć i zareagować?