Un generale invia un solo ordine, «attaccare all’alba», a tre tenenti accampati intorno a una città. L’ordine viaggia con un messaggero. Uno dei quattro uomini è un traditore e nessuno sa quale. Se 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 traditore è proprio il comandante, può dire a due tenenti di attaccare e al terzo di ritirarsi. Gli ufficiali leali riescono comunque a fare tutti la stessa cosa? Questo rompicapo è il problema dei generali bizantini, e nel 1982 Leslie Lamport, Robert Shostak e Marshall Pease dimostrarono che la risposta è sì con quattro generali e un traditore, e no con tre.
Ventisei anni dopo, il 13 novembre 2008, uno sviluppatore sconosciuto che scriveva come Satoshi Nakamoto disse a una mailing list di crittografia che il suo nuovo progetto risolveva lo stesso enigma tra estranei su internet, dove chiunque può entrare e nessuno tiene l’elenco di chi è chi. La strada tra i due episodi passa per i computer di bordo degli aerei, un articolo ribattezzato e un file server del MIT, e finisce su due numeri che ancora oggi decidono come falliscono le blockchain: un terzo e un mezzo.
Il problema dei generali bizantini in parole semplici
I computer che lavorano insieme si guastano in due modi. Alcuni si fermano e basta: un server si blocca, un cavo si taglia. Altri continuano a funzionare e inviano risposte sbagliate, e i peggiori inviano risposte sbagliate diverse ad ascoltatori diversi. La storia dei generali serve a far prendere sul serio agli ingegneri proprio questo secondo tipo di guasto. Un traditore è qualsiasi componente che si comporta in modo arbitrario: un sensore difettoso, un processore corrotto o, su una blockchain pubblica, un partecipante che mente di proposito.
La lezione precedente, che cosa decide un meccanismo di consenso e perché sicurezza e vitalità tirano in direzioni opposte, ha posto la domanda generale. L’articolo del 1982 la rende esatta. Riduce l’intero esercito a un comandante e ai suoi tenenti e chiede due cose. Primo, tutti i tenenti leali obbediscono allo stesso ordine. Secondo, se il comandante è leale, ogni tenente leale obbedisce all’ordine che lui ha davvero inviato. L’articolo chiama queste richieste condizioni di consistenza interattiva, IC1 e IC2.
Servono entrambe. Senza la prima, il campo leale si spacca. Senza la seconda, l’esercito potrebbe accordarsi su qualsiasi cosa, per esempio ritirarsi sempre, il che è inutile quando il comandante leale ha detto di attaccare.
Il denaro dà allo stesso enigma una forma familiare. Una doppia spesa è un traditore che racconta a due interlocutori due storie diverse sulla stessa moneta, come mostra la lezione sul problema della doppia spesa con attacchi reali. Un registro condiviso da molti computer serve a qualcosa solo se ogni copia onesta racconta la stessa storia, anche quando alcune copie sono gestite da bugiardi.
Perché tre generali non bastano quando uno mente
L’articolo fissa prima le regole per quelli che chiama messaggi orali, cioè messaggi che un traditore può inventare liberamente quando li inoltra. Valgono tre ipotesi: ogni messaggio inviato viene consegnato correttamente, chi lo riceve sa chi lo ha mandato, e l’assenza di un messaggio può essere rilevata. I messaggeri, quindi, sono affidabili. La difficoltà sta tutta nei generali.
La trappola dei tre generali
Si prenda un comandante e due tenenti, uno dei quali può essere un traditore. Il tenente 1 riceve «attacca» dal comandante. Il tenente 2 gli dice poi: il comandante mi ha detto di ritirarmi. Due scenari combaciano esattamente con questi fatti. Nel primo, il comandante è leale e il tenente 2 mente; IC2 impone allora al tenente 1 di attaccare. Nel secondo, il traditore è il comandante, che ha mandato «attacca» a un uomo e «ritirati» all’altro, mentre il tenente 2 riferisce onestamente.
Il tenente 1 vede gli stessi messaggi in entrambi i mondi, quindi qualunque regola lo faccia attaccare nel primo mondo lo fa attaccare anche nel secondo. Per simmetria, il tenente 2 nel secondo mondo deve eseguire l’ordine ricevuto, ritirarsi. I due tenenti leali sono allora in disaccordo e IC1 si rompe. Gli autori stessi avvertono il lettore di essere «very suspicious of such nonrigorous reasoning», cioè molto diffidente verso ragionamenti poco rigorosi; la loro dimostrazione completa è più accurata di questo schizzo e arriva alla stessa conclusione.
Quattro generali, un traditore: il voto che salva la giornata
Basta aggiungere un tenente leale e la trappola si apre. L’algoritmo che l’articolo chiama OM(1) ha due round. Nel primo, il comandante invia il suo ordine a ciascun tenente. Nel secondo, ogni tenente inoltra l’ordine ricevuto agli altri due. Ciascun tenente prende poi la maggioranza dei tre valori in suo possesso. Se un comandante traditore non invia nulla, l’articolo fissa un ordine predefinito, ritirarsi, in modo che il silenzio non possa paralizzare l’esercito.
La tabella qui sotto illustra il caso peggiore, quello in cui il traditore è il comandante e prova a spaccare il campo.
| Tenente (tutti leali) | Ordine del comandante | Ordini inoltrati dagli altri due | Maggioranza, quindi decisione |
|---|---|---|---|
| Tenente 1 | attacca | attacca (da T2), ritirati (da T3) | attacca |
| Tenente 2 | attacca | attacca (da T1), ritirati (da T3) | attacca |
| Tenente 3 | ritirati | attacca (da T1), attacca (da T2) | attacca |
Ogni tenente leale finisce con gli stessi tre valori in ordine diverso, quindi la maggioranza dà a tutti la stessa risposta: IC1 regge. Ora si rovesci il caso: il comandante è leale e dice di attaccare, mentre il tenente 3 è il traditore e inoltra «ritirati». I tenenti 1 e 2 hanno ciascuno attacca, attacca e ritirati, quindi attaccano entrambi, come ordinato dal loro comandante leale. Regge anche IC2. La bugia del traditore viene battuta perché lui ha una sola voce su tre.
La regola generale: più di due terzi devono essere leali
L’articolo del 1982 generalizza il risultato in entrambe le direzioni. Il suo abstract afferma che, con soli messaggi orali, il problema è risolvibile «if and only if more than two-thirds of the generals are loyal» (in inglese: se e solo se più di due terzi dei generali sono leali). In numeri: per reggere m traditori servono almeno 3m + 1 generali. Un traditore richiede quattro generali, due traditori ne richiedono sette, dieci traditori trentuno. L’algoritmo OM(m) funziona per qualsiasi esercito di questo tipo ripetendo m + 1 volte il round di inoltro, con ogni generale che passa agli altri ciò che ciascuno sostiene di aver sentito.
Questa ripetizione costa. Il numero di messaggi cresce molto in fretta con m, e la conclusione dell’articolo ammette che una soluzione «seems to be inherently expensive», cioè sembra intrinsecamente costosa. Il lavoro di Fischer e Lynch, citato dagli autori, mostra che gli m + 1 round non si possono evitare. L’unico modo per ridurre il costo, scrivono, è fare ipotesi su quali guasti possano verificarsi, e i quarant’anni successivi sono stati in buona parte una caccia a ipotesi economiche e ancora realistiche.
Gli ordini firmati cambiano i conti
Il secondo algoritmo dell’articolo, SM(m), aggiunge un’ipotesi. La firma di un generale leale non può essere falsificata, qualunque modifica a un messaggio firmato è rilevabile e chiunque può verificare di chi sia la firma. I traditori possono ancora colludere e firmare l’uno per l’altro. Con questa sola modifica, dice l’abstract, «the problem is solvable for any number of generals and possible traitors», cioè il problema è risolvibile per qualsiasi numero di generali e di possibili traditori.
Il motivo è che un traditore non può più mettere parole in bocca a un generale leale. Nella trappola dei tre generali, il tenente 2 poteva sostenere che il comandante avesse detto di ritirarsi. Con le firme dovrebbe esibire l’ordine firmato dal comandante, e se il comandante avesse davvero firmato due ordini diversi, entrambi i tenenti avrebbero la prova del suo tradimento e ripiegherebbero sullo stesso ordine predefinito. L’accordo non dipende più dall’essere più numerosi dei bugiardi, ma solo dall’inoltrare ordini firmati per un numero sufficiente di round.
Due precisazioni evitano che sembri magia. Primo, l’accordo in SM(m) riguarda l’esecuzione dell’ordine di un solo comandante. Quando l’obiettivo è concordare valori corretti che arrivano da molte macchine, come le letture di un sensore, la maggioranza degli ingressi deve comunque essere corretta: la nota di Lamport sul suo articolo del 1980 indica 2n+1 processori per tollerare n guasti quando si usano le firme, contro 3n+1 senza. Secondo, le firme dell’articolo non erano vera crittografia. Lamport le definisce «a metaphor», una metafora: dovevano resistere a guasti casuali, non a un avversario intelligente, e quindi erano molto più facili da realizzare delle vere firme digitali. Le blockchain usano quelle vere, spiegate nella lezione su chiavi private e chiavi pubbliche, ed è per questo che il caso firmato conta tanto nella pratica.
Le origini: i computer degli aerei e un articolo ribattezzato
I generali sono nati nell’avionica. Negli anni Settanta la NASA finanziò all’SRI International una ricerca su come rendere i computer abbastanza affidabili da pilotare aerei di linea. Il progetto si chiamava SIFT e il suo articolo di presentazione, firmato da John Wensley e colleghi, uscì sui Proceedings of the IEEE nell’ottobre 1978. Lamport, che lavorava all’SRI, dice che il progetto è forse noto soprattutto per aver prodotto il problema dei generali bizantini e le sue soluzioni (in inglese). L’articolo del 1982 elenca la NASA tra i finanziatori, insieme al Ballistic Missile Defense Systems Command e all’Army Research Office.
Il timore degli ingegneri era preciso. Un computer di volo diventa sicuro facendo girare più copie e prendendo il voto di maggioranza. Funziona solo se ogni copia legge lo stesso ingresso. Un sensore difettoso, o un sito radar di una rete di difesa missilistica, può inviare un valore a un processore e un altro valore al successivo. Può bastare anche un orologio onesto: due processori che lo leggono mentre scatta possono ottenere uno l’ora vecchia e l’altro la nuova. Il voto di maggioranza tra i processori non ha più nulla di coerente su cui votare.
I risultati sono più vecchi del nome. Un articolo del 1980 di Pease, Shostak e Lamport, «Reaching Agreement in the Presence of Faults», sul Journal of the ACM, dimostrava già che servono 3n+1 processori per n guasti e presentava il caso con le firme. Lamport attribuisce a Shostak la soluzione a quattro processori e la dimostrazione di impossibilità, a Pease la soluzione generale a 3n+1; l’algoritmo con messaggi firmati fu suo. Scrive anche, in inglese: «I am often unfairly credited with inventing the Byzantine agreement problem.» Il problema, dice, fu formulato dalle persone che lavoravano a SIFT prima del suo arrivo all’SRI. L’articolo del 1980 ricevette nel 2005 il Premio Dijkstra per il calcolo distribuito.
Quello che l’articolo del 1982 aggiunse fu la storia. Lamport riteneva che i filosofi a cena di Edsger Dijkstra, presentati come una favola su filosofi a tavola, avessero attirato più attenzione di problemi più pratici, e voleva la stessa forza di attrazione per questo. Cercò una nazionalità che non offendesse nessun lettore. L’Albania era allora una società completamente chiusa, e il primo titolo fu The Albanian Generals Problem. Il collega Jack Goldberg gli fece notare che c’erano albanesi anche fuori dall’Albania e, nelle parole di Lamport, «The obviously more appropriate Byzantine generals then occurred to me.»
Lo stesso Lamport dice che il motivo principale del nuovo articolo era dare al problema il suo nuovo nome. Il riferimento è «The Byzantine Generals Problem», ACM Transactions on Programming Languages and Systems, volume 4, numero 3, luglio 1982, pagine da 382 a 401, e una copia gratuita si trova sul sito di Lamport: venti pagine, leggibili da chi se la cava con un po’ di induzione.
Il problema dei due generali: quando i messaggeri si perdono
I generali furono presi in prestito. Lamport dice di averli ricavati da un enigma più vecchio su due eserciti che devono accordarsi se attaccare, che a suo dire viene talvolta chiamato Chinese Generals Problem. Quell’enigma è un altro, e i due vengono spesso confusi.
La sua prima forma pubblicata è un articolo del 1975 di E. A. Akkoyunlu, K. Ekanadham e R. V. Huber, «Some Constraints and Tradeoffs in the Design of Network Communications», presentato al quinto ACM Symposium on Operating Systems Principles (SOSP 1975, pagine da 67 a 74). La loro appendice non usa affatto i generali. Racconta la storia di due bande di gangster che pianificano un colpo e possono coordinarsi solo con messaggi che possono perdersi per strada.
Il ragionamento è questo. Il gruppo A invia un orario. Non può agire finché non sa che il messaggio è arrivato, quindi B deve rispondere. Ma B non può agire finché non sa che la sua risposta è arrivata, quindi A deve confermare, e così via. Si prenda qualsiasi scambio finito che dovrebbe funzionare e si guardi l’ultimo messaggio: chi lo invia non può sapere se è arrivato, quindi il piano non può dipendere da lui, quindi anche uno scambio più corto dovrebbe funzionare. Ripetendo il ragionamento non resta nulla. Gli autori osservano che la catena di conferme è infinita anche quando nessun messaggio si perde davvero.
Il contrasto è facile da ricordare. Nel problema dei due generali tutti sono onesti e i messaggeri inaffidabili. Nel problema dei generali bizantini i messaggeri sono affidabili e alcuni generali mentono. Le reti reali hanno entrambi i guai insieme, per cui gli ingegneri si accontentano di ripetizioni, timeout e un piccolo dubbio residuo.
FLP: perché nessun algoritmo può essere certo in una rete senza orologio
Le soluzioni del 1982 poggiano su un’ipotesi silenziosa: un messaggio mancante può essere rilevato. In pratica significa un tempo massimo di consegna noto e orologi che concordano entro un errore fisso, come spiega la sezione dell’articolo sull’implementazione. Se si toglie questo, le cose peggiorano molto.
Nel 1985 Michael Fischer, Nancy Lynch e Michael Paterson pubblicarono «Impossibility of Distributed Consensus with One Faulty Process» sul Journal of the ACM. Il loro risultato riguarda un sistema completamente asincrono, in cui i messaggi arrivano sempre ma possono impiegare un tempo qualsiasi: «no completely asynchronous consensus protocol can tolerate even a single unannounced process death», ossia nessun protocollo di consenso completamente asincrono tollera nemmeno la morte non annunciata di un solo processo. FLP, dalle iniziali degli autori, non richiede nemmeno dei traditori. Presuppone processi onesti e una rete che non perde mai un messaggio. Basta un processo che si ferma in silenzio, perché gli altri non possono mai sapere se è morto o solo lento.
FLP non dice che il consenso sia impossibile in pratica. Dice che nessun protocollo deterministico può garantire insieme di restare sempre corretto e di concludere sempre, senza un’ipotesi sul tempo. Ogni protocollo reale sceglie quindi una via d’uscita: un’ipotesi temporale, la casualità, o entrambe.
La via d’uscita che si è affermata è arrivata nel 1988. Cynthia Dwork, Nancy Lynch e Larry Stockmeyer, in «Consensus in the Presence of Partial Synchrony» (Journal of the ACM, volume 35), hanno ipotizzato che la rete si comporti male per un periodo ma prima o poi consegni i messaggi entro un limite che nessuno conosce in anticipo. I loro protocolli non rompono mai la sicurezza, nemmeno nel periodo cattivo, e avanzano quando la rete si calma. Quando l’articolo ricevette il Premio Dijkstra 2007, la motivazione del premio descrisse questo approccio della sincronia eventuale come il modo principale di aggirare il risultato FLP. PBFT, Tendermint e HotStuff vivono tutti in questo mondo parzialmente sincrono.
PBFT, 1999: la tolleranza ai guasti bizantini diventa pratica
Per diciassette anni dopo che i generali ebbero il loro nome, la Byzantine fault tolerance rimase soprattutto negli articoli e in alcuni sistemi critici, perché gli algoritmi noti erano troppo lenti per i servizi comuni. Miguel Castro e Barbara Liskov del MIT cambiarono le cose con «Practical Byzantine Fault Tolerance», presentato alla conferenza OSDI a New Orleans nel febbraio 1999.
PBFT fa girare un servizio su un gruppo fisso di repliche, una delle quali fa da primaria e ordina le richieste dei client. Ogni richiesta passa per tre fasi, pre-prepare, prepare e commit, in cui le repliche si scambiano messaggi firmati o autenticati finché abbastanza di esse garantiscono lo stesso ordine. Se la primaria sembra difettosa o si blocca, le altre avviano un cambio di vista e la replica successiva prende il suo posto. Con 3f + 1 repliche il sistema tollera f repliche difettose, e l’articolo osserva che è il minimo. L’aritmetica è questa: due gruppi qualsiasi di 2f + 1 repliche su 3f + 1 si sovrappongono in almeno f + 1 macchine, quindi almeno una macchina onesta sta in entrambi e impedisce due decisioni in conflitto.
PBFT mantiene la sicurezza anche in una rete asincrona come internet e si affida a una debole ipotesi temporale solo per la vitalità, cosa che, scrivono gli autori, gli permette di aggirare il risultato FLP. Il numero che fece ascoltare gli ingegneri: il loro file service replicato era «only 3% slower than a standard unreplicated NFS», cioè solo il 3% più lento di un NFS standard non replicato.
Restava un’ipotesi, e conta per il denaro. PBFT richiede un elenco di membri noto e fisso. Il voto di ogni replica conta perché ogni replica ha un’identità approvata da qualcuno. Su una rete aperta a cui chiunque può unirsi, un solo attaccante può creare migliaia di identità e superare tutti nel voto, quello che i ricercatori chiamano attacco Sybil. Il whitepaper di Bitcoin esprime la stessa obiezione in una riga: se la maggioranza si basasse su un indirizzo IP, un voto, «could be subverted by anyone able to allocate many IPs», cioè potrebbe essere sovvertita da chiunque riesca ad allocare molti IP.
Come Bitcoin risolve il problema dei generali bizantini con una catena di lavoro
Il whitepaper di Bitcoin non usa mai la parola bizantino. Il legame fu stabilito nella discussione che seguì. Sulla mailing list Cryptography, James A. Donald aveva sostenuto che far sapere a tutti che tutti conoscono un fatto era, come nel problema dei generali bizantini, il classico problema difficile dell’elaborazione distribuita dei dati. La risposta di Satoshi Nakamoto, datata 13 novembre 2008 dall’archivio del Nakamoto Institute, si apre con una sola riga: «The proof-of-work chain is a solution to the Byzantine Generals’ Problem.»
Poi raccontò la storia a modo suo. Un gruppo di generali vuole forzare il wi-fi del re indovinando insieme la password, e l’attacco funziona solo se una maggioranza colpisce nello stesso momento. Chiunque può annunciare un orario, e vale il primo che ogni generale sente. Invece di votare, ognuno avvia una proof of work che include quell’orario. Se due orari vengono proposti insieme, alcuni generali lavorano su uno e altri sull’altro, e appena un ramo si allunga gli altri passano a quello, perché la catena più lunga contiene più lavoro. Con ogni blocco che richiede circa dieci minuti dello sforzo dell’intero gruppo, scrisse che dopo due ore un orario d’attacco dovrebbe essere sostenuto da una catena di 12 proof of work, e ogni generale può verificare che l’abbia prodotta per forza una maggioranza.
Il trucco sta in ciò che sostituisce il voto. Il whitepaper lo dice chiaramente: «Proof-of-work is essentially one-CPU-one-vote.» Un voto costa calcolo ed elettricità, non un’identità, quindi i membri finti non guadagnano nulla. La condizione, nell’abstract: il sistema è sicuro finché i nodi onesti controllano insieme più potenza di calcolo di qualsiasi gruppo di attaccanti che cooperano. La spiegazione del whitepaper di Bitcoin, sezione per sezione copre il resto del progetto, mentre la lezione su come funziona una blockchain ricorda come i nodi scelgono una sola catena quando compaiono due blocchi.
L’altro cambiamento è la scala. PBFT era pensato per un gruppo piccolo e noto di repliche. Al 7 novembre 2026, intorno alle 09:56 UTC, la catena di Bitcoin era al blocco 974.916, e i miner, che non si registrano da nessuna parte, fornivano un hashrate medio su tre giorni di circa 1.014 exahash al secondo, secondo i dati di mempool.space.
Un accordo che si rafforza a ogni blocco
Il consenso di Nakamoto non dà mai il sì netto di PBFT. Un blocco è concordato solo con una probabilità che sale man mano che si accumula lavoro sopra di esso. La sezione 11 del whitepaper mostra che un attaccante con meno della metà della potenza di hash resta indietro a ritmo esponenziale, quindi la sua probabilità di riscrivere un blocco si riduce in fretta a ogni conferma. Quando due miner trovano un blocco insieme, la rete ha per un attimo due rami e poi si assesta su uno; le lezioni su finalità e riorganizzazioni e su soft fork e hard fork esaminano che cosa succede quando l’assestamento va storto o quando cambiano le regole stesse.
Alla cifra della maggioranza onesta si accompagnano due avvertenze. Ittay Eyal ed Emin Gün Sirer mostrarono nel 2013 che il selfish mining, in cui un pool trattiene blocchi per sprecare il lavoro altrui, conviene a gruppi che si accordano ben sotto la metà; la correzione da loro proposta protegge solo da pool sotto un quarto della potenza di hash. Quel dibattito appartiene a una lezione successiva sugli attacchi alla rete. L’altra avvertenza è la concentrazione. Nella settimana fino al 7 novembre 2026, mempool.space attribuiva il 23,1% dei blocchi a Foundry USA, il 19,8% ad AntPool e il 17,3% a F2Pool, quindi tre pool hanno trovato il 60,1% dei blocchi. Un pool coordina molti miner indipendenti che possono andarsene, quindi non è proprietà di potenza di hash, ma in pratica la maggioranza onesta dipende dalle scelte di una manciata di coordinatori. Che cosa potrebbe e non potrebbe fare un attaccante di maggioranza è spiegato in perché una blockchain è difficile da riscrivere.
Bitcoin è Byzantine fault tolerant? Un’etichetta contestata
Molti articoli chiamano il consenso di Nakamoto Byzantine fault tolerance probabilistica. L’etichetta è contestata. Satoshi definì la catena una soluzione del problema. Juan Garay, Aggelos Kiayias e Nikos Leonardos, nella loro analisi «The Bitcoin Backbone Protocol» (Eurocrypt 2015), dimostrarono che la catena offre due garanzie durature, che chiamano common prefix e chain quality, quando l’attaccante ha meno della metà della potenza di hash e la rete è veloce. Sull’accordo bizantino in senso stretto, però, scrivono che «Nakamoto’s suggestion falls short of solving it», cioè la proposta di Nakamoto non lo risolve del tutto. Descrivono una variante semplice che raggiunge l’accordo se l’attaccante ha al massimo un terzo della potenza di hash e una più elaborata che funziona sotto la metà con forti ipotesi sui tempi della rete.
Il loro abstract aggiunge che la quota di attaccante che il sistema può sopportare si riduce man mano che la rete diventa meno sincrona. Rafael Pass, Lior Seeman e abhi shelat, in un’analisi del 2016, hanno tracciato un quadro simile: la catena resta consistente e viva quando i ritardi dei messaggi hanno un limite noto, e in una rete completamente asincrona funziona un attacco semplice, quindi la difficoltà del puzzle va fissata in rapporto al ritardo massimo. Una sintesi equa: Bitcoin raggiunge un accordo che diventa praticamente certo col tempo, tra partecipanti anonimi, sotto ipotesi sulla potenza di hash e sul ritardo di rete. Se questo meriti il nome di accordo bizantino dipende dalla definizione di partenza, e la letteratura non chiude la questione.
Le blockchain BFT di oggi: votare, finalizzare o fermarsi
Molte catene proof of stake sono tornate alla strada del voto, con lo stake al posto dell’identità: il voto di un validatore pesa quanto i token che ha bloccato, il che rende di nuovo inutili le identità false. Le basi di quel modello stanno nella voce del glossario su proof of stake; una lezione completa sul proof of stake arriverà più avanti in questo percorso.
Tendermint, descritto da Ethan Buchman, Jae Kwon e Zarko Milosevic in un articolo del 2018, aggiunge all’idea di PBFT una messaggistica basata sul gossip. Il suo motore oggi è CometBFT, un fork di Tendermint Core usato da molte catene costruite con gli strumenti Cosmos. La specifica di CometBFT presuppone che meno di un terzo del potere di voto sia bizantino, richiede più di due terzi dei voti precommit per confermare un blocco e dice apertamente che «any 1/3+ coalition of validators can halt the blockchain by not broadcasting their votes», ossia che qualsiasi coalizione di oltre un terzo dei validatori può fermare la blockchain non trasmettendo i propri voti. Se un fork avvenisse davvero, la specifica mostra che più di un terzo dei validatori avrebbe firmato due blocchi in conflitto, fatto che si può provare e punire.
È questo il compromesso di fondo del BFT classico: quando troppi votanti mancano o mentono, la catena si ferma invece di dividersi. Terra ne ha dato un esempio pubblico, anche se insolito, il 12 maggio 2022. Durante il crollo di LUNA e UST, i suoi validatori hanno fermato la catena al blocco 7.603.700 per evitare attacchi alla governance, visto che il crollo del prezzo ne aveva ridotto molto il costo, riferì quel giorno Cointelegraph (in inglese). La rete sarebbe ripartita quando due terzi del potere di voto fossero tornati online, con le nuove deleghe disattivate. Fu una decisione deliberata dei validatori, non uno stallo automatico, ma poggiava sulla stessa regola dei due terzi.
HotStuff, di Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta e Ittai Abraham (2018, pubblicato al PODC 2019), è un protocollo parzialmente sincrono basato su un leader, la cui comunicazione cresce solo in modo lineare con il numero di repliche, anche quando cambia il leader, dove il cambio di vista di PBFT era molto più pesante. Diverse catene più recenti hanno costruito il loro consenso su idee di quella famiglia; Tendermint e HotStuff avranno una lezione dedicata più avanti in questo percorso.
Ethereum mescola i due mondi. La sua regola di fork choice, LMD-GHOST, tiene in movimento la catena blocco dopo blocco, un po’ come una regola della catena più pesante. Sopra di essa, il voto di finalità Casper-FFG segna i checkpoint come definitivi quando validatori che detengono almeno due terzi dell’ETH totale in staking sono d’accordo, e, secondo la documentazione proof of stake di ethereum.org, annullare un blocco finalizzato costerebbe a un attaccante almeno un terzo di tutto l’ETH in staking. Al 7 novembre 2026, intorno alle 09:56 UTC, un nodo beacon pubblico mostrava l’epoca finalizzata due epoche dietro la testa (487.553 contro una testa all’epoca 487.555), che è il ritmo normale quando il voto funziona.
Un terzo o metà: i numeri da ricordare
Ogni riga della tabella qui sotto ha le proprie ipotesi, quindi conviene leggere la seconda colonna prima di confrontare i numeri.
| Sistema | Modello di guasto e di rete | Tollera | Che cosa richiede |
|---|---|---|---|
| Generali bizantini, messaggi orali (1982) | bugiardi arbitrari, rete sincrona | m traditori | almeno 3m + 1 generali (4 per 1 traditore) |
| Generali bizantini, messaggi firmati (1982) | i bugiardi non falsificano le firme leali | qualsiasi numero di traditori, per l’ordine di un comandante | firme e sincronia |
| FLP (1985) | un crash silenzioso, nessun orologio | nessuno, se si vuole la certezza | un’ipotesi temporale o la casualità |
| PBFT (1999) | repliche bizantine, sicuro anche in asincronia | f difettose su 3f + 1 | un gruppo fisso e noto di repliche |
| Tendermint / CometBFT | validatori bizantini pesati per stake | meno di 1/3 del potere di voto | più di 2/3 dei precommit; 1/3 o più può fermare la catena |
| Finalità di Ethereum (Casper-FFG) | staker bizantini | meno di 1/3 dello stake per la sicurezza della finalità | almeno 2/3 dell’ETH in staking per finalizzare |
| Bitcoin (consenso di Nakamoto) | attaccante con potenza di hash, ritardi limitati | meno di 1/2 della potenza di hash, con accordo probabilistico | più lavoro cumulativo; il selfish mining abbassa la soglia |
Si legga la tabella come una scelta tra due stili di fallimento. Una catena BFT con un voto a due terzi è definitiva nel momento in cui il voto si chiude, ma può essere fermata da un terzo dei votanti. Una catena di Nakamoto continua a produrre blocchi qualunque cosa accada, ma ogni blocco recente resta in linea di principio reversibile, e l’accordo è questione di profondità.
Per chi usa le crypto, la differenza è concreta. Su una catena con finalità BFT, un pagamento definitivo non verrà annullato senza uno slashing ampio e dimostrabile dei validatori. Su Bitcoin è chi riceve a scegliere quanti blocchi aspettare, e gli exchange fissano da sé il numero di conferme per i depositi.
Blockchain con permessi e blockchain pubbliche: la visione del NIST
La descrizione ufficiale più chiara di queste scelte è il rapporto NIST IR 8202 del National Institute of Standards and Technology statunitense, «Blockchain Technology Overview» (ottobre 2018). Descrive il voto a più round tra staker, che secondo il rapporto viene talvolta chiamato Byzantine fault tolerance proof of stake, e la produzione di blocchi a turno usata da alcune reti blockchain con permessi, dove i membri sono noti e approvati.
Questa distinzione spiega molti progetti aziendali. Un consorzio di banche o di fornitori conosce già i suoi membri, quindi il problema Sybil non si pone mai e un voto in stile PBFT dà un accordo rapido e definitivo. Una rete pubblica come Bitcoin non ha un custode, quindi paga la sicurezza con il lavoro. Il rapporto del NIST è una panoramica tecnica, non una norma.
I punti da ricordare
- La questione dei generali bizantini è come le parti oneste di un sistema possano accordarsi quando alcune parti mentono, e mentono in modo diverso ad ascoltatori diversi.
- Con messaggi non firmati, più di due terzi devono essere onesti: 3m + 1 partecipanti per m bugiardi. Le firme non falsificabili tolgono questo limite quando si tratta di seguire l’ordine di un solo capo.
- La questione dei due generali (1975) riguarda i messaggi persi tra parti oneste, non i bugiardi.
- FLP (1985) esclude un consenso garantito senza ipotesi sul tempo; la sincronia parziale (1988) è diventata il modo standard di aggirarlo, e PBFT (1999) ha reso veloce il BFT per un gruppo noto di membri.
- Bitcoin ha sostituito l’elenco dei membri con la proof of work e accetta un accordo che si consolida blocco dopo blocco, sotto la metà della potenza di hash nel suo modello di base; le catene BFT classiche tollerano meno di un terzo di potere di voto cattivo e si fermano invece di dividersi.
La prossima lezione, la proof of work in profondità, apre la scatola a cui Satoshi puntava: come un miner calcola l’hash dell’header di un blocco, come la difficoltà tiene i blocchi vicini ai dieci minuti e quanto costerebbe oggi un attacco al lavoro.
