Solana a Firedancer – nowy klient walidatora, który ma wyeliminować awarie sieci

Kupuj kryptowaluty BLIKiem ⚡

Błyskawiczne wpłaty bez opłat i prowizji na giełdzie OKX.

Kup krypto z 0% prowizji

Solana a Firedancer to relacja polegająca na wprowadzeniu drugiego, niezależnego oprogramowania węzła, które ma całkowicie wyeliminować problem zatrzymywania się tego łańcucha bloków. Nowy klient walidatora pisany od zera w językach C i C++ przez zespół Jump Crypto usuwa pojedynczy punkt awarii, gwarantując ciągłość działania sieci nawet w przypadku krytycznych błędów w oryginalnym kodzie dostarczanym przez Solana Labs.

Kiedy sieć opiera się na jednym kliencie, każda usterka kładzie cały system. To jest najgorsza opcja z wszystkich. Właśnie dlatego programiści od lat zmagali się z przestojami Solany. Wszyscy operatorzy węzłów uruchamiali dokładnie ten sam kod Rusta. Błąd w logice konsensusu oznaczał natychmiastowe zatrzymanie produkcji bloków. Firedancer zmienia tę matematykę. Zamiast monolitu, mamy dwa różne silniki napędzające ten sam samochód. Awaria jednego nie przerywa jazdy.

Dlaczego Solana tak często ulegała awariom w przeszłości?

Prawda jest zresztą absolutnie taka, że nikt normalny nie chce debugować kodu łańcucha wariującego o trzeciej nad ranem tylko dlatego, że jeden klient nie udźwignął spamu od botów arbitrażowych. Pamiętam luty 2023 roku u nas w biurze. Sieć główna zwolniła niemal do zera. Transakcje wisiały. Komunikatory pękały od pytań o to, co się dzieje z siecią. Problem leżał u samych podstaw architektury. Solana została zaprojektowana na sterydach. Przetwarza ogromne ilości danych w czasie rzeczywistym. Brak tradycyjnego mempoola, w którym transakcje czekają na weryfikację, powoduje gwałtowne uderzenia ruchu prosto w lidera bloku.

Oryginalny klient walidatora nie zawsze radził sobie z alokacją pamięci i zarządzaniem pakietami sieciowymi. Kiedy boty uderzały z siłą milionów zapytań na sekundę podczas premiery popularnego tokena NFT, węzły po prostu dławiły się ruchem. Zjadały całą dostępną pamięć RAM i wyłączały się z powodu braku zasobów (Out of Memory). Ponieważ wszystkie węzły działały na tym samym oprogramowaniu, usterka propagowała się błyskawicznie po całej sieci.

Aby zrozumieć ten mechanizm, trzeba spojrzeć na to, jak oprogramowanie radzi sobie z siecią. W tradycyjnych systemach pakiety danych przechodzą przez jądro systemu operacyjnego Linux. To dodaje opóźnienia. W Solanie te opóźnienia są zabójcze. Zmieniliśmy te zasady na robocie, wprowadzając protokół QUIC, żeby lepiej filtrować ruch. To pomogło. Ale nie wyeliminowało głównego wektora ataku. Brak różnorodności klientów (client diversity) mścił się przy każdym większym obciążeniu.

Co to jest klient walidatora i dlaczego Solana miała tylko jednego?

Klient walidatora to po prostu program. Kawałek kodu, który pozwala serwerowi połączyć się z siecią blockchain, pobierać bloki, weryfikować podpisy kryptograficzne i głosować nad stanem sieci. Bitcoin ma Bitcoin Core. Ethereum ma Geth, Nethermind, Besu i Teku. Ta wielość klientów w Ethereum ratowała im skórę wielokrotnie. Gdy Geth miał błąd, sieć działała dalej na Nethermindzie.

