Cos’è la Byzantine Fault Tolerance (BFT)?

In poche parole, la Byzantine Fault Tolerance (BFT) è la capacità di una rete di computer di continuare a funzionare correttamente quando una parte dei partecipanti va offline, commette errori o diffonde di proposito informazioni sbagliate.

Questo è particolarmente importante per le blockchain. Una blockchain non ha un amministratore centrale che decide quali transazioni e blocchi sono validi. Al suo posto, computer distribuiti, chiamati anche nodi o validatori, devono raggiungere insieme un accordo su un’unica versione della blockchain.

Un validatore può “andare in errore” in diversi modi, cioè con un errore normale oppure con un Byzantine fault. In un errore normale è chiaro per la rete che il validatore non sta funzionando bene. Per esempio, va offline, perde la connessione internet o non invia un messaggio in tempo. In quel caso non fornisce informazioni utili. Di solito la blockchain riesce a gestire la cosa abbastanza facilmente. Gli altri validatori non aspettano all’infinito, ma dopo un certo tempo vanno avanti senza il validatore offline. Finché restano abbastanza validatori attivi, la rete continua a processare nuovi blocchi.

Con un Byzantine fault, invece, un validatore non si comporta solo in modo difettoso, ma in modo imprevedibile. Può continuare a inviare messaggi, ma fornire informazioni sbagliate o contraddittorie. Per esempio, può dire a un validatore che il blocco A è valido e a un altro validatore che il blocco B è valido.

Quindi la differenza è:

• Con un errore normale mancano le informazioni di un validatore.
• Con un Byzantine fault le informazioni ci sono, ma non è chiaro se siano corrette.

Per questo un Byzantine fault è più difficile da risolvere. La rete deve non solo riuscire ad andare avanti senza un validatore offline, ma anche evitare che messaggi sbagliati o contraddittori portino a una decisione errata.

La Byzantine Fault Tolerance descrive come una rete possa comunque prendere una decisione unica e condivisa nonostante questo tipo di problemi. Per farlo, il protocollo usa tra le altre cose controlli, firme digitali, diversi round di voto e una soglia di voto alta.

Molti protocolli BFT richiedono che più di due terzi del peso di voto totale supportino la stessa proposta prima che un blocco diventi definitivo. In questo modo un piccolo gruppo di validatori difettosi o malevoli non può decidere da solo quale versione della blockchain è valida.

La BFT non è un meccanismo di consenso a sé stante. È una proprietà di una rete o di un protocollo di consenso. Protocolli come PBFT, Tendermint e HotStuff usano ciascuno regole proprie per tollerare i Byzantine fault.

In breve

• La Byzantine Fault Tolerance aiuta una blockchain a gestire validatori difettosi o inaffidabili.
• Un Byzantine fault può nascere da un guasto tecnico, un bug software o un attacco intenzionale.
• I validatori controllano le proposte e votano sui nuovi blocchi.
• Molti protocolli BFT richiedono il supporto di più di due terzi del peso di voto totale.
• La BFT aiuta a evitare che versioni diverse della blockchain diventino definitive allo stesso tempo.
• PBFT, Tendermint e HotStuff sono esempi di protocolli BFT.

Cosa risolve la Byzantine Fault Tolerance?

La Byzantine Fault Tolerance impedisce che un piccolo gruppo di validatori difettosi o malevoli possa decidere da solo quale versione della blockchain è valida. Aiuta la rete a mantenere un’unica cronologia delle transazioni condivisa, anche quando alcuni partecipanti vanno offline, non rispondono o diffondono informazioni sbagliate.

Un validatore inaffidabile può per esempio inviare blocchi diversi a partecipanti diversi, votare per due blocchi in conflitto o provare a far approvare un blocco non valido. Un validatore può anche rifiutarsi di collaborare e così rallentare il raggiungimento del consenso.

Senza regole solide, diversi gruppi di validatori potrebbero finire per seguire ciascuno una versione diversa della blockchain. La rete non sarebbe più in grado di stabilire con certezza quali transazioni e blocchi sono validi.

La BFT lo evita confermando un blocco solo quando abbastanza validatori hanno controllato e supportato la stessa proposta. Così, un gruppo limitato di partecipanti inaffidabili non può ingannare la rete da solo.

