Problème du Consensus dans les systèmes avec homonymes

Problème du Consensus
dans les systèmes avec homonymes
Hung Tran-The
Réunion Displexity
La Rochelle, Avril 2013
1
Plan
Systèmes répartis classiques
Modèle Homonyme
Problème du Consensus
Résultats
Conclusion
2
Systèmes répartis classiques
Système réparti: un ensemble de processus
+ un réseau de communication.
– Systèmes avec les identités uniques: identités
distinctes.
– Systèmes anonymes: aucune identité.
3
Systèmes avec les identités uniques
Avantage: faciliter la détermination des expéditeurs et
récepteur des messages.
Désavantages:
– Difficulté de tenir les identités de tous les processus distincts.
• Le nombre de processus augmente.
• Le système peut accidentellement affecter la même identité à des
processus différents.
– Attaques Sybilles:
• Des processus malveillants peuvent usurper des identités des autres
processus.
• Systèmes P2P [John R. Douceur 02]. Un attaque dans système P2P
Maze [LZYDL 07].
• Réseaux de capteurs [NSSP 04].
4
Système anonyme
Introduit par Angluin [STOC80]
Applications: Web servers [RR98], Réseau de capteurs
[TKR05], P2P [AVML05].
Avantage: protéger la vie privée des utilisateurs
Désavantage: peu de problèmes peuvent être résolus.
– Impossibilité de l’élection de leader [STOC80].
– Impossibilité du problème de comptage dans un réseau inconnu
avec une diffusion et sans leader [MCS12].
– Impossibilité du problème de nommage même avec un leader
[MCS12].
– Impossibilité du problème du consensus:
– … [AFR06], [PS90]
5
Système anonyme
Difficulté de briser la symétrie en présence:
l’anonymat, l’asynchronie, des pannes ?
– Impossibilité de l’élection de leader:
• anonymat + anneau (synchronie)
• anonymat + asynchronie (n’importe quelle topologie)
– Impossibilité du consensus:
• asynchrone + panne crash [FLP80]
• anonymat + panne malveillante (synchronie) [Okun05]
6
Systèmes avec identité uniques:
Systèmes anonymes:
• Dificulté de tenir la distinction des
• Peu de problèmes peuvent être résolus.
identités
• Attaques sybille
Système avec homonymes
7
Modèle avec homonymes
Modèle général incluant les 2 modèles de
système: système avec identités uniques et
système anonyme.
n processus utilisent Ɩ identités où 1 ≤ Ɩ ≤ n
8
Exemple: n = 4, Ɩ = 2
2
1
3
4
Système avec identités uniques
1
1
2
2
Système anonyme
1
2
2
2
2
1
Distribution d’identités dans le système avec homonymes
1
1
9
Exemple
ASAP
LIAFA
LABRI
10
Modèle avec homonymes
Les processus sont divisés en groupes.
Chaque groupe a une identité unique.
Les processus dans une groupe (homonymes) utilisent la
même identité.
Les homonymes exécutent des algorithmes identiques.
Un processus peut envoyer des messages à un groupe mais
ne peut pas envoyer à un processus particulier.
Un processus ne peut pas déterminer si un message reçu
vient d’un processus ou vient de processus différents ayant
la même identité.
11
Motivation
D’un point de vue pratique:
– Moins de confidentialité, mais plus de problèmes
peuvent être résolus (briser la symétrie).
– Utile si certains processus sont affectés à la même
identité ou des processus byzantins usurpent l’identité
des autres processus. (aucun algo classique compte ça)
D’un point de vue théorique: comprendre
l'importance de l'identité en informatique
distribuée.
12
Quels problèmes peuvent être résolus dans les
systèmes avec homonymes?
13
Consensus
On utilise le problème du consensus pour étudier la puissance des
systèmes par messages avec homonymes.
Chaque processus propose une valeur. Chaque processus décide une
valeur telle que:
– Accord: Si deux processus corrects décident ils décident la même valeur.
– Validité: toute valeur décidée est l’une des valeurs proposées.
– Terminaison: tout processus correct décide au bout d’un temps fini.
Plusieurs variantes:
– Pour le modèle des pannes byzantines:
• Validité: si tous les processus corrects ont la même valeur proposée v alors v est valeur
décidée (Consensus byzantin).
– Consensus uniforme:
•
Accord Uniforme: si deux processus (correct ou non) décident, ils décident la même
valeur.
14
Modèle
n processus
Ɩ identités
au plus t processus en panne
Système par message:
– Synchrone: bornes supérieures de communication connues =>
rondes synchrones: émission, réception et calcul.
– Partiellement synchrone [DLS88]:
• Commutation en rondes synchrones.
• Il existe un temps T tel que après T, tous les messages diffusés par les
processus sont délivrés.
• Des messages peuvent ne pas être délivrés avant T.
Canal fiable: il ne crée pas, ni duplique ni modifie des messages.
15
Défaillances
Panne franche (crash)
Panne par omission d’émission (send
omission)
Panne par omission d’émission ou de
réception (general omission)
Panne Byzantine: comportement arbitraire.
16
Modèle
On considère 2 cas:
– Les processus peuvent compter des messages
identiques dans une ronde (numerate processes)
– Les processus ne peuvent pas compter des
messages identiques dans une ronde
(innumerate processes)
17
Travaux concernés
Consensus:
Consensus uniforme:
18
Résultats:
Cas synchrone
Conditions nécessaires et suffisantes pour le consensus
(n processus, Ɩ ids, au plus t processus byzantins)
Crash
General-omission
Byzantine
?
Impossible
[Okun05]
Ɩ ≥ 1, n ≥ t
Ɩ > 2t
Ɩ > 3t
Ɩ ≥ 1, n ≥ t
Ɩ ≥ 1, n > 2t
Ɩ > 3t
n ≥ t
n > 2t
n > 3t
Send-omission
Anonyme
Ɩ=1
n ≥ t
Innumerate
Homonyme
Ɩ < n
Numerate
IDs uniques
Ɩ = n
[PSL80]
Consensus uniforme
19
Consensus byzantin
Cas partiellement synchrone
En présence de la synchronisation partielle,
des pannes byzantines et des homonymes, la
condition nécessaire et suffisante pour le
consensus est: l > (n+3t)/2
20
ASAP
LIAFA
LABRI
21
Le consensus peut être résolu dans le système
avec homonymes.
Les identités ne sont pas nécessaires pour
résoudre le consensus si des pannes sont des
pannes franches, des pannes par omission
d’émission ou réception (pannes bénignes).
Les identités sont nécessaires avec des
défaillances Byzantines: l ≥ 3t+1 (la borne
inférieure).
– La solution dépend du nombre d’identités, pas du
nombre de processus.
– Augmenter le nombre de processus corrects n’améliore
rien.
22
Dans le cas partiellement synchrone: l >
(n+3t)/2
– Le nombre d’identité est presque même que le
nombre de processus.
– Augmenter le nombre de processus corrects
peut rendre l’accord impossible.
23
Publié à ICDCN13, PODC11, DC journal
Cas synchrone:
– Consensus uniforme avec des pannes bénignes: solution
en t+1 rondes (optimale).
– Consensus avec des pannes byzantines: solution
générique: transformer (l processus, l identités) en (n
processus, l identités).
Cas partiellement synchrone:
– Impossibilité: l’argument d’indistingabilité.
– Possibilité: basé sur l’algorithme Dwork-LynchStockmeyer [DLS88].
24
ASAP
LIAFA
LABRI
25
Impossibilité
Cas partiellement synchrone
Si l ≤ (n+3t)/2, impossible!
Par exemple: 5 processus affectés à 4
identités, un processus byzantin.
26
Scénario 1:
Tous les messages sont délivrés.
Le processus byzantin ne fait rien.
Tous les processus corrects proposent la valeur 1.
Par la validité, tous les processus correctes décident 1, après r1 rondes.
Byzantin
1
1
1
1
Décider 1
27
Scénario 1:
Byzantin
1
1
1
1
Décider 1
Scénario 2:
Byzantin
1
0
11
0
1
0
1
0
Décider 0
28
Scénario 3:
Les messages entre les deux groupes de processus corrects
ne sont pas délivrés en temps suffisamment longue.
Le processus byzantin envoie plusieurs messages à des
processus.
1
1
0
1
11
0
byzantin
29
Scenario 1
1
1
1
1
1
1
1
1
byzantin
Scenario 3
Scenario 2
0
1
11
0
0
1
0
1
1
0
11
0
0
1
0
1
30
Scenario 1
1
1
1
1
Décider 1
Scenario 2
1
0
11
0
1
0
1
0
Décider 0
1
1
1
1
Décider 1
byzantin
Scenario 3
0
1
11
0
1
0
1
0
Décider 0
Accord: la valeur décidée est la même pour tous les
processus corrects.
31
Algorithme en synchronie partielle
La preuve basée sur l’algorithme Dwork-LynchStockmeyer.
Utiliser la diffusion authentifiée [Srikanth,
Toueg].
Difficultés: les homonymes envoient des
messages contradictoires. Solution:
– Utiliser des quorums l-t ids.
– Un groupe leader au lieu d’un leader.
– Des messages supplémentaires pour aider les processus
corrects dans des groupes contenants des processus
byzantins à décider.
32
Consensus avec pannes byzantines
limitées
Restriction: le processus byzantin ne peut
pas envoyer plusieurs messages au même
processus dans une ronde.
33
Homonymes avec la distribution
d’identité disponible
Distribution d’identités: n = (n1, n2, …, nl)
Mode de pannes: t = (t1, t2, …, tl)
Groupe correct, partiellement byzantin,
byzantin.
Coefficient d’accord: ci = ni si G(i) est
correct. ci = 1 si G(i) est partiellement
byzantin et ci = 0 si G(i) est byzantin.
34
Homonymes avec la distribution
d’identité disponible
Condition nécessaire et suffisante pour le
consensus:
c = Min{c1 + c2 + … + cl} > 2t
Par exemple: si ni > t, l > t est suffisant pour le
consensus.
On fixe n, l, t. I, il existe une distribution
d’identités pour le consensus si et seulement si:
l > (n-r)t/ (n-t-min(r,t)) où r = mod l
Publié à ICDCN12, TCS
35
Homonymes avec des identités
usurpées
Des processus byzantins peuvent usurper
un ensemble d’identités F: |F| =k.
Sans authentification: l> 2t + k
Avec authentification: l> t + k
Publié à SIROCCO12
36
Conclusion
L’identité est nécessaire dans les systèmes
avec pannes byzantines mais pas nécessaire
dans les systèmes avec pannes bénignes.
Contrairement aux systèmes classiques
avec identités uniques, dans les systèmes
avec homonymes, augmenter des processus
corrects peut rendre l’accord impossible.
37
Conclusion
Deux méthodes pour réduire nombre
d’identités:
– Restreindre la puissance des processus
byzantins.
– Connaître la distribution d’identités.
38
Conclusion
Tout problème peut-il être résolu avec peu
d’identité?
Solvabilité + confidentialité: système avec
homonymes peut-il remplacer les systèmes
classiques?
39