Consensus distribué En ce qui concerne ce document, le problème de consensus sera étudié (examiner, considérer, explorer, analyser). Le problème est provoqué dans un système reparti quand chaque processus démarre avec une initiale valeur de type quelqu’un et sont invités éventuellement de donner une sortie de même type de donnée. Les sorties sont requises d’être les mêmes-les processus doivent mettre d’accord, même quand les entrées sont arbitrerais. Généralement, il y a une condition de validité, décrivant les sorties permis pour chaque pattern d’entrées.

Le problème du Consensus MB - LRIA Dans le cas d’absence (ou t-il n’y a pas) de fautes de composants du système, le problème du consensus peut être (est probablement) résolu (déduire ?, achever) facilement par simples échanges de messages. Pour plus d’intérêts, normalement le problème du consensus est considéré avec la présence de fautes. Tell situation apparaît dans plusieurs distribués applications. Par exemple plusieurs processus peuvent essayer (tenter) de se mettre en d’accord pour effectuer ou abandonner une transaction de base de donnée distribuée. Ou bien les processus doivent s’accorder sur une estimation de l’altitude d’un avion, basée sur la lecture à partir de plusieurs altimètres. Quelle que foie les processus doivent s’agréer de classifier un système comme fautif ou non suivi les résultats de plusieurs diagnostiques séparés tests, effectués par séparés processeurs En suite, la notion de fautes sera étudiée. Puis le problème du consensus sera étudié en présence des fautes de communications et en présence des fautes de processus. Le dernier cas sera considéré plus détaillé en examinant des solutions déterministes et probabilistes

Sommaire Définition, introduction, généralités Notion de faute Résultats d’impossibilité et hypothèses de travail Consensus en présence de pannes franches Un algorithme polynomial Un algorithme exponentiel Les généraux byzantins Un algorithme déterministe (Lamport & Al.) Un algorithe probabiliste (Rabin) En suite, la notion de fautes sera étudiée. Puis le problème du consensus sera étudié en présence des fautes de communications et en présence des fautes de processus. Le dernier cas sera considéré plus détaillé en examinant des solutions déterministes et probabilistes.

Introduction Problème fondamental Brique de base pour les applications Notion de fautes et hyp. sur le nb de fautes Résultat d'impossibilité Algorithmes systèmes synchrones et pannes franches Simulation (applets)

Notion de fautes Fautes de liens de communications Fautes de processus Pannes franches Pannes de type GB Notion de fautes Considérons 2 types de fautes sont considérés : la faute de liens de communication et la faute de processus.  Un processus peut tomber en panne en envoyant ses messages. C’est à dire il a peut-être envoyé un arbitrair sous-ensemble des messages (Il n’est pas le cas que le processus envois ses messages séquentiellement, et tombe en panne au milieu de cette séquence). Dans ce cas là, la faute est une panne franche (stop-fail). Dans autre cas, les processus peut-être fautif comme il peut comporte de façon arbitraire. Il peut envoyer des massages arbitrais, peut passer dans un état arbitrais, et ne suive pas la fonction de transition de l’état et la fonction de génération de messages. Ce type de faute est le type de pannes byzatins. Si un lien de communication est tombé en panne, la conséquence est la perte de messages. Processus peut envoyer des messages ver une chaîne de communications, la chaîne ne traites pas les messages. En bref, il y a des fautes du lien de communication et des processus. La dernière peut-être panne franche ou byzantines. Pour simplicité, un système est considéré de contenir un type de faute. Une autre hypothèse est pour la quantité des fautes dans un système. On considéré que la probabilité des composants dans un système est caractérisé par le nombre maximum des faute en présence dans le système. Une telle hypothèse est basée sur le fait que la probabilité d’avoir une faute est moins quand il y a plus de fautes dans le système (ce n’est pas toujours vrais)

Consensus Le consensus distribué (CD) Modèle de calcul et hypothèses liens avec des pbs similaires (GB, CI) définition Modèle de calcul et hypothèses Algorithmes dans le cas synchrone avec pannes franches