Solana wystartowała z jednym klientem napisanym w języku Rust przez zespół Anatolija Jakowienki. Powód był prosty. Czas i pieniądze. Zbudowanie tak skomplikowanego systemu od zera wymaga lat pracy wybitnych inżynierów. Solana Labs musiało szybko dostarczyć działający produkt na rynek. Napisali go sami. Przez długi czas nikt inny nie miał wystarczającej wiedzy o wewnętrznych mechanizmach działania tego łańcucha, żeby podjąć się stworzenia alternatywy. Dokumentacja była niepełna. Kod źródłowy zmieniał się zbyt szybko.

P O L E C A M Y:

Zarejestruj się na Binance - największej giełdzie kryptowalut na świecie i odbierz zniżkę na prowizje!

Odbierz zniżkę

Brak drugiego klienta to ryzyko systemowe. Kiedy masz tylko jedno oprogramowanie, staje się ono definicją prawdy w sieci. Jeśli oryginalny klient Solany zawiera usterkę powodującą błędne obliczenie stanu konta, cała sieć uznaje ten błąd za fakt. Nie ma drugiego systemu, który mógłby powiedzieć “zaraz, moje obliczenia dają inny wynik, zatrzymajmy konsensus”.

Czym dokładnie jest Firedancer i kto za nim stoi?

Za ten projekt odpowiada Jump Crypto. To ramię firmy Jump Trading, giganta z rynku tradycyjnych finansów (TradFi) zajmującego się handlem wysokiej częstotliwości (HFT). Ci ludzie jedzą opóźnienia sieciowe na śniadanie. Zbudowali biznes na urywaniu mikrosekund w przesyłaniu danych giełdowych między Chicago a Nowym Jorkiem. Wiedzą dokładnie, jak wyciskać z krzemu siódme poty. Zdecydowali się zbudować drugiego klienta dla Solany od absolutnych podstaw.

To nie jest fork. To nie jest kopia kodu z Rusta przetłumaczona na inny język. To inżynieria wsteczna i napisanie każdego komponentu na nowo. Firedancer jest w dużej mierze pisany w języku C i C++. Dlaczego te języki? Bo dają absolutną, brutalną kontrolę nad zarządzaniem pamięcią i sprzętem. Nie ma tu tak zwanego garbage collectora, który nagle wstrzymuje działanie programu, żeby posprzątać nieużywaną pamięć. W świecie milisekundowych czasów bloku Solany, taka pauza to wyrok śmierci dla wydajności.

Jump Crypto podeszło do sprawy jak do budowy systemu giełdowego. Rozbili proces walidacji bloku na mikroskopijne kroki. Weryfikacja podpisów (Ed25519). Propagacja paczek danych (Turbine). Wykonywanie kontraktów (Sealevel). Każdy z tych elementów został napisany tak, aby maksymalnie wykorzystać architekturę nowoczesnych procesorów wektorowych AVX-512.

Jakie technologie programistyczne odróżniają Firedancera od oryginalnego klienta?

Największa różnica leży w warstwie sieciowej. Standardowy klient Solany przyjmuje pakiety z karty sieciowej do jądra systemu operacyjnego (kernel space). Następnie Linux kopiuje te dane do przestrzeni użytkownika (user space), gdzie działa klient walidatora. To kopiowanie kosztuje cykle procesora. Przy ruchu rzędu gigabitów na sekundę, procesor dławi się samym przenoszeniem danych z miejsca na miejsce.

Firedancer używa technologii AF_XDP. To ominięcie całego stosu sieciowego Linuxa. Karta sieciowa wrzuca pakiety bezpośrednio do pamięci programu Firedancer. Zero kopiowania. Zero udziału jądra systemu w routingu. Oprogramowanie natychmiast analizuje bajty. To drastycznie obniża zużycie procesora i pozwala maszynie skupić się na kryptografii zamiast na logistyce plików.

