Proteggere la blockchain: il ruolo della tolleranza ai guasti bizantini

Ogni volta che invii una transazione in criptovaluta, ricevi un pagamento o interagisci con uno smart contract, una rete di computer che non si conoscono e non si fidano l'uno dell'altro deve concordare sulla validità della transazione e sulla sua registrazione permanente. Alcuni di questi computer potrebbero essere offline. Altri potrebbero essere controllati da malintenzionati che inviano deliberatamente informazioni false. Ciononostante, la blockchain deve giungere alla stessa conclusione corretta su ogni nodo onesto.

Il meccanismo che rende possibile tutto ciò è la tolleranza ai guasti bizantini (BFT). Si tratta di uno dei concetti più importanti e meno compresi nei sistemi distribuiti, che costituisce il fondamento di sicurezza sottostante. La tecnologia blockchainfinanza decentralizzata, registri aziendali e Internet delle cose.

Questa guida illustra la tolleranza ai guasti bizantini, dai principi fondamentali alle implementazioni moderne più avanzate, confrontandola con Proof of Work e Proof of Stake, i vettori di attacco specifici da cui protegge, i protocolli che si basano su di essa oggi e le sfide che i ricercatori stanno ancora cercando di risolvere.

Il problema dei generali bizantini: dove tutto ebbe inizio

Per comprendere la tolleranza ai guasti bizantini, è necessario comprendere il problema che è stato progettato per risolvere. Il problema dei generali bizantini fu descritto formalmente per la prima volta nel 1982 dagli informatici Leslie Lamport, Robert Shostak e Marshall Pease in un articolo intitolato "The Byzantine Generals Problem", pubblicato sulla rivista ACM Transactions on Programming Languages ​​and Systems.

Il problema viene presentato come un'analogia militare. Immaginate diverse divisioni di un esercito bizantino che circondano una città nemica. Ogni divisione è comandata da un generale e le divisioni possono comunicare tra loro solo tramite messaggeri. Devono concordare un piano d'azione comune: attaccare o ritirarsi. Se attaccano tutte insieme, vincono. Se si ritirano tutte insieme, sopravvivono. Ma se alcune attaccano mentre altre si ritirano, vengono distrutte.

La complicazione sta nel fatto che alcuni generali potrebbero essere dei traditori. Un traditore potrebbe inviare messaggi diversi a generali diversi, dicendo ad alcuni di "attaccare" e ad altri di "ritirarsi", con l'obiettivo deliberato di impedire un accordo. I generali leali non possono semplicemente ignorare i messaggi che sospettano siano falsi, perché non sono in grado di identificare immediatamente quali generali siano dei traditori.

Il problema si pone la seguente domanda: quale algoritmo possono utilizzare i generali leali per garantire che tutti giungano alla stessa decisione, anche quando una parte di essi è composta da traditori che cercano attivamente di creare disaccordo?

Lamport, Shostak e Pease dimostrarono che una soluzione è possibile solo se più di due terzi dei generali sono leali. In altre parole: un sistema di n nodi può tollerare al massimo f nodi difettosi o malevoli, purché n sia almeno pari a 3f + 1. Con meno di due terzi di partecipanti onesti, nessun algoritmo può garantire l'accordo.

Questo risultato matematico è diventato il fondamento teorico per ogni algoritmo di consenso BFT successivo.

Leggi anche: Come l'hashing salvaguarda la tecnologia blockchain

Che cos'è la tolleranza ai guasti bizantini?

La tolleranza ai guasti bizantini si riferisce alla proprietà di un sistema distribuito che gli consente di continuare a funzionare correttamente e raggiungere il consenso anche quando alcuni dei suoi nodi si guastano in modi arbitrari, ad esempio inviando messaggi contraddittori o falsi, rispondendo in modo incoerente a partecipanti diversi o comportandosi in modo malevolo per interrompere la rete.

Il termine "bizantino" indica specificamente la classe di errore più grave: un comportamento arbitrario, ostile e incoerente. Questo tipo di errore è molto più difficile da gestire rispetto a un semplice crash (in cui un nodo smette completamente di rispondere), perché un nodo bizantino può sembrare comportarsi correttamente in alcuni momenti, mentre in altri mina attivamente il consenso.

Nel contesto di La tecnologia blockchainLa tolleranza ai guasti bizantini significa che la rete blockchain può mantenere la propria integrità e continuare a convalidare correttamente le transazioni anche quando alcuni validatori o nodi sono compromessi, offline o agiscono in modo deliberatamente malevolo.

La regola stabilita dal documento di Lamport rimane valida in ogni caso: finché almeno due terzi dei nodi della rete sono onesti e operano correttamente, un sistema BFT raggiungerà il consenso corretto. Nel momento in cui un singolo attaccante controlla più di un terzo dei nodi, le garanzie di sicurezza dei protocolli BFT classici iniziano a venire meno.

Tolleranza alle faglie non bizantine vs. bizantine: una distinzione fondamentale

Non tutte le tolleranze ai guasti sono uguali. Comprendere la differenza tra tolleranza ai guasti non bizantina e bizantina chiarisce perché quest'ultima sia più difficile da gestire e perché sia ​​così importante per la blockchain.

