Vai al contenuto
Financial Context Wiki

Tolleranza ai guasti bizantini: sicurezza, vitalità e quorum

La tolleranza ai guasti bizantini descrive quando un protocollo distribuito resta sicuro e vitale nonostante guasti arbitrari. Protocollo, modello di rete, limite dei guasti, quorum, pesi, finalità e recupero vanno valutati insieme.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

La tolleranza ai guasti bizantini (BFT) è una proprietà di uno specifico protocollo distribuito sotto specifici modelli di guasto e di rete: continua a rispettare le garanzie dichiarate anche se alcuni partecipanti si arrestano, trattengono messaggi, inviano messaggi incompatibili a destinatari diversi o agiscono arbitrariamente. BFT non è un singolo algoritmo e non implica che ogni servizio resti disponibile durante qualsiasi partizione.

Le garanzie vanno separate. safety (sicurezza) impedisce ai partecipanti onesti di decidere valori incompatibili; liveness (vitalità) permette agli input idonei di portare infine a una decisione; validity (validità) limita i valori decidibili. Un protocollo può arrestarsi per preservare la sicurezza se comunicazione o potere di voto onesto sono insufficienti. Un consenso corretto non prova inoltre che siano corretti il codice applicativo, le regole di validità, i bridge, le chiavi o la governance.

In una classe comune di protocolli BFT autenticati e parzialmente sincroni, n=3f+1 repliche tollerano al massimo f repliche bizantine e un certificato di commit usa q=2f+1 voti. Le espressioni “meno di un terzo guasto” e “quorum superiore a due terzi” derivano da questo modello. Protocolli sincroni, protocolli asincroni randomizzati, protocolli per guasti da arresto, blockchain Proof of Work e altre costruzioni BFT possono avere ipotesi e soglie diverse.

Nei sistemi ponderati per stake, le soglie riguardano il potere di voto definito dal protocollo, non necessariamente il numero di validatori, indirizzi, persone od operatori indipendenti. Prima di applicare una frazione bisogna indicare versione esatta, fotografia dei pesi, tipo di decisione, ipotesi di rete, confronto del quorum (> o >=) e comportamento guasto.

Sotto soglia
25%
Quota contraddittoria
25%
Margine alla soglia
8,4%

I risultati sono approssimazioni didattiche. Escludono regole della sede, tasse, latenza, comportamento degli oracoli e altri parametri specifici del protocollo se non indicati.

Come funziona

  1. Definire la decisione. Stabilire se i nodi ordinano transazioni, confermano un blocco, finalizzano un checkpoint, eleggono un leader, accettano una transizione di stato o scelgono una biforcazione. Non sono decisioni intercambiabili.
  2. Dichiarare i modelli di sistema e avversario. Registrare appartenenza, autenticazione, cambi di permessi, pesi, corruzione adattiva, compromissione delle chiavi, equivocazione, arresti, perdita di messaggi, censura, negazione del servizio e possibili guasti correlati.
  3. Dichiarare il modello di rete. Distinguere sincronia, sincronia parziale e asincronia. Nella sincronia parziale, precisare cosa è garantito solo dopo un tempo globale di stabilizzazione ignoto e come si adattano le scadenze.
  4. Derivare la regola del quorum. Usare soglia e regole esatte di blocco o voto. Nel caso classico n=3f+1, due quorum 2f+1 si intersecano in almeno f+1 repliche; con al massimo f bizantine, l’intersezione contiene una replica onesta.
  5. Seguire ogni fase e certificato. Verificare proposta, voto, blocco, cambio di vista o turno, commit, scelta della biforcazione e recupero. Una supermaggioranza firmata vale solo se si convalidano altezza, turno, valore, genitore, dominio, epoca dei membri e certificato precedente.
  6. Separare le prove di sicurezza e vitalità. Dimostrare quali decisioni incompatibili sono escluse in ogni momento rilevante, poi verificare che il progresso riprenda quando valgono le ipotesi di comunicazione e partecipazione onesta. Una scadenza è uno strumento di pianificazione, non prova di dolo.
  7. Verificare implementazione e operatività. Confrontare con il modello diversità dei client, custodia delle chiavi, failover dei firmatari, protezione dai replay, sincronizzazione dello stato, gestione delle prove, cambi dei membri, monitoraggio, politica di conferma e recupero.

Il risultato FLP afferma che un protocollo di consenso deterministico non può garantire la terminazione in un modello interamente asincrono anche con un solo possibile arresto. Non afferma che la sicurezza sia impossibile né che il consenso distribuito non possa mai funzionare. Sincronia parziale, casualità, rilevatori di guasto, ipotesi economiche o garanzie più deboli modificano in modi diversi le precise condizioni dell’impossibilità.

Esempi calcolati

1. Quattro repliche di pari peso

Siano n=4, f=1 e q=3. Due insiemi da tre voti si intersecano in almeno 3+3-4=2 repliche. Con al massimo una replica bizantina, almeno una nell’intersezione è onesta. Se le regole dei nodi onesti vietano voti per valori incompatibili nella cronologia rilevante di altezza e turno, non possono formarsi due certificati di commit incompatibili.

Se due repliche sono offline, restano solo 2 voti e non si forma un certificato q=3. È un guasto di vitalità, non automaticamente di sicurezza: un protocollo sicuro attende invece di ridurre localmente la soglia.

2. Sette repliche di pari peso

