PBFT

Da BitcoinWiki.

PBFT descrizione concisa[modifica]

Practical Byzantine Fault Tolerance (in inglese), PBFT, è un caso specifico e l'ottimizzazione della capacità di rete tolleranza ai guasti bizantina. È stato sviluppato da Barbara Liskov e Miguel Castro e introdotto nel 1999.

PBDF fornisce alla rete l'approccio Byzantine state machine, ovvero l'implementazione di una tolleranza ai guasti Byzantine copiando i server e sincronizzando le interazioni client con le copie del server PBFT può garantire la tolleranza ai guasti delle reti, consentendo al tempo stesso di elaborare migliaia di operazioni al secondo con aumenti quasi trascurabili dei tempi di attesa.

Byzantine Fault Tolerance[modifica]

Pratical Byzantine Fault Tolerance (Pbft) è un caso specifico e l'ottimizzazione della capacità di rete Byzantine Fault Tolerance. La tolleranza ai guasti bizantina è la capacità di una rete di raggiungere inequivocabilmente un consenso nonostante i tentativi dei nodi dannosi di propagare dati falsi ad altri colleghi.

Questa capacità è di fondamentale importanza per le reti distribuite per prevenire la diffusione di errori e informazioni errate inviate da nodi dannosi o rotti. Reti che non Bysantine Fault Tolerant se non hanno un consenso sufficiente sullo stato dei nodi.

Ad esempio, un server si è rotto e sta diffondendo dati errati. In una rete Bysantine Fault Tolerant, il consenso rimane tra i nodi che funzionano ancora correttamente. I dati, diffusi dal server rotto, non corrispondono ai dati dei partecipanti dell'altra rete e non influiscono sulla sua manutenzione. I sistemi di rilevamento dei guasti in tale rete rileveranno il suo problema e lo limiteranno dall'ulteriore funzionamento. In un "fallimento bizantino" questo server sarà visto in modo diverso da diversi nodi. Alcuni nodi lo considereranno pienamente funzionante e continueranno a raccogliere le sue informazioni. Sarebbe difficile arrestare automaticamente il server a causa della mancanza di consenso tra i partecipanti sulle sue condizioni.

L'idea e il termine moderno derivano dal problema dei generali bizantini, che è descritto nel paragrafo seguente.

Problema Dei Generali Bizantini[modifica]

Il problema dei generali bizantini è formulato in modo diverso in varie fonti, ma non sono stati emessi cambiamenti di significato, solo quelli stilistici.

Bisanzio. La notte prima della grande battaglia.

L'esercito bizantino è composto da n legioni, ognuna comandata dal suo generale. L'esercito ha anche un comandante in capo, a cui obbediscono i generali.

Allo stesso tempo, L'Impero Bizantino è in declino, e uno qualsiasi dei generali e persino il comandante in capo potrebbero essere traditori, interessati alla sconfitta di Bizantino.

Uno dei generali ottiene il leader della linea d'azione dell'ordine alle 10 del mattino (il tempo è lo stesso per tutti e conosciuto in anticipo), vale a dire: "attaccare il nemico" o "ritirarsi".

Possibili risultati della battaglia:

  • Se tutti i fedeli generali attaccano-Bisanzio distruggerà il nemico (esito favorevole).
  • Se tutti i fedeli generali si ritirano, Bisanzio manterrà il suo esercito (esito intermedio e neutrale).
  • Se alcuni generali fedeli attaccano e alcuni si ritirano, il nemico distruggerà l'intero esercito di Bisanzio (esito sfavorevole).

Inoltre si deve notare che se il comandante in capo un traditore, si può fare opposte generali ordini per garantire la distruzione dell'esercito. Pertanto, i generali meglio non fidarsi dei suoi ordini.

Se ogni Generale agirà completamente indipendentemente dall'altro (ad esempio, fare una selezione casuale), la probabilità di un risultato favorevole è molto bassa. Pertanto, i generali devono scambiare informazioni tra loro per giungere a una soluzione comune.

Secondo i risultati dello scambio, ciascuno dei generali fedeli deve ottenere un vettore di interi di lunghezza n, in cui l'elemento i-esimo è uguale al vero numero dell'esercito i-esimo (se il suo generale è fedele), o contiene disinformazione sul numero dell'esercito i-esimo (se il suo generale non è fedele). Allo stesso tempo, i vettori ottenuti da tutti i comandanti fedeli dovrebbero essere completamente identici, anche se le informazioni sull'esercito nemico sono false.

Funzionamento di PBFT[modifica]

Liskov e Castro hanno progettato il pBFT per funzionare in modo efficiente nei sistemi asincroni e. È ottimizzato per rimanere ad alte prestazioni con un runtime overhead impressionante e solo un leggero aumento della latenza.

Tutti i nodi nel modello pBFT sono ordinati in un modo in modo che non ci sia leader (centro) nella rete. Ogni nodo può comunicare l'altro. Questo sistema aiuta la rete a mantenere il consenso sullo stato attuale del sistema tra i nodi onesti. In pbft, i nodi devono interagire strettamente tra loro. le reti pBFT richiedono alla rete sia di convalidare i messaggi da altri nodi, sia di verificare l'affidabilità e l'inutilità del messaggio.

PBFT e Criptovaluta[modifica]

In relazione al settore delle criptovalute, il PBFT può essere un'alternativa o un'aggiunta al meccanismo di consenso proof-of-work (POW). Mentre Bitcoin raggiunge la tolleranza ai guasti bizantina con la sua proof-of-work, ha molti aspetti negativi. Il consenso Bitcoin richiede un grande consumo di energia, è difficile da scalare e non molto veloce.

Nelle reti pBFT, non è necessario convalidare ogni transazione poiché tutti i nodi della rete sono in Consenso sullo stato generale della rete. In make pbft significativamente meno computazionalmente intensivo e, quindi, meno energia esigente.

Tuttavia, PBFT richiede un alto livello di comunicazione tra i nodi, che porta alle limitazioni in termini di dimensioni della rete che può essere ben governata con pBFT. Piccole dimensioni possibili di tali reti possono portare all'attacco sybil — un attacco eseguito con la forgiatura di un gran numero di entità nella rete per assumere > ⅓ della rete.

Con alcune funzionalità aggiuntive, pBFT è implementato nella criptovaluta Zilliqa e nel progetto Hyperledger. pBFT in Hyperledger viene utilizzato per fornire ai suoi progetti una scalabilità aggiuntiva e in Zilliqa per fornire transazioni elevate al secondo indicatore combinando pBFT con la tradizionale prova di lavoro.

Vedere Anche[modifica]