Firedancer: gdy inżynierowie z parkietu HFT biorą się za blockchain

Zadaj sobie jedno pytanie. Dlaczego sieć, która na papierze miażdży konkurencję przepustowością, potrafiła w 2021 roku stanąć na 17 godzin? Nie przez dziurę w teorii konsensusu. Przez jedną linijkę kodu w jednym kliencie, którym jeździli wszyscy.

To jest cała historia Solany do niedawna — i dokładnie ten problem ma rozwiązać Firedancer, nowy, niezależny klient walidatora pisany od zera w C przez Jump Crypto we współpracy z Solana Foundation. Nie jest to kolejny fork ani łatka. To druga, całkowicie oddzielna baza kodu, zbudowana po to, żeby przetestować fizyczne limity serwera, wyeliminować historyczne przyczyny awarii i — co najważniejsze dla nas, ludzi z rynku — zdywersyfikować oprogramowanie sieci, zanim zrobi to za nas krytyczny bug.

I jeszcze jedno na wstępie. Ludzie, którzy to pisali, nie przyszli ze świata blockchaina. Przyszli z tradingu wysokich częstotliwości, gdzie milisekunda to różnica między zyskiem a stratą. Przenieśli te nawyki jeden do jednego do walidatora. Efekt jest… no właśnie, o tym jest ten tekst.

Skąd się wziął problem: monokultura Rusta

Przez pierwsze lata Solana jechała praktycznie na jednym kliencie. Napisał go pierwotnie Solana Labs w Ruscie, dziś rozwija go Anza pod nazwą Agave. Konstrukcja świetna — dała Solanie przepustowość, o jakiej większość sieci warstwy pierwszej może pomarzyć. Ale miała jedną wadę wpisaną w DNA: cała sieć wisiała na jednej bazie kodu.

Co to znaczy w praktyce, rynek zobaczył na własne oczy. Wrzesień 2021 — 17 godzin przestoju. Kwiecień 2022 — kolejne 7 godzin. Za każdym razem post-mortem pokazywał to samo: protokół konsensusu był w porządku, poległ kod wykonawczy i sieciowy pojedynczego klienta. Jeden błąd, cała sieć w dół.

I tu ważna rzecz, którą wielu myli. Dominujący dziś Jito-Solana — klient, na którym siedzi lwia część stake'u — tego problemu nie rozwiązuje. Jito to nie osobna implementacja protokołu. To fork kodu Rusta z doklejonym mechanizmem aukcji przestrzeni blokowej pod MEV (Maximal Extractable Value). Innymi słowy: Jito i Agave dzielą ten sam kręgosłup. Bug w krytycznej sekcji Rusta kładzie oba klienty jednocześnie. Z punktu widzenia odporności to nie są dwa niezależne silniki — to ten sam silnik w dwóch obudowach.

Dlatego napisanie nowego klienta od zera, w innym języku, to nie fanaberia inżynierów. To ubezpieczenie, którego dojrzała sieć rozproszona po prostu musi mieć.

Architektura HFT w praktyce: kafelki zamiast monolitu

Firedancer wychodzi z założenia, które na parkiecie jest oczywistością: wąskim gardłem nie powinien być twój kod, tylko fizyka — przepustowość magistral, karta sieciowa, RAM. Jeśli procesor czeka na cokolwiek innego niż dane, robisz coś źle.

Jak to osiągnąć? Zamiast jednego wielkiego procesu, Firedancer tnie walidatora na wyspecjalizowane, jednowątkowe moduły — kafelki (tiles). Każdy kafelek robi jedną rzecz i jest na sztywno przypięty (pinned) do konkretnego rdzenia CPU. Żadnego przełączania kontekstu przez system operacyjny, żadnego unieważniania cache'u procesora. Rdzeń dostaje jedno zadanie i miele je do końca świata.

Dane płyną przez kaskadę tych kafelków jak transakcja przez księgę zleceń:

• fd_net łapie pakiety prosto z karty sieciowej, na najniższym poziomie.
• fd_netmux multipleksuje strumienie.
• fd_quic obsługuje protokół transportowy QUIC, pilnuje kontroli przepływu i odsiewa ruch typu DoS.
• fd_verify równolegle weryfikuje podpisy kryptograficzne — co nie przejdzie, leci do kosza natychmiast.
• fd_dedup wyłapuje duplikaty po unikalnych podpisach.
• fd_pack sortuje i pakuje transakcje w mikrobloki tak, żeby w jednym mikrobloku nie było dwóch transakcji ruszających te same konta. Dzięki temu wykonanie w fd_bank idzie bezkonfliktowo, równolegle.

Widzisz analogię? To jest pipeline jak z systemu tradingowego o niskich opóźnieniach: każdy etap wyspecjalizowany, dane przechodzą liniowo, nic nie czeka bez potrzeby.

