Bitcoin przetwarza ok. 7 transakcji na sekundę. Ethereum — ok. 15–30. Solana celuje w 65 000, a jej deweloperzy publikują wyniki testów na poziomie miliona TPS. Skąd ta przepaść? I czy to nie jest zbyt piękne, żeby było prawdziwe?

Odpowiedź kryje się w jednym fundamentalnym przełomie: Solana oddzieliła synchronizację czasu od osiągania konsensusu — i dzięki temu przestała tracić czas na pytanie „która godzina?", zanim cokolwiek zatwierdzi.

Trylemat blockchaina — pułapka, z której nikt nie mógł wyjść

Każdy, kto budował lub analizował sieci Layer 1, zna ten dylemat: bezpieczeństwo, decentralizacja, skalowalność — wybierz dwie. Bitcoin wybrał bezpieczeństwo i decentralizację. Ethereum przez lata leżało w tym samym miejscu. Łańcuchy takie jak EOS próbowały kupić przepustowość kosztem decentralizacji.

Problem ma głębszy korzeń niż algorytm konsensusu. Chodzi o czas. W sieci bez globalnego, zaufanego zegara węzły muszą negocjować kolejność zdarzeń przy każdym bloku. To generuje narzut komunikacyjny, który fizycznie ogranicza liczbę transakcji na sekundę — niezależnie od mocy sprzętu.

Analogia z XIX wieku jest tu zaskakująco trafna: zanim w 1883 roku wprowadzono strefy czasowe dla kolei w USA, różnice minut w lokalnych zegarach uniemożliwiały synchroniczne planowanie i prowadziły do kolizji. Blockchain bez wspólnego zegara ma dokładnie ten problem — tylko że zamiast pociągów, kolizją jest podwójne wydatkowanie środków.

Proof of History — zegar, który istnieje przed konsensusem

Najczęstszy błąd w opisach Solany: traktowanie Proof of History (PoH) jako algorytmu konsensusu. To nie jest konsensus. PoH to kryptograficzny zegar — narzędzie do synchronizacji czasu, które działa równolegle z Tower BFT (mechanizmem decyzyjnym).

Technicznie to Weryfikowalna Funkcja Opóźnienia (VDF) oparta na SHA-256. Zasada jest prosta: weź dane wejściowe, wygeneruj skrót 256-bitowy, użyj wyniku jako wejścia do kolejnej iteracji. Powtarzaj miliony razy. Każda iteracja to „tyknięcie" zegara.

hash_0 = SHA256(seed)
hash_1 = SHA256(hash_0)
hash_2 = SHA256(hash_1)
...
hash_N = SHA256(hash_N-1)

Dlaczego tego nie da się sfałszować? Bo SHA-256 jest jednokierunkowy i nieprzewidywalny — nie możesz obliczyć wartości dla iteracji nr 100 000 bez przejścia przez 99 999 poprzednich. Żaden procesor wielordzeniowy na świecie nie obejdzie tej sekwencyjności. To jest matematyczna gwarancja, że generowanie czasu kosztuje rzeczywisty czas procesora.

Ale tu pojawia się asymetria, która robi całą robotę: generowanie jest sekwencyjne, weryfikacja jest równoległa. Inny węzeł może podzielić sekwencję na fragmenty i sprawdzić je jednocześnie na setkach rdzeni w czasie bliskim zeru.

Efekt praktyczny: węzły Solany wiedzą z góry, w jakiej kolejności nastąpiły zdarzenia — bez wysyłania wiadomości synchronizacyjnych. Tam gdzie Ethereum traci sekundy na uzgadnianie czasu, Solana już przetwarza kolejne transakcje.

PoH nie decyduje, które transakcje są zatwierdzone. Dostarcza zaufaną oś czasu, na której Tower BFT podejmuje decyzje — szybciej i z mniejszym narzutem komunikacyjnym.

Tower BFT — konsensus bez zegarków

Klasyczny algorytm PBFT z 1999 roku (prawie dekadę starszy niż Bitcoin) może osiągać konsensus nawet jeśli do 1/3 węzłów jest nielojalnych lub niedostępnych. Problem: wymaga trzech rund głosowania i polega na lokalnych zegarach każdego serwera — co w rozproszonej sieci generuje opóźnienia.

Tower BFT bierze PBFT i wyrzuca zegary do kosza. Zamiast nich — sekwencja tyknięć PoH. Limity czasowe są egzekwowane bezpośrednio w łańcuchu hashującym, nie przez hardware operatora.

Dwie kluczowe bariery bezpieczeństwa, o których warto wiedzieć:

