Fogo jest łatwiejszy do zrozumienia, gdy przestaniesz myśleć o nim jako o „kolejnej warstwie 1” i zamiast tego zobaczysz go jako silnik wykonawczy zbudowany specjalnie do działalności on-chain o dużej częstotliwości. Działa na Wirtualnej Maszynie Solana, co oznacza, że deweloperzy zaznajomieni z środowiskami SVM mogą wdrażać bez ponownego uczenia się wszystkiego. Ale prawdziwa różnica tkwi w intencji architektonicznej.
Większość łańcuchów ogólnego przeznaczenia stara się wspierać każdy przypadek użycia w równym stopniu. Fogo przyjmuje węższy punkt widzenia. Został zbudowany z myślą o infrastrukturze natywnej dla handlu. Mechanika książki zamówień nie jest traktowana jako dodatki. Kształtują one sposób, w jaki łańcuch obsługuje aktualizacje stanu i przepływ transakcji. Ten wybór projektowy wpływa na wszystko, od oczekiwań dotyczących opóźnień po zachowanie walidatorów.
Wydajność tutaj jest mniej zależna od szczytowych liczb, a bardziej od spójności. Architektura podąża za modelem klienta o wysokiej wydajności, podobnym w filozofii do wykonania w stylu Firedancer. Pomyśl o tym jak o poszerzaniu konkretnych pasów autostrady dla ruchu towarowego, a nie o rozszerzaniu całej sieci drogowej. Zator staje się bardziej przewidywalny. Przepustowość staje się mniej zmienna.
Ponieważ Fogo korzysta z kompatybilności SVM, przenośność narzędzi ma znaczenie. Istniejący deweloperzy Solany mogą eksperymentować bez porzucania swojego stosu. Konto projektu, @Fogo Official , podkreśla niezawodność wykonania ponad rozprzestrzenianie funkcji. To sygnalizuje inną priorytet w porównaniu z łańcuchami goniącymi za szerokimi narracjami.
Niemniej jednak, wyzwania pozostają. Sieci oparte na SVM rosną w liczbie. Dystrybucja walidatorów zajmuje czas. Głębokość ekosystemu nie pojawia się z dnia na dzień. Token $FOGO i szersza dyskusja #Fogo odzwierciedlają eksperyment w skoncentrowanej infrastrukturze, a nie rozszerzaniu dla samego rozszerzenia.
Niektóre sieci dążą do bycia wszystkim. Fogo wydaje się komfortowo próbować być precyzyjnym