Pamięć: nic nie alokujemy w locie

Tu robi się ciekawie. Firedancer nie alokuje pamięci dynamicznie podczas normalnej pracy. Cały RAM potrzebny walidatorowi jest rezerwowany raz, na starcie, w ciągłych blokach pamięci współdzielonej, z użyciem huge pages i gigantic pages w Linuksie.

Po co ta gimnastyka? Dwa powody. Po pierwsze, drastycznie spada narzut na przeszukiwanie tablic stron pamięci. Po drugie — i to zna każdy, kto pisał systemy pod presją czasu — znika fragmentacja. Alokator w krytycznym momencie potrafi cię zaskoczyć opóźnieniem znikąd. Firedancer po prostu nie daje mu okazji.

Do tego cała komunikacja między kafelkami działa bez blokad (lockless concurrency) — wątki nie biją się o dostęp do sekcji krytycznych. Oprogramowanie jest też w pełni świadome architektury NUMA: rdzeń przetwarza dane leżące w banku RAM lokalnym dla jego gniazda, a nie ciągnie ich przez interkonekt między procesorami. Brzmi jak drobiazg, dopóki nie policzysz, ile taki transfer kosztuje przy milionie operacji na sekundę.

Sieć i kryptografia: obejść jądro, policzyć na wektorach

W warstwie sieciowej Firedancer używa eBPF/XDP do kernel bypass. Pakiety są przejmowane bezpośrednio na karcie sieciowej (NIC) i lecą do przestrzeni użytkownika z pominięciem standardowego stosu Linuksa. Do tego RSS (Receive Side Scaling) rozkłada ruch przychodzący równo na rdzenie odbierające. Standardowy stos socketów? Dla tych obciążeń to kula u nogi.

Ale prawdziwy popis to kodowanie korekcyjne Reed-Solomon w protokole dystrybucji bloków Turbine. Zespół napisał własną implementację na instrukcjach wektorowych AVX-512, licząc na ciałach Galois $GF(2^8)$ z wielomianem $0x11d$. Liczby mówią same za siebie: ponad 120 Gbps kodowania na rdzeń i do 50 Gbps dekodowania na rdzeń. Standardowa biblioteka Rusta (rust-rse) wyciąga około 8 Gbps na rdzeń. To nie jest poprawka o kilka procent — to kilkunastokrotny skok.

⚡ Rzeczywistość vs teoria: w książkach przeczytasz, że język programowania „nie ma aż takiego znaczenia". Powiedz to komuś, kto z 8 Gbps zrobił 120 Gbps na tym samym krzemie. Różnicę robi bezpośredni dostęp do sprzętu i SIMD tam, gdzie Rust ładował abstrakcje.

Bezpieczeństwo: każdy moduł traktowany jak wróg

Filozofia bezpieczeństwa Firedancera jest żywcem wzięta z przeglądarek internetowych: zakładamy, że każdy moduł wejściowy jest niezaufany i podatny na atak. Nie ma jednego monolitycznego procesu, który wywalony w powietrze oddaje napastnikowi cały węzeł. Zamiast tego — piaskownice.

Każdy kafelek to osobny proces Linuksa z własną przestrzenią adresową. Ktoś znajdzie i wykorzysta lukę w kafelku obsługującym QUIC? Trudno — nie odczyta przez to pamięci innych procesów ani nie przejmie węzła. Dostęp do wywołań systemowych jądra jest zablokowany filtrem seccomp-BPF. Na starcie kafelki sieciowe i weryfikacyjne tracą prawo do niemal wszystkich syscalli — nie otworzą pliku, nie odpalą nowego procesu, nie nawiążą lewego połączenia. Nawet jak napastnik wejdzie, to wchodzi do pustego pokoju bez drzwi.

Wymiana danych między kafelkami idzie wyłącznie przez zmapowane, jednokierunkowe kanały pamięci współdzielonej. Każdy proces ma dostęp tylko do tego kawałka pamięci, który jest mu potrzebny do jego roboty. Nic ponad to.

Szczególną ochroną objęty jest kafelek podpisujący (signing tile) — ten, który trzyma klucz prywatny tożsamości walidatora. Nie ma połączenia z siecią zewnętrzną i podpisuje wyłącznie wcześniej zweryfikowane bloki. To jest twój sejf, odcięty od świata.

⚠ Uwaga na jedną rzecz: izolacja nie jest jeszcze stuprocentowa. W obecnej fazie kafelki Bank i Storage ze względów kompatybilności działają we wspólnej przestrzeni z komponentami Agave przez interfejs FFI (Foreign Function Interface). To jedyny wyłom — i warto o nim wiedzieć, zanim ktoś sprzeda ci narrację o „idealnej piaskownicy".

