Podczas zeszłotygodniowej konferencji Solana Breakpoint atmosfera tętniła życiem dzięki premierom produktów i różnym angażującym wydarzeniom towarzyszącym. Najważniejszym wydarzeniem była oficjalna premiera w sieci głównej wczesnej wersji klienta walidatora Solana – Firedancer.
To przełomowe osiągnięcie spotkało się ze szczególną uwagą, sygnalizując znaczący skok wydajności sieci Solana, jednocześnie zmniejszając ryzyko przestoju sieci spowodowanego awarią pojedynczego klienta.
Rozwój Firedancer sięga lat 2021-2022 i był prowadzony przez Jump Trading Group jako drugi klient walidatora Solana (wraz z pierwotnym klientem, Agave, opracowanym przez Anza). Jego głównym celem było wyeliminowanie pojedynczych punktów awarii, zwiększając ogólną solidność i odporność sieci.
W przeciwieństwie do oryginalnego walidatora opartego na Rust, Firedancer jest napisany w języku C, z wyłączeniem kodu Rust. Wybór ten znacznie zmniejsza potencjalny wpływ luk w zabezpieczeniach na sieć, dodając silną warstwę bezpieczeństwa do Solany.
Jak działa Firedancer?
Podczas prezentacji w Solana Breakpoint, główny naukowiec Jump Crypto, Kevin Bowers, zaprezentował zdolność Firedancer do przetwarzania ponad 1 miliona transakcji na sekundę (TPS), znacznie przekraczając obecny teoretyczny limit Solany wynoszący dziesiątki tysięcy TPS. Metaforycznie porównał to osiągnięcie do poszerzenia „wiejskiej drogi” do „autostrady międzystanowej”, wskazując na podwójną optymalizację kosztów i przepustowości sieci.
Główny inżynier Liam Heeger podzielił się postępami w sieci testowej, zauważając, że Firedancer z powodzeniem wyprodukował ponad 20 000 bloków przy współczynniku stakingu wynoszącym 1%. Inny inżynier, Aryaman Jain, zademonstrował wydajność Firedancer w określonych warunkach, ujawniając TPS sięgający miliona w środowisku 10 walidatorów, z ponad 1,2 miliarda obliczeń na sekundę i przepustowością przestrzeni blokowej 3,5 Gbps.
Jak działa Firedancer?
Firedancer opiera się na trzech głównych komponentach: wysokowydajnym stosie obliczeniowym, stosie sieciowym oraz mechanizmach uruchamiania i konsensusu. Jego zdolność do podniesienia wydajności Solany do 1 miliona TPS (obecne limity protokołu wynoszą około 81 000 TPS) leży w jego innowacyjnej architekturze i optymalizacji przepływu danych.
Walidator wykorzystuje model współbieżności, który wykonuje różne zadania w kilku wątkach, przy czym każdy wątek koncentruje się na określonych zadaniach, takich jak przetwarzanie pakietów sieciowych, walidacja transakcji i pakowanie bloków. Taka konstrukcja maksymalizuje wykorzystanie zasobów i znacznie przyspiesza przetwarzanie transakcji.
W szczególności, każdy wątek wykonuje jedno z 11 różnych zadań. Niektóre zadania wymagają tylko jednego wątku, podczas gdy inne wymagają równoległej pracy wielu wątków. Każdy wątek działa na dedykowanym rdzeniu procesora, dzięki czemu nigdy nie zasypia ani nie jest zmieniany przez system operacyjny.
Firedancer wprowadza również architekturę zwaną „kafelkami”, gdzie każdy kafelek reprezentuje zadanie, jego uruchomiony wątek i przydzielony rdzeń procesora. Takie połączenie pozwala na elastyczne i wydajne dostrajanie wydajności. Przykładowo, kafelki net i quic mogą obsłużyć ponad 1 milion TPS, podczas gdy kafelki verify i bank koncentrują się na walidacji transakcji i wykonywaniu bloków, co jest wystarczające w scenariuszach o wysokiej współbieżności.
Oficjalna dokumentacja Firedancer zawiera listę następujących 11 kafelków:
- netto: Wysyła i odbiera pakiety sieciowe (każdy kafelek może obsłużyć 1 milion TPS);
- szybki: Odbiera transakcje od klientów, zarządzając połączeniami i przetwarzaniem pakietów dla protokołu QUIC (każdy kafelek może obsłużyć 1 milion TPS);
- weryfikacja: Weryfikuje podpisy kryptograficzne przychodzących transakcji, odfiltrowując nieprawidłowe (każdy kafelek może obsłużyć 20-40 000 TPS);
- dedup: Sprawdza i filtruje zduplikowane transakcje przychodzące;
- opakowanie: Pakuje przychodzące transakcje, działając jako lider, inteligentnie planując ich wykonanie;
- bank: Wykonuje zaplanowane transakcje (każdy kafelek może obsłużyć 20-40 000 TPS);
- poh: Ciągłe haszowanie w tle, mieszanie wygenerowanych haszów z wykonanymi transakcjami w celu udowodnienia kolejności i czasu;
- strzęp: dystrybuuje dane blokowe do sieci, gdy działa jako lider; gdy nie, odbiera i retransmituje dane blokowe (przepustowość zależy głównie od wielkości klastra, a testy porównawcze wskazują > 1 milion TPS dla małych klastrów);
- sklep: Odbiera dane blokowe, gdy działa jako lider lub od innych węzłów, gdy są liderami, przechowując je w lokalnej bazie danych na dysku;
- metryczny: Zbiera informacje o monitorowaniu innych kafelków i dostarcza je do punktów końcowych HTTP;
- znak: Przechowuje klucz prywatny walidatora i odpowiada na żądania podpisu z innych kafelków.
Warto zauważyć, że zanim Firedancer dojrzeje, jego przejściowa wersja, Frankendancer, weszła już do Solana mainnet. Frankendancer to hybryda kodu Firedancer i Agave, wykorzystująca zalety Firedancer w zakresie stosu sieciowego i produkcji bloków, przy jednoczesnym zachowaniu funkcjonalności Agave w zakresie wykonywania i konsensusu. Natomiast Firedancer został zbudowany całkowicie od podstaw, bez żadnego kodu Agave.
Jaki jest wpływ Firedancer?
Niewątpliwie uruchomienie Firedancer ma znaczący wpływ na ekosystem Solana, znacznie zwiększając różnorodność walidatorów i jeszcze bardziej zmniejszając ryzyko pojedynczych punktów awarii, wzmacniając w ten sposób niezawodność sieci.
Co więcej, Firedancer zachowuje wsteczną kompatybilność z istniejącymi protokołami, zapewniając płynne przejście dla ekosystemu bez konieczności wprowadzania znaczących zmian przez twórców DApp i użytkowników.
Chociaż Firedancer jest obecnie w trybie niegłosowania i przechodzi ciągłą optymalizację i audyt, daje nadzieję na przyszły rozwój sieci Solana.
-
-
-
-
-
-
-
-
