blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il 22 settembre 2026 la Cosmos Hub, una catena che funziona con il consenso Tendermint, si è fermata. Il blocco 33.086.741 porta l’orario 11:18:23 UTC; il successivo, il 33.086.742, porta le 12:06:23 UTC del giorno dopo. Quell’intervallo di 24 ore e 48 minuti lo può leggere chiunque dalla catena stessa. Nessun server si era spento e nessun bug era scattato. I validatori della Hub hanno interrotto di proposito la produzione dei blocchi dopo che un attaccante, che aveva preso il controllo di alcune applicazioni su Neutron con un voto di governance, aveva spostato valore rubato sulla Hub sotto forma di ATOM, come ha riportato Protos. Quando la catena è ripartita, il suo primo blocco eseguiva una versione corretta del software che ha spostato 1.227.121,37 ATOM fuori dall’indirizzo collegato all’attaccante.
Quello stop è stato il voto BFT che funziona come progettato. Un blocco sulla Hub è definitivo quando i validatori che detengono più di due terzi del potere di voto lo hanno firmato, e quando troppi di loro si rifiutano di firmare non si muove più nulla. Questa lezione smonta quel voto: i round e i lock di Tendermint, che cosa ha cambiato il protocollo HotStuff dopo il 2018, le catene che usano i suoi discendenti, i progetti DAG che hanno abolito il leader unico e il motivo per cui tutti tengono ridotto l’insieme dei validatori.
La teoria alla base è nella nostra lezione sul problema dei generali bizantini. Il riassunto: un gruppo di n macchine riesce a mettersi d’accordo nonostante f bugiarde solo se n è almeno 3f + 1, le firme digitali cambiano i conti, PBFT ha reso pratica l’idea nel 1999 e il risultato FLP dice che nessun protocollo può essere insieme sempre sicuro e sempre vivo su una rete senza un orologio affidabile. Tendermint e HotStuff accettano entrambi questo compromesso: mantengono la sicurezza con qualunque ritardo di rete e promettono di avanzare solo quando la rete si comporta bene.
Le conseguenze per chi usa la catena sono trattate nella lezione su finalità e riorganizzazioni: un blocco confermato su una catena CometBFT è definitivo dopo un solo blocco, senza riorganizzazioni da attendere, e quando mancano troppi validatori la catena si ferma invece di dividersi. Bitcoin offre la finalità per profondità, Ethereum per voti di checkpoint ogni due epoche. Qui diamo per letti entrambi i temi e guardiamo dentro la macchina che produce quella finalità in un blocco.
La lezione precedente di questo percorso, sul delegated proof of stake, ha mostrato come vengono eletti i validatori e quanto pochi operatori possano arrivare a detenere un terzo della quota. Questa riguarda ciò che quei validatori eletti fanno, messaggio dopo messaggio, ogni pochi secondi.
Da Tendermint a CometBFT: un motore, dieci anni
Tendermint è nato dal libro bianco di Jae Kwon, «Tendermint: Consensus without Mining», che il repository di CometBFT collega ancora oggi. Ethan Buchman ha sviluppato l’algoritmo nella sua tesi di master all’Università di Guelph, «Tendermint: Byzantine Fault Tolerance in the Age of Blockchains», che la biblioteca universitaria registra come pubblicata il 23 giugno 2016. La versione formale è arrivata il 13 luglio 2018, quando Buchman, Kwon e Zarko Milosevic hanno pubblicato su arXiv «The latest gossip on BFT consensus», rivisto per l’ultima volta nel novembre 2019.
L’articolo parte da un contrasto. La replica classica di macchine a stati girava nei data center con «da tre a sette» repliche gestite da un’unica organizzazione. Una blockchain pubblica ha bisogno di centinaia di validatori distribuiti tra aziende e paesi, collegati solo dalla rete internet aperta. La risposta di Tendermint è stata mantenere il voto in stile PBFT e consegnare ogni messaggio con un protocollo di gossip tra nodi vicini, così che ogni validatore debba parlare solo con i propri vicini.
La seconda idea è la separazione dei compiti. Tendermint mette in ordine le transazioni e lascia il loro significato a un’applicazione collegata tramite un’interfaccia, ABCI. Il Cosmos SDK è uno di questi framework applicativi, ed è per questo che «Cosmos» e «Tendermint» vengono spesso confusi: l’SDK decide che cosa fa una transazione, il motore di consenso decide in quale ordine le transazioni diventano definitive.
La separazione è arrivata a cavallo del 2023. Il 5 gennaio Jae Kwon ha congelato l’insieme delle funzionalità di Tendermint Core alla linea 0.34, la versione che la Cosmos Hub usava allora, e ha annotato nel repository che il team di Informal Systems aveva creato un fork chiamato CometBFT. Informal Systems ha annunciato quel fork il 1° febbraio 2023 come un fork e un successore di Tendermint Core, e la prima versione, la v0.34.27, è seguita il 27 febbraio. Il README del progetto lo dice oggi senza giri di parole: CometBFT è un fork di Tendermint Core e implementa l’algoritmo di consenso Tendermint. Il nome è cambiato, l’algoritmo no.
Il motore è ancora mantenuto. La versione v0.40.0, pubblicata il 27 luglio 2026, ha aggiunto un tipo di chiave per validatori resistente ai computer quantistici, mldsa65, basato sullo standard di firma ML-DSA, e la v0.38.26 ne ha portato indietro la verifica il 13 agosto 2026. I nodi pubblici della Cosmos Hub interrogati l’8 novembre 2026 riportavano CometBFT v0.38.25. Diverse catene della famiglia, tra cui Celestia e dYdX, usano propri fork del motore, quindi il numero di versione cambia da una rete all’altra, e talvolta da un nodo all’altro.
Come funziona il consenso Tendermint, un round alla volta
Tendermint decide un blocco per ogni altezza. Ogni altezza esegue uno o più round, e ogni round ha tre passi: proposta, prevote, precommit. Se un round fallisce, il successivo parte con un nuovo proposer e la stessa altezza. Le regole che seguono si basano sulla specifica di consenso di CometBFT così come era pubblicata l’8 novembre 2026.
Proposta, prevote, precommit
Il proposer di ogni round viene scelto con una rotazione deterministica che la specifica descrive come pesata sul potere di voto: un validatore con il doppio della quota propone il doppio delle volte. Ogni nodo può calcolare chi sia il proposer, quindi non serve alcun messaggio di elezione. Il proposer costruisce un blocco e lo diffonde in gossip.
Nel passo di prevote ogni validatore firma un prevote per quel blocco se lo ha ricevuto in tempo e lo ritiene valido. Altrimenti esprime un prevote nil, un voto esplicito per il nulla. I voti si contano per potere di voto, non per numero di teste. La specifica scrive «+2/3» per più di due terzi del potere di voto e «1/3+» per un terzo o più.
Quando un validatore vede più di due terzi di prevote per lo stesso blocco, passa al precommit e firma un precommit per quel blocco. Quando poi vede più di due terzi di precommit per esso, il blocco è confermato e l’altezza è chiusa. Sulla Cosmos Hub, dove l’8 novembre 2026 c’erano 180 validatori nell’insieme attivo, questo significa firme che rappresentano più di due terzi degli ATOM vincolati, qualunque sia il numero di validatori che le hanno prodotte.
Servono due voti perché uno solo non basta a essere certi che gli altri abbiano visto la stessa cosa. Un quorum di prevote dice a un validatore che la rete, in questo round, si è accordata su un solo candidato. Un quorum di precommit gli dice che più di due terzi del potere lo sa a sua volta e si è impegnato a mantenerlo.
Perché un validatore si vincola a un blocco
Quell’impegno è il lock. Un insieme di più di due terzi di prevote per un blocco in un round si chiama proof-of-lock-change, o PoLC. Un validatore che vede una PoLC per il blocco B e fa il precommit di B resta vincolato a B. Nei round successivi della stessa altezza fa di nuovo il prevote di B, qualunque cosa offra il nuovo proposer, e libera il lock solo se vede una PoLC per qualcos’altro in un round successivo.
L’argomento di sicurezza, come lo dà la specifica, sta in poche righe. Si supponga che meno di un terzo del potere di voto sia bizantino. Se un validatore ha confermato B al round R, ha visto più di due terzi di precommit per B in R. Tolto da quel gruppo il terzo disonesto, resta più di un terzo del potere che è onesto e vincolato a B. Quei validatori non faranno il prevote di nient’altro, quindi nessun altro blocco potrà mai raccogliere i più di due terzi che gli servono. Due conferme in conflitto alla stessa altezza richiederebbero che più di un terzo dei validatori firmi entrambe, e questa è una prova che la catena sa dimostrare e punire, come spiega la nostra lezione su slashing e ricompense dei validatori.
I lock potrebbero bloccare una catena se validatori onesti diversi avessero lock diversi. L’articolo del 2018 risolve il problema con due variabili per validatore, il valore vincolato e il valore valido: un proposer successivo ripropone il blocco che per ultimo ha raccolto una PoLC, e i validatori vincolati a un round più vecchio possono accettarlo. Il progresso riprende non appena un round va bene.
Timeout, round aggiuntivi e il costo dell’attesa
La specifica elenca quattro motivi per cui un round può fallire: il proposer è offline, il suo blocco non è valido, il blocco non si è diffuso in tempo, oppure i prevote e i precommit non sono arrivati in tempo. Per questo ogni passo ha un timer. Nell’articolo del 2018 ogni timeout cresce con il numero del round, come un valore iniziale più il round moltiplicato per un incremento fisso, e si azzera a ogni nuova altezza. Una rete lenta allunga i round finché i messaggi non ci stanno dentro.
Dopo una conferma, i nodi attendono anche un timeoutCommit fisso per raccogliere le firme in ritardo prima di iniziare l’altezza successiva. Quelle attese fanno parte del tempo di blocco. Misurata su 1.000 blocchi l’8 novembre 2026, tra le 08:11:35 e le 09:46:45 UTC, la Cosmos Hub ha prodotto in media un blocco ogni 5,71 secondi. Osmosis, anch’essa su CometBFT, ha avuto una media di 0,84 secondi su un campione dello stesso tipo: il voto è lo stesso, i parametri no.
L’attesa è anche il punto su cui hanno puntato le critiche. Gli autori di HotStuff sostengono che progetti come Tendermint e Casper precludono la responsiveness. Il loro ragionamento: un nuovo proposer in Tendermint deve aspettare il ritardo massimo di rete noto per essere sicuro di aver saputo del lock più alto detenuto da un validatore onesto. Una catena non può andare più veloce di quel timer, nemmeno quando la rete è veloce.
Gossip invece di un raccoglitore centrale
In Tendermint ogni validatore trasmette il proprio prevote e il proprio precommit, e ogni altro validatore deve riceverli e controllarli. Con n validatori sono circa n al quadrato verifiche di firma per ogni passo, sull’intera rete. L’abstract dell’articolo dice che il progetto semplifica il BFT classico appoggiandosi a un protocollo di gossip tra i nodi. Il gossip mantiene il flusso dei messaggi anche quando alcuni collegamenti cadono, al prezzo di un traffico che cresce in fretta con n.
Tre stop sulle catene Cosmos, tre cause diverse
Poiché Tendermint sceglie la sicurezza rispetto alla vitalità, i suoi guasti sembrano tutti uguali visti da fuori: i blocchi si fermano. Le cause dietro tre stop su catene Cosmos sono invece molto diverse. (Gli stop di Terra del maggio 2022, durante il crollo di LUNA, sono raccontati nella lezione sui generali bizantini.)
| Catena | Date | Durata | Causa | Seguito |
|---|---|---|---|---|
| Neutron (protetta dai validatori della Cosmos Hub) | 1° agosto 2023 | Non indicata nelle fonti usate | Stop dopo un aggiornamento software; due validatori hanno firmato due volte aggiornando in fretta | Proposta 818 della Hub per applicare lo slashing, respinta il 24 agosto 2023 |
| Cosmos Hub | 5-6 giugno 2024 | Circa 4 h 40 min (dalle 19:21 alle 00:02 UTC) | Panic in GetLastValidators: più di 180 validatori vincolati dopo un unjail | Gaia v17.2.0, correzione del Cosmos SDK |
| Cosmos Hub | 22-23 settembre 2026 | 24 h 48 min tra i blocchi 33.086.741 e 33.086.742 | I validatori hanno smesso di firmare dopo l’attacco di governance a Neutron | Gaia corretta ha spostato 1.227.121,37 ATOM a un indirizzo di recupero; proposta 1056 respinta con veto |
Fonti: Informal Systems (agosto 2023), proposte 818 e 1056 della Cosmos Hub lette sulla catena, post-mortem della v17.1 della Cosmos Hub sul forum Cosmos, tempi di blocco letti sulla Cosmos Hub l’8 novembre 2026, Protos e CryptoSlate (settembre 2026).
Agosto 2023: Neutron si ferma e due validatori firmano due volte
Neutron, una catena allora protetta dai validatori della Cosmos Hub con la sicurezza replicata della Hub, si è fermata il 1° agosto 2023 dopo un aggiornamento software andato storto. Nella fretta di aggiornare, due validatori hanno cancellato il file che impedisce a un nodo CometBFT di firmare due volte alla stessa altezza, ed entrambi hanno firmato blocchi in conflitto, secondo un post-mortem di Informal Systems pubblicato il 17 agosto 2023. La proposta 818 della Hub, intitolata «Punish Equivocation on Neutron by Pupmos and Citizen Cosmos», chiedeva ai possessori di ATOM di applicare lo slashing. È stata respinta il 24 agosto 2023: circa 100,3 milioni di ATOM hanno votato no, 23,8 milioni sì, 16,2 milioni si sono astenuti e 2,0 milioni hanno posto il veto, secondo il conteggio della proposta sulla catena.
L’episodio mostra un lato della sicurezza BFT che le dimostrazioni lasciano fuori. Il motore ha registrato la prova della doppia firma, che chiunque poteva interrogare da un nodo Neutron. Se punirla o no era una questione politica, e chi fa staking ha risposto che un incidente avvenuto in un’emergenza non meritava un taglio.
Giugno 2024: un panic a 180 validatori
Il 5 giugno 2024 la Cosmos Hub è passata alla v17 tra le 16:58 e le 17:15 UTC. Alle 19:21 UTC si è fermata al blocco 20.740.970 e non ha prodotto il blocco 20.740.972 fino alle 00:02 UTC del 6 giugno, circa 4 ore e 40 minuti dopo, secondo il post-mortem sul forum Cosmos.
La causa è stata un panic in una funzione chiamata GetLastValidators, eseguita alla fine di ogni blocco. Una transazione di unjail ha messo per un attimo un validatore di troppo nell’insieme vincolato, e il codice ha trovato più del massimo di 180 validatori vincolati. Ogni nodo onesto ha incontrato lo stesso panic alla stessa altezza, quindi la catena si è fermata invece di divergere. La correzione è arrivata come Gaia v17.2.0 con un Cosmos SDK corretto. Il numero 180 è una scelta di governance, ed è anche cablato nella macchina a stati.
Settembre 2026: fermarsi di proposito
Lo stop di settembre 2026 è partito da Neutron. Lì è stata approvata una proposta di governance chiamata «AI Agent Takeover», che ha dato al suo autore il controllo di due applicazioni, Astroport e Drop, secondo Protos, che ha riferito come l’attaccante abbia speso circa 20.199 dollari in token NTRN per far passare il voto. Le stime della perdita divergono: Protos ha indicato perdite iniziali di 9,5 milioni di dollari, mentre un collaboratore di Neutron citato da CryptoSlate ha collocato il primo impatto intorno a 4,4 milioni. Parte del valore è arrivata sulla Cosmos Hub sotto forma di ATOM.
I validatori della Hub hanno quindi smesso di firmare, dopo il blocco 33.086.741. Perché una catena Tendermint si fermi, basta che validatori con più di un terzo del potere di voto restino in silenzio; la stampa non ha pubblicato chi abbia smesso per primo né in quale ordine. La catena è ripartita il 23 settembre 2026 intorno alle 12:06 UTC con una versione corretta di Gaia, e il suo primo nuovo blocco ha spostato 1.227.121,37 ATOM, circa 2,2 milioni di dollari all’epoca secondo CryptoSlate, verso un indirizzo di recupero controllato da un gruppo di validatori. La correzione non ha potuto intercettare tutto: 168.990,9 ATOM rimborsati da THORChain sono arrivati all’indirizzo collegato all’attaccante sette blocchi dopo la ripartenza, poi sono passati a Osmosis e sono stati venduti per circa 266.841 USDC, secondo un analista on-chain citato da CryptoSlate.
Una proposta sulla Hub, la numero 1056, ha poi chiesto al community pool di pagare 1.221.120 ATOM all’indirizzo collegato all’attaccante, descrivendo il sequestro come un furto, più un «justice bounty» da 500.000 ATOM per chi votava sì. Il voto si è chiuso il 30 settembre 2026 alle 23:20 UTC ed è stata respinta: circa 91,5 milioni di ATOM hanno votato no con veto, 6,0 milioni no, 3,9 milioni si sono astenuti e 0,6 milioni hanno votato sì, vicino al 90% di veto secondo la nostra lettura del conteggio sulla catena.
Che cosa mostra un halt e che cosa no
Nessuno di questi stop ha infranto la sicurezza. Mai due blocchi in conflitto sono stati definitivi alla stessa altezza. Mostrano dove sta il potere. La regola che permette a più di due terzi di rendere definitivo un blocco permette anche a un terzo di congelare una catena, e permette a una supermaggioranza di farla ripartire con una modifica di stato che nessuna transazione ha firmato. C’è chi definisce il settembre 2026 un salvataggio d’emergenza e chi un precedente di censura. Il protocollo non ha opinioni: conta solo le firme.
HotStuff: un solo leader raccoglie i voti
Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta e Ittai Abraham hanno pubblicato su arXiv HotStuff il 13 marzo 2018; una versione breve è stata presentata alla conferenza PODC nel 2019. Mantiene il modello parzialmente sincrono di PBFT e Tendermint e attacca due costi: il prezzo della sostituzione di un leader e l’attesa che rende Tendermint più lento della rete.
Il problema: i cambi di leader costosi
In PBFT, cambiare leader (un view change, cioè un cambio di vista) significa che ogni replica invia le proprie prove al nuovo leader, che deve inoltrare la dimostrazione di tutte: secondo il conto dell’articolo, O(n^3) autenticatori. Con quattro repliche non è nulla. Con un centinaio di validatori o più sparsi per il mondo, un solo leader difettoso diventa costoso, e una catena ruota i leader a ogni blocco. Tendermint ha evitato il cambio di vista pesante aspettando un ritardo fisso, che è il problema di responsiveness visto sopra.
Quorum certificate e tre fasi
HotStuff invia ogni voto al leader invece che a tutti. Il leader raccoglie i voti di n meno f repliche e li combina, con una firma a soglia, in un unico quorum certificate (QC): una prova compatta che un quorum si è accordato. Poi il leader trasmette il QC. Il traffico per decisione diventa lineare in n.
Una decisione attraversa fasi chiamate prepare, pre-commit e commit, ciascuna conclusa da un QC. Una replica si vincola quando vede il QC di pre-commit, e un blocco è deciso quando esiste il suo QC di commit. Un nuovo leader parte dal QC più alto ricevuto da n meno f repliche e non deve aspettare la più lenta: è quella che gli autori chiamano responsiveness ottimistica, il protocollo si muove alla velocità della rete reale.
Chained HotStuff: un voto, tre compiti
La versione pratica dell’articolo mette le fasi in pipeline. Ogni nuovo blocco porta il QC del genitore, e quel singolo voto vale come fase di prepare per il blocco più recente, come fase di pre-commit per il genitore e come fase di commit per il nonno. Quando un blocco ottiene un figlio con un QC forma una catena di uno; con un nipote, una catena di due, e a quel punto le repliche si vincolano; con un pronipote in viste consecutive, una catena di tre, e il più vecchio dei tre viene confermato.
A regime si propone un nuovo blocco a ogni vista e uno più vecchio diventa definitivo allo stesso ritmo. Un unico schema di messaggi, ripetuto, fa tutto il lavoro. Questa regolarità è una buona parte del motivo per cui HotStuff è diventato il modello delle catene costruite dopo il 2019.
Che cosa paga HotStuff: una fase in più
La terza fase non è un ornamento. L’articolo spiega che un protocollo a due fasi con cambio di vista lineare può bloccarsi: un nuovo leader può non sapere di un lock detenuto da una replica onesta, proporre altro e non ottenere il quorum, ripetutamente. Tendermint lo risolve aspettando; HotStuff lo risolve aggiungendo una fase, in modo che basti un leader che possiede il QC più alto. Gli autori lo definiscono un piccolo prezzo in termini di latenza.
| Protocollo | Leader corretto | Leader sostituito | f leader falliscono di fila | Responsive |
|---|---|---|---|---|
| PBFT | O(n2) | O(n3) | O(f n3) | Sì |
| SBFT | O(n) | O(n2) | O(f n2) | Sì |
| Tendermint / Casper | O(n2) | O(n2) | O(f n2) | No |
| Tendermint* / Casper* (con firme a soglia) | O(n) | O(n) | O(f n) | No |
| HotStuff | O(n) | O(n) | O(f n) | Sì |
Autenticatori (firme o MAC) inviati per decisione dopo che la rete si è stabilizzata, con n validatori e f difettosi. Fonte: tabella 1 dell’articolo su HotStuff, arXiv 1803.05069, versione del 23 luglio 2019. Le righe con l’asterisco sono la stima degli autori per una variante che i lavori originali non descrivevano.
La tabella è il confronto degli stessi autori di HotStuff, non un benchmark neutrale. La loro riga Tendermint* con nota conta: con le firme a soglia, che i lavori originali non descrivevano, anche il numero di messaggi di Tendermint sarebbe lineare. La differenza reale è la responsiveness, non il conteggio grezzo dei messaggi.
Dopo HotStuff: eredi e rivali
LibraBFT e DiemBFT
Il primo grande utilizzatore è stato il progetto Libra di Facebook, il cui rapporto tecnico del 2019 dice senza ambiguità che il suo nucleo di consenso è basato su HotStuff, con aggiunte proprie come un meccanismo di sincronizzazione dei round; il protocollo è stato poi ribattezzato DiemBFT. Il progetto è finito quando il Diem Group ha venduto i propri asset tecnologici a Silvergate, un accordo annunciato il 31 gennaio 2022 e valutato circa 182 milioni di dollari tra contanti e azioni. Gli ingegneri che avevano lavorato a Diem e al wallet Novi di Meta hanno poi fondato Aptos Labs e Mysten Labs, la società dietro Sui, come ha riportato The Block nel dicembre 2021 e nel marzo 2022.
Jolteon: ritorno a due fasi
Nel giugno 2021 un gruppo che comprendeva Rati Gelashvili, Lefteris Kokoris-Kogias e Alberto Sonnino ha pubblicato Jolteon, una variante di HotStuff a catena di due. Conferma dopo due QC invece di tre e lo paga con un cambio di vista quadratico, il costo che HotStuff aveva eliminato. La scommessa è che i leader falliscano di rado, quindi un caso comune più rapido vale un recupero più pesante. L’articolo riporta nei suoi test una latenza di conferma inferiore a quella di HotStuff di 200-300 millisecondi.
Aptos: AptosBFT, Baby Raptr e blocchi a un solo hop
Aptos documenta il proprio consenso solo come AptosBFT, un protocollo che tollera fino a un terzo di validatori malevoli. Le sue proposte di miglioramento mostrano la direzione. AIP-106, «Baby Raptr», segnata come Final, permette al consenso di proporre lotti di transazioni prima che sia raccolta la loro prova di archiviazione, togliendo dal percorso circa 180 millisecondi, due hop di rete (misura sulla mainnet di Aptos del 30 ottobre 2024). AIP-131, anch’essa Final, permette ai leader di proporre un blocco senza aspettare il QC del genitore, così il tempo di blocco passa da due hop di rete a uno.
La catena è veloce a prescindere dalla combinazione di queste modifiche oggi attiva. Tra le altezze di ledger 1.169.571.873 e 1.169.581.873, lette intorno alle 09:47 UTC dell’8 novembre 2026, Aptos ha prodotto 10.000 blocchi in 375 secondi, uno ogni 37,5 millisecondi in media, con 83 validatori attivi. È la distanza tra i blocchi, blocchi vuoti compresi, non un tempo di finalità né un numero di transazioni al secondo.
MonadBFT: un progetto rivale con finalità speculativa
Monad sta accanto alla famiglia, non dentro. La sua documentazione non presenta MonadBFT come una versione di HotStuff; lo misura rispetto ai protocolli di consenso in pipeline della famiglia HotStuff e ai loro punti deboli. La documentazione dà a MonadBFT un tempo minimo di blocco di 300 millisecondi, finalità speculativa dopo uno slot (300 ms) e finalità piena dopo due (600 ms). Dichiara una complessità lineare di messaggi e autenticatori nel caso felice e una protezione contro il tail-forking, in cui un leader malevolo scarta il blocco del predecessore per appropriarsi del suo valore. Secondo la documentazione, quei progetti in pipeline precedenti perdono spesso coppie di slot quando un leader salta il proprio turno, cosa che MonadBFT è costruito per evitare.
HyperBFT dietro un exchange
Hyperliquid, l’exchange di derivati on-chain, descrive il proprio consenso come una variante di HotStuff nella sua documentazione. Le cifre che pubblica riguardano il trading, non i blocchi: una latenza end-to-end mediana di 0,2 secondi e di 0,9 secondi al 99° percentile, e circa 200.000 ordini al secondo sulla mainnet. La nostra pagina sulla moneta HYPE tratta il token.
Consenso DAG: molti proposer, nessun leader unico per blocco
I protocolli a leader hanno un collo di bottiglia in comune: un validatore per round deve ricevere, impacchettare e inviare tutto il blocco. Una seconda linea di ricerca, costruita da diversi degli stessi autori, distribuisce quel lavoro tra tutti.
Narwhal: diffondere i dati separatamente dall’ordinarli
Narwhal e Tusk, pubblicati il 25 maggio 2021 da George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino e Alexander Spiegelman, dividono il lavoro in due. In Narwhal ogni validatore pubblica lotti di transazioni a round, ciascun lotto richiama i lotti del round precedente, e così si costruisce un grafo aciclico diretto (DAG) di dati certificati. L’ordinamento è poi un passo separato e leggero. Nei test in rete geografica dell’articolo, Narwhal combinato con HotStuff ha superato le 130.000 transazioni al secondo, e Tusk, un livello di ordinamento asincrono, ha raggiunto circa 160.000 con circa 3 secondi di latenza.
Bullshark, poi Mysticeti su Sui
Bullshark, pubblicato il 14 gennaio 2022, ordina lo stesso DAG con una regola parzialmente sincrona e ha riportato 125.000 transazioni al secondo con circa 2 secondi di latenza con 50 partecipanti. Mysticeti, pubblicato il 23 ottobre 2023, va oltre: i blocchi del suo DAG non sono certificati uno a uno, il che elimina dei round di messaggi, e i blocchi possono essere confermati direttamente dallo schema dei riferimenti che li sovrastano.
Sui ha adottato Mysticeti sulla mainnet nell’estate del 2024. La sua documentazione descrive Mysticeti come un protocollo di consenso basato su un grafo aciclico diretto e non cita HotStuff. Non è un discendente di HotStuff: non c’è un leader unico che raccoglie voti in una catena di QC, anche se le due famiglie condividono autori e la stessa regola del quorum a due terzi. Nell’epoca 1305, iniziata l’8 novembre 2026, la rete Sui aveva 125 validatori attivi.
I numeri pubblicati richiedono cautela. La documentazione di Sui cita risultati di benchmark di circa mezzo secondo per la conferma e un throughput molto alto, e precisa che non sono metriche di produzione. Gli articoli testano su reti controllate; una catena viva con validatori disomogenei e carico reale si comporta in modo diverso.
Perché gli insiemi di validatori restano piccoli
Ogni protocollo di questa lezione ha bisogno, per ogni decisione, di firme che rappresentino più di due terzi del potere di voto. È questo il prezzo che fissa la dimensione dell’insieme dei validatori.
Contare le firme
Prendiamo il progetto con gossip. Con 180 validatori, ciascuno dei quali invia un prevote e un precommit che ogni altro validatore controlla, un round significa circa 180 per 180 per 2, cioè 64.800 verifiche di firma sull’intera rete. Con 1.000 validatori sono due milioni. Le firme aggregate e un leader che raccoglie i voti riducono il traffico, ma ogni voto deve comunque essere prodotto, inviato e verificato entro un tempo di blocco misurato in secondi o meno.
Il tetto è scritto nelle catene. L’8 novembre 2026 i parametri di staking indicavano Cosmos Hub 180, Celestia 100, Injective 45, Sei 40, Osmosis 30 e dYdX 21. Come ha mostrato il panic del giugno 2024, il limite della Hub è anche una regola rigida nel suo codice.
Un insieme piccolo vuol dire un elenco corto di nomi
Più piccolo è l’insieme, meno operatori servono per fermarlo o per finalizzare. Secondo un nostro calcolo sui dati della catena dell’8 novembre 2026, senza unire i validatori gestiti dalla stessa entità, i 4 maggiori validatori della Cosmos Hub detenevano più di un terzo della quota vincolata, come aveva rilevato anche la lezione sul delegated proof of stake. Su Aptos i 14 maggiori su 83 validatori superavano un terzo del potere di voto; su Sui, i 18 maggiori su 125. Sono le coalizioni che potrebbero fermare ciascuna catena restando in silenzio.
La versione del problema di Ethereum
Ethereum mostra la scelta opposta. Ha circa un milione di validatori registrati e finalizza con checkpoint ogni due epoche invece che a ogni blocco. Nella sua nota sulle strade verso la single-slot finality, scritta quando i validatori attivi erano 445.064, Vitalik Buterin scrive: «We cannot quite take Tendermint or another existing BFT algorithm as-is» (in inglese: non possiamo adottare Tendermint o un altro algoritmo BFT esistente così com’è). Tendermint si ferma quando più di un terzo dei validatori va offline, mentre Ethereum è costruito per continuare a produrre blocchi, quindi sopra qualunque voto servono una regola di fork choice e un inactivity leak. Aggiunge che elaborare centinaia di migliaia di firme per slot è possibile, ed è per questo che le proposte abbinano una finalità più rapida a validatori meno numerosi e più grandi. La nostra lezione sul proof of stake spiegato a fondo tratta il modo in cui i validatori di Ethereum votano oggi.
La ricerca non si ferma. Minimmit, pubblicato il 14 agosto 2025 da Chou, Lewis-Pye e O’Grady, appartiene a un gruppo di protocolli che finalizzano dopo un solo round di voti, due contando la proposta, accettando un’ipotesi più severa: n almeno 5f + 1, cioè meno di un quinto dei validatori può essere difettoso invece di un terzo. In una simulazione con 50 processori distribuiti su dieci regioni virtuali, gli autori hanno misurato una latenza di vista inferiore del 23,1% e una latenza delle transazioni inferiore del 10,7% rispetto ai protocolli confrontati.
Le catene BFT a confronto, 8 novembre 2026
| Catena | Consenso | Famiglia | Validatori attivi (tetto) | Tempo di blocco o finalità |
|---|---|---|---|---|
| Cosmos Hub | CometBFT v0.38 | Tendermint | 180 (tetto 180) | 5,71 s per blocco, definitivo in un blocco (misurato) |
| Celestia | Basato su CometBFT | Tendermint | 100 (tetto 100) | 2,85 s per blocco (misurato) |
| Injective | Basato su CometBFT | Tendermint | 45 (tetto 45) | 0,60 s per blocco (misurato) |
| dYdX Chain | Basato su CometBFT | Tendermint | 21 (tetto 21) | 0,64 s per blocco (misurato) |
| Osmosis | CometBFT | Tendermint | 30 (tetto 30) | 0,84 s per blocco (misurato) |
| Sei | Fork Tendermint proprio di Sei (i nodi riportano v0.35) | Tendermint | 40 (tetto 40) | 0,47 s per blocco (misurato) |
| Aptos | AptosBFT | Linea HotStuff (eredità Diem; Baby Raptr e proposte ottimistiche secondo le sue AIP) | 83 | 37,5 ms tra i blocchi (misurato, blocchi vuoti compresi) |
| Monad | MonadBFT | In pipeline, confrontato dalla sua documentazione con i protocolli della famiglia HotStuff | Non pubblicato nelle fonti usate | 300 ms speculativa, 600 ms finalità piena (documentazione) |
| Hyperliquid | HyperBFT | «Una variante di HotStuff» (documentazione) | Non letto | 0,2 s di latenza mediana degli ordini (documentazione, non finalità) |
| Sui | Mysticeti | DAG (linea Narwhal e Bullshark) | 125 (epoca 1305) | Non misurato; la documentazione dà solo cifre di benchmark |
Cifre misurate: media sugli ultimi 1.000 blocchi (10.000 su Aptos), lette tra le 09:45 e le 09:55 UTC circa dell’8 novembre 2026 dall’API pubblica di ciascuna catena; tetti dai parametri di staking; versione del motore della Cosmos Hub dalle informazioni del nodo. «Basato su CometBFT» comprende le catene che usano CometBFT o un proprio fork. Monad e Hyperliquid: la loro documentazione, letta l’8 novembre 2026.
La tabella va letta con i suoi limiti. Su una catena CometBFT la distanza tra i blocchi coincide con il tempo di finalità, perché un blocco confermato è definitivo. Su Aptos la distanza include i blocchi vuoti e non dice nulla su quanto una transazione debba attendere. Le cifre di Monad e Hyperliquid vengono dalla loro stessa documentazione, non da una nostra misura.
Cinque domande da porre a qualunque catena BFT
Quando una nuova catena pubblicizza una finalità rapida, cinque domande la collocano sulla mappa tracciata in questa lezione. Quale quota del potere di voto può fermarla, ed è già successo? Un blocco è definitivo subito, o dopo due o più slot? Quanti validatori ci sono nell’insieme, c’è un tetto e quanti di loro detengono un terzo della quota? Un leader per round raccoglie i voti, oppure è un DAG con molti proposer? E com’è stato l’ultimo halt: un bug, un disallineamento o una decisione?
Nessuna di queste risposte classifica una catena come buona o cattiva. Mostrano dove un progetto ha speso il proprio budget: Tendermint aspetta perché le sue regole restino semplici, mentre Jolteon ha accettato un recupero più pesante per togliere qualche centinaio di millisecondi al caso comune. Altro contesto sulle famiglie di consenso si trova nel nostro panoramico su che cos’è il consenso, e le catene Cosmos della tabella hanno pagine proprie, per esempio Osmosis e Celestia.
La prossima lezione di questo percorso passa a Solana: la proof of history, l’orologio tenuto dai suoi leader di blocco, e Alpenglow, il sistema di voto che la rete ha attivato nell’ottobre 2026.
