Marigold, un système de sidechains pour Tezos

Photo of author

By Alexandre Dupont

La scalabilité, ou capacité à passer à l’échelle, constitue aujourd’hui l’un des enjeux majeurs dans le monde de la blockchain et des cryptomonnaies. En effet, contrairement aux systèmes centralisés qui n’ont juste qu’à se munir d’équipements plus performants, les systèmes crypto-économiques comme Bitcoin, Tezos ou même Ethereum ne peuvent pas se permettre de subir une charge transactionnelle trop grande s’ils veulent rester pertinents, résistants à la censure. Le défi est donc de réussir à augmenter la capacité de traitement du réseau tout en conservant sa décentralisation et sa sécurité, c’est-à-dire parvenir à contourner le trilemme des chaînes de blocs, qui stipule qu’un système blockchain ne peut pas être à la fois décentralisé, scalable et sécurisé.

À cause de leur succès, Bitcoin et Ethereum subissent des congestions régulières caractérisées par des temps de confirmation plus longs et des frais de transaction plus élevés. Pour Ethereum, on se rappelle d’ailleurs de la fin 2017 lorsqu’une application décentralisée de collection de chatons numériques, CryptoKitties, avait paralysé la chaîne pendant des jours. Bien que Tezos soit épargné aujourd’hui, il n’échappera pas à la règle : si l’usage devait augmenter drastiquement, Tezos rencontrerait, à un moment ou un autre, également le même problème. Tezos a toujours su anticiper et palier les éventuels défauts expérimentés par les autres blockchains, notamment sur les sujets de gouvernance et de sécurité. Alors comment Tezos a anticipé celui de la scalabilité ?

Il existe trois manières principales de monter en charge :

  • Augmenter la taille des blocs : pour Tezos, cette méthode a récemment été appliquée avec l’amendement Athènes qui, entre autres, doublait la limite de gaz d’un bloc et faisait ainsi passer la capacité maximale du réseau de 6,67 à 13,33 transactions « classiques » par seconde. Néanmoins, cette méthode d’augmentation de la taille limite des blocs fonctionne dans une certaine limite, et n’a réellement de sens que dans le cadre où le prix des ressources informatiques disponibles baisse (« loi de Moore »).
  • Optimiser le protocole et son implémentation : améliorer la façon dont fonctionne le logiciel pour augmenter la charge à ressources égales. Pour Tezos, un exemple qui pourrait être appliqué prochainement est l’optimisation du stockage de l’état du système grâce à la version 2 de Irmin. Un autre exemple, cette fois-ci sur Ethereum, est le sharding dont la mise en place est prévue pour 2020 ou 2021, et qui pourrait démultiplier la capacité du réseau en répartissant la charge de calcul entre les différents nœuds.
  • Utiliser des solutions de seconde couche décentralisées en traitant les transactions en dehors de la chaîne principale. C’est le cas des canaux d’état, qui permettent l’exécution de contrats hors chaîne entre plusieurs participants et dont Tezos pourrait se servir à l’avenir. Ces canaux généralisent les canaux de paiements, qui sont notamment utilisés par le réseau Lightning déployé sur Bitcoin.

Le projet Marigold pour Tezos, rentre dans cette catégorie. Ce projet consiste essentiellement à construire des chaînes latérales (sidechains) fonctionnant en parallèle de la chaîne principale de Tezos. Nous allons voir dans cet article ce qu’il en est.

Plasma, MVP et Marigold

Plasma est une collection de contrats autonomes (smart contracts) standards utilisés pour créer des chaînes latérales sur Ethereum. Le concept a été proposé en août 2017 par Vitalik Buterin, co-créateur d’Ethereum, et Joseph Poon, co-créateur du réseau Lightning.

L’idée originale est de créer un arbre de chaînes latérales à partir de la chaîne principale, appelée chaîne « mère » ou chaîne « racine ». Chaque contrat autonome Plasma est utilisé pour créer et gérer une chaîne latérale. Des chaînes « filles » peuvent ainsi être créées à partir de la chaîne mère, et il est possible de faire de même à partir de ces chaînes filles pour créer des chaînes petites-filles, etc., de sorte à construire une multitude de chaînes liées.

Cependant, Rome ne s’est pas faite en un jour et mettre en œuvre Plasma est plutôt complexe de prime abord. C’est pour cela que les développeurs se sont tournés vers une version simplifiée de ce standard : le Plasma minimal viable, ou Minimal Viable Plasma en anglais, abrégé en MVP. Comme son nom l’indique, MVP est une variante de Plasma qui se limite aux fonctionnalités de base du protocole, c’est-à-dire aux paiements simples entre deux personnes. Cette idée a initialement été proposée en janvier 2018 par Vitalik Buterin, Joseph Poon et David Knott en janvier 2018 dans le cadre d’Ethereum. MVP sert de point de départ pour le développement de Plasma. Une version de MVP est d’ailleurs implémentée par l’équipe de recherche d’OmiseGO.