Le pb du Consensus Terminaison: Accord: Validité: Tous les processus corrects vont de manière sûre choisir une valeur de décision Accord: Tous les processus corrects choisissent la même valeur Validité: Si tous les processus proposent une même valeur v alors la valeur de décision est v validité forte: La valeur de décision est celle proposée par un des processus

Contexte SD à passage de messsages, synchrone avec pannes franches SD à passage de messsages, synchrone avec pannes byzantines SD à mémoire partagée, asynchrone avec pannes franches FLP82 SD à passage de messsages, asynchrone avec pannes franches LP82

Une solution au consensus polynomial en présence de pannes franches Solution due à Dolev et Strong (1983)

Système distribué à passage de messages SYNCHRONE une exécution est une suite d’étapes on délivre tous les messages des buffers de communications sortants on effectue un calcul local après chaque étape d’envoi ou réception de messages

Pannes franches Un sous-ensemble d'au plus f processus fautifs un processus fautif peut s’arrêter après un envoi de messages quelconque f est connu les processus fautifs ne sont pas connus

Algorithme

Comportement de l’algorithme V1

1 étape V1 V2 V3 V4 V5

Validité de l’algorithme Plusieurs choses à montrer Après un tour sans faute, tous les processus corrects ont le même ensemble de valeurs. Dès la fin d’un tour sans faute, à chaque tour, les processus corrects ont des ensembles de valeurs identiques L’algorithme se termine en (f+1) tours où f est le nombre de faute;s; Le consensus est réalisé après un tour sans faute (càd après f+1 tours).

P1: Tous les ps corrects Pi et Pj réalisent l'accord à la fin du tour (f+1). Idée de la preuve supposons que x est ajouté à Vi au tour r pour la 1ère fois si r <= f, alors Pi envoie x à Pj au tour suivant si r = f+1, x est transmis via la chaine Pi1, ...Pif+1 Pi1 ® Pi2 au tour 1 Pif+1 ® Pi au tour f+1 implique f+1 ps distincts un ps correct parmi ceux ci et il envoie x à tous les processus avant f+1 --> Contradiction

P2: L'algorithme présenté résoud le pb du consensus en f+1 tours. si Pi et Pj sont corrects alors Vi et Vj sont les mêmes au tour f+1 et min(Vi) et min(Vj) sont les mêmes.

Complexité de l'algorithme f+1 tours jusqu'à ce que les processus corrects décident à chaque tour, il y a au maximum n2 messages envoyés donc O((f+1) . n2) messages L'algorithme est optimal (en nb de tours) il y a (f+1) tours

Solution exponentielle en nombre de message au consensus en présence de pannes franches Solution due à

Solution EIGStop Hypothèses Même conditions de travail Application de la solution Lamport Shostak et Pease Principe Maintien d’une structure de données en chaque site, correspondant à un arbre stockant les informations reçues et leurs parcours

Schéma de l’algorithme Processus Pi Début: Wi={v} Tour k Distribuer les pairs (étiquette, valeur)au dernier niveau, soft ceux qui contient i Recevoir les pairs (étiquette, valeur) de Pj. Mise à jour l’arbre dépendant de quel pair est reçu de quel processus. Tour k+1 Appliquer la condition de validité

Principe (pas de pannes franches) Au premier tour Si (i=1) S1 S3 S2 Arbre W1 V1 S1 V1 S2V2 S3V3 Identique pour S2 et S3

A la seconde étape (pas de pannes franches) encore un échange de messages S1 S2 S3

? Si (i=1) Arbre W1 V1 S1:V1 S2:V2 S3:V3 Identique pour S2 et S3 S1S2:V1 S1S2:V1 S2S1:V2 S2S3:V2 S3S1:V3 ? S1 reçoit S1V1 via S2 S1 reçoit S2V2 via S3 À vous… Identique pour S2 et S3