In più, i partecipanti non devono fidarsi personalmente gli uni degli altri. Si fidano delle regole fisse del protocollo di consenso, come firme digitali, round di voto e una soglia di voto alta.

In questo modo la BFT rende possibile mantenere una versione della blockchain unica e coerente senza un amministratore centrale.

Come funziona la Byzantine Fault Tolerance?

Per capire bene la Byzantine Fault Tolerance, è importante prima conoscere la differenza rispetto a un meccanismo di consenso.

Un meccanismo di consenso è l’insieme di regole con cui i partecipanti di una blockchain raggiungono un accordo sui nuovi blocchi e sulla cronologia valida della rete. Per esempio, stabilisce chi può proporre un blocco, come i validatori votano e quando un blocco viene confermato o reso definitivo.

La Byzantine Fault Tolerance è la proprietà che fa sì che questo processo continui a funzionare anche quando alcuni validatori vanno offline, commettono errori o inviano informazioni sbagliate.

Quindi la BFT di solito non è un sistema separato accanto al meccanismo di consenso. È fatta dalle regole dentro il processo di consenso che impediscono ai validatori inaffidabili di ingannare la blockchain. Pensa per esempio a una soglia di voto alta, firme digitali, più round di voto e la sostituzione di un validatore che non propone un blocco valido.

Il funzionamento preciso varia da blockchain a blockchain, ma in molti protocolli BFT il processo è più o meno lo stesso.

Un validatore viene scelto temporaneamente per proporre un nuovo blocco. Questo validatore viene spesso chiamato proposer o leader. Nel blocco ci sono nuove transazioni e un riferimento al blocco precedente. Il proposer firma digitalmente la proposta, così gli altri validatori possono controllare da chi arriva.

Gli altri validatori verificano poi se il blocco è valido. Guardano per esempio se le transazioni rispettano le regole, se gli utenti hanno saldo sufficiente e se gli stessi token non vengono spesi due volte. Controllano anche se il blocco si aggancia alla versione corretta della blockchain.

Quando un validatore ritiene valido il blocco, esprime un voto digitale. Grazie a questa firma, la rete può vedere chi ha votato, per quale blocco era quel voto e se un validatore ha votato anche per un blocco in conflitto.

Qui entra in gioco la Byzantine Fault Tolerance. La rete non si fida della decisione di un singolo validatore. In molti protocolli BFT, più di due terzi del peso di voto totale devono supportare lo stesso blocco prima che possa diventare definitivo.

Questa soglia di voto alta fa sì che un piccolo gruppo di validatori difettosi o malevoli non possa decidere da solo quale blocco è valido. Quando alcuni validatori inviano informazioni sbagliate o non rispondono, gli altri validatori possono comunque arrivare insieme a una sola decisione.

Esempio: Ethereum usa Proof of Stake e regole simili alla BFT per rendere i blocchi definitivi. I validatori bloccano ETH in stake e poi votano su checkpoint nella blockchain. Almeno due terzi del totale di ETH in stake devono supportare lo stesso checkpoint prima che diventi definitivo. Se una piccola parte dei validatori va offline o vota male, Ethereum può comunque raggiungere la finalità. Se circa un terzo del peso di voto totale non partecipa correttamente, la finalità può fermarsi temporaneamente. Ethereum ha per questo un inactivity leak: i validatori che non partecipano per lungo tempo perdono gradualmente una parte dello stake. Così i validatori attivi, alla fine, possono di nuovo rappresentare abbastanza peso di voto da raggiungere la finalità.

Nei network Proof-of-Stake quindi di solito non conta solo il numero di validatori, ma soprattutto il loro peso di voto. Quel peso dipende da quanti token hanno messo in stake.

Alcuni protocolli di consenso usano più round di voto. Un esempio noto è Tendermint, oggi sviluppato ulteriormente come CometBFT e usato da molte blockchain nell’ecosistema Cosmos, inclusa Cosmos Hub. I validatori prima votano sul blocco proposto e poi confermano in un round successivo che abbastanza altri validatori supportano la stessa proposta. Così la rete controlla non solo che il blocco sia valido, ma anche che ci sia un accordo ampio.

