Tezos, une blockchain auto-évolutive (partie 1/3)
Cet article est la première partie d’une suite d’articles où nous allons étudier la blockchain française Tezos, blockchain publique. Dans ce premier article, nous nous intéresserons au modèle de gouvernance de Tezos qui diffère des autres blockchains. Dans un second article, nous nous pencherons sur le consensus utilisé, à savoir le mécanisme de validation des blocs. Puis, dans un dernier article, la partie pratique de Tezos sera présentée : l’utilisation de la CLI pour faire des transactions, les appels RPC pour interagir avec la blockchain et enfin les SDK ainsi que les différents langages pour développer des smart contracts.
Si vous n’êtes pas familier avec le monde de la blockchain, il peut être intéressant de lire l’article Blockchain: Une introduction technique.
Histoire
La fondation Tezos a été créée par le Français Arthur Breitman (polytechnicien) et sa femme Kathleen Breitman à partir de ce White Paper paru en 2014, bien que l’idée de la créer a émergé depuis 2011.
Depuis 2014, Arthur Breitman a pu constater les faiblesses des premières blockchains comme Bitcoin et Ethereum, à savoir principalement :
- Les hard forks.
- Le consensus de Proof of Work qui est consommateur d’énergie et pose des problèmes de centralisation à cause des pools de minage.
- Le langage des smart contracts qui peut nous faire écrire du code non sécurisé.
Son but a alors été de ne prendre que les points positifs de ces blockchains comme les smart contracts et de proposer des solutions pour pallier ces faiblesses. Nous verrons les différentes solutions apportées au cours de cette suite d’articles.
De mars 2014 jusqu’à juillet 2017, c’est la société OCamlPro qui a participé au développement du prototype de Tezos. La plateforme a donc été développée dans le langage fonctionnel OCaml principalement utilisé dans le domaine de la recherche.
Tezos lance une ICO (levée de fonds dans le monde de la crypto-monnaie) en juillet 2017 permettant à la fondation de rassembler un montant record de 232 millions de dollars. Depuis cette ICO, l’entreprise Nomadic Labs, spécialisée dans la recherche et le développement des logiciels distribués, décentralisés et formellement vérifiés, a rejoint l’écosystème Tezos et participe désormais activement à son développement.
La sortie de Tezos s’est faite en 3 phases :
- Alphanet en février 2017.
- Betanet en juillet 2018.
- Mainnet (=réseau principal) en septembre 2018.
En ce qui concerne la monnaie, on parle de tez (au singulier), de tezzies (au pluriel) ou encore de XTZ ou ꜩ.
Présentation des points clefs
Par rapport aux blockchains des précédentes générations (Bitcoin et Ethereum), la blockchain Tezos se distingue par 3 principales caractéristiques :
- La gouvernance permettant l’auto-évolution du protocole.
- Le consensus LPOS (Liquid Proof Of Stake).
- Le développement des smart contracts avec le langage Michelson permettant d’utiliser les méthodes de vérification formelle.
Mécanisme d’évolution du protocole
Tezos permet à n’importe quel développeur de soumettre une proposal, c’est à dire une demande d’ajout, de modification ou de suppression d’une fonctionnalité du protocole.
Pour information, voici une liste non exhaustive des changements possibles :
- Changer le consensus.
- Rendre les transactions anonymes.
- Étendre le langage pour l’écriture des smart contracts.
- Changer la taille des rolls (définit juste après).
- Changer la taille des blocs.
- Changer la consommation du gas, coût d'exécution d'un smart contract sur la blockchain.
- etc.
Suite à une proposal, une gouvernance on-chain intervient : chaque personne faisant partie du réseau, plus exactement un baker ou un endorser, peut voter pour l’intégration ou non de cette proposal. Pour être baker ou endorser, il faut au minimum disposer d’un roll. Un roll est une notion qui permet de définir un ensemble de tezzies : 1 roll = 8 000 XTZ (10 000 XTZ au début), c’est un peu comme une liasse de billets.
Être baker/endorser permet de voter mais nous verrons dans le prochain article qu’ils ont également un autre rôle plus important. Une personne qui souhaiterait voter mais qui ne possède pas assez de tezzies a le droit de déléguer ses tezzies à un baker/endorser. Attention, la délégation de tezzies ne signifie pas que cette personne va transmettre ses tezzies au baker/endorser mais seulement qu’elle lui donne son poids de vote. En effet, plus un baker/endorser possède de tezzies et de tezzies délégués (qui ne lui appartiennent pas), plus son vote aura de poids par rapport à un autre baker/endorser. Pour information, le poids d’un tez et d’un tez délégué est identique. Une personne peut changer de délégué si elle le souhaite. Déléguer ses tezzies à un autre avantage mais nous verrons cela dans le prochain article.
Nous allons prendre un exemple pour détailler tout ce processus de soumission de proposals et de vote qui se nomme processus d’amendement.
Bob et Alice sont deux développeurs qui s’intéressent à la blockchain Tezos. Chacun d’entre eux voudrait apporter un changement dans le protocole.
Bob voudrait imposer un minimum de 10 XTZ pour pouvoir transférer des XTZ. Cette proposal sera nommée : PROP_BOB_MIN_10_XTZ.
Alice voudrait imposer un minimum de 20 XTZ pour pouvoir transférer des XTZ. Cette proposal sera nommée : PROP_ALICE_MIN_20_XTZ.
Une fois le développement terminé, ils voudront soumettre leur proposal puis différentes phases de votes et de tests vont avoir lieu.
Avant d’expliquer le fonctionnement de ce processus d’amendement, il convient de définir le terme de cycle. Le cycle est l’unité de temps utilisé par Tezos. On dit qu’un cycle s’est écoulé lorsque 4096 blocs ont été créés. Sachant que le temps de création entre deux blocs est d’au moins 1 minute, un cycle dure au minimum 2 jours, 20 heures et 16 minutes.
Maintenant que cette unité de temps est définie, nous pouvons nous intéresser aux 4 périodes du processus :
- Proposal.
- Exploration Vote.
- Testing.
- Promotion.
Sachant que chaque période dure 8 cycles (~22 jours), il faut attendre 32 cycles (~3 mois) pour la déroulement du processus.
Explorons chaque période en détail.
La période Proposal
C’est la période durant laquelle chaque développeur pourra soumettre leurs proposals. Chaque développeur a le droit de soumettre jusqu’à 20 proposals durant cette période.
Dans notre exemple, Bob et Alice vont chacun devoir créer une archive (au format .tar) contenant le code source de leur feature développée en OCaml (fichiers .ml/.mli).
Grâce à des outils fournis par Tezos, ils vont pouvoir créer un hash proposal à partir de leur archive puis le soumettre à liste des hash proposals. Ce hash est une représentation “unique” de l’archive en chaîne de caractères. Imaginons que l’archive de Bob et d’Alice ait respectivement pour hash proposal PROP_BOB_MIN_10_XTZ et PROP_ALICE_MIN_20_XTZ, les acteurs du réseau pourront alors voter entre ces deux features en indiquant le hash proposal correspondant. En réalité, un hash proposal ressemble plus à ce type de chaîne de caractères : Pt24m4xiPbLDhVgVfABUjirbmda3yohdN82Sp9FeuAXJ4eV9otd. Il faut noter que pour pouvoir soumettre ce hash proposal, le développeur doit au préalable injecter le code dans son noeuf pour vérifier que la compilation et le chargement du code fonctionne correctement.
La proposition ayant le plus de vote sera alors sélectionnée pour passer à la période d'Exploration Vote : c’est donc un vote à la majorité relative. Il faut noter que lorsqu’une personne soumet une proposal, elle votera également pour celle-ci, et ce, de manière automatique. Si jamais il y a une égalité de vote, dans notre cas 100 votes pour PROP_BOB_MIN_10_XTZ et 100 votes PROP_ALICE_MIN_20_XTZ, on repart pour une nouvelle période de Proposal. C’est également le cas lorsque aucune proposal n’a été soumise.
Comme nous venons de le voir, seul le hash proposal est soumis et non l’archive contenant le source code. Nous pouvons donc nous demander comment un votant va choisir entre les différentes proposals : c’est au développeur d’héberger l’archive et d’arriver à mettre le lien de téléchargement à disposition. Les votants pourront alors télécharger l’archive pour lire le code source et comprendre quelles sont les features de la proposal en question. A partir de cette archive téléchargée, le votant peut re-calculer le hash proposal pour vérifier que celui-ci correspond bien à celui qui a été soumis.
Le développeur peut mettre en place une documentation (sur son blog par exemple) pour expliquer son développement et mettre le plus de chance de son côté pour avoir des votes, c’est à lui de faire sa propore campagne. Il faut tout de même faire attention à la documentation dans le cas où un développeur pourrait vouloir implémenter une feature malicieuse. C’est le code source qui fait foi et non la documentation.Pour la suite de notre exemple, nous supposerons que la proposal de Bob a reçu le plus de votes : c’est donc la seule qui sera retenue. Toutes les autres proposals ne seront donc pas éligibles pour la prochaine période
La période Exploration Vote ou Testing Vote
Durant cette période, PROP_BOB_MIN_10_XTZ étant la proposal gagnante, chaque personne du réseau pourra voter pour l’envoyer en période de test ou non. Contrairement à la période précédente, ce n’est pas un vote à la majorité qui est utilisé.
Tezos utilise les concepts de quorum et de super-majority vote, qui correspond à un vote à la majorité qualifiée, pour décider de l’envoi en période de test ou non.
Par définition, un quorum est le nombre minimal de personnes requises pour qu’une délibération puisse avoir lieu. En prenant l’exemple d’une assemblée de 100 personnes et en définissant un quorum de 40%, cela signifierait qu’il faudrait au minimum 40 personnes présentes pour entrer en phase de vote.
Le vote à la majorité qualifiée permet quant à lui de définir un pourcentage minimal requis de votes positifs (= votes “pour”) pour que la décision soit acceptée ou non. Il s'apparente au vote à la majorité absolue où dans ce cas le pourcentage requis est de 51%. Mais dans le cas du vote à la majorité qualifiée, ce pourcentage est plus élevé : au minimum 60% dans la plupart des cas.
| Quorum | Majorité absolue | Majorité qualifiée |
| Nombre minimal de personnes requises pour entrer en phase de vote. | Plus de 51% des voix pour que la décision soit acceptée. | Plus de 60% (en général) des voix pour que la décision soit acceptée. |
Tableau récapitulatif des concepts de vote
Ces concepts étant définis, revenons au cas de Tezos pour comprendre leur utilisation dans cette période.
Au lancement du Mainnet de Tezos, le quorum défini était de 80%. On spécifie au lancement car dans les faits, le quorum évolue au fil du temps. Cette évolution sera expliquée dans la suite de l’article mais pour notre exemple, prenons ce quorum de 80% avec 100 personnes sur le réseau.
Dans Tezos, le quorum représente le nombre minimal de votes requis pour déclencher le mécanisme de validation des votes. Pour voter, il existe 3 types de vote:
- Yea : pour.
- Nay : contre.
- Pass : vote blanc.
En continuant sur notre exemple, prenons le cas où sur les 100 personnes, seulement 90 personnes ont voté (que ce soit Yea, Nay ou Pass) pour la proposal PROP_BOB_MIN_10_XTZ. Ce nombre de vote, 90%, est appelé ratio de participation. Comme ce ratio est supérieur au quorum défini, le principe de majorité qualifiée peut être appliqué pour valider les votes ou non. Dans le cas de Tezos, la majorité qualifiée est de 80% mais seuls les votes Yea et Nay comptent.
Prenons par exemple 90 votes = 75 Yea + 10 Nay + 5 Pass, alors 75 Yea + 10 Nay = 85 Yea_Nay. En utilisant le pourcentage de majorité qualifié, on a Nombre de Yea requis pour validation = 85 Yea_Nay * 80% = 68. Cela signifie que parmi les 90 votes, il faut au minimum 68 Yea pour que la proposal PROP_BOB_MIN_10_XTZ puisse passer en période de test. Dans cet exemple, on a bien 75 Yea >= Nombre de Yea requis (= 68): la proposal peut donc passer à la prochaine période appelée Testing.
Prenons un exemple d’un cas non passant : 90 votes = 20 Yea + 70 Nay + 0 Pass. En utilisant le pourcentage de majorité qualifié, on a Nombre de Yea requis pour validation = 90 Yea_Nay * 80% = 72. Or ici 20 Yea < Nombre de Yea requis (= 72). La proposal ne peut pas passer à la prochaine période : on retourne à la période Proposal.
Pour revenir sur l’évolution de la valeur du quorum évoquée plus haut, elle est mise à jour à la fin de cette période si la proposal a été acceptée en suivant cette formule :
Nouveau Quorum = Ancien Quorum * 80% + ratio de participation * 80%.
Dans notre cas, on aurait :
Nouveau Quorum = 80% * 80% + 90% * 80% = 82%, avec Ancien Quorum = 80% et Ratio de participation = 90%.
Lors d’une prochaine période où le quorum sera requis, ça sera cette nouvelle valeur qui sera utilisée.
Pour simplifier l’explication et les calculs, nous avons décidé de définir le vote de cette manière: 1 personne qui a voté = 1 vote. Mais il faut rappeler que le vote d’une personne a un poids qui est au prorata du nombre de tezzies qu’elle possède. Donc plus une personne aura de tezzies, plus son vote aura de poids. C'est comparable au vote lors d'une assemblée générale des copropriétaires : le poids de vote dépend de la superficie possédée.
La période Testing
Arrivé à cette période, la proposal PROP_BOB_MIN_10_XTZ va pouvoir être testée. Un fork est créé depuis la chaîne principale pendant 48 heures où est injecté le code de cette proposal. Cette injection est possible comme Bob a au préalable injecté le code en question dans son noeud lors de la période Proposal pour pouvoir soumettre son hash proposal : le code est alors automatiquement propagé dans le réseau aux autres noeuds. Pour information, cette chaîne vit en parallèle de la chaîne principale, le réseau principal doit toujours fonctionner.
Nous pouvons nous demander pourquoi cette phase ne dure seulement 48 heures alors que la période dure 22 jours. Le but de ce fork est simplement de vérifier que la migration de l’ancien protocole vers le nouveau fonctionne correctement. Dans le cas de cette proposal, il serait très facile de tester si la feature fonctionne en faisant une transaction dans le cas où l’utilisateur a moins de 10 tezzies ou plus de 10 tezzies mais en général les features sont plus complexes. Il serait donc idéal de prolonger la durée de vie de cette chaîne de test pour tester plus en profondeur et être sûr de la robustesse de ce nouveau protocole.
A l’heure où ces lignes sont écrites, la documentation de Tezos indique : “Testing period: a test chain is forked for 48 hours...”. Nous avons rencontré une partie de l’équipe de développeurs de Nomadic Labs et ils nous ont indiqué que la durée de vie de la chaîne de test a été étendue à la durée de la période de test, soit environ 22 jours, via la proposal Athens A qui sera présentée un peu plus tard dans cet article.
Il peut être intéressant d’aller vérifier soi-même dans le code source pour être sûr d’avoir la bonne information, même si ce n’est pas toujours évident de comprendre le code d'une autre personne.
Pour cette période, c’est le vote à la majorité qualifiée qui est utilisé. Si le vote ne passe pas, on retourne à la période Proposal, sinon on passe à la prochaine période.
La période Promotion Vote
Nous arrivons désormais à la toute dernière phase : c’est le vote final pour décider si la proposal PROP_BOB_MIN_10_XTZ va être acceptée ou non. Pour cette période, c’est le même principe de vote que l’Exploration Vote : il faut que le quorum soit atteint, c’est-à-dire 82% si on reprend notre exemple et qu’il y ait une majorité relative. A la fin cette période, le quorum est mis à jour et si la proposal est acceptée, elle sera directement activée sur le chaîne principale. Il ne sera pas nécessaire de faire une action manuelle pour que les noeuds du réseau récupère cette nouvelle feature, tout sera fait de manière automatique et transparente. C’est une des forces de Tezos : il n’existe toujours qu’une seule chaîne, en excluant la chaîne de test temporaire bien sûr, aucun fork n’est créé et la mise à jour est automatique. Dans d’autres blockchains, où un fork est possible, le choix du fork n’est pas toujours évident. Comme le dit très bien Arthur Breitman, il y aura forcément un fork qui sera gagnant par rapport à l’autre. De plus, une mise à jour manuelle du noeud devra être nécessaire, cela peut engendrer un coup en plus pour maintenir l'infrastructure. A la fin de cette étape, on repart dans tous les cas sur la période Proposal.
Bob peut être heureux, après presque 3 mois, sa feature est enfin active dans le protocole de Tezos. Mais qu’a-t-il gagné au final ? La réponse est assez simple. D’une part, en tant que développeur indépendant, il a pu faire évoluer la blockchain Tezos sans faire partie de l’équipe de développeurs de Tezos. D’autre part, il reçoit également une récompense en tezzies. Le montant de la récompense est écrite dans le code de la proposal qui a été initiée, c’est au développeur de décider du montant de sa récompense.
Pour l’histoire, le 28 février 2019, Nomadic Labs avait soumis 2 proposals :
- Athens B : augmenter la taille limite d’utilisation de gas.
- Athens A : les mêmes changements qu’Athens B + réduire la taille d’un roll de 10 000 XTZ à 8 000 XTZ (c’est ce qui a été décrit un peu plus haut dans l’article).
Voici un article rédigé par Nomadic Labs relatant les différents changements de ces deux proposals : https://blog.nomadic-labs.com/athens-our-proposals-for-the-first-voted-amendment.html.
Après presque 3 mois, le 30 mai 2019, Athens A fût acceptée et l’équipe de Nomadic Labs s’était fixée comme récompense 100 tezzies en cas de réussite :
Nous pouvons constater sur TzScan, un block explorer pour Tezos développé par OCamlPro, que le compte en question a bien une balance de 100 tezzies.
Conclusion
Athens A fût la première proposal qui a être intégrée automatiquement via ce processus d’auto-amendement. Ce premier amendement qui a permis à la blockchain d’évoluer démontre le fonctionnement du processus d'amendement de Tezos. Une seconde proposal nommée Babylon et développée par Nomadic Labs est actuellement en phase d’amendement et sera injectée dans le protocole fin octobre 2019 si elle est approuvée. Pour plus d’informations sur les nouvelles features apportées, vous pouvez consulter cet article.
Si l’on compare Tezos à d’autres blockchains, le fait que les mises à jour se fassent sans fork, cela permet d’éviter de mettre à jour soi même son noeud ce qui peut être fastidieux. Cela réduit les coûts de maintenance de l’infrastructure pour les possesseurs d’un noeud de et d’éviter de choisir entre les différents forks.
Il est important de noter qu’il n’est pas impossible de "hard forker" Tezos, bien que cela ne respecte pas la philosophie de Tezos qui est de faire évoluer le protocole via ce processus d’amendement. Pour l'anecdote, la société OCamlPro étant de plus en plus mise à l’écart du projet a décidé de faire un fork de Tezos nommé DUNE Network, fork qui n’a pas encore vu le jour.
Comme les nouvelles features sont intégrées via proposals, et donc potentiellement soumises par la communauté, il est assez difficile de définir une roadmap. Actuellement Nomadic Labs cherche encore à intégrer de nouvelles features mais encore faut-il qu'elles soient approuvées (via le système de vote) par la communauté.
Ici s’achève le premier article sur Tezos, le prochain sera publié fin septembre 2019 et portera sur le consensus de Tezos: le Liquid Proof Of Stake.