Découverte d'Avalanche et de la plateforme AVA

Si vous vous intéressez au fonctionnement de Bitcoin ou des autres cryptomonnaies, vous avez déjà étudié le concept de consensus. Ces algorithmes qui dictent les interactions entre les utilisateurs sont au cœur des systèmes décentralisés. Mais savez-vous quelles sont les différences entre deux consensus différents ? Qu’il existe différentes familles de consensus ? Aujourd’hui nous allons étudier une famille de consensus nommée Avalanche qui a récemment été présentée au grand public, et nous en profiterons pour revenir sur les consensus existants.

Il s’agit d’Avalanche, une famille de consensus innovante, présentée le 18 avril 2018 par la diffusion de son livre blanc. Utilisant quatre protocoles différents dont nous étudierons le fonctionnement, Avalanche tire avantage des consensus déjà existants. Nous verrons également qui sont AvaLabs, qui travaillent à l'implémentation de la plateforme AVA pour révolutionner la finance.

Les origines d'Avalanche

La première présentation de la famille de consensus Avalanche nous ramène aux origines de Bitcoin. En effet son livre blanc, intitulé Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family for Cryptocurrencies, a également été publié de façon anonyme sur IPFS. Ses créateurs, connus sous le pseudo « La Team Rocket », restent aujourd'hui anonymes. Le livre blanc contient la description d'une famille de consensus, principalement composée de quatre protocoles distincts, ainsi que de nombreuses ressources et études sur la viabilité des différents protocoles.

Une équipe de développeurs, composée de chercheur de l'université Cornell, a travaillé pour améliorer cette étude. Assistant la Team Rocket, ils ont participé à la révision du livre blanc et travaille désormais à son implémentation, AVA. Vous pouvez retrouver la nouvelle version du livre blanc intitulée Scalable and Probabilistic Leaderless BFT Consensus through Metastability. Nous reparlerons de cette équipe et de la plateforme AVA dans la suite de l'article.

Les familles de consensus

Avant de présenter ce que peuvent apporter les protocoles d'Avalanche, il est important de reprendre ce qu'est un protocole de consensus. Ce sont des protocoles qui visent à résoudre un problème mathématique : celui des généraux byzantins, une façon imagée de présenter le besoin de coordination d'acteurs indépendants pour trouver un accord entre tous les participants.

C'est un problème connu dans l'écosystème crypto puisque c'est sa résolution par Satoshi Nakamoto qui a permis de créer Bitcoin. Mais ce n'est pas la seule solution, et d'autres consensus existaient avant. Appartenant à la famille de protocoles dits « classiques », ils ont été développés dans les années 80 et sont beaucoup moins adaptés à la décentralisation. On séparait donc les consensus proches de celui qu'utilise Bitcoin, avec la famille « Nakamoto » qui permettait de coordonner un plus grand nombre de nœuds. Enfin vient la famille « Avalanche » qui cherche à prendre le meilleur des deux mondes afin de développer un réseau plus efficace.

Protocoles de consensus classiques

Ces protocoles ont été principalement créés par Barbara Liskov et Leslie Lamport, et fonctionnent encore actuellement. La validation des transaction y est rapide, mais les nœuds doivent être sélectionnés et la taille du réseau doit être limitée. En effet les échanges sont dits quadratiques, c'est-à-dire que chaque nœud doit être capable de réaliser des interactions avec l'ensemble des autres nœuds. Ils ne sont pas aussi efficaces dans la sécurité du réseau que la seconde famille comme nous allons le voir, mais peuvent gérer un plus grand nombre de transactions. Ils peuvent donc être utilisés pour des blockchains privées ou autres systèmes sélectionnant en amont les nœuds validateurs.

Protocoles de consensus Nakamoto