Marigold se veut être une solution de seconde couche qui sacrifie un peu la résistance à la censure au profit de la vitesse des opérations et de frais très faibles. Dans la version actuellement développée, il s’agit d’une variante du Plasma minimal viable. À l’avenir, il est possible que le projet se rapproche plus du Plasma généralisé (Generalized Plasma) mais nous nous concentrerons aujourd’hui sur la version existante.

Comment fonctionne Marigold ?

Marigold est aujourd’hui une variante du Plasma minimal viable et ne permet donc de réaliser que les opérations les plus simples de Tezos : les transferts de tez entre deux comptes. Nous allons voir comment fonctionne Marigold.

Une chaîne latérale Marigold est créée par le déploiement d’un contrat autonome correspondant sur la chaîne de Tezos. Ce contrat gère alors la chaîne Marigold, dans le sens où lui seul décide des règles que suivent les personnes interagissant avec la chaîne comme la procédure de dépôt, la forme des transactions, la procédure de retrait, etc.

En particulier, ce contrat détermine quel est l’opérateur de la chaîne. De manière générale, on parlera ici d’opérateur pour désigner le producteur de blocs de la chaîne, c’est-à-dire celui qui se charge de rassembler les transactions dans des blocs et de valider ces blocs. Contrairement à ce que cette appellation laisse à penser, l’opérateur n’est pas forcément un individu : il peut s’agir d’une entité unique certes, mais aussi d’une fédération d’acteurs ou encore d’un système de consensus par preuve de travail ou par preuve d’enjeu.

Néanmoins, la conception de Marigold (comme celle de Plasma) se base sur le fait que l’utilisateur doit toujours pouvoir récupérer ses fonds, même si les autres utilisateurs et l’opérateur se révèlent malveillants. Cela fait que des chaînes Marigold « privées » (soumises à une preuve d’autorité) pourraient voir le jour sans risque de vol pour l’utilisateur.

Voyons en détail une chaîne Marigold peut fonctionner. On omettra les frais de transaction par souci de simplicité.

Une utilisatrice, Alice, dépose des tez sur la chaîne Marigold en les envoyant au contrat avec une requête de dépot. Ses fonds sont bloqués par le contrat sur la chaîne principale et elle est créditée de l’équivalent sur la chaîne latérale.

Notons que, tout comme Bitcoin, Marigold utilise un système d’UTXO (pour Unspent Transaction Outputs, ou sorties transactionnelles non dépensées, qui peuvent être vus comme les pièces en circulation) : le dépôt d’Alice crée donc un UTXO de 2 tez contrôlé par elle.

Puis, Alice signe une transaction envoyant 1 tez à un autre utilisateur appelé Bob. Cela va créer deux nouveaux UTXO : une UTXO de 1 tez appartenant à Alice (elle se « rend la monnaie »), et un UTXO de 1 tez appartenant à Bob.

L’opérateur récupère cette transaction et l’ajoute aux autres transactions pour former un bloc. Il calcule ensuite la racine de Merkle de ce bloc et transmet cette racine (et uniquement cette racine) au contrat autonome sur la chaîne principale. L’opérateur envoie également le bloc à tous les utilisateurs de cette chaîne Marigold : Alice et Bob peuvent alors vérifier que leur transaction a été bien validée.

Enfin, Alice veut retirer ses fonds restants (1 tez) de la chaîne Marigold. Elle amorce une requête de retrait par le biais d’une transaction sur la chaîne autonome pour interagir avec le contrat (pas besoin de l’accord de l’opérateur). Elle fournit pour ce faire les données censées prouver qu’elle est légitime : son UTXO sur la chaîne Marigold, la hauteur du bloc qui le contient et le chemin de Merkle prouvant son inclusion.

Bien sûr il est possible qu’elle tente de tricher : c’est pour cela que la requête de sortie nécessite de mettre en jeu une caution de sortie définie par le contrat (ici représentée par 10 tez). Pour récupérer ses fonds, Alice devra attendre la fin d’une période de litige dont la durée est elle aussi déterminée par le contrat. Pendant cette période les autres utilisateurs pourront contester sa sortie s’ils détectent une fraude. À la fin de cette période Alice recevra ses fonds sur la chaîne principale et son UTXO de 1 tez sera détruit sur la chaîne Marigold.

Que se passe-t-il si Alice fraude ? Marigold, comme tous les autres systèmes de seconde couche décentralisés, se base sur un système analogue à un tribunal. Comme dans la vie réelle, les utilisateurs signent des contrats mais ont rarement l’occasion de se rendre devant la justice puisqu’ils se comportent bien de manière générale. Cela permet d’alléger considérablement la chaîne principale en ne traitant que les cas litigieux sur cette dernière.