Próg 1/3 (Halting Threshold): Jeśli nieuczciwe węzły kontrolują ≥1/3 całkowitego stake'u, mogą odmówić głosowania i zablokować wymaganą superwiększość 2/3. Sieć zatrzymuje produkcję bloków. To zamierzony mechanizm — integralność ponad ciągłość.

Próg 2/3 (Collusion Threshold): Gdyby nieuczciwe węzły zgromadziły ≥2/3 stake'u, przejęłyby pełną kontrolę nad łańcuchem. Ekonomicznie byłoby to atakowanie własnej inwestycji wartej miliardy dolarów.

Ważna różnica w codziennym użytkowaniu — dwie warstwy zatwierdzeń:

  • Optimistic Confirmation (~400 ms): Superwiększość zagłosowała na dany blok. Status „confirmed" w portfelu. Szybko, ale bez absolutnej gwarancji.
  • Finalized/Rooted (12–32 sloty, ok. 5–13 sekund): Absolutny, nieodwołalny konsensus PoS. Giełdy czekają na ten status przed uznaniem depozytu.
Same akty głosowania (VOTE transactions) są osadzane jako zwykłe transakcje w blokach. Stanowią przytłaczającą większość surowych metryk TPS — dlatego „4 000 TPS użytkownika" i „50 000 TPS łącznie" to dwie różne liczby. Protokół priorytetyzuje głosy nad transakcjami komercyjnymi.

8 technologii, które razem dają 65 000 TPS

PoH i Tower BFT to fundament. Ale samo rozwiązanie problemu czasu nie wystarczy — wąskie gardła są na każdym poziomie stosu. Solana adresuje je jednocześnie ośmioma komponentami:

Turbine — propagacja bloków bez kolapsowania sieci

Wyobraź sobie sieć 20 000 węzłów. Lider slotu musi rozesłać blok ~128 MB do każdego z nich w ułamku sekundy. Bezpośrednia transmisja „jeden do wielu" natychmiast nasyciłaby łącze.

Turbine rozbija blok na mikroskopijne paczki zwane shreds (strzępy) — każdy poniżej limitu MTU, co eliminuje fragmentację IP. Następnie buduje deterministyczne drzewo propagacji z rotacją przy każdym slocie. Routing jest wyznaczany na podstawie: ID lidera + indeks slotu + numer strzępa. Każda paczka podróżuje unikalną ścieżką — atak na jedno węzeł nie blokuje całego drzewa.

Korekcja błędów oparta na kodowaniu Reeda-Solomona (stosunek 32:32) pozwala zrekonstruować każdy utracony bajt dysponując dowolnymi 32 z 64 strzępów. Przy symulowanym packet loss 15% i 6 400 strzępach na sekundę — skuteczność doręczenia bloków wynosi 99%. Przesyłanie 6 MB przez Atlantyk (us-east-1 → eu-north-1) zamknęło się w ~100 ms vs. 900 ms przy TCP.

Gulf Stream — koniec globalnego mempoola

W Bitcoinie i Ethereum transakcje lądują w globalnym mempuolu — kolejce, która przy szczytowym ruchu pęcznieje do 100 000 oczekujących zleceń na wiele godzin. Gas fees lecą w kosmos.

Gulf Stream eliminuje tę kolejkę. Ponieważ harmonogram liderów jest deterministycznie znany z góry (dzięki PoH), węzły i serwery RPC wiedzą, kto będzie liderem za 2 sloty. Zamiast wrzucać transakcje do wspólnej puli, przesyłają je bezpośrednio do przyszłego lidera.

Wynik: węzły mogą buforować 100 000 transakcji i wyzerować zaległości przy przepustowości ~50 000 TPS — zanim powolna kolejka zdążyłaby się nawet uformować.

Sealevel (SVM) — równoległe wykonanie kontraktów

Ethereum Virtual Machine (EVM) jest jednowątkowa. Jeden kontrakt wykonuje się na raz. Solana Virtual Machine (SVM) działa inaczej: każda transakcja musi z góry zadeklarować, które konta czyta i które modyfikuje (is_writable, is_signer w tablicy AccountMeta).

SVM analizuje te deklaracje i identyfikuje transakcje, które dotykają różnych kont — i wykonuje je równolegle na setkach rdzeni CPU. Brak nakładających się kont = brak wyścigu o zasoby = brak blokad.

