Solana był 4,5 punkta procentowego od zatrzymania — a uptime trzymał się na 100%
Najważniejsze informacje
- •Awaria TeraSwitch 12 sierpnia odłączyła około 90 walidatorów z około 29% postawionego SOL, zatrzymując finalizację na około 30 minut, podczas gdy sieć pozostawała tuż powyżej progu dwóch trzecich głosów wymaganych do finalizacji bloków.
- •Październikowy raport FCAT wymienia 18–20 tożsamości walidatorów kontrolujących ponad trzecią część stakingu Solany, skoncentrowanych w dwóch krajach, na dwóch sieciach hostingowych i dwóch bazowych implementacjach klientów — zatrzymanie mogłoby więc nastąpić bez żadnego ataku.
- •Program delegacji Solana Foundation, wymagający utrzymywania udziału sieci hostingowej poniżej 25%, obejmował około 51% walidatorów, ale tylko około 4% aktywnego stakingu w trzecim kwartale, pozostawiając największą sieć powyżej limitu.
- •Aktualizacja Alpenglow, aktywująca 21 października w epoce 1064, ma skrócić finalizację z około 12,8 sekundy do około 150 milisekund, ale nic nie zmienia w miejscu hostowania walidatorów ani w wyborze dostawców je łączących.
- •Alpenglow tymczasowo zawęża różnorod klientów, wyłączając Firedancer i Frankendancer podczas migracji, a usunięcie transakcji głosujących z bloków zmusi narzędzia monitorujące do pobierania danych o uczestnictwie z certyfikatów w stopce bloku.

