Solana zabrakło zaledwie 14 punktów procentowych do całkowitego wstrzymania sieci we wczesnych godzinach porannych w środę, 12 sierpnia, po tym jak 28,83% staked SOL w sieci wypadło z konsensusu w następstwie awarii infrastruktury u dostawcy usług hostingowych Teraswitch. Ten incydent podkreśla rzadziej omawiane ryzyko w sieciach proof-of-stake: podczas gdy inżynieria protokołów i różnorodność klientów otrzymują dużą uwagę, operatorzy walidatorów często grupują się wokół tych samych dostawców hostingowych, co oznacza, że pojedyncza awaria w warstwie infrastruktury może szybko popchnąć łańcuch w kierunku jego teoretycznego punktu zatrzymania.

Incydent, po raz pierwszy zgłoszony przez protokół stakingowy Marinade Finance, doprowadził sieć w 86% do progu 33,34% niesolidności, powyżej którego Solana nie może już finalizować bloków. Gdyby wartość przekroczyła tę linię, zakończyłoby to 30-miesięczny okres działania (uptime) sieci Solana i odcięło ją od działania.

Jak działa mechanizm wstrzymania konsensusu Solana

Solana przestaje finalizować bloki, gdy więcej niż jedna trzecia (33,34%) wszystkich staked SOL staje się niesolidna. Niesolidność występuje, gdy walidator nagle wypada z składu konsensusu. 12 sierpnia sieć osiągnęła szczyt 28,83% niesolidnego stake'a przed ustabilizowaniem się.

Zgodnie z informacjami od Marinade, wydarzenie dotknęło 90 walidatorów, które łącznie straciły 333 SOL nagród w czasie swoich przestojów. Przy cenie handlowej SOL wynoszącej 76,9 USD w momencie tworzenia raportu, cała sieć Solana mogłaby zostać tymczasowo wstrzymana przez anomalię o wartości około 25 600 USD.

Mimo tego o mało unikniętego wypadku, oficjalna strona statusu Solana nadal zgłasza idealny 100% czas działania klastra (cluster uptime) przez poprzednie 90 dni. Ostatnie całkowite wstrzymanie sieci miało miejsce 6 lutego 2024 r. i trwało około pięciu godzin.

Incydent Teraswitch i jego rozwiązanie

Strona statusu Teraswitch dostarczyła szczegółów dotyczących podstawowej awarii infrastruktury:

"Klienci w lokalizacjach LON1, AMS1, AMS2, AMS3, DUB1, DUB2, FRA2, SGP1, SGP2, TYO1, TYO2 i TYO3 doświadczyli utraty łączności z celami w Internecie, a także z wewnętrznymi celami sieci szkieletowej Teraswitch pomiędzy dotkniętymi lokalizacjami. Inne lokalizacje w Ameryce Północnej nie były dotknięte."

Teraswitch zgłosił, że celowo usunął MIA1 (Miami, FL) ze swojego szkieletu sieci jako część reakcji na problem. Inżynierowie "zidentyfikowali błędnie uformowaną trasę w ciągu 10 minut od początku problemu i usunęli MIA1 ze szkieletu sieci, aby zatrzymać dalsze propagowanie."

Teraswitch potwierdził, że "dotknięte lokalizacje ponownie zbiegły się na swoich lokalnych trasach domyślnych, a usługa została przywrócona o 04:16:15 UTC."

Marinade zauważyło, że wydarzenie to ledwie gdziekolwiek zostało zauważone, pomimo jego wagi.

Wpływ na walidatory

Z 74 walidatorów monitorowanych przez Marinade, tylko trzy odzyskały sprawność bez problemów: laine należący do Solana Strategies, Cogent Crypto oraz Lion3d. Reszta puli walidatorów doświadczyła częściowego przestoju podczas incydentu. Helius, drugi co do wielkości walidator w sieci Solana, był offline przez całe 33-minutowe zakłócenie.

Jeśli chodzi o utracone nagrody w wysokości 333 SOL, Marinade stwierdziło, że straty te poniosą operatorzy walidatorów, pozostawiając stakerów bez żadnego ryzyka.

Historia niezawodności Solana

Na dwa dni przed tym bliskim wypadkiem, Solana Compass poinformował, że Solana osiągnęła 30 kolejnych miesięcy bez całkowitej awarii sieci. Poprzednia awaria z 6 lutego 2024 r. została prześledzona do błędu w pamięci podręcznej LoadedPrograms JIT, który wymuszał na walidatorach powtórzoną rekompilację, aż do zablokowania konsensusu na jednym bloku. Anza załatał ten błąd, a łańcuch wznowił działanie po około pięciu godzinach.

Poprawa niezawodności Solana w latach 2023 i 2024 została przypisana trzem kluczowym aktualizacjom: warstwa transportowa QUIC z usługą jakości ważoną stakiem w celu ograniczania spamu, rynek opłat priorytetowych, który stanowi obecnie około 88% dziennych przychodów z opłat, oraz Firedancer, niezależny klient walidatora opracowany przez Jump Crypto, który trafił do sieci głównej (mainnet) pod koniec 2025 roku. Dodanie drugiej implementacji klienta oznacza, że błąd w jednej bazie kodu nie ma już możliwości zatrzymania całej sieci. Jednakże bliski wypadek z Teraswitch pokazuje, że koncentracja infrastruktury u wspólnych dostawców hostingu stanowi odrębny wektor awarii, którego sama różnorodność klientów nie rozwiązuje – wyzwanie, z którym mierzą się ogólnie łańcuchy proof-of-stake, a nie tylko Solana.