Ho monitorato i tempi di blocco del testnet di Fogo durante una settimana prima di emettere un giudizio.
La stragrande maggioranza degli individui considera i nuovi L1 in base ai titoli dei picchi di TPS. Quel numero da solo è quasi inutile. Smetti di basare il giudizio sulle catene in base al soffitto di throughput; basato sulla coerenza del regolamento in base al carico effettivo.
Il seguente è il meccanismo da considerare riguardo a @Fogo Official :
- Architettura a client singolo (pure Firedancer) è un consenso cross client senza attrito. Un'unica base di codice, un unico percorso di esecuzione, anche latenza p99 più rigorosa. Devnet ha mostrato circa 46k TPS e blocchi di 40ms.
- Set di validatori registrati (consenso multi-locale). I validatori si trovano in posizioni strategiche, eliminando la variazione di latenza geografica. Questo è un chiaro compromesso per supportare la velocità di conferma e non l'apertura del validatore.
- La compatibilità SVM implica gli strumenti dei porti nativi di Solana. Il livello di attrito nella migrazione è ridotto, ma l'identità dell'ecosistema rimane un problema.
Il compromesso che nessuno può trascurare: un client è un punto di fallimento architettonico. C'è un bug serio senza un client di riserva per gestire il carico. Fogo sta scommettendo sulla disciplina ingegneristica piuttosto che sulla ridondanza.
Cosa osservare su $FOGO :
- deriva del tempo di blocco p99 - mantenuto >50ms indica stress.
- Il numero di validatori impostati rispetto alla concentrazione - curato non è ancora fermo.
- Il volume DEX su Ambient e Valiant - TPS sintetico non sarà utile senza un vero flusso d'ordine.
Opzioni di design limitate generano regolamenti più credibili o alternativamente possono rompere più difficilmente. Questa è la nostra intera tesi qui. #fogo
DYOR. Non è un consiglio finanziario.