Tolleranza ai guasti non bizantini (crash) Gestisce il caso più semplice in cui i nodi possono bloccarsi: si arrestano in modo anomalo, vanno offline o diventano irraggiungibili. Il sistema deve continuare a funzionare nonostante alcuni nodi non inviino alcun messaggio. Questo è più facile da gestire perché un nodo bloccato non invia messaggi e non causa confusione attiva. Sistemi come Apache ZooKeeper e i database distribuiti più vecchi sono stati progettati tenendo conto della tolleranza ai guasti.

Tolleranza agli errori bizantini Gestisce il caso più complesso in cui i nodi guasti possono comportarsi in modo arbitrario, inviando messaggi errati, contraddittori o strategicamente fuorvianti a diverse parti della rete. Un nodo bizantino non si limita a rimanere in silenzio; partecipa attivamente in modi progettati per causare confusione o impedire un accordo. Le reti blockchain sono esposte a questo problema più complesso perché operano in ambienti aperti e senza permessi, dove chiunque può gestire un nodo, inclusi gli avversari.

Nello specifico, nell'ambito della blockchain, i guasti bizantini includono: un miner che include transazioni fraudolente in un blocco proposto, un validatore che firma blocchi in conflitto per tentare un fork, un nodo che invia informazioni diverse sull'ordine delle transazioni a peer diversi e nodi che eseguono attacchi di doppia spesa trasmettendo simultaneamente transazioni in conflitto a diverse parti della rete.

Un sistema tollerante ai guasti di tipo crash ma non ai guasti bizantini sarebbe inadatto a una blockchain pubblica, dove i nodi sono gestiti da soggetti sconosciuti e potenzialmente ostili.

Come si realizza il BFT: i meccanismi fondamentali

La tolleranza ai guasti bizantini si ottiene attraverso la combinazione di tre meccanismi principali che lavorano insieme per consentire ai nodi onesti di raggiungere un accordo nonostante la presenza di partecipanti ostili.

Ridondanza

Anziché affidarsi a un singolo nodo per registrare o convalidare una transazione, i sistemi BFT utilizzano più nodi ridondanti. Finché più di due terzi di questi nodi ridondanti sono onesti, il sistema può identificare e scartare la minoranza di messaggi falsi o contraddittori. La ridondanza è il fondamento strutturale del BFT: è impossibile ottenere la tolleranza ai guasti bizantini senza utilizzare più nodi di quelli strettamente necessari per elaborare le transazioni.

Firme crittografiche

I protocolli BFT utilizzano la crittografia a chiave pubblica per autenticare i messaggi tra i nodi. Quando un nodo invia un messaggio (ad esempio, un voto sulla validità di un blocco proposto), lo firma con la propria chiave privata. Gli altri nodi possono verificare la firma utilizzando la chiave pubblica del mittente, confermando che il messaggio proviene effettivamente dal mittente dichiarato e non è stato alterato durante la trasmissione. Questo previene uno degli attacchi bizantini più pericolosi: un nodo malevolo che si spaccia per un altro nodo falsificandone i messaggi.

Protocolli di consenso strutturati

I protocolli di consenso BFT definiscono regole precise su come i nodi propongono, votano e finalizzano i nuovi dati. Questi protocolli sono specificamente progettati in modo che, anche se alcuni nodi inviano voti contrastanti, la maggioranza onesta possa raggiungere la stessa risposta finale. La struttura del protocollo elimina le ambiguità: esiste un processo definito per ciò che accade quando i voti sono in conflitto, quando un leader fallisce e quando i nodi non sono d'accordo sullo stato attuale.

Le tre proprietà che definiscono il consenso BFT

Ogni protocollo di consenso BFT, indipendentemente dalla sua specifica progettazione, deve soddisfare tre proprietà fondamentali:

Sicurezza Ciò significa che non esistono due nodi corretti (onesti) che decidano mai valori diversi. Se un nodo onesto conferma una transazione come valida, nessun altro nodo onesto la confermerà come non valida. La sicurezza garantisce che la blockchain non si biforchi in cronologie contrastanti tra i partecipanti onesti.

Vitalità Significa che il sistema alla fine fa progressi. Se un numero sufficiente di nodi corretti invia una transazione, questa verrà infine confermata. La rete non si blocca in modo permanente. La vivacità garantisce che i partecipanti onesti non vengano bloccati indefinitamente dall'elaborazione delle loro transazioni.

Un accordo Ciò significa che se un nodo corretto consegna una transazione, allora ogni nodo corretto consegna la stessa transazione. Tutti i nodi onesti vedono gli stessi dati nello stesso ordine.

Sicurezza e vivacità possono entrare in conflitto. Il famoso teorema CAP nei sistemi distribuiti dimostra che nessun sistema distribuito può garantire simultaneamente coerenza, disponibilità e tolleranza alle partizioni. I protocolli BFT operano dei compromessi deliberati. La maggior parte privilegia la sicurezza rispetto alla vivacità: si arrestano piuttosto che confermare un risultato potenzialmente errato se troppi nodi si comportano in modo scorretto.

Leggi anche: Cos'è il consenso nella blockchain?

Tipi di algoritmi di tolleranza ai guasti bizantini

Il campo BFT si è evoluto notevolmente dal documento del 1982. Oggi comprende diverse famiglie di protocolli distinte, ognuna con caratteristiche prestazionali, presupposti di fiducia e contesti di implementazione differenti.

Pratica Byzantine Fault Tolerance (PBFT)