Siano n=7, f=2 e q=5. Due quorum si intersecano in almeno 5+5-7=3=f+1 repliche. Poiché al massimo 2 sono bizantine, l’intersezione contiene un’onesta. Due bizantine non possono creare da sole un certificato di cinque voti, ma tre assenti o che trattengono voti lasciano solo 4 e possono fermare il progresso.

L’aritmetica della soglia è necessaria ma non sufficiente. Se implementazioni oneste accettano voti di un’altra altezza, riutilizzano membri, violano un blocco o firmano con chiavi compromesse, le ipotesi della prova non descrivono più il sistema installato.

3. Potere di voto ponderato

Si suppongano pesi 40, 30, 20 e 10, totale 100, e un certificato che richieda strettamente più di 2/3, qui almeno 67. La coalizione 40+30=70 può certificare; 30+20+10=60 no, pur riunendo tre validatori su quattro. Se il validatore di peso 40 va offline, restano 60 e la finalità si arresta.

Due insiemi di almeno 67 si intersecano in almeno 67+67-100=34. Certificati incompatibili implicano quindi che almeno 34 di peso abbia partecipato a entrambi o che sia fallita un’altra ipotesi. In alcuni protocolli poco più di un terzo che equivoca può violare la sicurezza; “due terzi per attaccare” non è un minimo universale.

4. Sincronia parziale e scadenze

Si suppongano scadenze di turno di 1 s, 2 s, 4 s e 8 s. Prima dell’istante ignoto di stabilizzazione, i messaggi possono arrivare dopo ogni scadenza e provocare cambi di turno senza decisione. Se poi il ritardo resta sotto 3 s, un turno da 4 s o successivo può dare tempo a proponente onesto e quorum, ferme le altre ipotesi.

I numeri illustrano il progresso finale, non una formula universale. Scadenze brevi causano cambi inutili; lunghe aumentano il tempo di recupero. La sicurezza non deve dipendere dall’indovinare il limite di ritardo prima della stabilizzazione.

Rischi ed errori di verifica

Modello e prova

  • Dire “BFT” senza nominare protocollo, versione, decisione, modello di guasto, rete, appartenenza e soglia.
  • Applicare n=3f+1 o un terzo a ogni registro distribuito anche quando la prova usa altre ipotesi.
  • Confondere sicurezza, vitalità, validità, disponibilità, coerenza, finalità, scelta della biforcazione e correttezza delle transazioni.
  • Affermare che FLP renda impossibile il consenso senza mantenere le condizioni di determinismo, piena asincronia e terminazione garantita.
  • Contare nodi o indirizzi quando il protocollo conta stake, delega, comitati, epoche o un’altra risorsa.
  • Arrotondare ambiguamente “due terzi” o ignorare >, >=, pesi interi e fotografia del denominatore.
  • Controllare la dimensione del quorum senza intersezione, blocchi, certificati, cambi di vista, riconfigurazione e trasferimento dello stato.
  • Presumere che una prova copra corruzione adattiva, furto di chiavi, guasti correlati, negazione del servizio o cronologie a lungo raggio.

Implementazione e operatività

  • Accettare firme non legate a catena, dominio, altezza, turno, valore, genitore, epoca dei membri e tipo di messaggio.
  • Riprodurre voti o certificati vecchi tra turni, altezze, biforcazioni, reti, aggiornamenti o cambi dei validatori.
  • Consentire doppia firma, regressione del blocco, failover insicuro o due repliche attive con la stessa identità di validatore.
  • Trattare la scadenza come prova di dolo e decidere sulla sicurezza usando soltanto orologi locali.
  • Ignorare guasti correlati dovuti a client, cloud, regione, rete, hardware, gestione delle chiavi od operatore comuni.
  • Presumere che lo slashing impedisca guasti, ripristini vitalità, annulli azioni finalizzate o risarcisca tutti.
  • Provare solo il caso normale, non partizioni, ritardi, riordino, equivocazione, guasto del proponente, riavvii e cambi dei membri.

Applicazione e governance

  • Trattare un valore oggetto di commit come stato valido senza esecuzione deterministica e convalida della transizione.
  • Accreditare depositi, coniare criptoattività tramite bridge o regolare scambi prima dell’esatta finalità richiesta.
  • Equiparare finalità del protocollo e irreversibilità sociale dopo chiavi compromesse, errore software o intervento di governance.
  • Ignorare censura e ritardo d’inclusione perché i blocchi degli altri utenti continuano a essere finalizzati.
  • Dedurre decentralizzazione, sicurezza delle attività, valore del token o efficacia giuridica dall’etichetta BFT o dal numero pubblicizzato di validatori.

Idee sbagliate comuni

  • BFT significa che la rete non si ferma mai. Molti protocolli sacrificano deliberatamente la vitalità durante guasti eccessivi o partizioni per preservare la sicurezza.
  • Più del 51% di partecipanti onesti basta sempre. La soglia dipende dal protocollo; il BFT classico parzialmente sincrono richiede spesso oltre due terzi del potere rilevante per progredire.
  • Un attaccante necessita sempre di due terzi per violare la sicurezza. Due terzi possono certificare da soli, ma due certificati incompatibili possono rivelare poco più di un terzo che equivoca.
  • Più indirizzi di validatori migliorano automaticamente la tolleranza. Proprietà comune, deleghe, client, infrastruttura, chiavi e domini di guasto determinano l’indipendenza.
  • Lo slashing è la prova BFT. È una risposta economica di alcuni sistemi PoS; la sicurezza deriva da regole e ipotesi e le sanzioni non annullano conseguenze esterne.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...