Ostatnio przeglądałem dokumentację techniczną Fogo i zauważyłem pewien szczegół, na który wcześniej nie zwracałem uwagi: jego strategia klienta to w rzeczywistości najostrzejszy cios całego projektu.

Większość publicznych łańcuchów mówi o "wielu klientach", co oznacza, że ta sama protokołowa struktura działa na kilku różnych implementacjach kodu - na przykład Ethereum ma Geth, Nethermind, Solana ma natywny klient Rust oraz Firedancer stworzony przez Jump. Logika jest taka, że różnorodność kodu może zapobiegać lukom i zwiększać bezpieczeństwo. Brzmi logicznie.

Ale @Fogo Official działa odwrotnie. Od samego początku działa tylko na jednym kliencie - na zmodyfikowanej wersji Firedancer. Powód jest taki: w scenariuszach o wysokiej częstotliwości, ostateczna prędkość sieci jest określana przez najwolniejszego klienta. Wiele klientów oznacza, że konsensus musi dostosować się do najgorzej działającego węzła, co sprawia, że szybkie nie mogą działać. Solana w rzeczywistości utknęła w tym punkcie - Firedancer w sieci testowej może osiągnąć milion TPS, ale po przejściu do sieci głównej musi współdziałać z innymi klientami, co obniża wydajność. Fogo w zasadzie pozbywa się tego obciążenia.

Niektórzy krytykują to jako centralizację, ale z innej perspektywy: jeśli celem jest osiągnięcie prędkości na poziomie Nasdaq, to wszystkie węzły muszą używać tej samej jednostki napędowej i tej samej platformy. Samochody wyścigowe F1 nie pozwolą, aby stary samochód osobowy włączył się do wyścigu, nie dlatego, że to dyskryminacja, ale dlatego, że naprawdę nie nadąża.

Kolejnym punktem jest logika selekcji walidatorów. Obecnie w głównej sieci Fogo jest tylko od 19 do 30 walidatorów, a ponadto mają jasne wymagania dotyczące sprzętu - 24-rdzeniowy CPU, 128GB pamięci RAM, 4TB NVME SSD to minimalna konfiguracja. Co ważniejsze, wymaga się, aby walidatorzy mieli doświadczenie w uruchamianiu sieci o wysokiej wydajności, takiej jak Solana czy Hyperliquid. Co to oznacza? Oznacza to, że ci, którzy mogą się dostać, nie są zwykłymi użytkownikami bawiącymi się na laptopach, lecz zespołami, które naprawdę rozumieją utrzymanie węzłów o wysokiej wydajności.

I ten "wielostrefowy konsensus", o którym wcześniej rozmawialiśmy, ale nie omówiliśmy jego mechanizmu zabezpieczającego. Fogo dynamicznie wybiera jedną strefę jako centrum wykonawcze w każdym Epoch, ale jeśli jakaś strefa napotyka problemy, a głosowanie nie spełnia standardów, sieć automatycznie przełącza się na "globalny tryb konsensusu" dla zabezpieczenia. To w zasadzie wprowadza ubezpieczenie w geograficznym rozkładzie: dążenie do prędkości, ale nie kosztem użyteczności.

Patrząc na te projekty razem, myśl Fogo jest w rzeczywistości dość jasna - nie chce stworzyć łańcucha, na którym "wszyscy mogą uruchamiać węzły", ale chce stworzyć łańcuch "wystarczająco szybki, aby instytucje chciały wejść" #fogo $FOGO