Konkurs bezpieczeństwa Solany o puli 50 000 SOL nie objął ataku na zegar ujawnionego miesiące wcześniej

Podczas konferencji USENIX Security, jednej z głównych recenzowanych konferencji w tej dziedzinie, badacze 12 sierpnia przedstawili atak na zegar Proof-of-History sieci Solana, który wcześniej, w grudniu 2025 r., zgłosili prywatnie programistom Solany. Anza — firma rozwijająca klienta walidatora Agave — zamknęła siedem dni później swój konkurs Alpenglow z pulą 50 000 $SOL, a jego regulamin, jak się wydaje, umieszczał ten atak poza zakresem.

Artykuł opisuje zgodną z protokołem metodę, dzięki której zaplanowany lider może wydłużyć swoje efektywne okno blokowe i stłumić propozycje uczciwych liderów w wariancie wspomaganym forkiem. Technika opiera się na Proof-of-History i TowerBFT — logicznym zegarze Solany oraz zbudowanym na nim mechanizmie konsensusu — czyli komponentach, które Alpenglow ma zastąpić, ale które w Agave 4.2 nie zostały jeszcze wyparte z mainnetu.

Wynik rodzi dwa odrębne zagadnienia: czy atak mieścił się w zakresie konkursu oraz czy samo przejście protokołu pozostawia przestrzeń dla ryzyka.

Regulamin konkursu wykluczał zachowania osiągalne wyłącznie wtedy, gdy Alpenglow było nieaktywne. Publiczne dokumenty projektowe wskazują, że dokładna starsza ścieżka opisana w artykule powinna stać się nieosiągalna po aktywacji, jednak Anza i Solana Foundation nie opublikowały rozstrzygnięcia ani analizy implementacji odnoszących się konkretnie do tego artykułu.

Jak lider może rozciągnąć zegar Solany

Proof-of-History, w skrócie PoH, wykorzystuje sekwencyjny łańcuch skrótów, aby zapewnić Solanie zegar logiczny. Walidatory nadal posuwają naprzód swój lokalny obraz tego zegara, gdy zaplanowany lider nie publikuje natychmiast bloku.

Według badaczy złośliwy zaplanowany lider może wstrzymać blok zgodny z protokołem, podczas gdy uczciwe walidatory posuwają się naprzód, a później opublikować blok zakotwiczony we wcześniejszym punkcie czasu logicznego. Jeśli walidatory zaakceptują tę gałąź, dopasują swój stan PoH do wcześniejszego punktu bloku. Badacze nazywają ten reset „re-anchoring”, czyli ponownym zakotwiczeniem.

Time Inflation (TI) powtarza ten manewr, dając atakującemu więcej czasu fizycznego na wybór transakcji, podczas gdy czas logiczny posuwa się wolniej. Fork-Assisted Time Inflation (FTI) łączy ten reset z regułą wyboru forka TowerBFT.

W zamodelowanych warunkach gałąź atakującego może osierocić blok uczciwego lidera, a zasada jednego bloku na slot w Solanie uniemożliwia temu liderowi po prostu wygenerowanie kolejnego bloku dla tego samego slotu.

Model zagrożeń przyznaje przeciwnikowi mniej niż 33% staku — czyli mniej niż jedną trzecią, granicę błędów, którą protokoły odporne na błędy bizantyjskie są zgodnie z przyjętą praktyką projektowane tolerować — oraz nie daje mu kontroli nad planistą sieci. Zakłada on znany, ważony stakiem harmonogram liderów, częściową synchroniczność oraz dostarczenie uczciwego bloku do uczciwych walidatorów w ciągu jednego nominalnego slotu po ustabilizowaniu się sieci.

Dla atakującego kontrolującego ℓ kolejnych czteroslotowych rund lidera eksperymenty stosują konserwatywne, niezależne od staku maksymalne opóźnienie wynoszące 4ℓ + 1 jednostek slotu. Jedna runda odpowiada parametrowi opóźnienia o wartości pięciu jednostek slotu.

Artykuł mówi, że większy stake mógłby poszerzyć bezryzykowne okno publikacji, ale nie przedstawia tego ustawienia eksperymentalnego jako uniwersalnego wyniku dla mainnetu.

Badacze zaimplementowali TI i FTI na lokalnym testnecie Solany oraz wykorzystali symulacje dla konfiguracji atakującego obejmujących pełną epokę. Nie wskazali konkretnej, dotkniętej wersji Agave, dlatego artykuł nie przesądza, że każda bieżąca wersja klienta jest narażona w ten sam sposób.