La tolleranza ai guasti bizantini (BFT) pratica è stata introdotta da Barbara Liskov e Miguel Castro al MIT nel 1999. È stato il primo algoritmo BFT sufficientemente pratico per un'implementazione reale in sistemi distribuiti, risolvendo il problema nelle reti asincrone con un overhead ridotto rispetto ai precedenti lavori accademici sulla BFT.

PBFT funziona attraverso tre fasi di comunicazione tra i nodi:

Fase di pre-preparazione: Il nodo primario (leader) riceve una richiesta dal client, le assegna un numero di sequenza e trasmette un messaggio di pre-preparazione a tutti gli altri nodi (chiamati repliche). Questo messaggio contiene la richiesta, il numero di sequenza e il numero della vista corrente.

Fase di preparazione: Ogni replica che accetta il pre-prepare trasmette un messaggio prepare a tutte le altre repliche. Una replica passa alla fase successiva solo quando ha ricevuto messaggi prepare corrispondenti da almeno 2f nodi (dove f è il numero massimo di nodi difettosi tollerati dal sistema). Questo requisito di quorum impedisce a un leader difettoso di ingannare diverse repliche inducendole ad accettare numeri di sequenza differenti.

Fase di impegno: Una volta che un nodo ha raccolto un numero sufficiente di messaggi di preparazione corrispondenti, trasmette un messaggio di commit. Una replica esegue la richiesta e risponde al client solo quando ha ricevuto messaggi di commit da almeno 2f + 1 nodi. Questo quorum finale garantisce che, anche se alcuni nodi che hanno inviato messaggi di commit dovessero successivamente guastarsi, rimarranno comunque abbastanza nodi con messaggi di commit da garantire la durabilità del risultato.

Un client accetta un risultato quando riceve f + 1 risposte corrispondenti, garantendo che almeno un nodo onesto abbia confermato il risultato.

La complessità di comunicazione di PBFT è O(n al quadrato), il che significa che il numero di messaggi cresce quadraticamente con il numero di nodi. Questo è gestibile per decine o poche centinaia di nodi, ma diventa proibitivo su larga scala. PBFT si basa inoltre su un insieme fisso e noto di validatori, il che lo rende più adatto ad ambienti blockchain con permessi o di consorzio.

PBFT può tollerare fino a un terzo (33%) di nodi bizantini. Questa soglia è matematicamente dimostrata essere il massimo teorico per i protocolli BFT classici.

Utilizzo del consenso derivato da PBFT da parte di Hyperledger Fabric È l'esempio aziendale più rilevante. Fabric utilizza un servizio di ordinazione (precedentemente basato su PBFT, ora basato su Raft con un percorso di aggiornamento a BFT tramite SmartBFT) che offre elevata velocità di elaborazione e bassa latenza per le applicazioni aziendali. Walmart ha utilizzato Hyperledger Fabric per tracciare i prodotti alimentari dalla fattoria allo scaffale, dimostrando la pratica implementazione di BFT in un ambiente di catena di approvvigionamento reale.

Accordo Bizantino Federato (FBA)

L'Accordo bizantino federato (FBA) adotta un approccio fondamentalmente diverso al problema della fiducia. Invece di richiedere a tutti i validatori di conoscere e concordare sull'insieme completo dei validatori fidati, l'FBA consente a ciascun nodo di definire la propria "quorum slice", ovvero il sottoinsieme di altri nodi di cui si fida personalmente.

Il sistema raggiunge un consenso globale quando queste singole porzioni di fiducia formano insiemi sovrapposti. Se il nodo A si fida dei nodi B e C, e il nodo B si fida dei nodi A e D, la loro fiducia sovrapposta crea un quorum globale implicito, anche se nessuna autorità centrale ne ha definito uno.

FBA è il meccanismo di consenso alla base della rete Stellar e, in forma modificata, della rete Ripple. L'implementazione di FBA di Stellar garantisce la finalità delle transazioni in tre-cinque secondi e supporta migliaia di transazioni al secondo, rendendola pratica per i pagamenti transfrontalieri. MoneyGram e altri fornitori di servizi di trasferimento di denaro utilizzano Stellar proprio perché il suo meccanismo di consenso FBA offre la rapidità e l'affidabilità necessarie per la finalità delle transazioni, requisiti indispensabili per le applicazioni di pagamento.

L'approccio FBA presenta un compromesso diverso rispetto a PBFT: si adatta a una struttura di fiducia più decentralizzata, ma richiede un'attenta progettazione delle porzioni di quorum per garantire il mantenimento della proprietà di accordo globale. Se le porzioni di quorum sono definite in modo inadeguato, parti della rete potrebbero formare gruppi di consenso disconnessi che concordano su stati diversi.

Roba calda

HotStuff è un protocollo di consenso BFT introdotto nel 2019 dai ricercatori Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta e Ittai Abraham. Ha acquisito grande influenza come base per il protocollo LibraBFT di Facebook (utilizzato nel progetto blockchain Diem) e ha ispirato la progettazione di numerosi sistemi di consenso blockchain moderni.

L'innovazione chiave di HotStuff consiste nel raggiungere una complessità di comunicazione lineare, O(n), anziché la complessità quadratica O(n quadrato) di PBFT. Ciò è possibile grazie a un design basato su un leader, in cui il leader raccoglie i voti nelle firme di soglia, aggregando n voti individuali in un'unica prova compatta. Questo significa che il sovraccarico di comunicazione non aumenta esponenzialmente con la crescita del set di validatori.

