Aliph

Aliph est un protocole de TFB spéculatif construit autour d’une nouvelle abstraction, Abstract [49], qui permet de simplifier la conception de protocoles de TFB. Aliph combine trois protocoles de TFB : (i) Quorum, un protocole spéculatif qui ne fonctionne que lorsqu’il n’y a pas de contention et lorsque la charge est faible, (ii) Chain, un protocole spéculatif très rapide lorsque la charge est élevée, et (iii) Backup, un protocole de TFB patrimonial (en l’occurrence PBFT). Dans cette section, nous présentons tout d’abord Abstract. Nous présentons ensuite une vue générale d’Aliph. Enfin, nous présentons plus en détails Quorum et Chain.

2.1.5.1 Abstract

Abstract [49] (Abortable Byzantine faulT toleRant stAte maChine replicaTion ; réplication de machines à état tolérant les fautes Byzantines qui peut avorter) est une nouvelle abstraction qui permet de simplifier la conception de protocoles de TFB. L’idée

principale derrière Abstract est de combiner plusieurs protocoles de TFB, appelés instances, afin de construire un nouveau protocole. Chaque instance peut être implantée, testée et vérifiée indépendamment des autres. De plus, la modularité d’Abstract permet de réutiliser une grande partie du code source d’un protocole existant (notamment la partie réseau) afin d’implanter un nouveau protocole plutôt que de partir de zéro. Enfin, la composition de deux instances d’Abstract est idempotente : combiner deux instances d’Abstract qui assurent des propriétés de sûreté et de vivacité retourne une nouvelle instance d’Abstract qui assure les mêmes propriétés de sûreté et vivacité.

Chaque instance d’Abstract ordonne les requêtes des clients sauf si certaines conditions du système ne sont pas satisfaites (p. ex. de la contention apparaît, le réseau est asynchrone, un réplica est malicieux). Dans une telle situation, les protocoles de TFB patrimoniaux procéderaient à un changement de vue. Dans Abstract, le changement de vue est remplacé par un basculement vers la prochaine instance. Plus précisément, chaque instance d’Abstract possède un numéro d’identification unique i et a accès à une fonction suivant(i), qui retourne l’identifiant de l’instance sur laquelle basculer. Cette fonction peut être statique (le choix de la prochaine instance est fixe) ou dynamique (le choix de la prochaine instance dépend de l’état actuel du système).

Nous présentons maintenant le protocole de basculement. Lorsqu’un client détecte un problème au niveau de l’instance courante (p. ex. il ne reçoit pas de réponse après une période donnée), alors il envoie un messagePANIQUEà tous les réplicas. Lorsqu’un réplica reçoit un tel message valide, il arrête de traiter de nouvelles requêtes et envoie un messageAVORTEau client. Ce message contient un historique des requêtes qui ont étés exécutées par l’instance courante jusqu’ici, ainsi que l’identifiant de la prochaine instance à utiliser. Lorsque le client reçoit 2f + 1 AVORTE valides pour la même prochaine instance, alors il extrait un historique d’avortement à partir des historiques présents dans les 2f +1AVORTE. Enfin, le client envoie sa prochaine requête à l’instance suivante en même temps que l’historique d’avortement ainsi que les 2f +1AVORTE. Un réplica qui reçoit cette nouvelle requête vérifie la validité de l’historique d’avortement. Le réplica doit également posséder, dans son propre historique, toutes les requêtes présentes dans l’historique d’avortement. Au cas où certaines requêtes manquent, il les demande auprès des autres réplicas.

2.1.5.2 Présentation générale d’Aliph

Aliph est un protocole de TFB nécessitant 3f + 1 nœuds. Il est la composition de trois instances d’Abstract, entre lesquelles il bascule de manière statique :

Quorum : Fonctionne lorsque les réplicas et les clients sont corrects, le réseau est synchrone, et il n’y a pas de contention.

Chain : Fonctionne lorsque les réplicas et les clients sont corrects et le réseau est synchrone.

Backup : Fonctionne en présence de fautes. PBFT est le protocole implanté dans Backup.

Quorum et Chain permettent de fournir de très bonnes performances dans le cas sans faute : selon les auteurs, Aliph est plus performant que les protocoles existants (p. ex. Zyzzyva) dans le cas sans faute à la fois en terme de latence (jusqu’à 30%) et en terme de débit (jusqu’à 360%). En l’absence de contention, les requêtes sont ordonnées par