Si (i=1) Arbre W1 V1 S1:V1 S2:V2 S3:V3 Identique pour S2 et S3 S3S2:V3 S1 reçoit S1V1 via S2 S1 reçoit S2V2 via S3 S1 reçoit S3V3 via S2 Identique pour S2 et S3

Nouvelle seconde étape (avec 1 panne franche) La panne se produit juste après l’envoi d’un message vers S1 et avant l’envoi des 3 autres messages (il y a en effet deux fois deux messages, en général il y a (n-1)2 messages sur un tour) S1:V1 S2 S3

Pour S1 Arbre W1 V1 S1:V1 S2:V2 S3:V3 S2 S2 S1S2:V1 S1S3: V1 S2S1:V2 S3S2:Null S2 S2

Pour S3 Arbre W3 V3 S1:V1 S2:V2 S3:V3 S2 S2 S1S2:Null S1S3: V1 S2S1:V2

Arbre W2 Pour S2 …panne V2 S1:V1 S2:V2 S3:V3

Preuve de validité Technique (3 lemmes à établir) La personne intéressé se réfèrera aux documents et à la bibliographie [Lynch 1997]

Complexité Nombre de messages Complexité en temps Il y a (f+1) tours Chaque tour, on a n processus qui envoie où k est le numéro de tour DONC Complexité en temps Modèle synchrone et donc le temps est (f+1) tours

Solution due à Lamport, Shostak et Pease (1982) Généraux Byzantins Solution due à Lamport, Shostak et Pease (1982)

Le problème Notion de faute byzantine

F fautes, 3F+1 participants ou si n généraux, il ne faut pas avoir plus de n/3 traitres

Hypothèses Système synchrone Graphe complet Absence de messages détectable Un général traître ne peut pas se faire passer pour un autre général (loyal).

Schéma de l’algorithme EIGSTop (rep) Processus Pi Début: Wi={v} Tour k Distribuer les pairs (étiquette, valeur)au dernier niveau, soft ceux qui contient i Recevoir les pairs (étiquette, valeur) de Pj. Mise à jour l’arbre dépendant de quel pair est reçu de quel processus. Tour k+1 Appliquer la condition de validité

Algorithme GB Fonctionne comme EIGStop Avec comme différences Si un processus reçoit un message qui n’a pas la forme standard, le processus rejette ce message Après (f+1) tours, tous les processus remplacent leurs valeurs Null avec leur valeur initiale. Tous les processus appliquent le schéma suivant. Un processus Pi va calculer une fonction de décision valeur_de_décision (récursive) avec comme donnée d’entrée l’arbre Wi

Fonction valeur_de_décision( Wi) Pour chaque feuille de Wi, on adopte la valeur associée comme valeur de décision Pour chaque nœud interne (non-feuille), on associe comme valeur au nœud, la valeur v=majorité(v1, v2 …vi ) où v1, v2 …vi sont les valeurs des enfants si elle n’existe pas, on prend une valeur par défaut prédéfinie (Retraite, O, Null) La valeur de cette fonction est la valeur de la racine

Scénario 6 GB 1 traître (GB N°2) propose retraite puis change les messages GB N°1,3,6 proposent l’attaque GB N°4,5 proposent la retraite Il y aura donc 2 tours avec 36 messages 6 messages au tour 1 6x5 au tour 2

Schéma de calcul de la Fonction valeur_de_décision( Wi) Le GB N°1 propose l’attaque (valeur 1) Arbre W1 1 S1:1 S2:1* S3:1 S4:0 S5:0 S6:1 S1S2: 0* S1S3:1 S1S4:1 S1S5:1 S1S6:1 S5S2: 1* S5S3:0 S5S4:0 S5S5:0 S5S6:0 Peut être quelconque La valeur transmise par S2 (traître) Si Sk:Vi on reçoit la valeur Si :Vi (la valeur est 0 ou 1) via Sk

