Travaux Dirigés - Fautes Byzantines Master II ISRI - 2015-16
Transcription
Travaux Dirigés - Fautes Byzantines Master II ISRI - 2015-16
Travaux Dirigés - Fautes Byzantines Master II ISRI - 2015-16 Yoann Dieudonné 18 mai 2016 Lors des TDs précédents nous nous sommes essentiellement focalisés sur le cas des pannes franches qui sont en fait les pannes les moins difficiles à traiter. Dans ce TD, nous allons passer d’un extrême à l’autre en s’intéressant au pire des cas auquel on peut être confronté : la panne byzantine. L’hypothèse des pannes byzantines est souvent utilisée pour des systèmes très critiques nécessitant une très haute fiabilité dans un environnement hostile (e.g., nucléaire, spatial, aéronautique, chirurgie, etc...). Pour des exemples plus précis concernant ces points, nous invitons le lecteur à effectuer des recherches sur le système de commande de vol du Boeing 777 ou 787, ou encore sur des navettes (e.g. SpaceX Dragon flight system) et véhicule d’exploration de la NASA ( NASA Crew Exploration Vehicle) qui utilisent tous une architecture tolérante aux pannes byzantines. On dit qu’une entité est sujette à une panne byzantine (ou plus simplement qu’elle est byzantine), si cette dernière a un comportement totalement imprévisible et peut faire “n’importe quoi”. Par exemple une telle entité peut faire le choix de ne jamais répondre, d’usurper l’identité d’autre processus, mentir, ne jamais coopérer, faire son possible pour faire échouer un protocole, etc... Dans le domaine de la tolérance aux fautes, ce type de panne est le pire des cas qui peut survenir. Ainsi, si jamais vous avez un protocole capable de résister à des pannes byzantines, vous avez un protocole capable de résister à n’importe quels types de panne. Bien sûr dans la pratique, il est impossible d’avoir un protocole qui fonctionne si tous les processus sont byzantins (de même qu’il est impossible d’avoir un protocole qui fonctionne si tous les processus font l’objet de pannes franches). On cherche alors généralement à élaborer des protocoles k-robustes où k est le nombre maximal de pannes byzantines auquel peut résister le protocole tout en continuant à rendre son service. Cependant là où dans un réseau de n processus, le k peut aller jusqu’à être égal à n − 1 quand on a uniquement des pannes franches (cf. consensus), le k est souvent beaucoup plus petit quand on est en face de pannes byzantines qui sont plus difficiles à traiter : très souvent (mais pas tout le temps) le k ne doit pas dépasser n3 − 1. Dans l’exercice qui suit, on s’intéresse au consensus en présence de byzantins (appelé consensus byzantin). Pour des raisons de sécurité, on demande dans le consensus byzantin (en plus des spécifications usuelles mentionnées dans le TD2) à ce que la valeur choisie soit une valeur qui ait été proposée par au moins un processus non byzantin. Exercice 1. Consensus byzantin en synchrone Dans un système sans perte de messages et synchrone (i.e., où le temps de transmission d’un message est borné par une constante δ), le résultat FLP ne tient plus. En fait, dans ce contexte le problème du consensus peut être résolu dans un réseau de n processus si, et seulement si, il y a au plus n3 −1 processus byzantins (i.e. il existe des protocoles ( n3 − 1)-robuste pour ce problème). Montrer qu’il ne peut pas exister en général de protocole k-robuste pour le consensus byzantin si jamais k ≥ n3 : pour cela on considérera le cas particulier où n = 3 et k = 1. 1 Exercice 2. Réseaux mobiles et pannes byzantines Comme mentionné en particulier dans l’introduction de ce TD, les systèmes résistants aux pannes byzantines ne sont pas l’apanage des réseaux de communications classiques. On retrouve également de tels systèmes dans les réseaux dits mobiles. On se propose ici d’étudier un problème fondamental des réseaux mobiles en présence de pannes byzantines : le problème du rassemblement. Considérons une équipe d’agents mobiles (ces derniers peuvent être par exemple des véhicules d’exploration comme le NASA Crew Exploration Vehicle) se déplaçant sur un terrain. Pour des raisons principalement pédagogiques lié à cet exercice, on adoptera la modélisation décrite ci-après. Le terrain dans lequel évolue les agents est modélisé sous la forme d’un graphe G(V, E). Les sommets V de G sont sans identificateurs permettant de les distinguer. Par contre, les arêtes incidentes à un noeud u ont des étiquettes distinctes ∈ {0, · · · , d − 1} où d est le degré du noeud u (voir figure ci-dessous). Par conséquent toute arête (u, v) a deux étiquettes qui sont respectivement appelées le port de u et le port de v. Il n’y a a priori aucune relation entre les numéros de port de deux noeuds distincts. 1 2 0 2 1 1 0 0 3 1 0 1 0 2 4 3 0 0 1 2 3 1 1 2 1 0 0 Figure 1: Exemple de graphe modélisant un terrain dans lequel vont évoluer des agents. C’est dans ce réseau que circule nos fameux agents mobiles. Les agents sont initialement sur des sommets distincts du graphe (il y a donc au plus n agents dans un graphe de n sommets) et ont chacun un label/identité qui est différent des autres. Au départ, les agents ne connaissent pas les labels des autres, ni le nombre d’agents dans le réseau, ni la topologie du réseau (y compris le nombre de sommets). Le temps est discrétisé en instants t1 , t2 , t3 , · · · où à chaque instant ti un agent applique un protocole P qui lui ordonne soit de bouger vers un noeud adjacent via un port donné, soit de rester sur le sommet où il se situe. Chaque agent applique le protocole P dès le premier instant. Quand un agent visite des noeuds, il mémorise les ports d’entrées et de sorties empruntés ainsi que le degré des noeuds visités. Lorsque plusieurs agents sont sur un même noeud au même instant, chacun voit les labels des autres et ils peuvent échanger toutes les informations qu’ils ont mémorisées depuis le début. Tous ces données sont bien entendu utilisés par la suite par le protocole P pour indiquer quoi faire à l’agent. 2 Les agents se croisant sur une arête en la traversant simultanément dans des directions opposées, ne détectent pas cet évènement de sorte qu’ils ne se voient ou ne communiquent que lorsqu’ils sont sur un même sommet. Ils ne peuvent laisser aucune marque de leur passage. Un agent byzantin est un agent qui peut à chaque instant et de manière imprévisible aller sur un noeud adjacent via n’importe quel port ou rester sur place. Quand un agent byzantin est avec un autre agent sur un même noeud, il peut dire n’importe quoi (par exemple lui donner un faux historique de ce qu’il aurait vu) ou ne rien dire. Dans ce qui suit on distinguera deux cas : un premier cas où les byzantins peuvent se forger n’importe quel label et le cas où ils ne le peuvent pas. Le problème du rassemblement consiste à faire en sorte que tous les bons agents finissent par être ensemble sur un même noeud et à ne plus jamais bouger. • Question 1. Expliquez pourquoi il n’existe pas de protocole déterministe permettant d’effectuer le rassemblement avec 4 agents dont 2 sont byzantins si ces derniers sont capables de se forger n’importe quel label à chaque instant. • Question 2. Décrivez un protocole déterministe permettant de résoudre le problème du rassemblement dans le cas où il y a 3 agents dont au plus 1 est byzantin si jamais la taille du graphe est initialement connue des agents et qu’un byzantin ne peut pas se forger un nouveau label. Pour cela vous utiliserez le protocole de base décrit ci-dessous. La procédure TZ(L). Cette procédure utilise, comme unique paramètre, le label de l’agent qui l’applique. En l’appliquant, la procédure indique à chaque instant si l’agent doit rester sur place ou sortir par un numéro de port donné (ce processus est potentiellement infini). La procédure a la propriété suivante : il existe une fonction f telle que si n’importe quel couple d’agents avec des labels l1 et l2 (l1 6= l2 ), évoluant dans un graphe à n sommets, appliquent simultanément la procédure pendant une période T de longueur f (n, min(l1 , l2 )), les agents se sont rencontrés au moins une fois durant cette période T . La propriété est vraie peu importe les moments où chacun des agents commence à appliquer la procédure. Remarque. f (n, x) < f (n, x0 ) ⇐⇒ x < x0 3