Monitorowałem czasy bloków testnetu Fogo przez tydzień przed podjęciem decyzji.

Znaczna większość osób ocenia nowe L1 na podstawie nagłówków szczytowego TPS. Ta liczba sama w sobie jest prawie bezużyteczna. Przestań oceniać łańcuchy na podstawie maksymalnej wydajności; opieraj się na spójności rozliczeń w oparciu o rzeczywiste obciążenie.

Poniżej przedstawiono mechanizm do rozważenia w odniesieniu do @Fogo Official :

- Architektura jednego klienta (czysty Firedancer) jest wolna od opóźnień konsensusu między klientami. Jedna baza kodu, jedna ścieżka wykonania, jeszcze surowsze opóźnienie p99. Devnet pokazał około 46k TPS i 40ms bloków.

- Zarejestrowany zestaw walidatorów (wielolokalny konsensus). Walidatorzy znajdują się w strategicznych lokalizacjach, eliminując geograficzne różnice w opóźnieniach. To wyraźny kompromis, aby wspierać szybkość potwierdzenia, a nie otwartość walidatora.

- Zgodność SVM implikuje narzędzia natywne dla portów Solany. Poziom tarcia w migracji jest zmniejszony, jednak tożsamość ekosystemu pozostaje problemem.

Kompromis, którego nikt nie może zignorować: jeden klient to jeden punkt awarii architektonicznej. Istnieje poważny błąd bez zapasowego klienta do przejęcia obciążenia. Fogo stawia na dyscyplinę inżynieryjną zamiast na redundancję.

Na co zwrócić uwagę w $FOGO :

- Dryf czasu bloku p99 - utrzymywany >50ms wskazuje na stres.

- Liczba ustalonych walidatorów w odniesieniu do koncentracji - kurator nie jest wciąż.

- Wolumen DEX na Ambient i Valiant - syntetyczne TPS będą bezużyteczne bez prawdziwego przepływu zleceń.

Ograniczone opcje projektowe generują bardziej wiarygodne rozliczenie lub alternatywnie mogą złamać trudniejsze. To jest nasza cała teza tutaj. #fogo

DYOR. Nie jest to porada finansowa.