Kolejna sprawa to architektura kafelkowa. Zespół Jump Crypto podzielił Firedancera na odizolowane procesy zwane kafelkami (tiles). Jeden kafelek zajmuje się tylko odbieraniem sieci. Inny tylko weryfikacją podpisów. Komunikują się one ze sobą za pomocą niesamowicie szybkich kolejek w pamięci współdzielonej, bez użycia tradycyjnych blokad (lock-free queues). Jeśli jeden komponent dostaje czkawki, nie blokuje całego potoku przetwarzania.

W jaki sposób nowy klient walidatora wyeliminuje przestoje sieci Solana?

Mechanizm ratunkowy opiera się na rozbiciu monopolu. Załóżmy, że obecnie 100% węzłów działa na kliencie od Solana Labs. Wychodzi nowa aktualizacja. Zawiera ukryty błąd w maszynie wirtualnej Sealevel. Atakujący wysyła specjalnie spreparowaną transakcję. Wszystkie węzły próbują ją przetworzyć, natrafiają na błąd i wywołują panikę (panic) w kodzie Rusta. Węzły gasną. Sieć staje.

Teraz wprowadzamy Firedancera. Zdecydowana większość sieci dzieli się na dwa obozy. Około 50% operatorów uruchamia klienta w C++, a 50% zostaje przy starym w Ruście. Atakujący wysyła tę samą, złośliwą transakcję.

• Węzły na Ruście padają natychmiast, wyrzucając błąd pamięci.
• Węzły na C++ analizują pakiet. Kod Firedancera był pisany niezależnie. Nie ma w nim tego samego błędu w logice maszyny wirtualnej. Przetwarza transakcję poprawnie lub ją odrzuca. Sieć działa dalej w oparciu o żywe węzły.
• Zmniejsza się przepustowość, ale łańcuch nie umiera.
• Deweloperzy mają czas na spokojne wydanie łatki.

To u nas w sumie chyba hipoteza z wczoraj bo pewności do tych trendów adaptacji nikt obecnie nie ma o 2025 r. Ale matematyka jest nieubłagana. Dwa niezależne systemy rzadko psują się w ten sam sposób w tej samej mikrosekundzie z powodu tego samego bodźca wejściowego.

Warto spojrzeć na proces wdrożeniowy w dużych węzłach. Operatorzy tacy jak Chorus One czy Blockdaemon nie przeskoczą od razu w 100% na nową technologię. Będą działać w trybie hybrydowym. Istnieje projekt o nazwie Frankendancer. To hybryda. Warstwa sieciowa z Firedancera (ta najszybsza), połączona z warstwą wykonawczą ze starego klienta Rusta. To pozwala na bezpieczne, fazowe wprowadzanie nowości na główny łańcuch bez ryzykowania miliardów dolarów ulokowanych w DeFi.

Jak Jump Crypto testuje Firedancera przed wdrożeniem na główną sieć?

Wrzucają go na głęboką wodę. Dosłownie zalewają kod ruchem w środowiskach testnet. Jump uruchamia tysiące wirtualnych instancji, które generują sztuczny, bezlitosny spam na węzły z nowym kodem. Bada się zachowanie pamięci podręcznej L3 w procesorach i śledzi zgubione pakiety UDP.

Zorganizowali też publiczne programy bug bounty. Płacą milionowe nagrody hakerom, którzy znajdą luki w kodzie w C++. Szukanie dziur w C++ to trudny biznes. Język ten jest bezlitosny, jeśli chodzi o wskaźniki i naruszenia pamięci (buffer overflows). Dlatego kod jest na bieżąco audytowany przez zewnętrzne firmy specjalizujące się w cyberbezpieczeństwie niskopoziomowym. Zanim Firedancer uzyska miano w pełni gotowego do obsługi głównego łańcucha (Mainnet Beta), miną miesiące rygorystycznych testów równoległych. Węzły na testnecie uruchamiają obydwa klienty obok siebie i weryfikują, czy po milionach transakcji ich stan (hash stanu kont) zgadza się co do jednego bita.