Può anche succedere che non ci sia abbastanza supporto. Per esempio il proposer può essere offline, proporre un blocco non valido o diffondere proposte contraddittorie. Il meccanismo di consenso allora avvia, dopo un certo tempo di attesa, un nuovo round con un altro proposer.

Anche questo fa parte della tolleranza ai guasti. Un singolo validatore difettoso o malevolo non può bloccare la rete all’infinito.

Quindi il meccanismo di consenso stabilisce come la blockchain prende decisioni in modo condiviso. La Byzantine Fault Tolerance fa sì che quel processo decisionale resti affidabile quando non tutti i partecipanti agiscono correttamente.

Riassunto rapido: come funziona la Byzantine Fault Tolerance?

1. Il meccanismo di consenso decide quale validatore può proporre un blocco e come gli altri validatori votano su di esso.
2. Gli altri validatori verificano se il blocco proposto è valido.
3. La BFT fa sì che la rete non si fidi di un singolo validatore, ma prenda una decisione solo quando una grande maggioranza supporta lo stesso blocco.
4. Le firme digitali rendono visibile chi ha votato per cosa e se un validatore ha espresso voti contraddittori.
5. In molti protocolli BFT serve più di due terzi del peso di voto totale per rendere un blocco definitivo.
6. Se un proposer va offline, mente o non ottiene una maggioranza valida, il protocollo avvia un nuovo round di voto con un altro proposer.
7. Il ruolo della BFT è quindi mantenere affidabile il consenso quando alcuni validatori vanno offline, commettono errori o diffondono intenzionalmente informazioni sbagliate.

Cosa cercano di proteggere safety e liveness?

La Byzantine Fault Tolerance deve fare in modo che una blockchain resti affidabile quando alcuni validatori vanno offline, commettono errori o diffondono informazioni sbagliate. In questo, la rete deve evitare due problemi.

Primo: i validatori non devono arrivare a due versioni definitive diverse della blockchain. Secondo: la rete deve, finché possibile, continuare a processare nuovi blocchi e transazioni.

Questi due obiettivi, nella BFT, si chiamano safety e liveness.

Safety: niente due versioni diverse

Safety significa che la rete non accetta due blocchi in conflitto come definitivi.

Immagina che due gruppi di validatori ricevano ciascuno un blocco diverso. Senza regole chiare, entrambi i gruppi potrebbero pensare che la propria versione sia valida. La blockchain potrebbe così avere due cronologie di transazioni diverse.

I protocolli BFT cercano di evitarlo con una soglia di voto alta, più round di voto e voti firmati digitalmente. Possono anche esserci regole che impediscono ai validatori di votare “a caso” per un altro blocco dopo aver già supportato una proposta.

Quindi safety fa sì che i partecipanti onesti continuino a seguire la stessa versione definitiva della blockchain, anche quando alcuni validatori diffondono informazioni contraddittorie.

Liveness: la rete continua ad andare avanti

Liveness significa che la rete può continuare a prendere nuove decisioni.

Vuol dire che vengono prodotti nuovi blocchi, le transazioni vengono processate e un proposer difettoso o malevolo può essere sostituito se blocca il processo.

I protocolli BFT usano per esempio tempi di attesa e nuovi round di voto. Se un proposer non propone un blocco valido o non risponde, dopo un po’ tocca a un altro validatore.

Safety e liveness a volte possono andare in conflitto. Se troppi validatori sono offline o diffondono informazioni diverse, la rete potrebbe non riuscire a raccogliere abbastanza voti affidabili.

Il protocollo può allora scegliere di non rendere definitivi i blocchi temporaneamente. La blockchain non fa progressi per un po’, ma evita che vengano approvate due versioni diverse.

Per questo, in caso di incertezza seria, i protocolli BFT di solito danno priorità alla safety. La rete preferisce fermarsi temporaneamente piuttosto che rendere definitiva una versione potenzialmente sbagliata o in conflitto della blockchain.

Qual è la differenza tra Byzantine Fault Tolerance e il Byzantine Generals Problem?

Il Byzantine Generals Problem e la Byzantine Fault Tolerance sono collegati, ma non significano la stessa cosa.

