105 lines
9.6 KiB
Markdown
105 lines
9.6 KiB
Markdown
|
# Problema del consenso con Bizantine Failures
|
||
|
|
|
||
|
|
Considerando il modello sincrono, il modello a fallimenti bizantini vuole rappresentare una categoria di malfunzionamenti in cui i processi possono esibire un comportamento imprevedibile, in contrapposizione con il modello a stopping failures che vuole rappresentare processi che falliscono fermandosi senza warning.
|
||
|
|
|
||
|
|
## Il problema del consenso
|
||
|
|
|
||
|
|
*(agreement problem)*
|
||
|
|
I processi sono **inizializzati con inputs individuali da un set di valori V**. Tutti i processi che eseguono correttamente **devono produrre un output appartenente allo stesso set di valori V**.
|
||
|
|
L'output e' soggetto a un semplice consenso e a condizioni di validita'. Per la validita', si assume che se ogni processo inizia con lo stesso valore `v`, allora l'unico valore permesso e' `v`.
|
||
|
|
Il problema del consenso deriva dallo sviluppo di on-board aircraft control systems, in cui un numero di processi, ognuno con il proprio altimetro indipendente, devono raggiungere un accordo (*consenso*) riguardante l'altitudine dell'aereo. Qualche processo potrebbe essere malfunzionante.
|
||
|
|
|
||
|
|
Il numero di *failures* e' considerato limitato in partenza, da un numero `f` fissato. Questo permette di evitare l'analisi probabilistica del numero di fallimenti, per semplicita'. Si nota pero' che questo e' poco pratico nelle applicazioni reali, dove i failures sono solitamente indipendenti (o correlati positivamente), mentre fissando il numero massimo in partenza risultano correlati negativamente.
|
||
|
|
|
||
|
|
*Nota: il coefficiente di correlazione ha range [-1,1], per cui:*
|
||
|
|
|
||
|
|
* *>0 implica correlazione positiva, quindi le variabili crescono e decrescono assieme (se una cresce, anche l'altra cresce, e viceversa).
|
||
|
|
* <0 implica correlazione negativa, quindi le variablil cresconon e decrescono in maniera opposta (se una cresce, l'altra decresce, e viceversa).*
|
||
|
|
|
||
|
|
#### Ridondanza
|
||
|
|
|
||
|
|
Gli **algoritmi di consenso Bizantini** sfruttano spesso la ridondanza di processi che compiono uguali operazioni / computazioni per garantire robustezza contro i fallimenti bizantini.
|
||
|
|
|
||
|
|
### Statement del problema
|
||
|
|
|
||
|
|
Si assume che il network e' un **grafo non direzionale connesso** con processi 1...n, in cui ogni processo **conosce l'intero grafo**. Ogni processo inizia con un input da un set di valori fissato V, assumendo che per ogni processo c'e' **esattamente uno stato iniziale contenente ogni valore di input**. L'obbiettivo dei processi e' di restituire in output decisioni dallo stesso set di valori V, settando dei componenti speciali detti **stati di decisione** a valori in V.
|
||
|
|
Il numero di processi che puo' fallire e' limitato a `f`, tutti i link sono invece *reliable*, ossia non possono fallire. Di conseguenza, tutti i messaggi inviati sono consegnati.
|
||
|
|
In questa situazione, i tipi di malfunzionamento considerati (stopping failures, fallimenti bizantini) sono gli unici possibili.
|
||
|
|
|
||
|
|
#### Stopping failures model - condizioni di correttezza
|
||
|
|
|
||
|
|
In presenza di stopping failures, un processo puo' fermarsi senza preavviso, anche nel mezzo di un invio di messaggi. Le condizioni di correttezza del problema del consenso sono quindi:
|
||
|
|
|
||
|
|
* **CONSENSO**: Nessuna coppia di processi decide valori differenti.
|
||
|
|
* **VALIDITA'**: Se tutti i processi partono con lo stesso valore iniziale `v` appartenente a V, allora `v` e' l'unico valore decisione possibile.
|
||
|
|
* **TERMINATION**: Tutti i processi funzionanti correttamente, alla fine, decidono (settano lo stato di decisione).
|
||
|
|
|
||
|
|
### Bizantine failures model - condizioni di correttezza
|
||
|
|
|
||
|
|
In presenza di fallimenti bizantini, un processo potrebbe fallire non solo fermandosi, ma esibendo un comportamento indeterminato. Questo vuol dire che potrebbe iniziare in uno stato arbitrario, non necessariamente uno dei suoi stati iniziali, potrebbe mandare **messaggi arbitrari**, ed eseguire **transizioni di stato arbitrarie**. L'unica limitazione e' che un processo puo' influenzare solo le variabili sulle quali ha controllo (il suo stato e i messaggi di output che manda).
|
||
|
|
|
||
|
|
* **CONSENSO**: Nessuna coppia di processi **funzionanti correttamente** decide valori differenti.
|
||
|
|
* **VALIDITA'**: Se tutti i processi **funzionanti correttamente** partono con lo stesso valore iniziale `v` appartenente a V, allora `v` e' l'unico valore decisione possibile.
|
||
|
|
* **TERMINATION**: Tutti i processi funzionanti correttamente, alla fine, decidono (settano lo stato di decisione).
|
||
|
|
|
||
|
|
### Relazione tra stopping failures e bizantine failures
|
||
|
|
|
||
|
|
Si nota come **un algoritmo che risolve il problema dei fallimenti bizantini solitamente NON risolve gli stopping failures**, mentre **il contrario di solito e' vero**. Questo perche' negli stopping failures e' richiesto che tutti i processi, anche quelli malfunzionanti, producano una decisione corretta.
|
||
|
|
|
||
|
|
#### Nota: misurazioni complesse
|
||
|
|
|
||
|
|
Per misurare la *time complexity* si contano tutti i cicli finche' ogni processo funzionante correttamente decide. Per misurare la *communication complexity*, si contano sia il numero di messaggi sia il numero di bit di comunicazione. **Per i processi bizantini, non c'e' modo di stabilire un boundary sulla comunicazione mandata da un processo malfunzionante.**
|
||
|
|
|
||
|
|
## Algoritmi per Stopping failures
|
||
|
|
|
||
|
|
### 6.2.1 - Basic algorithm (FloodSet)
|
||
|
|
|
||
|
|
Si basa su un funzionamento semplice: **i processi propagano tutti i valori di V che hanno mai visto / considerato, e utilizzano una semplice regola di decisione alla fine.**
|
||
|
|
|
||
|
|
*(vedi libro per dimostrazione di correttezza, lemmi, pseudocodice)*
|
||
|
|
|
||
|
|
### 6.2.2 - Ridurre la comunicazione del FloodSet
|
||
|
|
|
||
|
|
Uno dei problemi dell'algoritmo FloodSet e' che il numero di messaggi che richiede e' abbastanza alto, `O((f+1)*n^2)`, come anche il numero di bits, `O((f+1)*n^3)`.
|
||
|
|
|
||
|
|
Il numero di messaggi puo' essere ridotto a `O(2*n^2)` utilizzando l'idea seguente.
|
||
|
|
Essendo che, alla fine dell'esecuzione dell'algoritmo, il processo `i` necessita di conoscere solo gli elementi esatti del suo set `W[i]` se `|W[i]| = 1`, altrimenti necessita di sapere solo che `|W[i]| >= 2`. Per questo motivo, ogni processo puo' mandare in broadcast **solo i primi due valori che vede**, invece che tutti.
|
||
|
|
|
||
|
|
### 6.2.3 - Algoritmi di raccolta delle informazioni esponenziale (EIG)
|
||
|
|
|
||
|
|
*(Exponential information Gathering algorithms)*
|
||
|
|
La strategia EIG si struttura come segue:
|
||
|
|
|
||
|
|
* i processi mandano e ricevono valori iniziali per vari cicli, salvando i valori ricevuti in una data structure chiamata **EIG tree**.
|
||
|
|
* alla fine, i processi utilizzano una regola di decisione comune basata sui valori registrati nei propri *trees*.
|
||
|
|
|
||
|
|
Questi algoritmi sono di solito molto costosi (*overkill*) per la risoluzione di stopping failures, ma la struttura dell'EIG tree e' utilizzata anche nella risoluzione di casi di fallimento bizantino.
|
||
|
|
|
||
|
|
### 6.2.4 - Consenso bizantino con autenticazione
|
||
|
|
|
||
|
|
Gli algoritmi EIG descritti in [questa sezione](#6.2.3) sono pensati per tollerare stopping failures, ma alcuni possono tollerare anche tipi peggiori di fallimenti, anche se non sono adeguati per risolvere il modello completo di fallimenti bizantini. Possono pero' risolvere un *subset* del modello dei fallimenti bizantini, quello in cui i processi hanno la capacita' di **autenticare le proprie comunicazioni**, utilizzando **firme digitali** (*digital signatures*).
|
||
|
|
|
||
|
|
## Algoritmi per Fallimenti Bizantini
|
||
|
|
|
||
|
|
Una proprieta' comune di tutti gli algoritmi presentati in seguito e' che il numero di processi che usano e' **piu' di 3 volte il valore di failures**, quindi `n > 3*f`.
|
||
|
|
|
||
|
|
### 6.3.1 - Esempio (vedi libro)
|
||
|
|
|
||
|
|
### 6.3.2 - Algoritmo EIG per fallimenti bizantini
|
||
|
|
|
||
|
|
L'algoritmo presentato e' chiamato **EIG-biz**. L'algoritmo presuppone che il **numero di processi e' grande rispetto al numero di fallimenti**, con la regola `n > 3*f`. Utilizza la stessa struttura dati degli algoritmi EIG presentati in 6.2, nonche' la stessa strategia di propagazione. L'unica differenza e' che un processo che riceve un messaggio malformato **corregge l'informazione di modo che sia accettabile**. Un'altra grande differenza e' la **decision rule**, infatti i processi non possono piu' fare affidamento sui valori che compaiono sul suo *tree*, ma deve mascherare i valori che arrivano con messaggi malformati.
|
||
|
|
|
||
|
|
### 6.3.3 - Consenso Bizantino generico - utilizzo di Consenso Bizantino Binario
|
||
|
|
|
||
|
|
Si mostra un algoritmo che risolve il consenso bizantino per input in `{0,1}`, come una subroutine per risolvere consenso bizantino generico. L'overhead e' di 2 cicli aggiuntivi, `2*n^2` messaggi aggiuntivi e `O(n^2*b)` bits.
|
||
|
|
|
||
|
|
### 6.3.4 - Ridurre la comunicazione
|
||
|
|
|
||
|
|
Nonostante l'algoritmo per la risoluzione di consenso bizantino binario possa essere usato per ridurre la comunication complexiti nel Bizantine Agreement, il suo costo e' comunque esponenziale nel numero di fallimenti. In generale **gli algoritmi polinomiali nel numero di fallimenti sono molto piu' difficili da ottenere nel modello di fallimenti bizantini che nel modello di stopping failures.** L'algoritmo presentato usa una tecnica detta di **consistent broadcast** per tutte le sue comunicazioni.
|
||
|
|
Questo meccanismo e' un modo di assicurare un determinato livello di **coerenza** tra i messaggi ricevuti dai diversi processi.
|
||
|
|
Si basa sul fatto che un processo puo' fare *broadcast* di un messaggio nella forma (m,i,r) al round `r`. I processi che ricevono possono poi **accettare** il messaggio a un round successivo qualunque. Il meccanismo consiste nel:
|
||
|
|
|
||
|
|
* Se un processo funzionante fa broadcast di un messaggio, allora al round successivo il messaggio e' accettato da tutti i processi funzionanti correttamente.
|
||
|
|
* Se un processo funzionante **non fa broadcast** di un messaggio, allora il messaggio non e' mai accettato dai processi funzionanti correttamente.
|
||
|
|
* Se un messaggio e' accettato da qualunque processo funzionante correttamente, allora nel round successivo e' accettato da tutti i processi funzionanti correttamente.
|