Vendredi 26 juillet 2019, une nouvelle proposition d’amendement du nom de Babylone a été injectée dans le système de gouvernance de Tezos. Il s’agit de la quatrième proposition soumise au vote du réseau. Elle fait suite à Athènes A qui est intégrée au protocole depuis le 30 mai, Athènes B son alternative non adoptée, et Brest une proposition plus récente n’ayant pas reçu l’approbation du réseau.

Cette proposition est le résultat du travail conjoint de trois équipes :

  • Nomadic Labs, l’équipe de recherche basée en France qui était à l’origine de l’amendement Athènes ;
  • Cryptium Labs ;
  • L’équipe derrière Marigold et LIGO.

Une rémunération (symbolique) de 500 ꜩ sera distribuée aux équipes si l’amendement est adopté.

Les principaux changements apportés par Babylone sont :

Emmy+

L’actuel algorithme de consensus est surnommé Emmy. Il s’agit d’une version améliorée de l’algorithme de consensus de Nakamoto : il se fonde sur une chaîne de blocs et la chaîne « la plus longue » est sélectionnée. Les participants sont sélectionnés par preuve d’enjeu liquide : ils doivent disposer d’un minimum de 8000 ꜩ pour prendre part au consensus. Un bloc est formé et validé par un boulanger (ou baker), puis est approuvé par d’autres boulangers qui prennent alors le nom d’approbateurs. La meilleure chaîne va être déterminée par un score de sélection (fitness), qui est défini comme la somme du nombre de blocs de la chaîne (hauteur) et du nombre total d’approbations. Ce système permet d’éviter le problème du « selfish baking ». Pour plus d’informations, vous pouvez consulter notre explication détaillée sur le sujet.

L’idée derrière Emmy+, proposée par Nomadic Labs, est de modifier le délai avant qu’un bloc soit considéré comme valide. Dans Emmy, ce délai dépend du temps de bloc (60 secondes) et de la priorité du boulanger : celui qui a la priorité 0 peut valider un bloc une minute après le dernier bloc ; si le premier est hors-ligne, celui qui a la priorité 1 peut valider un bloc au bout de 2 minutes 15, etc. La modification consiste à prendre en compte le nombre d’approbations du bloc dans ce délai : moins un bloc recevra d’approbations, plus cela prendra de temps avant qu’il soit considéré comme valide. Cela incite donc les boulangers à attendre que leurs blocs soient pleinement approuvés par les autres.

Le nombre d’approbations étant compris dans la production de blocs, le score de sélection de Emmy+ devient simplement la hauteur de bloc.

Emmy+ est à la fois plus robuste et plus facile à analyser qu’Emmy. Il se rapproche également un peu des algorithmes traditionnels (dits parfois « BFT ») en faisant que la production de blocs devienne plus lente si le consensus a du mal à être atteint.

De nouvelles fonctionnalités pour Michelson

Le deuxième apport de l’amendement Babylone est l’ajout de multiples fonctionnalités pour Michelson, le langage de contrats autonomes de Tezos. Le but est, entre autres, de faciliter la tâche des développeurs. Parmi les changements principaux, on peut citer :

  • La mise en place de points d’entrée dans les contrats, permettant à une transaction de viser une partie spécifique du code en utilisant un nom. Cela améliore l’expérience utilisateur et autorise le polymorphisme.
  • La possibilité de traiter plusieurs variables de type big_map par programme.
  • Une révision du système de coût de gaz.

À ceci il faut rajouter les modifications apportées pour simplifier le développement de contrats autonomes complexes, notamment demandées par l’équipe derrière Marigold et LIGO. Celles-ci consistent en de nouvelles instructions (DIG, DUG, DIPN, DROPN, APPLY…) facilitant la compilation des langages de haut niveau (Liquidity, LIGO, etc.) vers Michelson.

Une refonte du système de comptes

La troisième partie de la proposition Babylone concerne le modèle des comptes de Tezos. Ce dernier est en effet un peu déroutant pour les utilisateurs. D’un côté, les comptes implicites tz, qui sont les comptes simples liés à une clé privée, peuvent servir aux boulangers pour valider des blocs, mais ne peuvent pas être utilisés pour déléguer des fonds. De l’autre côté, les comptes engendrés KT1, dont le rôle principal est d’héberger des contrats autonomes, peuvent également servir à déléguer des fonds.

L’évolution, proposée par Cryptium Labs, consiste à clarifier la distinction entre comptes implicites et engendrés. Les comptes implicites serviront à réaliser les diverses opérations et les comptes engendrés à accueillir des contrats.

Ceci se ferait par le biais de deux modifications. D’abord, il sera rendu possible de déléguer des tez à partir d’un compte implicite. Cela permettra aux utilisateurs de ne plus à avoir à créer un autre compte pour procéder au staking de leurs fonds.

Ensuite, les comptes engendrés KT1 n’hébergeant pas de code Michelson (c’est-à-dire ceux qui servent à déléguer) seront modifiés pour contenir un contrat équivalent au système de délégation actuel. L’idée est de faire en sorte que la migration se passe de la façon la plus fluide possible en conservant toutes les délégations en place.

Un perfectionnement de la formule du quorum

Enfin, le quatrième point que Babylone compte modifier est la formule du quorum, un quorum étant la participation minimale requise dans une période de vote. Le processus d’amendement est en effet constitué de multiples phases, qui sont décrites plus en détails dans cet article.

Le quorum de la période de vote suivante est calculé d’après la formule suivante :

Qt + 1 = (0.8) Qt + (0.2) q

Qt est le quorum de la phase de vote présente et q le taux de participation réel. Le quorum dépend donc du quorum précédent et de la participation. Si cette dernière est très élevée durant les premières phases, cela peut poser problème et les propositions peuvent échouer à la fin, même si l’acceptation est très large dans la communauté.

C’est pour cela que Cryptium Labs a inclus des limites de quorum : à l’avenir, le quorum ne pourra pas descendre en-dessous de 20 % et ne pourra pas monter au-dessus de 70 %. Certains petits changements ont aussi été implémentés.

De plus, il est prévu d’implémenter un quorum de 5 % pour la période de proposition, à savoir la première période du système de gouvernance. Cette mesure a pour but d’éviter le spam potentiel de propositions provenant d’un baker malveillant.

Conclusion

La proposition Babylone est ainsi une proposition bien fournie qui apporte son lot d’améliorations à Tezos. Elle a été mise en place par trois équipes ayant une bonne réputation dans la communauté (Nomadic Labs, Cryptium labs et l’équipe de Marigold). Bien qu’il y ait quelques dissensions, tout indique que la proposition devrait être acceptée par les boulangers.

Notez qu’une version légèrement modifiée de Babylone a été proposée ce vendredi 2 août : c’est donc pour celle-ci qu’il faudra voter et non la première version.

Merci à Nomadic Labs pour la relecture.


Ludovic Lars

Ludovic est fasciné par les protocoles crypto-économiques et par l'impact qu'ils pourraient avoir sur nos vies. De formation scientifique, il s'attache à décrire leur fonctionnement technique de la façon la plus fidèle possible.

0 commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *