Les smart-contrats évolutifs sur Tezos

Jérémy Martin
December 6, 2023
Blockchain

L'innovation et l'adaptabilité sont des pierres angulaires de l'écosystème blockchain. Au cœur de cette évolution se trouvent les smart-contracts, des programmes autonomes qui exécutent une logique pré-implémentée comportant des possibilités de transferts de valeur. La puissance de cette architecture réside dans son inaliénabilité qui génère de la confiance, car paradoxalement mettre à niveau la logique des smart-contracts pourrait permettre de suivre des réglementations changeantes, de corriger des failles de sécurité, ou d'intégrer des améliorations fonctionnelles. Cette modularité est particulièrement précieuse pour mettre en place des dispositifs de mise à jour rapides et efficaces.

1- L’utilité des smart-contrats évolutifs

Les smart-contracts évolutifs, aussi appelés amendables, versionables ou upgradables, sont définis comme des smart-contrats dont on peut modifier dynamiquement la logique d'exécution. On entend ici une modification bien plus profonde que les modifications classiques que l’on peut appliquer à un smart-contrat, comme mettre à jour les variables ou les structures de données. En particulier, la création de nouvelles fonctions a toujours été un sujet complexe, car par défaut, la plupart de la logique interne doit être prédéfinie lors de la phase de création du smart-contrat, appelée aussi phase d’origination. Par exemple, dans le secteur financier, les tokens peuvent être mis à jour pour intégrer des mécanismes de conformité plus récents. Dans les applications décentralisées, les fonctionnalités peuvent être améliorées ou adaptées en fonction des retours des utilisateurs ou des évolutions du marché.

A- Un identifiant fixe

Le premier point fort est évidemment le fait que les contrats versionables permettent d’avoir une adresse fixe sur la blockchain, même en considérant des mises à jour logiques. Une adresse fixe est une sorte de Graal, car comme les vraies adresses ou par exemple les identifiants twitter, on peut mettre en place un système d’adressage bijectif, c’est à dire que chaque chaîne de caractère correspond à un unique point de chute. Cette correspondance forte a des propriétés très intéressantes qui peuvent être exploitées.

B- L’obtention d’une expérience utilisateur qualitative

Cette évolutivité assure également une meilleure expérience utilisateur, car les services peuvent être améliorés sans interruptions majeures. De plus, dans le contexte de la gouvernance décentralisée, elle permet une participation communautaire active dans l'évolution des protocoles, par exemple en mettant en place des systèmes de votes ou autre. Un autre aspect essentiel est la compatibilité avec les écosystèmes existants et la facilité de transition vers d’autres dispositifs de normes. Les smart-contrats évolutifs possèdent des mécanismes pour assurer une migration transparente et sans perturbation, permettant aux utilisateurs et aux smart-contrats existants de s'adapter facilement aux nouvelles versions.

C- La résolution fine de l’antinomie du droit à modifier

Il est important de noter que l’évolutivité d’un smart-contrat pose la question fondamentale : “qui a le droit de proposer, ou d’appliquer des mise à jour sur le smart-contrat, et par quel mécanisme de consensus ?”. Ici, on ne traitera pas cet aspect directement mais on peut noter que n’importe quel mécanisme de gouvernance peut être branché à ce type d’architecture technique. Par exemple, on pourrait penser naturellement à une DAO (organisation décentralisée autonome). La décentralisation est un principe fondamental et doit être bien calibrée. Tout système de smart-contrat upgradable doit respecter cet aspect, évitant la centralisation excessive du pouvoir ou du contrôle dans les mains de quelques-uns. Les smart-contrats évolutifs doivent élaborer des mécanismes de gouvernance pour les mises à jour des smart-contrats, permettant une participation équitable de la communauté.

2. Les contrats amendables sur Tezos

Dans le cas de la blockchain Tezos, que nous évoquons ici, l’évolutivité des smart-contracts est appelée aussi la 18ème proposition d’amélioration de Tezos  (Tezos Improvement Proposal 18 ou TZIP-18 en anglais). Dans cet écosystème, avec son modèle de gouvernance auto-amendable, notre architecture est particulièrement  pertinente, car la blockchain Tezos elle-même est auto amendable.

A. Les spécificités Techniques de Tezos

Tezos se distingue par ses mécanismes de gouvernance et de consensus innovants. Cependant, ces caractéristiques uniques posent des défis pour l'intégration de smart-contrats upgradables. La blockchain Tezos utilise un langage de smart-contract spécifique, le LIGOLang, qui nécessite une compréhension approfondie pour le développement de solutions upgradables. La proposition de smart-contrats évolutifs doit donc être conçue en tenant compte de ces particularités techniques, assurant une compatibilité totale avec l'écosystème Tezos.

B. L’équilibre entre Sécurité et Flexibilité

Un défi majeur réside dans l'équilibre entre la sécurité et la flexibilité. Les smart-contrats upgradables, par leur nature même, introduisent des vecteurs de risque supplémentaires, notamment en matière de sécurité des fonds et de l'intégrité des smart-contrats. La proposition smart-contrats amendables doit donc intégrer des mécanismes robustes pour prévenir tout abus ou faille, tout en conservant la flexibilité nécessaire pour les mises à jour. Pour les utilisateurs finaux, les smart-contracts upgradables signifient une plus grande confiance dans la durabilité et la réactivité des applications qu'ils utilisent. Ils bénéficient d'améliorations constantes et d'une assurance que les applications resteront compatibles avec les normes émergentes et les attentes du marché.

C. Performance et Optimisation

Les smart-contrats upgradables peuvent affecter la performance de la blockchain en raison de leur complexité accrue et du nombre d’appels supplémentaires pour gérer la logique d’évolutivité. L’utilisation des smart-contrats évolutifs est optimisée pour minimiser l'impact sur la vitesse de transaction et la charge du réseau, ainsi que les coûts d'exécution en gaz et les données sauvegardées sur la blockchain.

3. Aperçu de l'Implémentation de l’architecture

La proposition de smart-contrats amendables introduit une architecture et une méthode d'implémentation totalement innovantes. Cette section détaille les composantes clés de cette architecture. Le but est donc de pouvoir faire évoluer un smart-contract arbitraire en version 1 vers une certaine version 2 qui contiendrait des nouvelles fonctionnalités.

Notre système de smart-contrat évolutif repose sur une architecture modulaire, composée d'un smart-contrat appelé le proxy qui va transférer la demande de traitement à la bonne version fonctionnelle du contrat. En informatique, proxy signifie “intermédiaire”. Il possède en effet un rôle d’intermédiaire entre l’utilisateur appelant et les contrats comportant la logique effective du traitement demandé. On peut aussi le voir comme un module d’aiguillage entre les différentes versions qui comportent les mises à jour.

Le proxy agit comme un point d'entrée unique pour les interactions des utilisateurs, tandis que les smart-contrats auxiliaires contiennent la logique spécifique aux fonctionnalités et peuvent être mis à jour ou remplacés indépendamment. Le proxy délègue les appels aux smart-contrats appropriés et assure que les interactions restent fluides et sécurisées, même après une mise à niveau.

Le mécanisme de mise à niveau

Le système permet de déployer de nouveaux smart-contrats et de mettre à jour les références dans le proxy. Cette approche garantit que les améliorations peuvent être apportées sans interrompre le fonctionnement du smart-contrat. Il n’y a donc pas de rupture de service possible.

Les parties à suivre sont très techniques, et certaines idées ont été vulgarisées pour avoir un aperçu global du dispositif.

A. La contrainte des fonctions de transformation

Quand on passe d’une version 1 à une version 2, on passe aussi d’un état 1 à un état 2. Il faut donc définir une fonction de transformation. Par exemple, si une variable passe d’une plage de 1 à 10 à une plage de 1 à 100, il faut déterminer une règle de transformation, et la plupart du temps, il en existe une infinité. Dans notre cas on pourrait recopier la valeur initiale, ou lui ajouter 90, ou bien par exemple multiplier la valeur initiale par 10, et ces deux choix sont valides car on passe bien d’une plage de 1 à 10 à une plage de 1 à 100. Il s’agit maintenant d’une question de sens métier sur ce que représente cette valeur.

Il est obligatoire de mettre en place une fonction de transformation pour chaque donnée de chaque version de contrat. Ces fonctions doivent être implémentées dans le smart-contrat de version supérieur ( par exemple il faut implémenter dans le smart-contract version 3 la transformation de la version 2 en version 3 ).

B. La contrainte des mappings paresseux

Certaines classes de types de structures de données sont gérés de manière paresseuse, c'est -à -dire qu’il n’est pas possible de connaître leur valeur simplement, et en particulier il n’est pas possible de les copier, ni de les envoyer à d’autres fonctions ou messages. Cela est dû aux contraintes implicites sous-jacentes de l’architecture blockchain.

Pour résoudre ce problème, on ne va pas simplement transporter les données d’une version à la version suivante : la version successeur va prendre le contrôle complet de la version inférieure et l’utiliser comme une base de données fantoche. L’ancienne version zombie ne pourra plus recevoir d’appel ni utiliser sa logique, mais la fonction de transformation supérieure va pouvoir aller récupérer la donnée dans ses mappings paresseux, les qualifier et les transformer, puis les remonter dans le contrat de la version suivante.

C. La contrainte d’avoir une machine stricte

La machine à état d’assemblage utilisée pour le moteur de Tezos est basée sur le OCaml, et ne peut traiter que des smart-contrat compilés en Michelson. Ce langage est par construction strict au sens informatique du terme, c'est-à-dire que toutes les données sont fortement typées.

En particulier tous les appels de fonctions doivent être typés, et comme les points d’entrée du contrat proxy sont des fonctions, on doit savoir à l’avance tous les types de donnée. Or, cela est problématique dans notre cas car on ne sait pas à l’avance les données qu’on utilisera dans les versions futures !

La solution que nous proposons est de packer toutes les données dans un format générique, de type byte, et de dépacker les données à chaque appel, puis de matcher les données dépackés avec ce qu’attend la fonction. Si les données sont bien celles attendues, on peut continuer le traitement normalement.

En conclusion, cet article présente la notion des smart-contracts évolutifs et quelques-unes de ces contraintes, en se focalisant particulièrement sur la blockchain Tezos. Il illustre l'importance de l'adaptabilité dans l'écosystème blockchain, en mettant en avant le rôle crucial d’une architecture raisonnable dans l'évolution de la technologie.

Écrit par
Jérémy Martin
Research Director