Frankendancer kontra Pełny Firedancer: dwa etapy tej samej drogi

Nikt przy zdrowych zmysłach nie wrzuca nowego silnika na produkcję wartą miliardy z dnia na dzień. Dlatego wdrożenie idzie etapami, w dwóch wariantach.

Frankendancer — hybryda na rozgrzewkę

Frankendancer to wersja przejściowa. Bierze napisany w C stos sieciowy i produkcję bloków, a spina to z silnikiem wykonawczym i logiką konsensusu z Agave. W tej konfiguracji nowy kod odpowiada za przyjmowanie pakietów, filtrowanie DoS, weryfikację podpisów i dystrybucję bloków przez Turbine — ale samo wykonanie transakcji i zarządzanie stanem kont dalej robi Rust.

Debiut na testnecie, a we wrześniu 2024 wejście na beta-mainnet. I tu liczby, które robią wrażenie: w czerwcu 2025 Frankendancer trzymał ~8% stake'u, a do października 2025 urósł do 20,9% — ponad 207 walidatorów. To nie jest eksperyment garażowy, to realna adopcja.

Pełny Firedancer — samodzielny zawodnik

Pełny Firedancer to już całkowicie niezależny węzeł w C, który wyrzuca Agave za burtę — łącznie z weryfikacją stanu i głosowaniem konsensusowym. Ma własny silnik wykonawczy, przetwarzający niekonfliktujące transakcje na poziomie ~40 000–50 000 TPS na rdzeń. Przy 20 rdzeniach oddanych kafelkowi fd_bank daje to teoretyczną przepustowość przekraczającą 1 000 000 TPS.

Zanim jednak wyślesz to na Księżyc: od września 2024 Pełny Firedancer chodzi na beta-mainnecie w trybie niegłosującym (non-voting). Węzły przetwarzają pełny strumień transakcji, ale ich rozstrzygnięcia nie wpływają na finalny konsensus. Pełne wdrożenie z prawem głosu zaplanowano na drugą połowę 2025, po zamknięciu kompletu audytów bezpieczeństwa.

💡 Ważne: milion TPS to liczba z testów, teoretyczny sufit przy idealnym sprzęcie i bezkonfliktowym ruchu. Realna sieć to inna bajka. Ale nawet ułamek tego to poziom, o którym konkurencja może pomarzyć.

Po co to wszystko: decentralizacja, której nie widać na wykresie

Tu dochodzimy do sedna. Drugi niezależny klient nie zmienia liczby walidatorów. Zmienia coś ważniejszego — przenosi decentralizację z poziomu „ile jest węzłów" na poziom „na ilu niezależnych silnikach one jadą".

Żeby to zrozumieć, trzeba znać dwa progi z teorii Byzantine Fault Tolerance (BFT). W sieci Proof-of-Stake liczą się dwie liczby: 33,3% i 66,7% skumulowanego stake'u.

Jeśli jeden klient kontroluje ponad 33,3% stake'u, wystarczy jeden bug zatrzymujący pracę (liveness bug), żeby sparaliżować całą sieć — reszta walidatorów nie zbierze wymaganych 2/3 głosów do zatwierdzenia bloku. A jeśli jeden klient przekroczy 66,7%, robi się jeszcze groźniej: błąd w obliczeniach może przepchnąć nieprawidłowe transakcje albo trwale rozwidlić łańcuch (safety failure). Pierwsze to sieć stoi. Drugie to sieć kłamie. Nie wiem, co gorsze.

I teraz clou: gdy Frankendancer i Pełny Firedancer razem przekroczą progi 33,3% i 50% stake'u, awaria kodu Agave albo Jito przestanie kłaść całą Solanę. Niezależne węzły Firedancera pojadą dalej, produkując bloki. To jest dokładnie to ubezpieczenie, którego brakowało w 2021 i 2022 roku.

Dywersyfikacja kodu wpina się w resztę wskaźników decentralizacji Solany, które — wbrew popularnej narracji — nie wyglądają źle:

• Współczynnik Nakamoto: 19–20. Tyle niezależnych podmiotów trzeba by zmówić, żeby sparaliżować konsensus. To czołówka branży.
• Ponad 4 500 węzłów — w tym ~1 400 walidatorów głosujących i ponad 3 100 węzłów RPC, rozsianych po 49 krajach.
• Geografia stake'u: Europa ~42–50,5%, Ameryka Północna ~20–28%, z rosnącym udziałem Azji.
• 135 niezależnych dostawców centrów danych. Największe udziały: Teraswitch (24%) i Latitude.sh (19%).

Firedancer domyka jedyny punkt, który do tej pory wisiał nieobsłużony: monokulturę oprogramowania. Fizyczną decentralizację Solana miała nieźle. Programistyczną — dopiero teraz.

Dylemat walidatora: ideologia kontra portfel