Czy Firedancer faktycznie podniesie przepustowość Solany do miliona TPS?

Szczerze mówiąc, milion TPS na produkcji to na razie bajka dla inwestorów z Twittera. Owszem, Firedancer osiągnął 1.2 miliona TPS w izolowanym środowisku testowym. Ale testy laboratoryjne rzadko przekładają się w skali 1:1 na brutalną rzeczywistość rozproszonego internetu. W laboratorium masz idealne kable światłowodowe, cztery serwery obok siebie i wyłączoną kryptografię o wysokim stopniu złożoności.

P O L E C A M Y:

Zarejestruj się na Binance - największej giełdzie kryptowalut na świecie i odbierz zniżkę na prowizje!

Odbierz zniżkę

W prawdziwym świecie sieć składa się z ponad 3000 walidatorów rozsianych od serwerowni w Niemczech po garaże w Teksasie. Prędkość światła staje się fizycznym limitem. Nie prześlesz bloku z Europy do Australii szybciej niż pozwalają na to podmorskie kable. Zresztą zastanawiacie się dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Zrobiłem test pingów między różnymi chmurami AWS. Opóźnienia rzędu 150 milisekund to standard. W tym czasie Solana musi osiągnąć konsensus i zamknąć blok.

Realistycznie, Firedancer drastycznie poprawi zdolność sieci do obrony przed atakami DDoS i spamem. Zwiększy realną, użyteczną przepustowość z obecnych kilku tysięcy do może 50 000 – 100 000 prawdziwych transakcji na sekundę (nie licząc prostych głosowań walidatorów). To i tak będzie potężny wynik. Zrobi z Solany łańcuch o rzędy wielkości szybszy niż cokolwiek innego na rynku. Pozwoli to na w pełni on-chainowe księgi zleceń (orderbooks) giełd kryptowalutowych, które będą działać równie płynnie co scentralizowane serwery Binance czy Coinbase.

Wydajność Firedancera zmienia również wymagania sprzętowe. Oryginalny klient dusi się nawet na procesorach AMD Threadripper z 64 rdzeniami przy wielkim obciążeniu sieciowym. Optymalizacja kodu w Firedancerze sprawia, że ten sam sprzęt będzie miał ogromny zapas mocy. Procesor będzie zużywał 20% zasobów zamiast 90%. To obniża koszty chłodzenia, zużycia prądu i wydłuża żywotność dysków NVMe, które w Solanie są katowane ciągłym zapisem stanu (AccountsDB).

Co wdrożenie drugiego klienta oznacza dla zwykłych inwestorów i deweloperów DApps?

Deweloperzy w końcu odzyskają sen. Budowanie aplikacji w ekosystemie, który co kilka miesięcy stawał w miejscu na 12 godzin, było frustrujące. Każdy przestój oznaczał panikę na rynku, gwałtowne spadki cen tokenów i konieczność ręcznego resetowania klastrów. Stabilność to fundament adopcji instytucjonalnej. Banki i fundusze płatnicze typu Visa nie zbudują swoich systemów na infrastrukturze, która może po prostu zgasnąć w środku wtorkowej sesji handlowej.

Firedancer usuwa argument o braku stabilności z rąk krytyków Solany. To bezpośrednie uderzenie w narrację konkurencyjnych łańcuchów warstwy drugiej (Layer 2) na Ethereum. Jeśli Solana osiągnie 100% czasu bezawaryjnego działania (uptime) przez dwa lata po wdrożeniu nowego klienta, zmieni układ sił na rynku smart kontraktów.

