Jak Solana zneutralizowała atak o przepustowości 6 Tbps, wykorzystując specyficzny protokół kształtowania ruchu, który uniemożliwia skalowanie spamu

Kiedy sieć chwali się przepustowością, tak naprawdę chwali się tym, ile chaosu jest w stanie przełknąć, zanim się zadławi. Dlatego najbardziej interesującą częścią najnowszego „testu obciążeniowego” Solana jest to, że… nie ma żadnej historii.

Sieć dostawcza o nazwie Pipe opublikowała dane, z których wynika, że niedawny atak na Solana osiągnął około 6 terabitów na sekundę, a współzałożyciele Solana publicznie potwierdzili ogólny wydźwięk tych informacji. Jeśli liczba jest prawidłowa, to taki wolumen ruchu zarezerwowany jest zwykle dla największych celów w internecie, o czym Cloudflare pisze długie wpisy na blogu, bo to nie powinno być normalne.

A jednak Solana nadal produkowała bloki. Nie było skoordynowanego restartu ani grupowego czatu walidatorów zamieniającego się w nocny film katastroficzny.

Według własnych doniesień CryptoSlate dotyczących tego incydentu, produkcja bloków pozostała stabilna, potwierdzenia transakcji przebiegały płynnie, a opłaty użytkowników nie wzrosły znacząco. W dyskusji pojawił się nawet kontrargument: SolanaFloor zauważył, że jeden z kontrybutorów Anza twierdził, iż liczba 6 Tbps była krótkotrwałym szczytem, a nie stałą ścianą ruchu przez cały tydzień, co ma znaczenie, bo „szczyt” może być zarówno prawdziwy, jak i nieco teatralny.

Taka niuansowość jest w porządku. W rzeczywistych atakach typu denial-of-service szczyt jest często kluczowy, bo krótki cios może przewrócić system dostrojony do stanu ustalonego.

Raporty o zagrożeniach Cloudflare wskazują, że wiele dużych ataków kończy się szybko, czasem zbyt szybko, by ludzie mogli zareagować, dlatego nowoczesna obrona powinna być automatyczna. Najnowszy incydent z Solana pokazuje teraz sieć, która nauczyła się sprawiać, że spam staje się nudny.

Jaki to był rodzaj ataku i czego tak naprawdę chcą atakujący?

DDoS to najprymitywniejsza, ale najskuteczniejsza broń internetu: przeciążenie normalnego ruchu celu przez zalanie go śmieciowym ruchem z wielu maszyn jednocześnie. Definicja Cloudflare jest dosadna; to złośliwa próba zakłócenia normalnego ruchu przez przeciążenie celu lub pobliskiej infrastruktury zalewem ruchu internetowego, zwykle pochodzącego z przejętych systemów.

To wersja web2 i do niej odnosi się Pipe, pokazując wykres terabitów na sekundę. Sieci kryptowalutowe dodają do tego drugi, bardziej natywny dla krypto wariant: spam, który nie jest „śmieciowymi pakietami na stronie”, lecz „niekończącymi się transakcjami w łańcuchu”, często dlatego, że po drugiej stronie zatoru są pieniądze.

Historia awarii Solana to niemal podręcznikowy przykład tego problemu z motywacją. We wrześniu 2021 roku łańcuch był offline przez ponad 17 godzin, a wczesny raport Solana określił zalew transakcji generowanych przez boty jako w istocie atak typu denial-of-service powiązany z IDO organizowanym przez Raydium.

W kwietniu 2022 roku oficjalny raport Solana o awarii opisał jeszcze intensywniejszą ścianę przychodzących transakcji – 6 milionów na sekundę, przy czym pojedyncze węzły notowały ponad 100 Gbps. W raporcie stwierdzono, że nie było dowodów na klasyczną kampanię denial-of-service, a ślady wskazywały na boty próbujące wygrać mint NFT, gdzie nagroda przypada pierwszemu zgłaszającemu się.

Tego dnia sieć przestała produkować bloki i konieczna była koordynacja restartu.

Czego więc chcą atakujący, poza uwagą i satysfakcją z popsucia wszystkim niedzieli? Czasem to prosta próba wymuszenia: zapłaćcie nam, albo nie wyłączymy hydrantu.

Czasem chodzi o szkodę wizerunkową, bo łańcuch, który nie potrafi utrzymać ciągłości, nie może wiarygodnie gościć aplikacji, które ludzie chcą budować. Czasem to gra rynkowa, gdzie popsuty UX tworzy dziwne ceny, opóźnione likwidacje i wymuszone objazdy, które nagradzają tych, którzy są przygotowani na chaos.

W wersji on-chain spam celem może być bezpośrednio: wygrać mint, wygrać trade, wygrać likwidację, wygrać miejsce w bloku.

To, co się zmieniło, to fakt, że Solana zbudowała więcej sposobów na odmowę zaproszenia.

Zmiany projektowe, które utrzymały Solana online

Solana stała się lepsza w utrzymywaniu dostępności, zmieniając miejsce, w którym pojawia się problem. W 2022 roku awarie miały znajomy kształt: zbyt wiele przychodzących żądań, zbyt duże obciążenie zasobów węzłów, zbyt mała możliwość spowolnienia złych aktorów i efekty uboczne, które zamieniały zatory w problemy z żywotnością sieci.