Dla złożonych protokołów DeFi z dziesiątkami odnóg kont, wprowadzono Address Lookup Tables (ALTs) — zamiast 32-bajtowych kluczy publicznych, transakcja odwołuje się do 1-bajtowych indeksów w tablicy on-chain. Limit ~35 kont na transakcję przestał być problemem.

Pipelining (TPU) — fabryka transakcji

Jednostka TPU (Transaction Processing Unit) to potok inspirowany architekturą procesorów krzemowych. Transakcje przepływają przez cztery wyspecjalizowane etapy jednocześnie:

  1. Ingestion (Kernel level, QUIC): Odbiór pakietów z weryfikacją tożsamości nadawcy i filtrowaniem DDoS przez SWQoS.
  2. SigVerify (GPU): Weryfikacja podpisów Ed25519 — operacja O(N), zrównoleglona na tysiącach rdzeni GPU. Fałszywe transakcje wylatują tutaj, nie zakorkowując dalszych etapów.
  3. Banking (CPU): Wykonanie logiki SVM, zapis stanu, timestamping przez PoH.
  4. Broadcast (NVMe + Turbine): Asynchroniczny zapis na dysk i propagacja strzępów do sieci.

Każdy etap przetwarza 550 paczek jednocześnie. Żaden nie czeka na inny — jak linia montażowa, gdzie spawanie, malowanie i montaż kół idą równocześnie.

Cloudbreak — baza danych, która nie dusi przepustowości

Standardowe bazy LevelDB (używane przez większość blockchainów) osiągają max ~5 000 TPS przy zapisie. Przy 50 000 TPS Solany to byłoby terminalne wąskie gardło.

Cloudbreak stosuje trzy mechanizmy systemu operacyjnego bezpośrednio na sprzęcie:

  • Memory-Mapped Files: Stan kont mapowany wprost na przestrzeń adresową RAM, z ominięciem standardowych wywołań systemowych. Prędkość dostępu zbliżona do natywnej pamięci RAM.
  • Horizontal Sharding na NVMe SSD: Dane kont rozpraszane po wielu dyskach NVMe jednocześnie, eliminując sekwencyjne wąskie gardło zapisu.
  • Copy-on-Write (CoW): Modyfikacje dopisywane na końcu pliku zamiast nadpisywania istniejących danych — koniec z kosztownymi operacjami kasowania i fragmentacją.

Efekt teoretyczny: ponad 1 milion operacji I/O na sekundę vs. 5 000 w LevelDB.

Archivers — rozproszony magazyn historii

Pełna historia transakcji Solany to terabajty danych. Walidatorzy nie mogą trzymać wszystkiego — Archivers (Replicators) to dedykowane węzły przechowujące historyczne dane. Nie uczestniczą w konsensusie, ale odpowiadają za dostępność archiwum.

Historia awarii — bo bez tego obraz jest niepełny

Sieć z takim poziomem optymalizacji ma też słabe punkty. I nie byłoby uczciwie, gdybym je pominął.

Data Przyczyna Czas przestoju Rozwiązanie
Grudzień 2020 Bug w propagacji bloków Turbine (duplikat slotu u64) ~6 h Zmiana identyfikacji bloków na hash zamiast ID slotu
Wrzesień 2021 Grape Protocol IDO — 300 000 TPS od botów, przepełnienie RAM, nieskończona pętla przy restarcie ~17 h Priorytety VOTE tx, patch przepełnienia zmiennej int
Kwiecień 2022 Candy Machine NFT DDoS — >6 mln żądań/s, >100 Gbps ~7 h Wdrożenie QUIC + SWQoS
Luty 2024 Bug w JIT cache (LoadedPrograms) — nieskończona pętla przy ładowaniu starych programów ~5 h Hotfix od Anza w ~4 h, restart z ostatniego potwierdzonego bloku
Wszystkie powyższe przestoje wynikały z jednego wspólnego mianownika: zdominowanie kodu przez jednego klienta (Agave/Rust). Jeden bug w jednym kliencie = cała sieć staje. To jest systemowe ryzyko, które Solana adresuje teraz przez dywersyfikację klientów.

Od wprowadzenia QUIC i SWQoS w połowie 2022 roku sieć utrzymuje ciągłość operacyjną. W okolicach roku 2025 — ponad 16 miesięcy bez zatrzymania, latencja bloku stale poniżej 400 ms, wolumen DEX w styczeń 2025 przekroczył 200 milionów dziennych transakcji.

Dywersyfikacja klientów — odpowiedź na systemowe ryzyko

To jedna z bardziej niedocenianych zmian w ekosystemie Solany. Analogia z Ethereum jest trafna: sieć, która ma czterech niezależnych klientów (Geth, Besu, Erigon, Nethermind) jest odporna na bug w jednym z nich.

