BLOCKCHAIN - I SISTEMI DISTRIBUITI, Pratica tolleranza ai guasti bizantini o PBFT Part. 5

nota: abbiamo visto che gli algoritmi di  Paxos e Raft non sono di default tolleranti ai guasti bizantini.

L'algoritmo PBFT gestisce meno di ⅓ errori bizantini, ma alla condizione:  3f + 1 nodi totali
dove f ( errore bizzantino ) 1 ( corrisponde a un NODO ).

L'algoritmo PBFT  è costituito da TRE fasi: Pre - preparazione, Preparazione e Commit
L' algoritmo PBFT inizia quando il client invia una richiesta al nodo primario.

Si ponga l'atenzione sulla seguente condizione, dove ricordando PAXOS era come quando  il Proponente propone nuovi decreti ad altri legislatori del Parlamento Paxos in base alle richieste del popolo.

Nell'esempio che segue il nodo principale è DERRICK

Abbiamo un totale di 4 nodi, il che significa che il sistema dovrebbe essere in grado di resistere a 1 guasto, poiché ¼ è inferiore a ⅓.

Ora supponiamo che uno di i nostri 4 nodi, Nadir, si elimina a causa di una connessione internet fasulla

Nadir potrebbe essersi ritirato, ma gli altri 3 nodi potrebbero non saperlo ancora, quindi lo considerandolo ancora aattivo gli inviano messaggi

Il prossimo passo è la preparazione preliminare ( Pre-preparazione ), che è una delle tre fasi principali. Nella fase di pre-preparazione, il nodo principale Derrick invia Pre-preparazione attraverso messaggi a tutti, nella rete. Un nodo accetta il messaggio di pre-preparazione a condizione che sia valido.

I messaggi contengono un numero di sequenza simile ed essi contengono firme e altri metadati utili, che possono consentire ai nodi di determinare la validità del messaggio.

Ora, se un nodo accetta un messaggio di (Pre-preparazione ) preparazione preliminare, ne segue inviando un messaggio di preparazione a tutti gli altri.

Un nodo è considerato "preparato" se ha visto la richiesta originale dal nodo primario, dopo che i nodi sono stati preparati, questi inviano un messaggio di commit.

Se il nodo riceve f + 1 valido messaggio di commit ( dove f è l'errore bizantino ), Il client attende f + 1 della stessa risposta. E affinche' la risposta sia garantita dobbiamo aspettare almeno la condizione f + 1 , che garantisce che il client ha ottenuto la risposta corretta.

APPROFONDIMENTO

Per comprendere meglio l'esempio appena citato, si faccia riferimento al grafico che segue:

Dove Il client è processo C. 

> Derrick è processo 0

>> Rustie è processo 1

>>>  Gloria è processo 2 

>>>> Nadir è il processo 3.

Nel primo passaggio il Client ha inviato un messaggio a Derrick ( processo 0 ) 

Durante questo periodo, Nadir fallisce. Quindi, Derrick invia un messaggio di pre-preparazione al resto dei processi. 

Tutti tranne Nadir rispondono con un messaggio di preparazione.

Dopo aver riconosciuto la presenza di tutti, tutti inviano il ​​messaggio di commit.

Dopo aver ascoltato una quantità sufficiente di commit, rispondiamo direttamente al cliente.

Nota dell'autore. Se sei arrivato fino a qui, grazie ! Se vuoi supportare questo documento ( con note e / o miglioramenti ) oppure mi vuoi suggerire errori e/o omissioni, aggiunte da fare, ti invito a lasciare un commento ed una nota di miglioramento, attraverso l'apposito campo " commenti " .

Ti ringrazio.

Write By     Andrea Belvedere
Follow me. https://twitter.com/AndreaBelvedere