Da Manlio Carlo Soldani 
Indice dei contenuti
Un’equazione data per scontata
Quando si parla di distributed ledger technology e di blockchain, prima o poi compare un termine che ha finito per assumere il ruolo di sinonimo della “sicurezza vera”: il Byzantine Fault Tolerance, spesso abbreviato in BFT. L’idea diffusa è semplice e intuitiva, almeno in apparenza. Se una rete distribuita deve resistere ai comportamenti maligni dei suoi nodi — nodi che non solo possono fallire, ma possono attivamente ingannare gli altri — allora il protocolo di consenso adottato deve essere necessariamente BFT. Questa affermazione viene ripetuta in corsi universitari, whitepaper e articoli divulgativi come se fosse un assioma della distributed computing. Eppure non lo è. È un’assunzione, e un’assunzione che vale la pena esaminare con attenzione, perché la sua acritica accettazione ha finito per distorcere il modo in cui il settore valuta i protocolli di consenso, e quindi le stesse infrastrutture digitali su cui si fondano sempre più processi economici e giuridici.
Cosa significa davvero “Byzantine Fault Tolerance”
Per capire perché l’equazione “blockchain = BFT” sia così radicata, è utile tornare alle origini del problema. Il problema dei Generali Bizanti, come viene chiamato nella letteratura informatica, descrive uno scenario in cui un gruppo di generali deve coordinare un attacco contro un nemico comune. Alcuni generali potrebbero essere traditori e tentare di sabotare il coordinamento, inviando messaggi contraddittori a quelli fedeli. Il problema è che i generali fedeli non sanno chi è un traditore e non hanno un canale di comunicazione garantito: i messaggi possono essere intercettati, falsificati o semplicemente non arrivare.
Un sistema è Byzantine Fault Tolerant quando riuscisce a raggiungere un accordo corretto anche in presenza di nodi che si comportano in modo arbitrariamente maligno, purché la percentuale di questi nodi resti sotto una soglia specifica — generalmente il terzo dei nodi totali nel caso dei protocolli classici come PBFT. Questa è una condizione molto forte. Implica che il sistema deve funzionare correttamente non solo quando qualcosa va storto per caso, ma anche quando qualcuno cerca attivamente di farlo andare storto in modo coordinato e sofisticato.
Il punto di partenza errato: l’assunzione sul modello di minaccia
Il problema nasce dal modo in cui la conversazione sulla sicurezza dei consensus protocol viene tipicamente impostata. Si parte dal modello di minaccia più severo possibile — quello in cui i nodi possono comportarsi in modo completamente arbitrario — e si conclude che tutti i sistemi blockchain devono essere progettati per resistere a quella minaccia. Questa logica ha una sua coerenza interna, ma presuppose qualcosa che non è sempre verificato nella realtà: ovvero che ogni rete distribuita che si chiama blockchain si trovi effettivamente in un ambiente in cui quel livello di minaccia è presente e rilevante.
La verità è che il modello di minaccia dovrebbe essere una scelta progettuale, non un dogma. E questa scelta dipende strettamente dal contesto in cui opera il sistema. Una rete completamente pubblica e permissionless, in cui chiunque può diventare nodo senza verifica alcuna, si trova in una situazione molto diversa rispetto a una rete consortium o permissioned, in cui i partecipanti sono identificati, contrattualmente vincolati e soggetti a meccanismi di governance condivisi. Trattare queste due situazioni come se richiedessero la stessa soluzione di sicurezza è come disegnare una porta blindata da bunker militare per l’ingresso di un condominio nel quale tutti i residenti si conoscono e si fiduciavano da anni.
Perché Proof of Work non è BFT, eppure funziona
Il esempio più clamoroso di questa disconnessione tra l’assunzione teorica e la pratica è rappresentato dal Proof of Work, il meccanismo di consenso originale di Bitcoin. PoW non è un protocollo BFT nel senso classico della letteratura sulla distributed computing. Non garantisce la tolleranza a faulting byzantino nel modo in cui lo intende il problema dei Generali, dove il fallimento è attivo e intenzionale. Quello che PoW fa è creare un sistema di incentivi economici per cui comportarsi in modo disonesto diventa più costoso che comportarsi in modo onesto.
Un miner che tenta di alterare il registro deve spendere risorse computazionali enormi per farlo, e anche se riuscisse a creare un blocco fittizio, questo verrebbe rifiutato dalla rete maggioritaria che segue la catena più lunga con più lavoro dietro. La sicurezza del sistema non discende dalla capacità formale di gestire nodi maligni, ma dalla struttura economica che rende il comportamento maligno irrazionale. Questa è una forma profondamente diversa di sicurezza rispetto a quella BFT, ma non è meno valida. È semplicemente basata su un modello di minaccia diverso: quello in cui gli attori sono razionali e guidati da interessi economici, non quello in cui gli attori possono comportarsi in modo completamente arbitrario e irrazionale.
Il ruolo degli incentivi e della governance
Questa osservazione apre un punto ancora più importante. Molte delle blockchain più utilizzate nel mondo reale — in scambio di valute tokenizzate, nella gestione di supply chain, in applicazioni di finanza decentralizzata — operano in ambienti in cui i partecipanti hanno identità nota o verificabile, hanno firmato contratti e sono soggetti alle leggi vigenti. In questi ambienti il modello di minaccia “byzantino” nel senso stretto è largamente improbabile, proprio perché un nodo che si comportasse malignamente sarebbe identificabile e perseguibile sia tecnicamente che legalmente.
Per questi contesti, protocolli come Raft, o varianti basate sull’accordo basato su leader eletto, offrono performance molto superiori al PBFT classico, con overhead di comunicazione enormemente inferiore e con un livello di sicurezza che è più che adeguato al modello di minaccia reale. Raft, ad esempio, tollera i fallimenti crash — ovvero nodi che semplicemente smettono di rispondere — ma non i fallimenti byzan tini. Questo lo rende inadatto a una rete completamente pubblica senza governance, ma perfettamente appropriato a una rete permissioned dove i nodi sono fidati e monitorati.
La tradeoff che viene ignorata
Dietro l’insistenza sull’unicità del modello BFT si nasconde una tradeoff che viene spesso ignorata nella discussione pubblica: quella tra sicurezza e scalabilità, ma anche tra sicurezza e complessità di implementazione. I protocolli BFT classici hanno una complessità di comunicazione che cresce quadraticamente con il numero dei nodi. Questo significa che oltre un certo numero di partecipanti, il sistema inizia a degradare rapidamente in termini di prestazioni. Per questa ragione, le implementazioni BFT in sistemi distribuiti di grandi dimensioni richiedono tipicamente architetture a più livelli, dove un sottoinsieme di nodi partecipa al consenso BFT e gli altri interagiscono con il sistema in modo diverso.
Non si tratta di un dettaglio tecnico marginale. Si tratta di un vincolo architetturale fondamentale che incide direttamente sulla struttura del sistema e, di conseguenza, sul suo livello di decentralizzazione. Un sistema che per necessità deve limitare il numero di nodi che partecipano direttamente al consenso è, structuralmente, meno decentralizzato di uno che può coinvolgere un numero arbitrariamente grande di partecipanti. Se l’obiettivo di una blockchain è proprio la decentralizzazione, imporre BFT come condizione necessaria di sicurezza significa accettare un compromesso che non sempre è giustificato dal contesto.
Un sistema sicuro non significa un sistema byzantino
La conclusione non è che BFT sia inutile o che debba essere abbandonato. BFT resta uno strumento potente e necessario in scenari in cui il modello di minaccia giustifica davvero il suo utilizzo — reti completamente pubblica, ambienti altamente adversariali, sistemi in cui l’identità dei partecipanti è sconosciuta e non verificabile. Il problema è l’equazione rigida tra “blockchain sicura” e “consenso BFT”, che non tiene conto della diversità dei contesti in cui le tecnologie a registro distribuito vengono applicate.
Un sistema a registro distribuito è sicuro quando il suo protocollo di consenso è adeguato al proprio modello di minaccia, ai propri vincoli di scalabilità e alla propria struttura di governance. Questo può significare BFT. Ma può anche significare Proof of Work, Proof of Stake con meccanismi di slashingeconomici, o protocolli basati su accordo leader-follower come Raft, a seconda di come rete sia concepita e a chi è destinata. La sicurezza di un sistema distribuito non è un livello fisso da raggiungere, ma una proprietà relativa che dipende dalle assunzioni sul mondo in cui il sistema opera. Capire questa distinzione è fondamentale per chi si cimenta nella progettazione o nella valutazione di infrastrutture digitali basate su registro condiviso, perché significa smettere di chiedere “questo sistema è BFT?” e iniziare a chiedere la domanda giusta: “questo sistema è sicuro rispetto alle minacce che deve concretamente affrontare?”
Il presente articolo ha carattere generale e informativo, non costituisce parere legale personalizzato e non sostituisce la consulenza diretta con un notaio. Per assistenza specifica relativa alla vostra situazione, vi invitiamo a contattare il nostro Studio per fissare un appuntamento. Contenuto generato con sistemi di Intelligenza Artificiale e supervisionato da professionisti dello Studio Notarile, in conformità ai requisiti di trasparenza del Regolamento UE 2024/1689 (AI Act).