Avalanche (AVAX): zoom sur les protocoles - Partie I

Présentation de Slush un des quatre protocoles formant la nouvelle famille de consensus Avalanche (AVAX).

Nicolas Lemaitre
Avalanche fr
6 min readJun 16, 2019

--

Avalanche — protocole Slush

La nouvelle famille de consensus Avalanche est une combinaison de quatre protocoles : Slush, Snowflake, Snowball et Avalanche. Dans cet article, nous allons voir comment le protocole Slush (Neige fondante) fonctionne individuellement. La technologie a été vulgarisée pour permettre à tout le monde d‘assimiler le sujet. Afin de faciliter votre compréhension, nous illustrerons par des schémas le fonctionnement du protocole Slush. Les couleurs rouge et bleue représente une double-dépense. Si vous avez râté l’introduction d’Avalanche, suivez ce lien : https://medium.com/@n.lemaitre44/avalanche-nouvelle-famille-de-consensus-e3a6b6d42266.

Slush : introduction de la métastabilité.

Le Protocole Slush (neige fondante en français) introduit la notion de métastabilité, il est inspiré des protocoles épidémiques ou protocoles gossip*. Il n’est pas tolérant aux pannes byzantines ( BFT: problèmes des généraux byzantins — des nœuds du réseau qui seraient mal intentionnés) mais seulement aux crash-faults ( CFT: le système ne s’arrête pas de fonctionner, qu’il y ait défaillance matérielle ou défaillance logicielle, il est résistant aux pannes). Le protocole Slush permet de définir la communication entre les nœuds et leurs interactions avec le réseau.

La procédure du protocole Slush sera expliquée en utilisant les couleurs rouge et bleue pour une meilleure compréhension.

Les nœuds commencent dans un état incolore. Quand ils reçoivent une transaction d’un client, un nœud incolore prend la couleur reçue dans la transaction.

Dans notre exemple ci-dessous, un nœud appelé N I (Nœud Initial — nous utiliserons N I tout au long de cet article) commence sans couleur. N I reçoit la transaction d’un client dont la couleur est rouge, N I adopte alors le rouge comme couleur.

Nœud Initial recevant une transaction dans Slush.

Ce nœud initial (N I) lance ensuite une requête. Le processus de requête consiste à sélectionner au hasard un petit échantillon de taille constante (qu’on appellera (k)) du réseau et à envoyer un message de requête aux nœuds. Dans l’exemple qui suit, (k) représentera 5 autres nœuds (N2-N3-N4-N5-N6).

Le Nœud Initial fait une requête à 5 nœuds.

Lorsqu’un nœud reçoit ce type de requête deux cas sont possibles (voir exemple au-dessus):

  1. Le nœud qui n’a pas encore de couleur (dans notre exemple N2 , N3 , N5 et N6), adopte la couleur reçue et répond avec cette couleur. Ce nœud initie ensuite ses propres requêtes avec d’autres nœuds toujours dans un échantillon aléatoire. Pour faciliter la compréhension du graphique seul l’action de N2 a été représentée mais N3, N5 et N6 font exactement les mêmes actions que N2.
  2. Le nœud qui a déjà une couleur (dans notre exemple N4) répond seulement avec sa couleur (qu’elle soit rouge ou bleue).

Une fois que le nœud collecte toutes les réponses (k), il vérifie si la majorité (seuil paramétré dans le protocole) est en accord avec la couleur.

Deux cas de figure possibles :

  1. Si la couleur de la majorité échantillonnée est la même que sa couleur actuelle, alors le nœud conserve sa couleur. (exemple #1 et #2 ci-dessous).
  2. Si la couleur de la majorité échantillonnée est différente de la sienne alors le nœud changera sa couleur pour celle-ci. (exemple #3 ci-dessous).
Réactions possibles du Nœud Initial suite à ses requêtes.

Cette opération se répète plusieurs fois (plusieurs tours) avant que le nœud décide de sa couleur finale.

Exemple de convergence des nœuds dans un contexte où le réseau est initialement divisé entre la couleur bleue et rouge. Il faut imaginer que ce processus va se faire très rapidement en réalité.

Slush, convergence de huit nœuds pour la même couleur. Crédit à Ludovic Lars.

Même dans le cas où il y aurait 10.000 nœuds la convergence se ferait en moins de 2 secondes. D’après le livre blanc le réseau serait capable théoriquement d’intégrer plus d’un million de nœuds sans trop perdre en performance.

Crucially, the experimental data show that median latency is more-or-less independent of network size. — page 11 du livre blanc Scalable and Probabilistic Leaderless BFT Consensus through Metastability

Les données expérimentales montrent que la latence médiane est plus ou moins indépendante de la taille du réseau.

Figure 13 shows that overall throughput degrades about 1:34% to 6909 tps when the network grows by a factor of 16 to n = 2000. — page 10 du livre blanc Scalable and Probabilistic Leaderless BFT Consensus through Metastability

Les transactions par seconde se dégradent de 1.34% à chaque fois que le réseau augmente sa taille par 16.

Ces tests ont été réalisés sur différentes tailles de réseau: 125, 250, 500, 1000 et 2000 nœuds. Reste à prouver que la théorie fonctionne à une plus grande échelle.

En résumé Slush provose les avantages suivants:

  • Le protocole n’est pas gourmand en mémoire : les nœuds ne conservent aucun état entre les différents tours et les échanges faits avec les autres nœuds. Il ne conserve que sa couleur actuelle. Cela en fait un protocole très léger.
  • Chaque tour ne demande pas la participation de l’ensemble du réseau mais un échantillon aléatoire de celui-ci.
  • Le protocole ne peut pas être bloqué par n’importe quelle configuration du réseau (un 50/50 entre deux couleurs) puisqu’une perturbation aléatoire dans l’échantillon fera toujours basculer vers une couleur définie. Ce léger avantage sera amplifié par les échantillonnages suivants.
  • Slush assure que tous les nœuds auront choisi la même couleur avec une haute probabilité.

Avez-vous compris le mode de fonctionnement du protocole Slush? Qu’en pensez-vous? Dans le prochain article, nous allons décortiqué le protocole Snowflake (Flocon de neige), le deuxième des trois protocoles qui composent la famille Avalanche.

Lexique :

Protocoles gossip (épidémiques) : Ils utilisent un principe simple : tout pair du réseau transmet l’information aux pairs qu’il connait (un sous-ensemble du total) et ceux-ci, à leur tour, vont transmettre cette information aux pairs qu’ils connaissent (on appelle parfois cette procédure “indondation” — flooding). Jusqu’à ce que la totalité des pairs du réseau connaissent l’information, sans avoir eu besoin d’un système centralisé.

Références :

  • Scalable and Probabilistic Leaderless BFT Consensus Through Metastability — Team Rocket 2019

À propos d’Avalanche :

Avalanche est une plateforme open-source permettant de lancer des applications financières décentralisées et des déploiements de blockchain d’entreprise dans un écosystème interopérable et hautement évolutif. Les développeurs qui se servent d’Avalanche peuvent facilement créer des applications puissantes, fiables et sécurisées et des réseaux blockchain personnalisées avec des ensembles de règles complexes ou s’appuyer sur des sous-réseaux privés ou publics existants.

Telegram Francophone | Twitter Francophone |Site Web |Papier blanc | Twitter | Discord | GitHub | Documentation | Explorer | Avalanche-X | Telegram | Facebook | LinkedIn | Reddit | YouTube

--

--