Wnioski z Curve Finance i Web3 dotyczące podatności na ataki

Wnioski z Curve Finance i Web3 dotyczące podatności na ataki

Znacznik czasu: 26 września 2023 11:03
Wnioski z Curve Finance i Web3 dotyczące podatności na ataki PlatoBlockchain Data Intelligence. Wyszukiwanie pionowe. AI.

Curve Finance niedawne przeżycie bliskie śmierci (i zapobieganie jego rozprzestrzenianiu się) może wydawać się rozmyciem w lusterku wstecznym Web3, ale w rzeczywistości jest to coś, co ciągle dzieje się w branży. To nie pierwszy raz, kiedy A zdecentralizowane finanse protokół — lub jakakolwiek zdecentralizowana aplikacja — został dotknięty atakiem, który jest całkowicie legalny w ramach jego własnego kodu. Co więcej, kryzysowi można było zapobiec, gdyby istniało zarządzanie ryzykiem w łańcuchu.

Wszystko to wskazuje na szerszy problem w Web3. Na tym polega problem ograniczona ekspresja i zasoby które istnieją w jego środowiskach programistycznych i jak wpływa to na ogólne bezpieczeństwo.

Włamać się czy wykorzystać?

Kiedy atakującemu Curve Finance udało się odzyskać aktywa o wartości 61.7 mln USD od Curve Finance inteligentne kontrakty, wiele środki masowego przekazu i komentatorzy nazwali to wydarzenie „siekać.” Ale to nie był hack – to był exploit. Różnica tutaj jest kluczowa. 

W tym kontekście do włamania doszłoby, gdyby osoba atakująca w jakiś sposób ominęła lub złamała istniejące zabezpieczenie. Ale atak na Curve był exploitem. Nie wydarzyło się nic niezwykłego w świetle tego, na co pozwalał kod Vyper protokołu. Szabrownik po prostu wykorzystał sposób działania projektu protokołu.

Kto jest temu winien? Nikt. Kod Vyper firmy Curve, podobnie jak większość kodu (Solidity) używanego w aplikacjach Web3, ma poważnie ograniczone możliwości wyrażania złożoności wykraczającej poza stosunkowo prostą logikę transakcji. 

Utrudnia to każdemu zaprojektowanie środków bezpieczeństwa, które zapobiegłyby temu lub jakimkolwiek innym atakom. Co bardziej niepokojące, utrudnia to również właściwe zaprojektowanie narzędzi, aby zapobiec ich rozprzestrzenianiu się w rozległym i komponowalnym krajobrazie płynności DeFi.

Analiza ryzyka w łańcuchu

Nie oznacza to jednak, że Curve nie mogła nic zrobić, aby zapobiec temu atakowi i jego rozprzestrzenianiu się w DeFi. Prostym przykładem rozwiązania może być analiza ryzyka w łańcuchu. 

Uogólnioną wersję problematycznego wzorca, którą można rozwiązać, można podsumować w hipotetycznej sytuacji takiej jak ta:

  • Zły aktor Bob kupuje wysoce zmienny token $RISKY o wartości 5 milionów dolarów za pośrednictwem a Pożyczka.
  • Wartość tokena $RISKY jest skutecznie pompowana przez Boba po zakupie. 
  • Bob zaciąga pożyczkę w wysokości 100 milionów dolarów w firmie Naive Finance wspieraną przez $RISKY.
  • Naive Finance sprawdza cenę RYZYKA $ i potwierdza, że ​​Bob jest „dobry” pod względem pieniędzy.
  • Bob biegnie.
  • Kiedy Naive Finance likwiduje RYZYKOWE $, jego wartość wynosi tylko 5 milionów dolarów.

(Inny przykład tego ogólnego wzorca można znaleźć w Hack Eulera od marca.)

Tradycyjnie problem ten rozwiązuje się za pomocą rozwiązań analizy ryzyka, które określają, jak dobra gwarancja może być składnikiem aktywów. Gdyby istniały w sieci, Naive Finance mogłoby sprawdzić szacunki statystyczne w oparciu o historyczną cenę tokena przed zatwierdzeniem pożyczki. Protokół przejrzałby pompę i odmówił Bobowi 100 milionów dolarów.

DeFi brakuje tego rodzaju analizy i zarządzania ryzykiem w łańcuchu.

Wracając do Curve Finance, spreadowi można by zapobiec, gdyby Aave i Frax miały zautomatyzowany, łańcuchowy limit zatwierdzania pożyczek, gdy przekraczają procent podaży tokenu zabezpieczającego w obiegu. Byłaby to sytuacja bezpieczniejsza i mniej stresująca dla wszystkich.

Ograniczona ekspresja i zasoby

Prawdziwym problemem jest to, że obecne ekosystemy Web3 nie obsługują czegoś takiego jak rozwiązanie do analizy ryzyka w łańcuchu. Są one ograniczone rodzajem bibliotek i frameworków dostępnych na maszynach wirtualnych, takich jak maszyna wirtualna Ethereum. Mają także ograniczone zasoby, którymi dysponują.

Aby opracować coś takiego jak rozwiązanie do analizy i zarządzania ryzykiem, zdecentralizowana aplikacja musiałaby polegać na bibliotekach kodujących, które mają funkcje przynajmniej podstawowe pojęcia matematyczne, takie jak logarytmy i inne. 

Nie ma to miejsca w przypadku Web3, ponieważ dApps nie ma do nich dostępu numpy, na przykład moduł matematyczny w Pythonie. Brakuje typowego zestawu narzędzi i zamiast tego programiści muszą wymyślić koło na nowo.

Wtedy mamy kolejny problem. Nawet gdyby mieli takie biblioteki, kodowanie ich byłoby zbyt drogie. Dosłownie drogie. Maszyna wirtualna Ethereum została zaprojektowana w taki sposób, że za każde obliczenia ma swoją cenę. 

Chociaż istnieją ku temu uzasadnione powody, takie jak zapobieganie nieskończonym pętlom itp., powoduje to również ograniczenie zasobów dla dApps, które mogą wymagać skalowania obliczeniowego bez ponoszenia nieuzasadnionych kosztów. Można łatwo zobaczyć, że utrzymanie rozwiązania do zarządzania ryzykiem będzie kosztować więcej, niż pozwala na zaoszczędzenie środków.

Koncentrowanie się na właściwych problemach

Na poziomie lokalnym rozprzestrzenianiu się impasu w Curve Finance można było zapobiec poprzez zarządzanie ryzykiem w łańcuchu dostaw. Ogólnie rzecz biorąc, całej tej klasie ataków można zapobiec dzięki większej ekspresji i zasobom w Web3.

Są to dwa aspekty skalowalności blockchainu, które od dawna były pomijane, ponieważ wykraczają poza zapewnianie większej przestrzeni współdzielonych bloków dla dApps. W rzeczywistości obejmują one tworzenie środowisk programistycznych w Web3, które emulują środowiska Web2. Są o skalowalność obliczeniowa i programowalność, a nie tylko skalowanie ilości danych dostępnych w łańcuchu.

Być może, gdyby twórcy protokołów w firmach Curve, Aave lub Frax mogli liczyć na lepszy zestaw narzędzi i więcej zasobów, można byłoby całkowicie uniknąć tych i przyszłych exploitów. Może moglibyśmy zacząć od zarządzania ryzykiem w łańcuchu.

Znak czasu:

Więcej z Forkast