Plus robuste, le consensus Nakamoto est apparu avec Bitcoin et utilise un système de blocs de transactions qui sont organisés sous forme de chaîne. La chaîne ayant le plus de supporters, et donc la plus longue, est choisie par les acteurs. La validation des transactions se fait en amont (par preuve de travail ou preuve d'enjeu) et le nombre de participants n'est pas limité. Contrairement aux consensus classiques, les participants n'ont pas besoin d'être identifiés. Personne ne peut empêcher un nœud de rejoindre le réseau, il n'y a pas de limitations ou de censure. En revanche les transactions mettent du temps à être validées, et le débit de ces dernières doit être maintenu faible.

Protocoles de consensus Avalanche

Afin d'optimiser le fonctionnement de l'existant, Avalanche utilise quatre protocoles différents qui reprennent à leurs manière le meilleur des deux familles de consensus précédentes. Même si aujourd'hui il n'existe pas d'implémentations à grande échelle, le livre blanc nous présente des caractéristiques exceptionnelles. En effet le premier paragraphe du livre blanc présente les résultats des expérimentations. Ce sont plus de 6000 transactions pas secondes qui pourront être réalisées, pour un temps d'exécution d'une transaction de 1 sec. Les transactions ne sont pas mises en forme dans des blocs, et sont organisées dans un DAG dont nous verrons le fonctionnement par la suite.

Les différents protocoles d'Avalanche

La famille de consensus Avalanche repose sur quatre protocoles différents : Slush, Snowflake, Snowball et Avalanche, qui apportent chacun des fonctionnalités qui assure le bon fonctionnement du système.

Slush

C'est le premier protocole à être introduit dans le livre blanc d'Avalanche. Vous allez vous en rendre compte, son fonctionnement est assez simple. Il n'est toutefois pas résistant aux pannes byzantines, mais permettra de mettre en place la communication entre les nœuds. L'objectif étant d'être plus performant que les consensus Nakamoto dans le cadre des interactions au sein du réseau, et donc d'être rapide. Il reste tout de même résistant aux crashs et à l'arrêt des nœuds du réseau. Les nœuds peuvent donc renforcer et quitter le réseau à tout moment.

Fonctionnement de Slush

Je reprendrais l’exemple très illustré du livre blanc pour vous le présenter. L'état originel du réseau est composé de nœuds incolores. À chaque nouvelle itération, cet état va changer puisque les nœuds vont interagir entre eux, et avec les clients. C'est par le biais des transactions que les premiers changements interviennent. Si un nœud est toujours dans son état d'origine lorsqu'il reçoit une transaction, il va prendre l'état de cette transaction. Nous prendrons deux état différents pour cette explication, la couleur rouge et la couleur bleue. Notre nœud a donc reçu une transaction rouge, et devient à son tour un nœud rouge.

Il va par la suite effectuer un sondage auprès du réseau. Puis il sélectionnera un nombre constant de nœuds, de manière totalement aléatoire. Enfin il enverra un message à cet échantillon réduit, contenant sa couleur. Lorsqu’un nœud reçoit ce message, deux cas sont possibles. Si le nœud en question n'a pas de couleur attitrée, il acceptera simplement cette couleur comme la sienne et renverra cette couleur comme réponse. Il effectuera par la suite un nouveau sondage indépendant. Si le nœud possède déjà une couleur, il renverra cette dernière. Si un nœud ne reçoit pas un nombre suffisant de réponses (nœuds indisponible ou crash par exemple), il renverra son sondage à d'autre nœuds, choisis aléatoirement également, de manière à obtenir le bon nombre de réponses.

Une fois les réponses provenant des autres nœuds tirés au hasard reçues, il va travailler sur les résultats. Si la majorité des résultats qu'il a obtenus sont des retours d'une couleur différente de la sienne, il change alors de couleur. Sinon il conserve sa couleur tout simplement. Il va répéter ce programme X fois, où X est la variable choisie lors de l'implémentation du protocole.

Ce protocole permet plusieurs choses, et possède des caractéristiques bien particulières. Tout d'abord il n'a pas besoin de mémoire, puisqu'il conserve que l'état actuel du nœud. On ne peut pas connaître les états précédents, ou les interactions avec les autres nœuds lors du sondage. Aussi, le nœud n'a pas besoin d’interagir avec tout les nœuds du réseau, seul l’échantillon tiré suffit. Cela permet de rester efficace lors de l'augmentation du nombre de nœuds sur le réseau. Dernier point plus technique, même si le réseau est composé d'un ratio 50 / 50 d'état différents, si le nombre de tirage est suffisamment grand le résultat convergera vers un état commun pour chaque nœud du réseau. Pour reprendre l'exemple les nœuds seront tous rouges, ou bien tous bleus.

Snowflake

Snowflake est le deuxième protocole d'Avalanche qui va améliorer l'utilisation du précédent, Slush. En effet Snowflake apporte un système de comptage des états des nœuds du réseau. Cela permet de connaître le nombre de fois consécutives où le nœud renvoie la même couleur, et donc en quelque sorte la confiance envers cet état. On avait vu que le protocole Slush ne possédait pas de mémoire, Snowflake permet tout de même de conserver une information. Chaque nœud possède désormais un compteur personnel, qui va comptabiliser le nombre d'itérations pour lequel le nœud a renvoyé la même couleur. Le compteur revient à zéro lors de tout changement de couleur.

L'objectif d'un protocole de consensus est d'arriver d'une manière ou d'une autre à une décision. Compter des couleurs et réaliser des sondages à l'infini ne permet pas d'arriver à un accord. En fonction des paramètres du protocole, le réseau fixera donc une décision lorsque le compteur dépassera un certain nombre, en fonction du paramétrage du réseau. Une fois les nœuds engagés, il n'y a pas de retour en arrière et la décision est validée.

L’objectif de Snowflake est de rendre le système résistant aux pannes byzantines, selon le nombre défini comme seuil de sécurité. Plus ce nombre est grand, plus le protocole est long mais plus les probabilités de réussite d’attaques de nœuds malhonnêtes sont faibles.

Snowball

La faculté de mémoire qu'apporte le deuxième protocole reste éphémère, en effet dès que la couleur du nœud change le compte revient à zéro. C’est là que Snowball intervient, permettant de rendre plus durable cette mémoire. C’est surtout un moyen d’obtenir la confiance des nœuds envers une décision précise. Snowball apporte donc un nouveau compteur dit de « comptabilisation de la confiance ». Il va enregistrer le nombre de sondages qui ont retournés la même couleur. Le nœud modifiera sa couleur lors d'une suite de sondages consécutifs, et la confiance envers la couleur sera plus grande que celle des autres couleurs.

Ce système de compteur fonctionne différemment que Snowflake, vu précédemment. En effet, à chaque retour de sondage effectué le compteur de la couleur reçue sera incrémenté. Il ne s'agit donc pas d'un compteur unique qui se réinitialise à chaque changement. C'est donc la confiance envers chacune des couleurs qui est compté. Également, le nœud changera automatiquement sa couleur pour celle dont le compteur est le plus grand.

Snowball apporte une couche de protection supplémentaire contre les attaques. Il ne modifie pas le fonctionnement du protocole, mais apporte une fonctionnalité propre qui est la confiance envers le choix de chaque nœud. Il est aussi, selon le livre blanc, plus facilement exportable vers des protocoles à décisions multiples.

Avalanche

Avalanche est le quatrième et dernier protocole que nous allons étudier. Il permet la mise en place ce que l'on nomme DAG (Directed Acylic Graph) de toutes les transactions effectués par le réseau. Un DAG est une figure mathématique principalement utilisé en informatique qui peut se résumer à une chaîne de maillons finis, non linéaire. La particularité de cette chaîne est que chaque maillon est accessible par un autre maillon, formant une multitude de chemins d'accès. Cette figure peut représenter une forme d'arbres de décisions, avec une relation parent-enfant entre chaque nœuds de cet arbre. Un seul nœud ne possède pas de liens sortant et il s'agit du point vers lequel les autres nœuds vont tendre. Ce « genesis vertex » représente la toute première transaction réalisée sur le réseau. On pourrait le comparer au « genesis block » de Bitcoin.

Mettre en place un tel graphe possède deux avantages principaux pour notre protocole. Premièrement cela permet d'améliorer l'efficacité du réseau. En effet un nouveau vote mis en place sur le DAG vote implicitement pour les autres votes qui existent. Notons qu'il ne s'agit que des votes dont les nœuds se positionnent entre le nouveau vote et le genesis vertex. Il n'y a donc pas besoins de méthodes particulières pour ajouter un vote à ce DAG, comme des regroupements de transactions par blocs que l'on retrouve pour Bitcoin par exemple. Le DAG apporte également une sécurité contre les réécritures des transactions effectuées. En effet, de par l'historique des transactions, il est complexe d'annuler ou de modifier des décisions passées. Il faudrait pour cela l'approbation des nœuds spécifiques, tâche complexe dans un cas de décentralisation.

La plateforme AVA

L'équipe d'Avalabs travaille actuellement à une intégration d'Avalanche. Nommée AVA, il s'agit d'une plateforme dédiée au développement de tokens et d'applications décentralisées. Dédiée principalement à la finance décentralisée, AVA souhaite utiliser les pleins potentiels des protocoles d'Avalanche pour mettre sur pied une infrastructure fiable et efficace. Ainsi, elle est capable de fournir une architecture flexible en fonction des projets, tout en garantissant un niveau de scalabilité élevé.

Le jeton AVA

AVA viendra avec un token, qui n'est pas disponible actuellement. Ce token ne sera pas seulement un moyen d'utiliser le réseau ni une monnaie d'échange. C'est un outil permettant d'assurer la sécurité de la plateforme en se protégeant des attaques de types Sybil. En effet c'est la preuve d'enjeu (proof-of-stake, POS) qui a été retenue afin de réaliser la validation des transactions. Une vente publique sera mise en place au fil du projet, et les informations à ce propos n'ont pas été dévoilées pour le moment.

Il permettra également de recueillir les avis des détenteurs sur les paramètres du système. Ces derniers pourront ainsi décider des variables importantes comme les frais de minages, le nombre minimal de jetons pour accéder au staking et bien plus encore.

Un système de sous-réseaux

AVA souhaite apporter la notion de plug-and-play lors de la création de sous-réseaux. Différentes options sont disponibles en fonction des besoins. Prenons un exemple de création d'un sous-réseau personnalisé, et voyons quels choix seront disponibles.

Tout d'abord si le réseau est utilisé pour réaliser des transactions, ou le déploiement de smart-contracts. Ensuite le type de machine virtuelle que l'on souhaite : EVM, WASM, Move ou encore Bitcoin Script. Quels seront les validateurs des transactions effectués sur mon réseau ? Je les sélectionne ou sera-il complément ouvert aux utilisateurs ? AVA vous permettra également d'ajouter des fonctionnalités supplémentaires par le biais de différents plugins. Cela peut permettre par exemple d'ajouter une sur-couche de conformité ou de KYC, nécessaire pour certaines utilisations.

Cette notion de flexibilité n'est actuellement pas ou encore peu disponibles dans les systèmes de création de réseaux. Même si certains services de Hyperledger ou d'AWS existent, il reste lourd et complexe de personnaliser complètement l'architecture d'un projet.

Snowman

AVA permet également le déploiement de smart-contracts sur son réseau. Ces derniers sont déployés et exécutés sur une chaîne à part, Snowman. Snowman ne prend pas la forme d'un DAG comme la chaîne utilisée pour réaliser les transactions, mais elle est linéaire. Pour le moment seul les contrats en Solidity désignés pour l'EVM sont utilisable. En revanche d'autres types de machines virtuelles sont à venir comme WASM et Move. WASM est un standard de VM très utilisé permettant l'utilisation de langages tels que Python / C / C++. AVA se veut beaucoup plus scalable que les plateformes de smart-contracts actuelles. De nombreuses informations à propos de Snowman sont à venir.

Athereum

Récemment AvaLabs a annoncé le projet Athereum, une « spoon » soit un fork amical de Ethereum. Pour le moment en testnet, ce réseau déployé sur AVA permet d'utiliser tout les outils et fonctionnalités d'Ethereum tout en validant les transactions par le protocole de consensus Avalanche. Tous les utilisateurs actuels d'Ethereum pourront facilement utiliser Athereum puisqu'un swap 1:1 des tokens est proposé, c'est-à-dire que la quantité d'Éthers que vous possédez vous octroie l'accès à un montant égale de token ATH, le token d'Athereum.

AVA est encore en phase de développement, et assez peu de fonctionnalités sont actuellement peu disponibles pour le public. En effet que ce soit du côté utilisateur final ou développeur, il n’y a pas vraiment de matière. Par exemple il n’y a pas de documentation technique disponible. C’est donc assez compliqué de se projeter dans l’écosystème futur d’AVA.

Aller plus loin

Si vous souhaitez allez plus loin dans l'étude de la famille de protocoles Avalanche, je vous conseille tout d'abord la lecture du livre blanc de cette dernière, disponible ici. Vous y retrouverez des informations plus techniques que je n'ai pas traitées dans cette présentation, notamment les études de sécurité et l'intégration des protocoles afin d'en tester la scalabilité.

Vous retrouverez également de nombreuses ressources moins techniques sur le Medium de l'équipe AvaLabs. Je vous conseille particulièrement le Medium français de l'équipe, sur lequel Nicolas Lemaitre poste régulièrement des explications sur Avalanche. Un grand merci à lui qui m'a fournit de nombreuses informations pour la rédaction de cet article, n'hésitez pas à le contacter si vous avez besoin d'informations complémentaires. Un groupe français Telegram est également disponible si vous avez besoin d'informations complémentaires.

Le blog que tient Nicolas vous permettra d’aller plus loin dans le fonctionnement des quarte protocoles. Il propose également une présentation très accessible du fonctionnement d’Avalanche, jetez-y un coup d’oeil. C’est également un bon moyen de rester informé sur l’avancée de l’équipe. Vous y retrouverez également des interviews en français de l’équipe d’AVA. Cela permet de mieux comprendre les objectifs de l’équipe et les principales difficultés qu’ils rencontrent pendant le développement du projet. J'ai présenté rapidement Athereum, mais plusieurs guides d'utilisation d'outils comme Metamask ou MEW sont également disponibles sur le Medium de l'équipe, en français.

Voilà pour cet article, j’espère que vous avez pris autant de plaisir à découvrir le monde des consensus que j'en ai eu à écrire cet article. Connaissiez-vous AVA et Avalanche avant la lecture de cet article ? Pensez vous qu’Avalanche tiendra toutes ses promesses une fois implémentée de façon fonctionnelle ? Si vous avez des questions à propos de cet article, n’hésitez pas à me contacter dans les commentaires ou sur Twitter.

Passionné par les crypto-monnaies, j’ai rapidement appris à développer des outils dans le domaine des technologies blockchain. J’aime partager mes connaissances sur le sujet et je participe activement au rayonnement des aspects techniques de la blockchain au sein de la communauté crypto. Je suis principalement intéressé par Ethereum et par son code Solidity.

Guillaume Chanut

64 articles

Tous ses articles