Podczas incydentu 12 sierpnia około 90 walidatorów Solany posiadających około 29% postawionego SOL straciło łączność, a finalizacja bloków trwała do około 30 minut zamiast zwykłych 13 sekund — zgodnie z analizą incydentu przygotowaną przez Metrikę.
A jednak Solana nigdy nie stanął. Bloki były dalej produkowane, a wykres uptime za ten dzień pokazałby zwykłą sesję. W środę 21 października sieć ma aktywować Alpenglow — aktualizację, której celem jest finalizacja na poziomie około 150 milisekund — ale nic w niej nie rozwiązuje problemu hostingu, który doprowadził do niemal zatrzymania. Opublikowany 16 października raport badawczy jednostki FCAT firmy Fidelity, The State of Solana: Network Health and Resilience, szacuje udział największej sieci hostingowej na około 29% stakingu — blisko udziału, który według Metriki przeszedł offline.
Co wydarzyło się 12 sierpnia
Solana może sfinalizować blok — moment, w którym transakcja staje się nieodwracna — tylko wtedy, gdy ponad dwie trzecie postawionego SOL głosuje, a proces ten zwykle trwa około 13 sekund. 12 sierpnia, przy około 71% stakingu wciąż online, sieć pozostała powyżej tej granicy, ale tylko o włos. Metrika podaje udział offline na 28,83%, wobec poziomu 33,34%, przy którym finalizacja zatrzymuje się w całym łańcuchu.
Wykres: udział postawionego SOL offline 12 sierpnia na tle linii zatrzymania finalizacji. Źródło: Metrika.
Według Metriki kolejne cztery-pięć punktów procentowych stakingu na dotkniętych trasach oznaczałoby zatrzymanie całej sieci wymagające skoordynowanego odzyskiwania. Awaria rozpoczęła się w centrum danych TeraSwitch w Miami i rozprzestrzeniła się na infrastrukturę walidatorów w Londynie, Amsterdamie, Frankfurcie, Singapurze i Tokio, a w większości przypadków systemy zapasowe dotkniętych walidatorów nigdy się nie uruchomiły.
TeraSwitch usunął usterkę około dziesięć minut po jej zdiagnozowaniu, a ruch został przywrócony o 04:16 UTC, 33 minuty po jego rozpoczęciu. Walidatory odzyskały sprawność w ciągu kolejnych 40 minut. W tym czasie udział zaplanowanych slotów bez bloku wzrósł powyżej 32%, z poziomu poniżej 1%. Liczba transakcji innych niż głosy spadła z około 1100–1300 na sekundę do poniżej 300. Przez około pół godziny żaden blok nie został sfinalizowany, a zaległości zostały potem przetworzone w serii uderzeń, ze średnim czasem od wyprodukowania do finalizacji wynoszącym około 1600 sekund.
Jedyną liczbą, która się nie zmieniła, był uptime, utrzymany na 100%, ponieważ łańcuch nigdy nie przestał produkować bloków. Przez około pół godziny nikt jednak nie potrafił powiedzieć, kiedy płatność stanie się nieodwracalna. Metrika, która sprzedaje platformę do zarządzania ryzykiem aktywów cyfrowych i korzysta tu z własnych wskaźników, traktuje opóźnienie finalizacji — a nie przestój — jako zdarzenie mające znaczenie dla każdego, kto rozlicza środki na Solanie.
Co zatrzymany łańcuch by oznaczał — i czego by nie oznaczał
Ryzyko opisane przez FCAT to zatrzymana finalizacja i możliwa cenzura. Koalicja posiadająca ponad jedną trzecią stakingu mogłaby uniemożliwić reszcie osiągnięcie dwóch trzecich potrzebnych do finalizacji — czytamy w raporcie — ale nie zyskałaby nieograniczonej kontroli nad aktywami użytkowników ani zdolności do przepisywania sfinalizowanych transakcji. Awaria hostingu usuwająca ten sam udział stakingu zatrzymałaby finalizację bez żadnego ataku.
Taki udział nie jest trudny do osiągnięcia. FCAT liczy około 20 tożsamości walidatorów (18 w innym fragmenc) posiadających ponad trzecią część stakingu i wskazuje, że ta trzecia część znajduje się w dwóch krajach, na dwóch sieciach hostingowych i dwóch bazowych implementacjach klientów. To konta głosujące, a niezależne organizacje: Figment na przykład prowadzi dwa z pięciu największych walidatorów w tej grupie. Ogólna ocena FCAT jest pozytywna — przywołuje ponad dwa lata bez poważnej awarii mainnetu, średnią skuteczność głosowania około 99,7% w 2026 roku oraz powoli dywersyfikujący się stos oprogramowania. Za rzecz wymagającą dalszej obserwacji uznaje koncentrację. FCAT to jednostka badań technologii stosowanych firmy Fidelity i sama prowadzi niewielki walidator Solany.
Dwa miesiące później udział nadal wynosi około 29%
Październikowy snapshot FCAT szacuje udział największej sieci hostingowej na około 29% stakingu. Obie liczby mierzą co innego — staking offline podczas awarii i udział sieci w całym stakingu — ale prowadzą do tego samego wniosku. FCAT informuje, że Solana Foundation już wcześniej pracowała nad zmniejszeniem dominacji TeraSwitch. Oto jak rozkładają się jej liczby — od osób prowadzących walidatory po uruchamiany przez nie kod:
- 18–20 operatorów — tożsamości walidatorów posiadające ponad trzecią część stakingu. To konta głosujące, nie niezależne organizacje; Figment prowadzi dwa z pięciu największych w tej grupie.
- ~40% lokalizacja — udział stakingu we Frankfurcie i Amsterdamie. To szacunek na podstawie geolokalizacji IP, który według FCAT może być niedokładny; około 59% przypada na Niemcy, Holandię i USA.
- ~29% dostawca sieci — udział stakingu w jednej sieci hostingowej, według październikowego snapshotu. Walidatory w różnych miastach mogą korzystać z tego samego dostawcy, a walidatory w jednym mieście — z różnych.
- ~63% oprogramowanie — udział stakingu uruchamiającego oprogramowanie oparte na Jito w trzecim kwartale, kolejne 26% korzystało z Harmonic. Większość konfiguracji w dalszym ciągu współdzieli kod Agave, więc jedna luka mogłaby dotknąć je wszystkie jednocześnie.
Źródło: FCAT, The State of Solana: Network Health and Resilience (październik 2026).
Walidatory klastrowe mają swoje uzasadnienie. Opóźnienie premiuje bliskość innych węzłów — zauważa FCAT — a wyspecjalizowani operatorzy tacy jak TeraSwitch i Latitude budują sprzęt pod obciążenia Solany. Operatorzy mają pewne zabezpieczenia: przełączanie awaryjne, zasilanie zapasowe i prywatne sieci jak DoubleZero, które ograniczają zależność od publicznego internetu. Fundacja utworzyła na początku 2026 roku także sieć reagowania na incydenty, SIRN. 12 sierpnia jednak większość systemów zapasowych nigdy się nie uruchomiła.
Limit Fundacji obejmuje około 4% stakingu
Główną zasadę ustala program delegacji Solana Foundation. Od 1 maja 2026 roku walidatory chcące otrzymać staking od Fundacji muszą działać w sieci hostingowej o udziale poniżej limitu 25% oraz w centrum danych o udziale poniżej 15%. Walidator, który nie spełni wymogów, traci delegację Fundacji do czasu ponownego zaliczenia.
Limity weszły w życie trzy miesiące przed sierpniową awarią, a według październikowego snapshotu FCAT największa sieć wciąż znajdowała się powyżej limitu. Drugą połową problemu jest zasięg programu. W trzecim kwartale obejmował on delegacjami około 51% walidatorów, ale te delegacje stanowiły około 4% aktywnego stakingu. Zasada daje walidatorom powód do dywersyfikacji, ale nie obejmuje pozostałego stakingu.
Październikowe dane FCAT szacują udział największej sieci hostingowej na około 29% stakingu — powyżej limitu 25% Fundacji — podczas gdy program Fundacji zdelegował około 4% aktywnego stakingu na koniec trzeciego kwartału.
Co naprawia Alpenglow — a czego nie
Alpenglow uruchamia się na mainnecie w epoce 1064, która według Solany rozpocznie się około 15:00 UTC w środę 21 października; Anza, zespół stojący za klientem Agave, podawał godzinę około 14:50. Stary system głosowania działa przez pierwsze 5000 slotów, około 18 minut, a nowy przejmuje przy slocie 459 653 000. Finalizacja ma spaść z około 12,8 sekundy do około 150 milisekund — liczby, którą Solana opisuje jako oczekiwanie, a nie stałą. Portfele i aplikacje działają dalej tak jak dotychczas.
Aktualizacja nie robi nic w kwestii problemu hostingu. Szybsze głosowanie skraca czas dochodzenia do porozumienia, ale nic na stronie aktualizacji Solany nie zmienia miejsca, w którym działają walidatory, ani dostawcy, który ich łączy.
Na razie zawęża też różnorodność oprogramowania. Walidatory muszą uruchamiać Agave, Jito-Solana lub Harmonic Salsa w wydaniu opartym na Agave 4.3.0. Firedancer i Frankendancer nie są obsługiwane podczas migracji, a strona Solany nie podaje daty, kiedy to się zmieni. Firedancer to niezależna baza kodu, którą FCAT nazywa najważniejszym krokiem Solany w stronę niezależnej różnorodności klientów. Walidatory muszą też posiadać w koncie głosującym co najmniej 0,8 SOL powyżej minimum zwalniającego z opłaty za przechowywanie (rent-exempt), inaczej nie będą głosować ani produkować bloków w następnej epoce.
- Przed — od teraz do około 14:50–15:00 UTC, 21 października: operatorzy Firedancer i Frankendancer przechodzą na klienta opartego na Agave, a każdy głosujący walidator posiada 0,8 SOL powyżej rent-exempt w koncie głosującym.
- W momencie przełączenia — rozpoczyna się epoka 1064: stary system głosowania działa przez pierwsze 5000 slotów, około 18 minut, a Alpenglow przejmu przy slocie 459 653 000.
- Po — co zmienia się w danych: transakcje głosujące znikają z bloków, więc liczba transakcji spada; stany confirmed i finalized stają się tożsame; a dane o uczestnictwie przenoszą się do certyfikatów w stopce bloku.
Zmienia się też monitorowanie. Analiza Metriki traktuje liczbę głosów na blok jako najbliższy wskaźnik odległości sieci od linii finalizacji, ponieważ głosy są zwykłymi transakcjami zapisywanymi w blokach. Alpenglow usuwa głosy z bloków, a zgodnie z notatkami migracyjnymi Solany każde narzędzie mierzące uczestnictwo walidatorów przez parsowanie transakcji głosujących będzie potrzebowało nowego źródła, ponieważ te dane trafiają do certyfikatów w stopce bloku. Raportowana liczba transakcji również spadnie bez żadnego spadku rzeczywistej aktywności.
Co sprawdzić w tym tygodniu
Jeśli stakujesz SOL: przed delegacją sprawdź, gdzie hostowany jest Twój walidator. Validators.app, źródło używane zarówno przez FCAT, jak i Fundację, śledzi staking według sieci hostingowej i centrum danych. Walidator w największej sieci dzieli ryzyko z sierpnia.
Jeśli budujesz na Solanie: spodziewaj się spadku na dashboardach liczby transakcji i TPS w środę bez zmiany rzeczywistej aktywności. Korzystaj ze stanu confirmed, dopóki Alpenglow nie ruszy, a następnie przechodź na finalized, zgodnie z zaleceniami notatek migracyjnych Solany. Przed aktywacją finalized wciąż oznacza oczekiwanie około 12,8 sekundy. Zweryfikuj wszelkie timeouty i mechanizmy ponawiania dostosowane do tego opóźnienia i śledź czas do finalizacji obok uptime.
Jeśli prowadzisz walidator: jeśli używasz Firedancer lub Frankendancer, przejdź na klienta opartego na Agave przed epoką 1064 i sprawdź, czy konto głosujące posiada 0,8 SOL.
Po środzie warto obserwować dwie liczby: czy udział największej sieci hostingowej spadnie poniżej limitu 25% Fundacji oraz kiedy ponownie będzie obsługiwany Firedancer. Żadna z tych rzeczy nie figuruje w środowym harmonogramie.
Ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady finansowej ani inwestycyjnej.