HotStuff utilizza una struttura a tre fasi (preparazione, pre-conferma, conferma) che concettualmente corrisponde alle fasi di PBFT, ma opera in modo più efficiente grazie alla pipeline: mentre un blocco viene confermato, il blocco successivo è già in fase di proposta, migliorando drasticamente la produttività.

HotStuff offre una scalabilità nettamente superiore a fronte di una latenza leggermente maggiore (tre round-trip contro i due di PBFT). Per grandi insiemi di validatori composti da centinaia o migliaia di nodi, questo compromesso è estremamente vantaggioso. Sia CometBFT (precedentemente Tendermint Core) dell'ecosistema Cosmos, sia il meccanismo di consenso utilizzato in Aptos e Sui, si basano su architetture della famiglia HotStuff.

Tendermint e CometBFT

Tendermint è un algoritmo di consenso BFT specificamente progettato per l'uso su blockchain, introdotto da Jae Kwon nel 2014. Separa il livello di consenso dal livello applicativo tramite l'Application Blockchain Interface (ABCI), consentendo a qualsiasi applicazione di utilizzare il consenso Tendermint senza dover costruire la propria infrastruttura di rete e di consenso.

Tendermint raggiunge il consenso in round. In ogni round, un proponente trasmette un blocco. I validatori votano in due fasi (prevoto e pre-commit). Un blocco viene confermato quando almeno due terzi dei validatori inviano voti di pre-commit corrispondenti. Se il round fallisce (perché il proponente è difettoso o la rete è troppo lenta), inizia un nuovo round con un nuovo proponente.

Tendermint garantisce la finalità istantanea: una volta che un blocco è stato confermato, non può essere annullato senza violare il principio della maggioranza onesta dei due terzi. Questo rappresenta un vantaggio significativo rispetto ai sistemi di finalità probabilistica come il proof-of-work, in cui una transazione è considerata definitiva solo dopo l'aggiunta di più blocchi successivi.

Tendermint gestisce migliaia di transazioni al secondo con una latenza di circa un secondo. Nel 2023 è stato rinominato CometBFT per riflettere un modello di governance della comunità più ampio. Cosmos Hub e ogni blockchain basata su Cosmos SDK (oltre 100 blockchain attive entro il 2025) utilizzano CometBFT come livello di consenso. Un esempio significativo in produzione è stato il blocco della blockchain di Cosmos Hub v17.1, che non è stato causato da un difetto nella prova di sicurezza principale di CometBFT, bensì da un bug del software nel codice di aggiornamento del set di validatori relativo a EndBlock, a dimostrazione di come le garanzie BFT siano integrate in un'implementazione completa e non isolate a livello teorico.

BFT in Proof of Stake: Casper ed Ethereum

La transizione di Ethereum al proof of stake tramite la fusione avvenuta nel settembre 2022 ha introdotto Casper FFG (Friendly Finality Gadget) in combinazione con la scelta del fork LMD-GHOST, dando vita al protocollo di consenso Gasper. Casper fornisce una finalità in stile BFT (Block for Transparency) al di sopra di un set di validatori proof-of-stake.

Casper funziona come un dispositivo di finalità sovrapposto alla produzione dei blocchi. I validatori votano sui checkpoint ogni 32 slot (circa 6.4 minuti). Quando due terzi degli ETH totali in staking hanno votato per un checkpoint, questo viene "giustificato". Quando due checkpoint consecutivi vengono giustificati, il primo viene "finalizzato". I blocchi finalizzati non possono essere annullati senza che l'attaccante bruci almeno un terzo di tutti gli ETH in staking, creando una potente garanzia economica contro il BFT (Block Fraud and Abuse).

Questo meccanismo di penalizzazione economica è l'adattamento di Ethereum del classico BFT: invece di garanzie puramente matematiche, la finalità è imposta attraverso il costo economico di un comportamento scorretto. Se un validatore firma blocchi in conflitto, perde l'intera quota (viene penalizzato). La minaccia di perdere un capitale considerevole allinea il comportamento onesto all'interesse economico personale.

Tolleranza ai guasti bizantini nella prova di lavoro

Il Proof of Work di Bitcoin realizza una forma probabilistica di tolleranza ai guasti bizantini attraverso un meccanismo diverso rispetto ai protocolli BFT classici. Il white paper di Bitcoin del 2008 di Satoshi Nakamoto ha introdotto il PoW come soluzione al problema dei generali bizantini in un contesto senza permessi, in cui i partecipanti sono sconosciuti e non possono essere pre-identificati.

Nel sistema PoW di Bitcoin, la tolleranza ai guasti bizantini significa che, finché i miner onesti controllano più del 50% della potenza di calcolo totale della rete, un attaccante che ne controlla meno del 50% non può riscrivere la cronologia delle transazioni confermate. Il costo di un attacco del 51% aumenta con l'hash rate di Bitcoin e con la difficoltà dei problemi di mining.