Najważniejsze ulepszenia znajdują się na krawędzi sieci, tam gdzie ruch trafia do walidatorów i liderów. Jednym z nich jest przejście na QUIC do komunikacji sieciowej, co Solana później wymieniła jako część prac nad stabilnością, obok lokalnych rynków opłat i stake-weighted quality of service.

QUIC to nie magia, ale jest zaprojektowany do kontrolowanych, multipleksowanych połączeń, a nie starszych wzorców połączeń, które ułatwiały nadużycia.

Co ważniejsze, dokumentacja dla walidatorów Solana opisuje, jak QUIC jest używany w ścieżce Transaction Processing Unit: limity na równoczesne połączenia QUIC na tożsamość klienta, limity na równoczesne strumienie na połączenie oraz limity skalowane według stawki nadawcy. Opisuje także ograniczenia liczby pakietów na sekundę w zależności od stake oraz informuje, że serwer może odrzucać strumienie z kodem ograniczającym, a klienci powinni się wycofać.

To zamienia „spam” w „spam, który trafia na wolny pas”. Już nie wystarczy mieć przepustowość i botnet, bo teraz potrzebujesz uprzywilejowanego dostępu do pojemności lidera lub rywalizujesz o jej węższy wycinek.

Przewodnik dla deweloperów Solana dotyczący stake-weighted QoS wyjaśnia to jasno: po włączeniu tej funkcji walidator posiadający 1% stake ma prawo przesłać do lidera do 1% pakietów. To powstrzymuje nadawców z niskim stake przed zalaniem wszystkich innych i zwiększa odporność na Sybila.

Innymi słowy, stake staje się rodzajem roszczenia do przepustowości, nie tylko wagą głosu.

Jest jeszcze kwestia opłat, gdzie Solana stara się unikać sytuacji „jedna hałaśliwa aplikacja psuje całe miasto”. Lokalne rynki opłat i opłaty priorytetowe dają użytkownikom możliwość rywalizacji o wykonanie transakcji bez zamieniania każdego ruchliwego momentu w ogólnosieciową aukcję.

Dokumentacja opłat Solana wyjaśnia, jak działają opłaty priorytetowe poprzez jednostki obliczeniowe – użytkownicy mogą ustawić limit jednostek obliczeniowych i opcjonalną cenę za jednostkę, która działa jak napiwek zachęcający do priorytetyzacji. Wskazuje też praktyczną pułapkę: opłata priorytetowa opiera się na zadeklarowanym limicie jednostek obliczeniowych, a nie na faktycznie użytych, więc nieostrożne ustawienia mogą oznaczać płacenie za niewykorzystaną rezerwę.

To wycenia zachowania wymagające dużych zasobów obliczeniowych i daje sieci narzędzie do podnoszenia kosztów nadużyć tam, gdzie to boli.

Połączenie tych elementów daje inny tryb awarii. Zamiast zalewu szumu wpychającego węzły w spirale śmierci pamięci, sieć ma więcej sposobów na ograniczanie, priorytetyzację i kontrolę.

Sama Solana, patrząc wstecz na erę 2022, określiła QUIC, lokalne rynki opłat i stake-weighted QoS jako konkretne kroki podjęte, by niezawodność nie była poświęcana na rzecz szybkości.

Dlatego weekend na skalę terabitów może minąć bez realnych konsekwencji: łańcuch ma więcej automatycznych „nie” przy drzwiach wejściowych i więcej sposobów na utrzymanie kolejki dla użytkowników, którzy nie próbują jej zepsuć.

To nie oznacza, że Solana jest odporna na trudne dni. Nawet osoby chwalące anegdotę o 6 Tbps spierają się o to, co ta liczba oznacza i jak długo trwała, co jest uprzejmym sposobem powiedzenia, że pomiary internetowe są nieuporządkowane, a prawa do chwalenia się nie są poparte audytem.

Kompromisy nie znikają. System, który wiąże lepsze traktowanie ruchu z stake, z założenia jest przyjaźniejszy dla dobrze dokapitalizowanych operatorów niż dla walidatorów-hobbystów. System, który pozostaje szybki pod obciążeniem, nadal może być miejscem dla botów gotowych zapłacić.

Mimo to fakt, że sieć była cicha, ma znaczenie. Wcześniejsze awarie Solana nie były „ludzie zauważyli lekkie opóźnienie”. Produkcja bloków całkowicie ustawała, następowały publiczne restarty i długie okna koordynacji, w tym zatrzymanie w kwietniu 2022 roku, które trwało godziny.

Dla kontrastu, historia tego tygodnia to fakt, że łańcuch pozostał aktywny, podczas gdy ruch rzekomo osiągnął skalę bardziej znaną z raportów o zagrożeniach Cloudflare niż z kryptowalutowych legend.

Solana zachowuje się jak sieć, która spodziewa się ataków i zdecydowała, że to atakujący powinien pierwszy się zmęczyć.

Artykuł How Solana neutralized a 6 Tbps attack using a specific traffic-shaping protocol that makes spam impossible to scale pojawił się najpierw na CryptoSlate.