Quorum. Le protocole bascule vers Chain lorsque de la contention est détectée, c.à.d. lorsqu’un réplica reçoit deux nouvelles requêtes en parallèle sans qu’aucune des deux ne soit encore exécutée. En effet, ces deux requêtes pourraient être exécutées dans un ordre différent par les différents réplicas. Enfin, en cas de fautes, Aliph bascule vers Backup (c.à.d. PBFT) pour un nombre défini de requêtes, après quoi il bascule à nouveau dans Quorum, et ainsi de suite. Nous présentons Quorum et Chain plus en détails dans les sections suivantes.

2.1.5.3 Quorum

Quorum est une instance d’Abstract qui fournit de très bonnes performances en exécutant les requêtes de manière spéculative. Exécuter une requête ne nécessite que deux échanges de messages, comme décrit dans la Figure 2.5. Lorsqu’un client souhaite

FIGURE2.5 – Échange de messages dans Quorum (f = 1).

soumettre une requête au système, il l’envoie à tous les réplicas. Chaque réplica, après avoir reçu cette requête, l’exécute de manière spéculative et répond au client. Enfin, le client attend 3f + 1 réponses identiques avant d’accepter le résultat de sa requête. Si tel n’est pas le cas, alors le client panique et initie un basculement de protocole vers Chain. Il est important de noter que Quorum ne peut fonctionner qu’en l’absence de contention. Sans cette propriété, c.à.d. en présence de contention, les clients peuvent recevoir des réponses différentes et l’état des réplicas peut diverger.

2.1.5.4 Chain

Chain est une instance d’Abstract qui fournit de très bonnes performances en organisant les réplicas à la manière d’un pipeline et en exécutant les requêtes de manière spéculative. Un réplica, appelé tête, est le point d’entrée de la chaîne et reçoit les requêtes, tandis qu’un autre réplica, appelé queue, est le point de sortie de la chaîne et renvoie les réponses aux clients. De plus, contrairement à Quorum, Chain est capable d’ordonner des requêtes en présence de contention sans que l’état des réplicas ne diverge. La particularité de Chain est qu’il nécessite un nombre minimal d’opérations de cryptographie au niveau du nœud qui fait office de goulot d’étranglement. Étant donné que les performances des protocoles de réplication sont bornées par le coût des opérations de cryptographie plutôt que par la vitesse du réseau, cela permet à Chain de fournir un débit supérieur au débit des protocoles de BFT patrimoniaux existants. La Figure 2.6 présente les étapes du protocole. Le client créé une requête qui contient un

FIGURE2.6 – Échange de messages dans Chain (f = 1). Le réplica 0 (resp. 3) est la tête (resp. queue) de la chaîne.

authentificateur de chaîne, c.à.d. un tableau de f + 1 MACs, qui permet à un ensemble de f + 1 réplicas, appelés successeurs, de vérifier un message. Cet authentificateur contient un MAC pour chacun des f + 1 premiers réplicas de la chaîne. Ensuite, le client envoie sa requête à la tête de la chaîne uniquement. Lorsque la tête reçoit une requête, elle (i) vérifie le MAC de ses prédécesseurs dans la chaîne (en l’occurrence le client), (ii) modifie l’authentificateur MAC afin d’enlever ceux de ses prédécesseurs (en l’occurrence celui du client) et d’inclure celui de ses successeurs, (iii) exécute la requête, puis (iv) transmet la requête au prochain réplica. Le processus est similaire pour les autres réplicas de la chaîne sauf la queue. Lorsque le réplica en queue de la chaîne reçoit la requête, il vérifie les f + 1 MACs de ses prédécesseurs puis en rajoute un pour le client, avant de transmettre la réponse au client. Notons que les f prédécesseurs de la queue ajoutent une empreinte de la réponse dans la requête qu’ils propagent, afin que le client puisse vérifier la validité de la réponse. Enfin, lorsque le client reçoit une réponse valide, il accepte le résultat de la requête. Sinon, il panique et initie un basculement vers Backup.

En résumé, Aliph est un protocole spéculatif conçu autour d’une abstraction per-mettant de simplifier la conception de protocoles de TFB. Dans le cas sans faute, Aliph minimise le nombre de phases de communications et d’opérations de cryptographie, ce qui lui permet de fournir de meilleures performances que Zyzzyva. En présence de fautes, Aliph bascule vers PBFT afin de garantir les propriétés de sûreté et de vivacité du protocole.