En nous renseignant sur le fonctionnement de Bitcoin, nous arrivons rapidement à l’étude des consensus et de leurs fonctions au sein des réseaux des diverses cryptomonnaies. Il existe aujourd’hui de nombreux consensus appartenant à différentes familles, dont une a même hérité du nom du créateur de Bitcoin. Mais aujourd’hui, je vous présente une toute autre famille de consensus, Avalanche.
Le Consensus Avalanche
On peut reconnaître un petit air de ressemblance quand à la présentation au monde d’Avalance et de Bitcoin. En effet, Snowflake To Avalanche: A Novel Metastable Consensus Protocol Family for Cryptocurrencies a été dévoilé par une équipe qui a cherché à conserver une partie de son anonymat. La curieuse “Team Rocket” a donc publié de manière anonyme le livre blanc sur un protocole d’hébergement de fichiers décentralisé, IPFS. Une nouvelle famille de consensus donc, qui vient s’ajouter aux consensus dits classiques ainsi qu’au consensus de Nakamoto. Tous ces consensus visent à résoudre un problème mathématique, celui des généraux byzantins, qui permet d’illustrer les difficultés de la coordination d’acteurs indépendants sur un même réseau.
Les protocoles classiques développés dans les années 80 fonctionnent de manière très efficace dans des réseaux de petite taille. Ils ne sont pas particulièrement forcément adaptés aux idéaux de décentralisation, puisque les nœuds du réseau doivent être sélectionnés. Pour donner des exemples de cas d’utilisations de ces derniers dans l’écosystème de la technologie blockchain, des consensus de ce type pourraient être utilisés pour des blockchains privées ou dans le cadre de délégations. Plus adapté à cette décentralisation permettant une résistance face à un milieu adverse, mais beaucoup moins performant en termes de vitesse initiale d’exécution des transactions, le consensus dit de Nakamoto apparaît avec la création de Bitcoin.
Les protocoles Avalanche
Le consensus Avalanche utilise quant à lui différents protocoles – au nombre de quatre – pour coordonner les acteurs et les transactions du réseau. Nous allons voir plus en détail par la suite ces protocoles, qui sont Slush, Snowflake, Snowball et Avalanche.
Slush
Slush ne résout absolument pas le problème des généraux byzantins et son fonctionnement est destiné principalement à établir la communication entre les nœuds du réseau. Résistant à la panne des nœuds, il permet notamment à ces derniers de rejoindre et de quitter le réseau à tout moment. Il fonctionne de la manière suivante.
• À l’instant T = 0, tous les nœuds du réseau sont dits incolores, c’est-à-dire qu’ils n’ont pas encore jugé de la validité de transactions données, et c’est ensuite à chaque interaction entre les nœuds que ces derniers vont modifier leurs états.
• A chaque nouvelle transaction entrante, si le nœud est toujours incolore, il prendra la “couleur” de la transaction qu’il reçoit. Sinon le processus est légèrement plus complexe. En effet il va réaliser un sondage auprès d’un nombre fini de nœuds et recevra en réponse les couleurs de ces deniers. Il prendra alors la couleur contenue dans une majorité des réponses reçues.
• Ce processus va être répété un certain nombre de fois, lequel peut être variable en fonction des paramètres de l’implémentation du protocole. Progressivement, et par effet boule de neige, tous les nœuds se mettront d’accord sur la même “couleur”, donc sur les mêmes transactions.
Illustrons ce phénomène à l’aide d’une petite animation proposée par mon collègue Ludovic Lars, sur son site personnel :
[arve model=”gif” url=”https://viresinnumeris.fr/app/uploads/2019/05/slush.mp4?_=1″ align=”center” promote_link=”no” autoplay=”yes” maxwidth=”480″ controlslist=”nodownload” controls=”no” loop=”yes” muted=”yes” /]
Slush est un protocole qui reste très efficace même si la taille du réseau augmente de manière conséquente. En effet il n’utilise pas de mémoire, puisque seul l’état actuel du nœud est conservé et les échantillons de nœuds sondés sont de tailles fixes. Si le nombre d’itérations du système est suffisamment grand, tous les nœuds posséderont un état similaire à la fin de ce dernier.
Snowflake
Si Slush ne permettait pas de conserver les états des différents nœuds en fonction des itérations, Snowflake apporte un semblant de mémoire. Ce protocole apporte à chaque nœud un compteur qui permet de mémoriser le nombre d’itérations consécutives où un nœud conserve le même état. Cela permet notamment de mesurer la confiance du nœud envers cet état, et de fixer une confiance minimale avant la prise d’une décision. Les nœuds seront en effet invités à s’engager une fois que ce fameux compteur dépasse la limite paramétrée par l’implémentation du consensus. Cela permet notamment de résister aux pannes byzantines, de manière plus ou moins efficace selon les paramètres évidemment.
Snowball
Si le protocole précédent, Snowflake apporte la notion de mémoire aux consensus, Snowball va plus loin dans cette démarche. En effet les compteurs de Snowflake ne sont pas permanents et se remettent à zéro lors de chaque changement d’état des nœuds. De ce fait, il n’est pas possible de comparer la confiance envers chaque état.
Snowball apporte cette fonctionnalité en comptabilisant les états des autres nœuds par le biais de sondages. Les nœuds ne changent donc plus d’état à chaque retours de sondages, en faveurs de ces derniers : un changement ne s’opère que lorsque la confiance envers le nouvel état est plus importante qu’envers l’ancien. Il faudrait un nombre suffisamment grand de retours pour qu’un nœud du réseau prenne un état spécifique.
Snowball est donc une sécurité supplémentaire par rapport aux nœuds potentiellement malhonnêtes, puisque cela permet de mesurer la confiance du réseau envers les états des nœuds.
Avalanche
Avalanche est le quatrième protocole qui compose le consensus du même nom. Dédié à la conservation de l’historique des transactions, il permet de facilement déployer ces dernières de manière efficace en utilisant un DAG, ou Directed Acylic Graph. L’utilisation de ce graph permet de rendre le réseau beaucoup plus efficace et diminuer le temps moyen de la confirmation d’une transaction à environ une seconde, tout en conserver un haut niveau de sécurité.
Un DAG : Qu’est-ce que c’est ?
Un DAG est une chaîne de maillons non linéaire, c’est-à-dire très différente de la classique chaîne de bloc utilisée dans le consensus Nakamoto par exemple. Pour illustrer cette figure mathématique, nous pouvons nous représenter un arbre de prise de décisions dans lequel nous stockons tous les votes des nœuds du réseau à chaque itération du consensus. Chaque maillon est accessible par le biais d’un autre maillon, et il existe autant de chemins menant à la transaction fondatrice (genesis vertex) réalisée par le réseau. Nous pouvons comparer ce dernier au “genesis block” du réseau Bitcoin.
La mise en place d’un DAG permet donc en théorie d’ajouter plus facilement et plus rapidement de nouvelles transactions ayant été validées par le réseau de nœuds par le biais des protocoles cités précédemment. Rappelons tout de même que la viabilité des DAG est parfois questionnée par certains experts en cybersécurité, par exemple dans des implémentations utilisées par le projet IOTA.
L’implémentation d’Avalanche par Avalabs
Un protocole ne reste qu’un livre blanc et de démontre pas ses qualités ni ne profite pas aux utilisateurs tant qu’il n’a pas été implémenté. C’est pour cette raison qu’une équipe d’universitaires s’est lancée le projet de réaliser une implémentation nommée Ava. Avalabs a donc collaboré avec la Team Rocket afin d’améliorer le livre blanc originel et d’utiliser ces quatre protocoles pour déployer des infrastructures blockchain modulables. Notons qu’Avalabs comporte quelques figures connues de la cryptosphère, quoique là aussi parfois discutées, comme Emin Gün Sirer.
Avalabs entend déployer des réseaux blockchains plug-and-play visant les entreprises en réseaux fermés, mais également des projets ouverts. Différentes machines virtuelles seraient disponibles, comme les traditionnels Bitcoin Script ou l’EVM, mais également la WSAM et Move.
Mise à jour juillet 2020 :
ll est désormais possible d’acheter des tokens AVAX en pré-vente sur plusieurs exchanges via des IOU. Un IOU (I Owe You) est une reconnaissance de dette : l’acheteur a la garantie d’obtenir ses tokens dès qu’ils seront disponibles.
ZeBitex, plateforme d’échange française régulée, propose des IOU sur le token AVAX en euros.
Ava Labs n’a pas encore annoncé sur quelles plateformes de change le token sera listé. Mais au vu du succès du projet et des sommes levées, il y a peu de doutes : l’AVAX sera listé sur les plus grosses plateformes.
Athereum
Athereum est un hard fork d’Ethereum, dédié à l’implémentation du consensus Avalanche dans un environnement Ethereum. Ce réseau est déployé par le biais de la plateforme AVA, qui permet la mise en place de sous réseaux personnalisés en fonction des besoins des développeurs. Les outils largement utilisés par les développeurs de la communauté tels que Metamask, la librairie Web3js ou la suite Truffle sont également disponibles pour développer des applications sur Athereum. L’objectif étant de proposer à ces développeurs les services d’Avalabs sans qu’ils aient à modifier leurs outils et méthodes de travail. Chaque possesseur d’éthers bénéficie d’un nombre égal d’ather pour utiliser le réseau Athereum.
Athereum est toujours déployé sur un réseau de test disposant de 25 nœuds mais les premiers résultats sont encourageants quand aux améliorations techniques. Le réseau se présente comme une alternative plus rapide et différente d’Ethereum pour explorer des cas d’utilisation de dApps plus larges. Mais cela reste un réseau de test et il faudra attendre de voir évoluer des Dapps de grande envergure pour pouvoir définir la réelle plus-value ou non d’Athereum et des consensus Avalanche.
Voilà pour cette présentation de la famille de protocoles Avalanche ainsi que celle de la première implémentation qu’est la plateforme Avalanche. Si vous souhaitez aller plus loin dans la découverte, je vous conseille la lecture du livre blanc de la Team Rocket ainsi que le blog Medium de l’équipe d’Avalabs. Vous y retrouverez de nombreuses explications quand au fonctionnement plus précis des différents protocoles, et il est entièrement écrit en français par Nicolas Lemaitre. Si vous avez des questions ou remarques à propos de cet article, n’hésitez pas à nous en faire part.