Il Byzantine Generals Problem è un esperimento mentale che mostra perché raggiungere un accordo è difficile in una rete senza un decisore centrale. Nella storia, diversi generali devono decidere insieme se attaccare o ritirarsi. Comunicano solo tramite messaggi, mentre alcuni generali potrebbero mentire o diffondere informazioni contraddittorie.

In una blockchain succede in pratica lo stesso. I validatori devono decidere insieme quali transazioni e blocchi sono validi, mentre non sono sicuri che ogni partecipante sia onesto e affidabile.

La Byzantine Fault Tolerance descrive poi come una rete gestisce questo problema. Fa sì che i validatori possano comunque arrivare a una decisione unica e condivisa, anche quando una parte dei partecipanti va offline, commette errori o invia informazioni sbagliate.

Quindi il Byzantine Generals Problem descrive il problema. La Byzantine Fault Tolerance è la capacità di una rete di risolverlo. Le regole concrete con cui si fa, come round di voto, firme digitali e una soglia di voto alta, messe insieme formano il protocollo BFT.

Come applicano le blockchain la Byzantine Fault Tolerance?

Le blockchain possono applicare la Byzantine Fault Tolerance in modi diversi. Non tutte le reti usano lo stesso protocollo, ma l’obiettivo è sempre simile: i validatori devono scegliere insieme un’unica versione valida della blockchain, anche quando una parte di loro va offline o diffonde informazioni sbagliate.

Le differenze stanno soprattutto nel modo in cui si sceglie un validatore per proporre un blocco, quanti round di voto servono e quando un blocco diventa definitivo. Inoltre, a seconda del protocollo cambia cosa succede quando i validatori non rispondono o esprimono voti contraddittori.

Practical Byzantine Fault Tolerance

La Practical Byzantine Fault Tolerance, di solito abbreviata in PBFT, è uno dei protocolli BFT più conosciuti. È stata sviluppata da Miguel Castro e Barbara Liskov per rendere la Byzantine Fault Tolerance utilizzabile in sistemi informatici reali.

PBFT funziona con un leader temporaneo che manda una proposta agli altri partecipanti. Loro controllano la proposta e poi si scambiano tra loro se la ritengono valida. Dopo di che confermano che abbastanza partecipanti supportano la stessa proposta.

Grazie a questi diversi round di comunicazione, la rete può verificare se c’è davvero un accordo ampio. PBFT funziona soprattutto bene con un gruppo relativamente piccolo di partecipanti noti. Quando il gruppo cresce, bisogna scambiarsi sempre più messaggi. Questo rende il protocollo meno efficiente per blockchain con tantissimi validatori.

Tendermint BFT

Tendermint BFT viene usato da molte blockchain nell’ecosistema Cosmos. In Tendermint, prima un validatore propone un blocco. Poi ci sono due round di voto in cui i validatori indicano se supportano il blocco.

Un blocco diventa definitivo solo quando più di due terzi del peso di voto è d’accordo. Tendermint usa anche un meccanismo di locking. Quando un validatore vede che un blocco ha abbastanza supporto, viene in un certo senso “bloccato” su quel blocco.

Dopo di ciò, il validatore non può votare così facilmente per un blocco in conflitto. Questo aiuta a evitare che in round diversi vengano approvati due blocchi contraddittori.

HotStuff

HotStuff è un protocollo BFT più moderno che prova ad applicare la stessa idea di base in modo più efficiente. Anche qui un leader temporaneo propone blocchi e abbastanza validatori devono supportarli.

HotStuff può riassumere il supporto dei validatori in un quorum certificate. È una prova crittografica che abbastanza validatori hanno supportato la stessa proposta. I validatori devono comunque inviare i loro voti, ma il quorum certificate permette di trasmettere in modo compatto la prova di quel supporto ampio. HotStuff è inoltre progettato per rendere più efficiente la comunicazione e il cambio di leader.

Così non serve elaborare ogni volta tutti i voti singoli separatamente. Inoltre, il protocollo è progettato per cambiare leader più velocemente quando quello attuale non funziona bene.

Diversi protocolli blockchain moderni sono ispirati in tutto o in parte a HotStuff.

Ethereum

Ethereum non usa una forma classica di PBFT, Tendermint o HotStuff. La rete usa Proof of Stake, dove i validatori votano con l’ETH che hanno messo in stake. Comunque, i principi BFT si vedono chiaramente nel modo in cui Ethereum raggiunge la finalità.

I validatori votano sui checkpoint nella blockchain. Un checkpoint diventa definitivo solo quando almeno due terzi del totale di ETH in stake lo supporta.

Se più di un terzo del peso di voto non collabora, la finalità può fermarsi temporaneamente. La rete sceglie allora di aspettare abbastanza voti affidabili, invece di rendere definitive due versioni diverse.

I validatori che votano dimostrabilmente per versioni in conflitto possono essere puniti. Questo si chiama slashing. La penalità economica supporta qui le regole BFT: i validatori possono diffondere informazioni sbagliate, ma quel comportamento è visibile e può avere conseguenze.

Bitcoin

Bitcoin affronta lo stesso problema di base in modo diverso. Anche la rete deve raggiungere un accordo mentre i partecipanti non si fidano completamente tra loro, ma non usa un protocollo BFT classico basato su voti.

Bitcoin usa Proof of Work. I miner usano potenza di calcolo per produrre nuovi blocchi, e poi i nodi controllano se questi blocchi sono validi. I miner continuano a costruire sulla chain valida in cui è stato investito il maggior lavoro computazionale cumulativo.

Un blocco non è subito definitivo. La probabilità che venga annullato diminuisce man mano che vengono costruiti più blocchi sopra di esso. Questo si chiama finalità probabilistica.

Quindi Bitcoin prova a risolvere lo stesso problema generale dei protocolli BFT: come fa una rete a mantenere una cronologia affidabile quando non tutti i partecipanti sono affidabili? La differenza è che Bitcoin usa potenza di calcolo e costi economici, mentre i protocolli BFT classici lavorano soprattutto con round di voto espliciti e una soglia di voto alta.

Cosa succede quando i validatori non collaborano?

Quello che succede quando i validatori vanno offline o si comportano male dipende da quanto peso di voto rappresentano insieme.

Quando solo un piccolo gruppo di validatori non collabora, gli altri validatori di solito riescono comunque a raccogliere abbastanza supporto per confermare nuovi blocchi. La rete continua quindi a funzionare normalmente, anche se non tutti i validatori sono attivi o affidabili.

La situazione cambia quando più di un terzo del peso di voto totale non partecipa. In molti protocolli BFT, la rete allora non può più raccogliere il supporto richiesto di più di due terzi. Di conseguenza, nuovi blocchi possono non diventare definitivi temporaneamente. Questo gruppo può quindi bloccare l’avanzamento, ma di solito non può approvare da solo una versione in conflitto della blockchain.

Se un gruppo controlla più di due terzi del peso di voto e collabora, può formare da solo abbastanza supporto per confermare i blocchi. Un gruppo del genere può quindi decidere quali blocchi validi raggiungono la finalità e può censurare transazioni non includendole. Per rendere definitive due versioni in conflitto, però, i validatori devono violare in modo dimostrabile le regole di consenso, cosa che in molte reti Proof-of-Stake può portare a slashing.

Per questo non conta solo il numero di validatori, ma soprattutto la distribuzione del peso di voto. Una blockchain può avere migliaia di validatori e comunque essere relativamente concentrata se un piccolo numero di parti controlla una grande quota dei token in stake.

Come vengono puniti i validatori malevoli?

Le blockchain Proof-of-Stake possono punire i validatori quando violano dimostrabilmente le regole di consenso. Questo si chiama slashing.

Per esempio, un validatore può essere punito se vota per due blocchi in conflitto o prova a supportare due versioni diverse della blockchain. Siccome ogni voto è firmato digitalmente, la rete può controllare quale validatore ha commesso l’infrazione.

La punizione varia a seconda della blockchain. Un validatore può perdere reward di staking, perdere una parte dei token in stake o essere rimosso temporaneamente dal set di validatori. In caso di infrazioni gravi, l’esclusione può durare di più o essere permanente.

Lo slashing non rende impossibile barare, ma aumenta le conseguenze economiche. Un validatore che viola le regole di consenso rischia quindi di perdere una parte del proprio valore messo in gioco.

Quali sono i vantaggi della Byzantine Fault Tolerance?

La Byzantine Fault Tolerance ha diversi vantaggi:

1. La rete può continuare a funzionare in caso di errori: Non ogni validatore deve essere sempre online o senza difetti. Finché abbastanza validatori continuano a lavorare correttamente, la rete può continuare a processare nuovi blocchi.
2. La blockchain mantiene un’unica cronologia condivisa: La BFT aiuta a evitare che gruppi diversi di validatori rendano definitivi blocchi in conflitto. Così i partecipanti onesti continuano a seguire la stessa versione della blockchain.
3. I blocchi possono diventare definitivi velocemente: Molti protocolli BFT rendono un blocco definitivo non appena abbastanza validatori lo supportano. Quindi gli utenti spesso non devono aspettare molti blocchi extra.
4. Il comportamento dei validatori è verificabile: I voti sono firmati digitalmente. Così la rete può vedere quale validatore ha votato per quale blocco e se qualcuno ha espresso voti contraddittori.
5. Non serve un decisore centrale: I validatori possono decidere insieme quali blocchi sono validi, senza che una sola parte centrale prenda tutte le decisioni.

Quali sono gli svantaggi della Byzantine Fault Tolerance?

La Byzantine Fault Tolerance ha anche diversi svantaggi:

1. La rete può fermarsi temporaneamente: Se partecipano troppo pochi validatori, non si riesce a formare il quorum richiesto. La rete può magari continuare a proporre blocchi, ma non renderli definitivi. Le transazioni restano quindi incerte più a lungo e gli utenti devono aspettare che abbastanza validatori tornino a partecipare.
2. I validatori devono scambiarsi molte informazioni: Durante il processo di consenso, i validatori devono condividere tra loro proposte, voti e conferme. Man mano che cresce il numero di validatori, aumenta anche la quantità di comunicazione. Questo può rallentare la rete e richiedere più banda e potenza di calcolo.
3. I protocolli BFT sono tecnicamente complessi: Questi protocolli lavorano con più round di voto, tempi di attesa, leader temporanei e regole che stabiliscono quando un validatore può cambiare voto. Un errore in queste regole o nel software può far sì che i validatori si blocchino, elaborino informazioni diverse o non raggiungano il consenso per un po’.
4. Il peso di voto può concentrarsi: Una blockchain può avere molti validatori, mentre alcuni grandi provider di staking o organizzazioni controllano insieme una grossa quota del peso di voto. Se queste parti controllano più di un terzo del peso di voto, possono forse bloccare la finalità. Con più di due terzi, possono influenzare molto quali blocchi vengono confermati.
5. La BFT protegge solo il livello di consenso: La BFT aiuta i validatori a mettersi d’accordo sulla blockchain valida, ma non protegge tutte le parti della rete. Per esempio, una transazione può essere confermata correttamente mentre lo smart contract usato contiene un errore. Inoltre la BFT non impedisce wallet hackerati, bridge vulnerabili, informazioni di prezzo sbagliate da oracoli, problemi con crypto-exchange o perdite dovute ai cali di prezzo.

In conclusione

La Byzantine Fault Tolerance fa sì che una blockchain possa continuare a funzionare in modo affidabile quando alcuni validatori vanno offline, commettono errori o diffondono intenzionalmente informazioni sbagliate. La rete non si fida di un singolo partecipante, ma usa tra le altre cose firme digitali, round di voto e una soglia di voto alta per arrivare a una decisione unica e condivisa.

La BFT non è un meccanismo di consenso separato, ma una proprietà del processo di consenso. Aiuta a evitare che versioni diverse della blockchain diventino definitive allo stesso tempo e fa sì che la rete, finché partecipano abbastanza validatori, possa continuare a processare nuovi blocchi.

Le blockchain applicano questi principi in modi diversi. Tendermint usa più round di voto e regole di locking, Ethereum usa regole simili alla BFT per la finalità e Bitcoin risolve un problema simile con Proof of Work e finalità probabilistica.

La Byzantine Fault Tolerance non rende una blockchain completamente protetta da tutti gli errori e gli attacchi. Però è una base importante per reti in cui i partecipanti non devono fidarsi completamente tra loro, ma possono comunque mantenere insieme una cronologia di transazioni valida e unica.