Co pokazują dane publiczne

Badacze przeanalizowali również publiczne dane z mainnetu i wybrali dwa walidatory, które wielokrotnie plasowały się w ogonie rozkładu interwałów znaczników czasu. Walidatory te łączyły dłuższe interwały z wyższym poziomem włączania transakcji do bloków i niskim wskaźnikiem pominięć.

Wzorzec ten jest spójny z kanałem bodźców TI, ponieważ dłuższe okno fizyczne tworzy więcej okazji do wybierania transakcji niosących opłaty — przewagi w zakresie ustalania kolejności transakcji, jaką branża szeroko omawia pod pojęciem maximal extractable value, czyli MEV.

Według artykułu podobne wzorce czasowe mogłyby również wywoływać różnice sprzętowe, lokalne grupowanie transakcji lub inne wybory konfiguracyjne, warunki sieciowe oraz zakłócenia operacyjne. Badacze nie stwierdzili też istotnie podwyższonego wskaźnika pominięć w kolejnych slotach i ocenili, że zaobserwowany wzorzec jest niespójny z przypisaniem go do FTI.

Badanie dokumentuje, poprzez kontrolowane testy i sugestywne pomiary, kwestię sprawiedliwości i opóźnień zgodną z protokołem. Nie pokazuje natomiast działającego exploita, kradzieży, wykazanej manipulacji na mainnecie ani złamania bezpieczeństwa konsensusu.

Dlaczego konkurs Solana Alpenglow prawdopodobnie go wykluczył

Zgłoszenia do konkursu Alpenglow zamknięto 19 sierpnia o 16:00 UTC. Regulamin obejmował powierzchnię konsensusu z aktywną funkcjonalnością Alpenglow, kod integracyjny, którego zachowanie zmieniło się z powodu aktywacji Alpenglow, oraz ścieżkę migracji z TowerBFT do Alpenglow.

Zachowania osiągalne wyłącznie przy nieaktywnym Alpenglow należały do domeny TowerBFT i znajdowały się poza konkursem. Kwestie wcześniej publicznie znane również nie kwalifikowały się do zgłoszenia.

Ta luka to znany problem w ograniczonych czasowo konkursach bezpieczeństwa: o tym, co zostaje wynagrodzone, decydują reguły zakresu, a nie waga błędu. Konkurs obejmował usterki powodowane przez Alpenglow lub jego migrację, podczas gdy artykuł wymierza w starszy model czasu i wyboru forka, który Alpenglow ma zastąpić.

Co zmienia Alpenglow

Przegląd Alpenglow przygotowany przez Anzę mówi, że ulepszenie zastępuje TowerBFT i PoH jako podstawowe komponenty konsensusu mechanizmem Votor. Oficjalna propozycja SIMD-0326 — dokument ulepszeń Solany w formalnym procesie zmian w sieci — opisuje lokalne limity czasu pełniące rolę czasową bez zsynchronizowanego czasu i określa tę zmianę jako niekompatybilną wstecz.

Projekty te usuwają przesłanki TI i FTI: ponowne zakotwiczenie PoH oraz wybór forka TowerBFT. Publiczny zapis nie obejmuje analizy Anzy ani Solana Foundation, która mapowałaby każdy krok ataku na wydany kod Alpenglow albo wykluczała analogiczny problem w logice migracji.

Według badaczy zespół programistów Solany odpowiedział w ciągu jednego dnia od zgłoszenia z grudnia 2025 r. Artykuł mówi, że zespół traktował to zachowanie jako znane wewnętrznie, spodziewał się, że rozwiąże je przyszłe ulepszenie protokołu, takie jak Alpenglow, je monitorował i uważał najbardziej dotkliwe scenariusze za mało prawdopodobne w bieżących warunkach.

Autorzy dodali, że do momentu publikacji nie wdrożyli w pełni środków zaradczych.

Przegląd Agave 4.2 opublikowany przez Solana Foundation mówił, że klient zawierał kod Alpenglow dla społecznościowych klastrów testowych, ale nie aktywował nowego konsensusu na mainnecie, a aktywację przewidywano w Agave 4.3.

Atak na starszy mechanizm PoH opisany w artykule najwyraźniej wypadł poza konkurs z pulą 50 000 $SOL, a Alpenglow zaprojektowano tak, aby usunąć jego dokładne przesłanki. Do czasu aktywacji — przewidywanej w Agave 4.3 — oraz publicznej odpowiedzi na poziomie implementacji przejście pozostaje nierozstrzygniętą częścią tej historii.