Teraz część, którą każdy operator węzła zna od podszewki. Bo adopcja Frankendancera na początku kulała nie z powodów technicznych, tylko czysto ekonomicznych.

Jito zbudowało dominację (72–88% stake'u), oferując walidatorom wpięcie w swój silnik aukcyjny — a to znaczyło wyższe przychody z opłat priorytetowych i tipów MEV. Konkretnie: pierwsze wydania Frankendancera skupiały się na warstwie sieciowej i nie wspierały w pełni infrastruktury aukcyjnej Jito. Przejście z Jito na Frankendancer oznaczało dla operatora utratę 15–20% łącznych przychodów z MEV.

I tu masz klasyczny konflikt, który rynek zna na wylot: wspierać decentralizację sieci czy zarobić tu i teraz? Ideologia jest piękna, dopóki nie płacisz nią rachunków za prąd w serwerowni. Większość operatorów głosuje portfelem — i słusznie, to biznes, nie fundacja charytatywna.

Przełom przyszedł, gdy Frankendancer nauczył się obsługiwać pakiety transakcyjne Jito (bundles), a społeczność przyjęła zmiany w protokole — m.in. SIMD-123, przegłosowane większością 74,91%. Nagle dało się mieć jedno i drugie: architekturę HFT i ochronę DoS bez oddawania przychodów z MEV.

💰 Koszt (a właściwie oszczędność): dzięki wydajniejszemu kodowi C Frankendancer ściął obciążenie procesora o ~12% względem Jito. Mniej CPU to niższy rachunek za prąd i tańsza obsługa infrastruktury. Nagle „ideologiczny" wybór zaczął się po prostu opłacać. I dopiero wtedy stake ruszył.

Sprzęt: rachunek za milion TPS płacisz w RAM-ie

Jest jednak druga strona medalu. Firedancer przesuwa wąskie gardło z kodu na fizyczny sprzęt — a to znaczy, że jak chcesz jechać na pełnej wydajności, musisz za to zapłacić żelastwem. To nie jest klient, który odpalisz na VPS-ie za 20 dolarów.

⚠ Pułapka: zwróć uwagę na ECC — jest wymagane, nie opcjonalne. Przy tym wolumenie przetwarzania losowe przekłamanie bitu w RAM to nie teoria, to statystyka. Zwykła pamięć bez korekcji błędów prędzej czy później podłoży ci minę. Kto próbował oszczędzić na tym elemencie, ten wie.

Co z tego wynika i dokąd to zmierza

Firedancer udowadnia rzecz, którą wielu przeczuwało, ale mało kto potrafił pokazać liczbami: limity przepustowości blockchainów warstwy pierwszej nie siedzą w teorii rejestrów rozproszonych, tylko w kiepsko napisanym oprogramowaniu. Architektura kafelkowa, rezygnacja z dynamicznej alokacji, kernel bypass, optymalizacje wektorowe — to wszystko istnieje w tradingu HFT od dwóch dekad. Ktoś w końcu przeniósł to na blockchain i sufit wystrzelił w górę.

Znaczenie dla Solany jest dwuwymiarowe. Programistycznie — złamanie monokultury Rusta i wprowadzenie niezależnej bazy C chroni sieć przed paraliżem, gdy w Agave znajdzie się krytyczna luka. Strukturalnie — przekroczenie progu 33,3% stake'u przez alternatywnego klienta gwarantuje ciągłość działania w świetle BFT. To nie są dwie osobne korzyści. To jedna, oglądana z dwóch stron.

Na horyzoncie jest jeszcze Alpenglow — aktualizacja konsensusu celująca w ostateczność transakcji na poziomie 100–150 ms. Połącz to z pełnym Firedancerem w trybie głosującym (druga połowa 2025) i dostajesz infrastrukturę, która na poważnie może obsłużyć globalny rynek finansowy w czasie rzeczywistym. Nie „wolny rejestr transakcyjny", tylko wydajną, globalną maszynę stanu, która nie pada pod obciążeniem.

Teraz twój ruch. Jeśli prowadzisz węzeł — sprawdź, ile realnie kosztowałoby cię przejście na Frankendancer po integracji Jito bundles i policz to przy nowym obciążeniu CPU. Jeśli tylko trzymasz SOL — obserwuj jeden wskaźnik: kiedy łączny stake Firedancera przebije 33,3%. To będzie moment, w którym Solana po raz pierwszy przestanie wisieć na jednym silniku. A na rynku to jest różnica między siecią, która „zwykle działa", a siecią, na której możesz oprzeć poważne pieniądze.

Powyższy materiał ma charakter edukacyjny i nie stanowi porady inwestycyjnej. Autor nie jest doradcą inwestycyjnym — decyzje dotyczące alokacji kapitału podejmujesz na własną odpowiedzialność.