Supposons qu’Alice veuille tricher en essayant de retirer sa sortie transactionnelle de 2 tez après qu’elle ait réalisé sa transaction avec Bob. Comme on l’a dit, Bob disposera de la période de litige pour contester cette sortie. Il devra pour cela soumettre une preuve de fraude au contrat (en fournissant la transaction et la preuve qu’elle a bien été incluse dans un bloc Marigold valide). Si cette preuve est correspond bien à la réalité, alors la sortie d’Alice ne sera pas faite et elle ne récupérera pas sa caution de 10 tez.

Ce système a néanmoins un défaut majeur : tous les utilisateurs doivent être des nœuds complets de la chaîne Marigold et doivent la surveiller en permanence pour détecter les tentatives de vol.

Que se passe-t-il si l’opérateur fraude ? Si la fraude de la part des utilisateurs est plutôt facile à traiter, celle provenant de l’opérateur est bien plus dure à gérer. L’opérateur est entièrement en charge de la production de blocs et peut y inclure ce qu’il veut.

Supposons par exemple qu’il inclue une transaction dans un bloc qui dépense 90 % de tous les tez présents sur la chaîne Marigold et qu’il demande de retirer ses fonds vers la chaîne principale. Puisqu’il est impossible de mettre en place un système de preuve de fraude dans ce cas-là, on est contraint de recourir à une solution extrême : l’évacuation générale (mass-exit). Tous les utilisateurs sont alors autorisés à retirer leurs fonds avant ceux de l’opérateur et ce pendant une période d’évacuation pré-définie. La priorité est alors donnée aux UTXO les plus anciens.

Théoriquement, cela fonctionne, mais cela pose des problèmes pratiques évidents. S’il y a une congestion sur la chaîne principale par exemple, certains utilisateurs les moins fortunés pourraient ne pas avoir le temps de retirer leurs fonds et les perdre définitivement. Outre ce risque, cela donne surtout à l’opérateur un grand pouvoir de nuisance en lui permettant de perturber toute l’activité du réseau.

Les caractéristiques de Marigold

Par rapport à MVP sur lequel il est basé, le projet Marigold présente un certain lot de différences.

Tout d’abord, Marigold mitige l’impact lié à l’évacuation générale par le biais de la délégation. Un utilisateur peut en effet déléguer la permission de sortie d’un UTXO à un autre utilisateur, pour qu’en cas d’évacuation générale, ses fonds puissent être mis en sécurité. De plus, Marigold prévoit d’implémenter un système de vote pour que les fonds soient transférés sur une autre chaîne Marigold plutôt que sur la chaîne principale.

Ensuite, du côté de la sécurisation de la chaîne, Marigold impose aux utilisateurs de vérifier des données précédentes à chaque opération de leur part. Cette mesure permet de limiter le problème lié au parasitisme des utilisateurs qui voudraient profiter de la sécurité de la chaîne sans y contribuer.

Enfin, Marigold pourra bénéficier prochainement d’un tout nouveau langage de programmation de contrats autonomes propre à Tezos : LIGO. Ce langage, développé en collaboration par Nomadics Labs et par le projet Marigold, est un langage permettant de développer des contrats autonomes complexes. En effet, s’il est possible de créer une chaîne Marigold avec Michelson, un langage de plus haut niveau possédant des fonctions spécialisées en facilite beaucoup le développement.

Pour ce qui est de l’avenir de Marigold, l’un des buts est d’améliorer la confidentialité des transactions avec des preuves à divulgation nulle de connaissance (ZK-SNARK), des schémas de mélanges de jetons ou encore du chiffrement homomorphique comme celui utilisé par AZTEC.

Un autre objectif est de rendre le protocole moins interactif (dans l’idéal non-interactif) pour que les utilisateurs n’aient pas à devoir surveiller la chaîne en permanence : cela pourrait se faire en utilisant des systèmes incitatifs, des canaux d’état ou par le biais de ZK-SNARK (comme le fait le protocole Coda).

Comme on l’a dit, Marigold pourrait également voir ses fonctionnalités se diversifier en ne s’inspirant plus du Plasma minimal viable, mais du Plasma généralisé. Cela lui permettrait de gérer tous les changements d’état plutôt que les simples transactions.

Conclusion

Marigold est un standard de contrats autonomes permettant de déployer une multitude de chaînes latérales sur le réseau Tezos. Marigold permettra à terme de traiter un très grand nombre de transactions sans affecter la décentralisation de Tezos. On estime que la capacité transactionnelle du réseau pourrait être multipliée par 100 !

Marigold est encore un projet hautement expérimental et fait toujours l’objet de recherches. Il ne sera pas implémenté de sitôt mais se développera sans doute beaucoup dans les années à venir.

Pour aller plus loin

Joseph Poon et Vitalik Buterin, Plasma: Scalable Autonomous Smart Contracts (livre blanc), 11 août 2017.
Daniel Goldman, Understanding Plasma, Part 1: The Basics, 7 février 2019.

Alexandre Dupont

Laisser un commentaire