A differenza dei protocolli BFT classici che garantiscono la finalità assoluta dopo un singolo round di votazione, la finalità di Bitcoin è probabilistica: la probabilità che una transazione venga annullata diminuisce esponenzialmente con ogni blocco aggiuntivo aggiunto successivamente. Questo è il motivo per cui tradizionalmente per le transazioni Bitcoin di grandi dimensioni si utilizzano conferme a 6 blocchi (circa un'ora).

Il compromesso è significativo: PoW fornisce BFT in un ambiente senza permessi a costo di un enorme consumo energetico, una finalità lenta (10-60 minuti) e una vulnerabilità agli attacchi del 51% che i protocolli BFT classici non affrontano mai al di sotto della loro soglia.

Confronto tra i protocolli BFT: una panoramica completa

Protocollo	Soglia di guasto	Finalità	Complessità della comunicazione	Ideale per
PBFT (Castro-Liskov)	1/3 bizantino	Istantaneo	O(n al quadrato)	Piccole reti con accesso autorizzato
Roba calda	1/3 bizantino	Istantaneo	O(n) lineare	Grandi set di validatori
Tendermint / CometBFT	1/3 bizantino	Istantaneo (~1s)	O (n)	Catene Cosmos, blockchain pubbliche
Accordo bizantino federato	Fette di quorum sovrapposte	secondi 3-5	Variabile	Reti di pagamento (Stellar, Ripple)
Casper FFG (Ethereum PoS)	1/3 degli ETH messi in staking	Ogni 6.4 min	O(n) con aggregazione BLS	Blockchain PoS pubbliche
BitcoinPoW	potenza di calcolo del 50%	Probabilistico (6+ blocchi)	O(1) trasmissione	Reti senza autorizzazione e senza fiducia
Algorand BA	1/3 bizantino	~ 4.5 secondi	Sublineare con VRF	Senza autorizzazione con finalità rapida

Implementazioni concrete del BFT nel mondo reale nel 2025

Hyperledger Fabric e Enterprise Blockchain

Hyperledger Fabric è il framework blockchain aziendale più diffuso in produzione. Alimenta il sistema di tracciabilità alimentare di Walmart, le soluzioni per la supply chain di IBM e centinaia di applicazioni finanziarie e logistiche. Il servizio di ordinamento di Fabric ha subito una significativa evoluzione: dopo essere passato da PBFT a Raft (un consenso tollerante ai guasti per implementazioni più semplici), Fabric ha introdotto SmartBFT come servizio di ordinamento tollerante ai guasti bizantini per ambienti che richiedono garanzie BFT complete. SmartBFT segue il familiare schema di broadcast a tre fasi ereditato da PBFT e offre un throughput elevato con bassa latenza, adatto ad applicazioni di livello enterprise.

L'accordo bizantino federato di Stellar nei pagamenti globali

L'implementazione FBA di Stellar elabora milioni di transazioni al giorno, e MoneyGram, Wirex e altre istituzioni finanziarie la utilizzano per i pagamenti transfrontalieri. Il meccanismo di consenso di Stellar raggiunge il regolamento finale in tre-cinque secondi, un tempo di gran lunga inferiore rispetto al tradizionale sistema bancario di corrispondenza (da uno a cinque giorni) e più rapido rispetto alla maggior parte delle alternative basate su blockchain. Il modello FBA consente a ciascun nodo di definire le proprie relazioni di fiducia, pur raggiungendo un accordo globale, rendendo il modello di consenso di Stellar particolarmente adatto a una rete di pagamento in cui non tutti i partecipanti si fidano completamente l'uno dell'altro, ma tutti desiderano un regolamento affidabile.

Protocollo di accordo bizantino di Algorand

Algorand impiega un approccio BFT unico, chiamato Pure Proof of Stake, combinato con sorteggio crittografico. In ogni round di consenso, viene selezionato casualmente un comitato di validatori utilizzando una funzione casuale verificabile (VRF). Solo i membri del comitato selezionati sanno di essere stati scelti (e possono dimostrarlo agli altri), rendendo di fatto impossibili gli attacchi mirati contro i membri del comitato, poiché l'attaccante non sa in anticipo chi colpire.

Il protocollo BA di Algorand raggiunge la finalità in circa 4.5 secondi con una velocità di elaborazione superiore a 1,000 transazioni al secondo in produzione. La sua architettura offre BFT in un ambiente senza permessi e senza il costo energetico della prova di lavoro, una combinazione che lo distingue sia da Bitcoin che dai classici sistemi BFT con permessi.

Ecosistema del cosmo e cometa BFT

Nel 2025, l'ecosistema Cosmos comprenderà oltre 100 blockchain sovrane, tutte basate su CometBFT come livello di consenso. Il protocollo di comunicazione inter-blockchain (IBC) si fonda sulla garanzia di finalità istantanea di CometBFT: le prove IBC sono valide solo se l'hub Cosmos e le sue blockchain di controparte possono dimostrare che una transazione è effettivamente finalizzata, e non semplicemente probabile che lo sia. Senza le solide garanzie di finalità fornite dal consenso BFT, la comunicazione cross-chain di questo tipo sarebbe molto più difficile da proteggere. L'ecosistema gestisce quotidianamente miliardi di dollari in trasferimenti di valore cross-chain, tutti protetti dal consenso tollerante ai guasti bizantini di CometBFT.

Klaytn's Istanbul BFT

Klaytn, implementato dalla sudcoreana Kakao, utilizza Istanbul BFT (IBFT) con una velocità di oltre 4,000 transazioni al secondo e tempi di blocco di un secondo. IBFT è una variante di BFT compatibile con EVM che consente a Klaytn di mantenere la compatibilità con gli strumenti di Ethereum, raggiungendo al contempo prestazioni di gran lunga superiori rispetto al livello base di Ethereum. La sua architettura ibrida pubblico-privata permette alle aziende di gestire sidechain con permessi, mentre la blockchain principale pubblica mantiene le garanzie decentralizzate di BFT.

Vettori di attacco contro cui BFT si difende

Comprendere da cosa protegge BFT chiarisce il suo valore e i suoi limiti.

Attacchi a doppia spesa

In un attacco di doppia spesa, un malintenzionato tenta di spendere gli stessi fondi due volte trasmettendo simultaneamente due transazioni in conflitto. Il consenso BFT impedisce questo tipo di attacco richiedendo che i due terzi dei validatori concordino su un singolo ordine di transazione prima che quest'ultima venga finalizzata. Una volta che una transazione è stata confermata in un sistema BFT, non è possibile effettuare transazioni concorrenti per gli stessi fondi senza violare la soglia dei due terzi.

Attacchi di Eclipse

In un attacco di eclissi, un aggressore isola un nodo specifico circondandolo con nodi malevoli, controllando così tutte le informazioni che quel nodo riceve. Un nodo eclissato con successo può ricevere informazioni false sullo stato della blockchain. I protocolli BFT si difendono da questo tipo di attacco richiedendo l'approvazione di una supermaggioranza dell'intero set di validatori, non solo dei nodi vicini. Anche se un nodo viene eclissato, la maggioranza onesta, nel suo complesso, rifiuterà le transazioni che sono in conflitto con lo stato effettivo della blockchain.

Sibilla Attacchi

Un attacco Sybil consiste nella creazione, da parte di un malintenzionato, di molteplici identità di nodi falsi per ottenere un'influenza sproporzionata su una rete. Nei sistemi BFT con permessi, gli attacchi Sybil vengono prevenuti richiedendo la registrazione e l'autenticazione formale dei validatori. Nei sistemi BFT proof-of-stake come Ethereum, la resistenza agli attacchi Sybil deriva dal costo economico dello staking: la creazione di più validatori richiede lo staking di valore reale per ciascuno di essi, rendendo gli attacchi Sybil costosi da eseguire su larga scala.

La soglia di attacco del 33%

I protocolli BFT classici offrono garanzie di sicurezza solo quando meno di un terzo dei nodi sono bizantini. Se un attaccante controlla più di un terzo del set di validatori (o più di un terzo del valore in staking nei sistemi PoS-BFT), la garanzia di sicurezza del protocollo viene meno. Questa è la limitazione fondamentale del consenso BFT. Ciò non significa che un attaccante con il 33% dei nodi possa rubare fondi a caso, ma significa che potenzialmente può impedire la finalità o, nel peggiore dei casi, indurre nodi onesti a confermare stati contrastanti.

Ecco perché la soglia del 33% è un elemento critico per il modello di sicurezza di qualsiasi sistema basato su BFT. Protocolli come Casper di Ethereum aggiungono una penalità economica alla soglia BFT: anche se un attaccante raggiunge un terzo degli ETH in staking, per attaccare con successo la finalità sarebbe necessario che l'intera sua partecipazione venisse penalizzata, rendendo l'attacco economicamente devastante per l'attaccante.

Manipolazione dei messaggi e attacchi di replay

Senza firme crittograficheUn nodo bizantino potrebbe intercettare e modificare i messaggi tra nodi onesti, oppure riprodurre vecchi messaggi validi per confondere il processo di consenso. I protocolli BFT si difendono dalla manipolazione dei messaggi richiedendo che ogni messaggio di consenso sia firmato con la chiave privata del mittente. I numeri di sequenza e gli identificatori di round incorporati nei messaggi impediscono che messaggi validi di un round vengano riprodotti in un round successivo, causando confusione.

Vantaggi della tolleranza ai guasti bizantini nella blockchain

Finalità deterministica e istantanea della transazione

Forse il vantaggio più importante del consenso BFT rispetto ai sistemi proof-of-work è la finalità istantanea. In Bitcoin, una transazione non è mai matematicamente definitiva; diventa solo sempre più difficile annullarla man mano che vengono aggiunti altri blocchi. In un sistema BFT, una volta raggiunta la soglia dei due terzi nella fase di commit, la transazione viene finalizzata con certezza in base ai presupposti del protocollo. Non è necessario attendere ulteriori conferme.

Questo aspetto riveste un'importanza enorme per le applicazioni finanziarie. Le reti di pagamento non possono funzionare in modo efficiente se ogni transazione può essere annullata ore dopo. Le applicazioni di finanza decentralizzata richiedono una finalità affidabile per liquidazioni, prestiti e regolamento di derivati. La comunicazione cross-chain tramite protocolli come IBC richiede che una blockchain dimostri a un'altra che una specifica transazione è effettivamente definitiva.

Energy Efficiency

Il consenso BFT classico non richiede l'enorme lavoro computazionale richiesto dalla prova di lavoro di Bitcoin. I validatori votano utilizzando firme digitali, non risolvendo complessi enigmi computazionali. Questo rende BFT notevolmente più efficiente dal punto di vista energetico. La transizione di Ethereum a PoS-BFT ha ridotto il suo consumo energetico di circa il 99.95%, una riduzione resa possibile proprio dalla sostituzione della prova di lavoro con il voto dei validatori in stile BFT.

Resilienza ai guasti di rete e ai nodi dannosi

Un protocollo BFT ben implementato continua a funzionare correttamente finché due terzi dei nodi rimangono onesti e connessi. Gestisce contemporaneamente guasti, partizioni di rete (temporanee), nodi bizantini e combinazioni di questi. Questa resilienza è esattamente ciò di cui hanno bisogno le reti blockchain pubbliche: non possono sapere in anticipo quali nodi si guasteranno o si comporteranno in modo malevolo, quindi il protocollo di consenso deve gestire i guasti arbitrari in modo elegante.

Elevata velocità di trasmissione per sistemi con autorizzazioni

I protocolli BFT in ambienti con permessi, come Hyperledger Fabric, possono raggiungere un throughput di transazioni molto elevato. Poiché il set di validatori è fisso e noto, l'overhead di comunicazione è prevedibile e ottimizzabile. Le implementazioni aziendali raggiungono regolarmente migliaia di transazioni al secondo con una finalità inferiore al secondo, prestazioni impossibili con il proof-of-work e impegnative persino per molti sistemi proof-of-stake.

Sicurezza contro guasti bizantini e attacchi coordinati

I meccanismi BFT offrono una solida protezione contro gli attacchi bizantini coordinati. Un gruppo di nodi malevoli collusi, che rappresentino meno di un terzo del set di validatori, non può interrompere il consenso, indipendentemente dalla strategia adottata. Non possono impedire ai nodi onesti di raggiungere un accordo, non possono inserire transazioni false nella cronologia concordata e non possono indurre i nodi onesti a confermare stati contrastanti. Questa solida garanzia di sicurezza è dimostrata matematicamente, non solo osservata empiricamente.

Sfide e limiti della tolleranza alle faglie bizantine

Vincoli di scalabilità

La sfida fondamentale degli algoritmi BFT classici è che la complessità della comunicazione cresce con il numero di validatori. La complessità dei messaggi di PBFT, pari a O(n al quadrato), implica che aggiungere altri validatori diventi rapidamente impraticabile. Una rete con 100 validatori PBFT richiede fino a 10,000 messaggi per ogni round di consenso. Con 1,000 validatori, questo numero sale a 1,000,000 di messaggi.

HotStuff e i suoi derivati ​​hanno affrontato questo problema in modo significativo, riducendo la complessità a O(n) lineare tramite l'aggregazione di firme a soglia. Tuttavia, anche la complessità lineare ha dei limiti pratici. La maggior parte delle attuali blockchain pubbliche basate su BFT mantiene insiemi di validatori che vanno dalle centinaia alle poche migliaia, anziché le decine di migliaia presenti nella rete di mining di Bitcoin.

Questo limite di scalabilità è il motivo per cui il consenso BFT è comune nelle blockchain con permessi e nelle reti proof-of-stake con insiemi di validatori limitati, mentre il proof-of-work senza permessi rimane il meccanismo per le reti che privilegiano la partecipazione illimitata.

Dipendenza da un set di validatori noto

La maggior parte dei protocolli BFT richiede un insieme definito e autenticato di validatori. Questo funziona bene in ambienti con permessi e nelle reti proof-of-stake, dove i validatori investono capitale per guadagnarsi un posto. È molto più difficile in ambienti completamente senza permessi, dove chiunque può partecipare senza registrarsi. Il proof-of-work di Bitcoin ha risolto la versione senza permessi del problema dei generali bizantini proprio perché il PoW non richiede di conoscere in anticipo l'identità dei partecipanti.

Prestazioni generali

Il raggiungimento della tolleranza ai guasti bizantini richiede una comunicazione tra i nodi significativamente maggiore rispetto ai sistemi non tolleranti ai guasti bizantini. Il voto multifase richiesto nei protocolli in stile PBFT, la necessità di raccogliere e verificare un gran numero di messaggi firmati crittograficamente e il sovraccarico di coordinamento dei protocolli di cambio vista (gestione dei leader falliti) aggiungono latenza e costi computazionali. Per le applicazioni che richiedono migliaia di transazioni al secondo con latenza molto bassa, questi sovraccarichi richiedono un'attenta progettazione.

Complessità della corretta implementazione

Le dimostrazioni matematiche alla base degli algoritmi BFT sono esatte: il protocollo è sicuro e funzionante se implementato esattamente come specificato. Tuttavia, il software raramente corrisponde esattamente alle specifiche. Le implementazioni reali contengono bug di concorrenza, casi limite nella gestione della rete, vulnerabilità di temporizzazione dei messaggi ed errori di implementazione crittografica che possono violare le garanzie del protocollo nella pratica, anche quando la progettazione teorica è corretta. L'arresto della blockchain di Cosmos Hub v17.1 ne è un esempio: la garanzia di sicurezza fondamentale di BFT è stata rispettata, ma un errore software nel codice circostante ha causato un blocco della produzione. Una corretta implementazione di BFT richiede un rigore estremo in tutto lo stack di implementazione, non solo nella logica del round di consenso.

Vulnerabilità alla soglia del 33%

Il requisito della maggioranza onesta del 33% rappresenta sia il punto di forza che il limite invalicabile del BFT. Finché tale presupposto è valido, il sistema è sicuro. Tuttavia, se un attaccante acquisisce il controllo di un terzo o più del set di validatori (o di un terzo del valore in staking nei sistemi PoS-BFT), le garanzie di sicurezza vengono meno. In pratica, ciò richiede ingenti risorse per le reti consolidate, ma le reti più piccole con un valore totale in staking inferiore sono più vulnerabili a questo tipo di attacco.

Il futuro della tolleranza ai guasti bizantini nella blockchain

BFT post-quantistica

Gli attuali protocolli BFT si basano su schemi di firma crittografica vulnerabili ai computer quantistici. Un computer quantistico sufficientemente potente potrebbe violare la crittografia a chiave pubblica utilizzata dai protocolli BFT per autenticare i voti dei validatori. La ricerca post-quantistica sul BFT sta esplorando attivamente schemi di firma resistenti agli attacchi quantistici, tra cui la crittografia basata su reticoli e su hash. Trezor Safe 7, un portafoglio hardware, implementa già la crittografia post-quantistica standardizzata dal NIST per la verifica del firmware, a dimostrazione del fatto che l'intero ecosistema crittografico si sta muovendo verso la resistenza quantistica. I protocolli BFT dovranno adeguarsi a questa evoluzione con il progredire del calcolo quantistico.

Protocolli BFT asincroni

Il PBFT classico e la maggior parte dei suoi derivati ​​si basano su ipotesi di sincronia parziale: presuppongono che i ritardi dei messaggi siano alla fine limitati, anche se il limite è sconosciuto. In condizioni completamente asincrone (dove i ritardi dei messaggi possono essere arbitrariamente lunghi), il teorema di impossibilità FLP dimostra che il consenso deterministico è impossibile. Tuttavia, i protocolli BFT asincroni randomizzati che utilizzano funzioni casuali verificabili possono raggiungere il consenso probabilistico anche in condizioni di completa asincronia. HoneyBadgerBFT e Dumbo sono esempi di protocolli BFT asincroni progettati per funzionare in modo affidabile anche quando le condizioni di rete sono gravemente degradate.

Scalabilità tramite sharding e Layer 2

Un approccio promettente per superare i limiti di scalabilità di BFT consiste nell'eseguire più istanze di BFT in parallelo tramite lo sharding, in cui la rete viene divisa in sottoinsiemi (shard) che eseguono ciascuno il proprio consenso BFT su una porzione di transazioni. La roadmap di Ethereum include lo sharding insieme alla finalità in stile BFT. L'architettura app-chain di Cosmos è un'altra forma di scalabilità orizzontale: ogni applicazione esegue la propria blockchain CometBFT, distribuendo il carico del consenso. Le soluzioni di livello 2 come i rollup aggiungono un'ulteriore dimensione raggruppando le transazioni off-chain e utilizzando blockchain protette da BFT per la liquidazione finale.

BFT nell'Internet delle cose

Le reti IoT rappresentano un caso d'uso convincente per il consenso BFT. Miliardi di dispositivi IoT devono coordinarsi e condividere dati in modo sicuro attraverso reti distribuite in cui i singoli dispositivi potrebbero essere fisicamente compromessi, rimanere senza energia o essere manipolati deliberatamente. La ricerca del 2025 mostra che gli algoritmi basati su BFT forniscono la bassa latenza richiesta dalle applicazioni IoT, sebbene il loro elevato costo computazionale e la vulnerabilità agli attacchi del 33% rendano necessarie architetture di rete con permessi per le implementazioni IoT. Internet Di cose rappresenta una delle aree a più alta crescita per la ricerca e l'implementazione di BFT.

BFT nella finanza decentralizzata

Finanza decentralizzata Le applicazioni DeFi, che entro il 2025 avevano bloccato un valore totale di oltre 56.3 miliardi di dollari, dipendono fondamentalmente dal consenso BFT per l'affidabilità delle loro operazioni. Liquidazioni, feed di prezzo degli oracoli, posizioni di prestito e regolamenti dei derivati ​​richiedono tutti una finalità affidabile e veloce. Ogni protocollo DeFi principale si basa su blockchain con consenso in stile BFT: Ethereum con Casper, Cosmos Chain con CometBFT e Stellar con FBA. Man mano che le applicazioni DeFi diventano più sofisticate e gestiscono valori sempre maggiori, la richiesta di garanzie BFT diventa più critica, non meno.

Interoperabilità tra sistemi BFT

Il futuro della blockchain è sempre più multi-chain. Asset e messaggi si spostano tra Ethereum, Cosmos Chain, Stellar, Hyperledger e altre reti. Interoperabilità tra catena richiede che ogni catena verifichi le prove di finalità delle transazioni su altre catene. La finalità istantanea di BFT semplifica notevolmente questo processo: una prova BFT finalizzata è compatta e verificabile, a differenza della finalità probabilistica di proof-of-lavoro, il che richiede di attendere numerose conferme prima che qualsiasi operazione cross-chain sia sicura. Il protocollo IBC nell'ecosistema Cosmos e i progetti di bridge cross-chain nell'ecosistema più ampio dipendono entrambi dalla finalità BFT per funzionare in modo sicuro. La ricerca sull'interoperabilità è una delle frontiere più attive nella progettazione dei protocolli BFT.

Domande frequenti