Calcul de valeur_de_décision( Wi): étape 0 Le GB N°1 propose l’attaque (valeur 1) Arbre W1 1 S1:1 S2:1* S3:1 S4:0 S5:0 S6:1 S1S2: 0* S1S3:1 S1S4:1 S1S5:1 S1S6:1 S5S1: 1* S5S2:0 S5S3:0 S5S4:1 S5S6:0 1 1 1 1 1 1 Valeur

C’est une valeur suspecte, elle peut varier selon les Wi Détail de la branche S2 C’est une valeur suspecte, elle peut varier selon les Wi Arbre W1 1 S1:1 S2:1* S3:1 S4:0 S5:0 S6:1 Ce sont les valeurs reçues au premier tour, de S2 par les Si - qui sont éventuellement suspectes mais qui sont ici retransmises correctement à tous les Si à la seconde étape. S2S1:V1 S2S3:V3 S2S4:V4 S2S5:V5 S2S6:V5 1 1 Valeur

Détail de la branche S2 (suite) Arbre W1 1 S1:1 S2:1* S3:1 S4:0 S5:0 S6:1 S2S1:V1 S2S3:V3 S2S4:V4 S2S5:V5 S2S6:V6 V1 V3 V4 V5 V6 On calcule la fonction valeur_de_décision( )

Détail de la branche S2 (suite 2) Arbre W1 1 S1:1 VALEUR S2:1* S3:1 S4:0 S5:0 S6:1 VALEUR On calcule la fonction valeur_de_décision( ) qui est majorité(V1,V3 , V4 , V5 , V6) et sera la même pour tous les arbres Wi (pour les ps non-fautifs càd i≠2) S2S1:V1 S2S3:V3 S2S4:V4 S2S5:V5 S2S6:V6 V1 V3 V4 V5 V6 DONC même avec un traître on assure l’accord et on remarque que le calcul de la valeur de décision est la même pour tous

Calcul de valeur_de_décision( Wi): étape 1 Le GB N°1 propose l’attaque (valeur 1) Arbre W1 1 S1:1 0* 1 1 S2:1* S3:1 S4:0 S5:0 S6:1 Valeur majoritaire =1 Valeur majoritaire =0 S1S2: 0* S1S3:1 S1S4:1 S1S5:1 S1S6:1 S5S2: 1* S5S3:0 S5S4:0 S5S5:0 S5S6:0 1 1 1 1 1 Valeur

Question: quelle est la décision? 0 ou 1??? Réfléchir au cas où il n’y aurait pas de traître… On ne peut rien décider également! Ici Sinon 1 si on peut calculer 1 ou 0 si la majorité existe Sinon on prend la valeur par défaut (0 dans ce cas)

Algorithm probabiliste de GB Due à Michael O. Rabin Utilise probabilité pour dépasser les GB

Algorithme de Rabin, hypothèses Serveur d’authentications, Dealer: un ps non fautif Partage d’un secret Asynchrones système Phase Local horloge p(i) Nombre maximum de fautes f Probabilité d’erronée réponse 

Schéma Pour k=1 à R fait Vote (k) Loterie(k) Décisions(k) Fin pour

Vote Distribuer signe(msg(i),k) Recevoir (msg(j),k) Jusqu’à n-t msg reçus Temp(i)=major(reçus) Count(i)

Loterie Dealer: Processus choisisse aléatoirement un secret sk={0,&} calcule Ei(k) pour partage sk Distribue signe(Ei(k)) Processus Requise Ej(k) Attende t reçus Calcule sk

Décision S=sk Si (s=0 et n/2<count(i)) or (s=1 et n-2t< count(i)) Msg(i)=temp(i) Else Msg(i)=« système fautif »

Bibliographie The Byzantine Generals Problem L.Lamport, R.Shostak, M.Pease ACM TOPLAS Vol.4, No.3, July 1982, pp.382-401 Randomized Byzantine Generals Michael O. Rabin IEEE. 1983.