Klient Język Rola
Agave (Anza) / Jito Rust Dominujący ~80–88% stake'u; Jito dodaje MEV-boost dla priorytetów bloków
Firedancer (Jump Crypto) C/C++ Testy pokazały ~1 000 000 TPS; planowany główny klient produkcyjny
Frankendancer C++ (sieć) + Rust (konsensus) Już na mainnecie; łagodna migracja ku pełnemu C++
Sig (Syndica) Zig Optymalizowany pod odczyt RPC
Mithril Go Lekki klient weryfikujący

Firedancer w zamkniętych testach odtworzył bloki produkcyjne przy blisko 1 000 000 TPS. To nie jest marketingowy benchmark — to odtwarzanie rzeczywistych bloków mainnet na sprzęcie komercyjnym.

Solana vs. konkurencja — bez owijania w bawełnę

Sieć Maks. TPS (teoret.) Realne TPS (szczyt) Finalizacja
Solana 65 000 (ewolucja do 1 mln) 1 000–4 000 (z wyłączeniem VOTE tx) ~400 ms optimistic; ~12 s finalized
SUI 120 000 Dziesiątki tysięcy w testach <500 ms (single-owner objects)
Aptos 160 000 Niższe od benchmarków Zbliżone do błyskawicznego
Ethereum L1 ~15 15–30 12 s blok; 12–13 min finalizacja
Ethereum L2 Zależy od Rollupa Setki do tysięcy Minuty do godzin (settlement do L1)

Kluczowa różnica filozoficzna: Ethereum rozwiązuje skalowalność przez fragmentację — Rollups, mosty, osobne warstwy płynności. Solana stawia na jeden globalny stan na Layer 1. Żadnych mostów, żadnej fragmentacji płynności, natywna kompozycja protokołów DeFi.

⚡ PRO TIP: Jeśli budujesz protokół DeFi, który musi atomowo odwoływać się do wielu pul płynności — Solana daje to natywnie. Na Ethereum musisz złożyć wniosek do oracle'a i modlić się, że mosty nie zepsują ci arbitrażu.

Decentralizacja i ekonomia węzłów

Wymagania sprzętowe walidatora Solany to nie przelewki: 24 rdzenie CPU taktowane >4,2 GHz, 512 GB RAM, NVMe SSD ≥2 TB. Koszt bare-metal serwera to kilka–kilkanaście tysięcy dolarów plus miesięczne koszty hostingu z symetrycznym gigabitowym łączem.

Próg opłacalności (break-even) dla stakowanego kapitału spadł z ~50 000 SOL w 2022 roku do 16 000–20 000 SOL w 2025 — efekt zmian SIMD-0096 (100% napiwków dla walidatorów) i SIMD-0033 (Timely Vote Credits nagradzające szybkie głosy).

Współczynnik Nakamoto (minimalna liczba podmiotów potrzebna do osiągnięcia 33,3% głosów) oscyluje w rejonach 19–34 niezależnych bytów — wyraźnie wyżej niż Ethereum (~6) czy SUI (~18). Fundacja Solana Delegation Program (SFDP) wspiera ~72% nowych wejść operacyjnych, aktywnie zapobiegając monopolizacji.

Jito Labs kontroluje ~80–88% stake'u poprzez swój klient MEV. To jest koncentracja, którą należy monitorować — szczególnie w kontekście potencjalnej cenzury transakcji. Frankendancer i Firedancer są tu strategicznym buforem.

Podsumowanie: co naprawdę rozwiązał PoH?

Proof of History nie jest magiczną różdżką. Jest precyzyjnym rozwiązaniem jednego konkretnego problemu: uzgadniania kolejności zdarzeń bez ciągłej komunikacji między węzłami.

To odblokowanie pozwoliło na całą resztę — Tower BFT z jedną rundą głosowania zamiast trzech, Gulf Stream bez globalnej kolejki, Sealevel z równoległym wykonaniem, Pipelining z GPU offloadem podpisów.

Łańcuch jest tak mocny, jak jego najsłabsze ogniwo. Solana zaadresowała każde ogniwo osobno — od kryptograficznego zegara, przez propagację danych z korekcją błędów, po fizyczny I/O dysków. Wynik: jedyna sieć Layer 1, która obsługuje masowy ruch DEX, NFT i płatności bez warstw podrzędnych.

Otwórz teraz Solscan i sprawdź aktualny TPS w realu. Porównaj z Etherscanem. Liczby mówią same za siebie.