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