Dla inwestorów detalicznych zmiana będzie niewidoczna na pierwszy rzut oka. Transakcje z portfeli Phantom czy Solflare będą po prostu przechodzić bez opóźnień, nawet gdy po sieci rozleje się mania na nową kolekcję meme-coinów generującą terabajty śmieciowego ruchu. Brak przerw w działaniu to mniejsze ryzyko likwidacji pozycji na rynkach lewarowanych. Kiedy sieć staje, nie możesz dodać zabezpieczenia do swojej pożyczki DeFi. Wyrocznie cenowe (oracles) przestają aktualizować ceny. Gdy sieć rusza ponownie, dochodzi do kaskadowych likwidacji majątków po starych cenach. Firedancer przecina ten chory schemat u samego źródła.

Ten kod to twardy dowód, że ekosystem dojrzał. Przestajemy polegać na jednej firmie z San Francisco. Wchodzimy w fazę prawdziwie rozproszonego rozwoju oprogramowania bazowego. Uderzaj do przodu z własnym węzłem, podłącz go do testnetu i zobacz na własne oczy, jak w terminalu logi przetwarzają pakiety z prędkością, której stary kod Rusta nigdy nie widział na oczy. Przestań czytać obietnice z białych ksiąg, a zacznij patrzeć na zużycie procesora w htop na serwerze.

Często zadawane pytania (FAQ)

• 1. Czy Firedancer zastąpi całkowicie obecnego klienta Solany?
  Nie. Celem jest współistnienie obu klientów w sieci. W idealnym scenariuszu węzły będą podzielone między oprogramowanie Solana Labs (Rust) a Jump Crypto (C++), co zminimalizuje ryzyko globalnej awarii w przypadku błędu w jednym z nich.
• 2. Kiedy Firedancer zostanie uruchomiony na głównej sieci (Mainnet)?
  Proces wdrażania jest wieloetapowy. Firedancer działa już na sieciach testowych (testnet). Wersje hybrydowe (Frankendancer) pojawiają się u operatorów stopniowo. Pełne, produkcyjne wdrożenie przewiduje się na końcówkę 2024 lub początek 2025 roku, po zakończeniu wszystkich rygorystycznych audytów bezpieczeństwa.
• 3. Skąd pochodzi finansowanie projektu Firedancer?
  Projekt jest tworzony i finansowany przez Jump Crypto, dział kryptowalutowy dużej firmy tradingowej Jump Trading. Mają oni bezpośredni interes w posiadaniu ekstremalnie szybkiej i stabilnej sieci do realizacji swoich strategii handlowych.
• 4. Czy Firedancer zmniejszy opłaty transakcyjne na Solanie?
  Opłaty na Solanie są już ułamkiem centa. Nowy klient nie ma na celu ich dalszego obniżania u podstawy. Zwiększy jednak przepustowość, co zapobiegnie drastycznym skokom opłat priorytetowych (priority fees) w momentach ogromnego przeciążenia sieci.
• 5. Jakie wymagania sprzętowe ma nowy klient Jump Crypto?
  Dzięki ominięciu jądra systemu Linux i lepszemu zarządzaniu pamięcią podręczną procesora, Firedancer potrafi przetworzyć więcej transakcji na tym samym sprzęcie co stary klient. Może to w przyszłości obniżyć barierę wejścia dla nowych walidatorów i pomóc w decentralizacji sprzętowej łańcucha.
• 6. Co to jest architektura kafelkowa (Tile architecture)?
  To model programistyczny izolujący różne zadania walidatora. Zamiast jednego wielkiego procesu, oprogramowanie dzieli się na małe jednostki. Jedna zajmuje się siecią, inna kryptografią, a kolejna logiką kontraktów. Porażka jednego kafelka nie powoduje awarii całego programu.

Bibliografia

1. Solana Foundation – https://solana.com
2. Jump Crypto – https://jumpcrypto.com
3. GitHub Repository (Solana) – https://github.com
4. CoinMarketCap Research – https://coinmarketcap.com
5. Messari Crypto Data – https://messari.io

Kupuj kryptowaluty BLIKiem ⚡

Błyskawiczne wpłaty bez opłat i prowizji na giełdzie OKX.

Kup krypto z 0% prowizji