TECH TALK #2 — Mystères du Stateful UTXO : Le guide ultime du modèle comptable d’Alephium (et un peu plus !) — Partie 1
Une discussion avec Cheng Wang, inventeur du Stateful UTXO et fondateur d’Alephium
Cet entretien est le deuxième d’une série d’interviews sur les innovations techniques apportées au monde par Alephium. La discussion a été menée dans un format virtuel en présence de la plupart des membres de l’équipe Alephium qui ont contribué aux questions et à l’échange qui s’en est suivi. Le texte qui suit a été édité dans un souci de clarté, de concision et d’optimisation de la lisibilité et coupé en deux parties, la présente étant la partie 1. Il a déjà été précédé d’une introduction à sUTXO et de nombreux threads sur Twitter.
TL;DR — Une introduction sur les modèles de registres comptables / Qu’est-ce que le stateful UTXO / À propos des tokens comme citoyens de première classe / À propos des arbres de merkle, de la séparation des états contractuels et des actifs / La deuxième partie est à venir !
UNE INTRODUCTION AUX MODÈLES DE COMPTABILITÉ DE GRAND LIVRE
Vladimir Moshnyager : Bonjour Cheng, avant d’aborder notre sujet principal d’aujourd’hui, le stateful UTXO, j’aimerais commencer par un peu de contexte pour comprendre ce dont nous discutons. Pourriez-vous expliquer brièvement le modèle UTXO ?
Cheng Wang : Le modèle UTXO (Unspent Transaction Output) a été développé par Satoshi Nakamoto pour le bitcoin. Il s’agit essentiellement d’un système comptable que la première blockchain utilise pour contrôler les soldes en bitcoins.
Il reflète une transaction physique en espèces : chaque transaction comprend des entrées de l’expéditeur, le token à transférer, et des sorties, le montant envoyé au destinataire (sortie du destinataire) plus le solde restant des entrées initiales (sortie du changement). Ce solde est renvoyé à l’expéditeur sous forme de “monnaie”. La prochaine fois que l’utilisateur initiera une transaction, il pourra utiliser cet UTXO comme entrée.
Bien qu’il s’agisse d’un outil fonctionnel pour la comptabilité, il présente quelques inconvénients : il n’est pas le plus convivial et limite les possibilités de programmation, raison pour laquelle la plupart des blockchains utilisent aujourd’hui l‘account model pour le stockage des soldes, ce qui facilite la création de dApps.
VM : Quelles sont les alternatives au modèle UTXO ?
CW : Il existe deux grandes familles de systèmes comptables dans la blockchain : les différents systèmes UTXO et les account models. Du point de vue d’un développeur, le premier est caractérisé par ses propriétés d’immutabilité (UTXO), et l’autre est principalement utilisé pour ses qualités de mutabilité et d’expression (l’account model).
Lorsque Satoshi a inventé le bitcoin il y a 10 ans, il n’a pas été conçu pour le cas d’utilisation des dApps. Il est tout à fait naturel que d’autres développeurs aient ensuite proposé différents modèles pour contourner ce problème, comme l’UTXO étendu (eUTXO) popularisé par Cardano ou Ergo, le modèle cellulaire de Nervos et le modèle stateful UTXO (sUTXO) d’Alephium.
VM : Quels sont les problèmes posés par ces alternatives ? Pourquoi ne pas utiliser le modèle UTXO, l‘account model ou l’une des autres variantes d’UTXO ?
CW : La principale limite du modèle UTXO est sa propriété essentielle : l’immutabilité. Ce qui le rend extraordinairement sûr pour manipuler des actifs ne permet pas de construire des applications dessus, car il n’y a pas d’accès à “l’état” mutable.
À l’inverse, l‘account model (principalement popularisé par Ethereum) donne aux développeurs et aux contrats intelligents un large accès à toutes les informations stockées dans l’état et bien mieux, ce qui améliore considérablement l’expressivité.
Cette caractéristique permet la création d’applications décentralisées puissantes mais complique la sécurité. Un accès et une liberté excessifs ont souvent conduit à des conséquences désastreuses, et de simples bugs ont à plusieurs reprises causé des pertes financières importantes pour les utilisateurs sur de nombreuses chaînes basées sur les comptes en raison des difficultés à sécuriser efficacement les actifs.
Le modèle eUTXO est l’une des variantes d’UTXO les plus connues. Il a fait progresser la programmabilité du modèle UTXO en autorisant une logique arbitraire dans les scripts de verrouillage des UTXO. Bien qu’il préserve l’immutabilité du modèle UTXO classique, il soulève des défis lorsqu’il s’agit de l’exécution concurrente de transactions de contrats intelligents.
J’aime à la fois l’immutabilité, la sécurité et le déterminisme des ensembles UTXO, et les propriétés d’expressivité du modèle de compte, j’ai donc décidé de construire le stateful UTXO, qui combinerait le meilleur des deux mondes !
QU’EST-CE QUE LE STATEFUL UTXO ?
VM : Pouvez-vous nous dire plus précisément comment vous est venue l’idée du stateful UTXO ? Quel est le contexte et l’évolution qui t’ont conduit à l’inventer ?
CW : C’est l’évolution d’une idée ! En 2017 et 2018, j’étais concentré sur la façon de mettre à l’échelle une L1. C’est à ce moment-là que j’ai conçu l’algorithme de sharding Blockflow. Il était conçu pour être beaucoup plus simple que la feuille de route de mise à l’échelle (toujours changeante) d’Ethereum 2.0, et il était excitant, alors j’ai mis les mains dans le cambouis pour le construire.
J’ai réalisé que cela ne pouvait être réalisé qu’avec le modèle UTXO parce que le paradigme entrée-sortie et l’immutabilité sur la chaîne étaient cruciaux pour construire la structure de sharding. L’utilisation de l’account model aurait été impossible en raison de sa mutabilité et de l’impossibilité de paralléliser l’exécution des transactions.
Pendant l’émergence du DeFi en 2018, une autre caractéristique intéressante du modèle UTXO m’est apparue : un UTXO modifié pourrait potentiellement améliorer l’expérience des contrats intelligents en résolvant de nombreux problèmes de sécurité flagrants qui prévalent dans les machines virtuelles comme l’EVM et les langages de programmation comme Solidity.
En même temps, la DeFi summer a démontré au monde entier la puissance des applications décentralisées, et je voulais qu’il en soit de même pour Alephium. Par conséquent, l’expressivité de l’ensemble du système était un objectif dès le départ, mais jamais au détriment de la sécurité.
VM : Qu’entendez-vous par sharding et UTXO évolutif, et en quoi est-il plus évolutif que le modèle UTXO standard ?
CW : Notre architecture Blockflow fonctionne comme suit : Nous avons G groupes, puis nous avons G x G blockchains. UTXO est utilisé pour effectuer des transactions entre les groupes. C’est ce que j’entendais par modèle UTXO évolutif : il est basé sur le modèle UTXO, mais nous l’évoluons via le sharding à l’aide de l’algorithme Blockflow et les transactions peuvent se faire en parallèle sur la chaîne.
VM : Qu’est-ce que le modèle stateful UTXO et comment fonctionne-t-il à un niveau élevé ?
CW : La réponse en une phrase est que le stateful UTXO combine la sécurité des UTXO avec l’expressivité de l’account model.
Le concept de base est que l’account model est excellent pour créer et gérer des contrats intelligents, un accès global aux données et une malléabilité générale de la logique et de l’information. Mais cela présente des risques lorsqu’il s’agit de manipuler des actifs financiers.
En revanche, le modèle UTXO est très efficace pour gérer les actifs en toute sécurité, même s’il n’offre pas la flexibilité et l’expressivité dont les développeurs ont besoin et qu’ils apprécient lorsqu’ils écrivent des dApps utiles.
Le modèle stateful UTXO décompose le modèle comptable en deux parties : une partie est immuable et gère les actifs numériques, le code du contrat et les états immuables, et l’autre partie, les états mutables.
Cette structure distincte pour les actifs numériques permet davantage de vérifications et de garanties au niveau de la VM, assurant que toutes les opérations sur les actifs sont traitées correctement et en toute sécurité, tout en permettant aux développeurs de créer des dApps qui peuvent accéder à l’état et le mettre à jour avec des transactions de contrats intelligents.
VM : D’autres modèles UTXO apparus après Bitcoin prétendent également offrir la possibilité de fusionner les capacités de l’UTXO et de l’account model en un seul. Quelles sont les différences avec l’eUTXO (UTXO étendu, utilisé dans Cardano et Ergo) et le modèle cellulaire (utilisé dans Nervos), par exemple ?
CW : Tout dépend de la façon dont l’état est géré dans le modèle. Dans le modèle sUTXO, l’état est global et mutable, tous les contrats ayant accès à leur propre état. L’environnement d’exécution est vaste et englobe l’ensemble de la blockchain.
En revanche, dans les modèles eUTXO (Cardano, Ergo) et cellulaires (Nervos), les transactions sont sans état et ne dépendent que des entrées de la transaction ; elles sont donc faciles à valider, mais la concurrence peut poser problème.
VM : Avez-vous une idée de la raison pour laquelle il n’y a pas tant d’autres tentatives d’UTXO ? Il y a l’eUTXO, le modèle cellulaire de Nervos, le sUTXO d’Alephium, et peu d’autres. On a l’impression que tout l’espace s’est déplacé vers l‘account model. Avez-vous une hypothèse sur les raisons de cette évolution ?
CW : Si vous n’avez pas besoin de diviser le réseau, si vous ne donnez pas la priorité à la sécurité ou si vous n’innovez pas au niveau de la couche de base, l‘account model et la pile EVM existante constituent une excellente option. Il est beaucoup plus simple de démarrer, et vous pouvez utiliser le design EVM comme modèle et rester compatible avec les dApps EVM populaires. Cela vous permet de construire sur le travail des autres sans avoir à forker Bitcoin, qui a une base de code obsolète et est difficile à forker efficacement.
Le code de Bitcoin est complexe et exige que presque tout soit construit à partir de zéro, ce qui est un processus difficile et chronophage. La mise en place de l’infrastructure prend du temps, et c’est là le principal défi à relever. C’est presque aussi difficile que de créer un tout nouveau système d’exploitation, car il faut reconstruire de nombreux composants à partir de zéro.
Alephium a construit une telle infrastructure au cours des quatre dernières années, depuis la conceptualisation de l’algorithme de sharding, jusqu’à la construction d’une toute nouvelle machine virtuelle et la création d’un langage spécifique au domaine pour permettre aux développeurs de construire des dApps plus sécurisées….
LES TOKENS COMME CITOYENS DE PREMIERE CLASSE
VM : Le seul équivalent d’état sur les UTXO classiques est le token natif, mais avec Alephium, tous les tokens peuvent fonctionner nativement, dans les UTXO, sans conteneur. C’est pourquoi vous dites que ce sont des citoyens de première classe ? Pouvez-vous nous expliquer plus en détail comment cela fonctionne et ce que cela permet ?
CW : Cette fonctionnalité n’est pas propre à nous. Certaines blockchains modernes ont la capacité de prendre en charge des tokens intégrés au système, mais Bitcoin et Ethereum n’en font pas partie. Bitcoin ne prend pas en charge les tokens, tandis qu’Ethereum le fait par le biais de la norme ERC-20, une norme externe. Bien que cette norme soit utilisée pour émettre de nouveaux tokens par le biais de contrats intelligents, elle présente certains inconvénients et limitations.
Le premier problème est qu’il est difficile de concevoir de telles normes, et il existe de nombreuses normes différentes pour les tokens, telles que l’ERC-20 et l’ERC-777. Chaque fois que les gens trouvent une caractéristique qu’ils n’aiment pas ou qui manque, ils proposent quelque chose de nouveau, ce qui conduit à la fragmentation de l’écosystème. Il a fallu de nombreuses années pour que l’écosystème consolide les normes.
Le deuxième problème est que la sécurité de cette approche n’est pas aussi forte qu’elle pourrait l’être puisque la norme n’est pas la mise en œuvre. La norme se limite à quelques fonctions qui doivent être mises en œuvre dans le contrat intelligent, et il n’y a aucune garantie que ces fonctions seront mises en œuvre correctement, ce qui peut conduire à des piratages.
Le concept d’un token en tant que citoyen de première classe implique que la blockchain supporte nativement le token. Ainsi, de nouveaux tokens peuvent être émis en utilisant les fonctionnalités inhérentes à la blockchain. Cela résout le problème de la normalisation, car tout le monde utiliserait la même méthode pour émettre des tokens. Comme il s’agit d’une fonctionnalité intégrée, elle est largement testée sur la blockchain.
En outre, la blockchain peut ajouter des contrôles supplémentaires pour la gestion des tokens. Par exemple, nous avons un système de permission d’actifs pour tous les transferts afin de garantir que la machine virtuelle peut s’assurer que tous les transferts sont attendus (ou définis) par le contrat intelligent.
VM : Ne perdons-nous pas un peu de flexibilité ? Par exemple, les gens continuent d’inventer de nouvelles normes pour Ethereum. Des normes auxquelles ils n’avaient peut-être pas pensé auparavant. Par exemple, il y a le 721 pour les NFT, et puis il y en a un nouveau, le 1155. Si nous le souhaitons, pouvons-nous également construire un système de conteneurs sur Alephium ?
CW : Alephium est une plateforme qui permet de créer de nouvelles normes et de nouveaux tokens avec des caractéristiques supplémentaires. Toutefois, les fonctions essentielles d’émission, de transfert et de dépôt sont intégrées.
VM : Si les tokens sont natifs d’Alephium, cela signifie-t-il que je peux payer le GAS avec n’importe quel token ?
CW : Non. Dans notre conception, seul le token intégré peut être utilisé pour payer les frais de transaction (gas). L’utilisation de tokens arbitraires pour payer le gas peut s’avérer difficile car elle nécessite un oracle pour déterminer avec précision le prix du token avant la transaction. En outre, le fait d’autoriser des tokens arbitraires pour payer le gas peut rendre la conception et le code plus complexes, ce qui n’en vaut peut-être pas la peine. Au lieu de cela, l’utilisation du token intégré, ou token de blockchain, pour payer les frais de gas garantit qu’il y a une demande pour le token. Cela contribue à créer un modèle durable pour la plateforme.
VM : Cosmos a étudié la possibilité de payer le gas avec des UST à un moment donné.
CW : L’utilisation de stablecoins comme méthode de paiement des frais de transaction sur une plateforme blockchain a ses avantages et ses inconvénients et peut être intéressante pour de futures recherches. L’avantage est la stabilité. Cependant, si un stablecoin perd son peg, cela pourrait avoir un impact sur la fonctionnalité de la blockchain. Cela pourrait nécessiter des mises à jour de la blockchain pour supprimer ou ajouter les stablecoins comme forme de paiement valide, un processus qui peut être compliqué et prendre du temps.
A PROPOS DES ARBRES DE MERKLE, DE LA SÉPARATION DES ÉTATS CONTRACTUELS ET DES ACTIFS
VM : L’UTXO d’Alephium est appelé stateful UTXO. Pouvez-vous nous expliquer ce que signifie le terme “ état “ dans le contexte de la blockchain ? Pouvez-vous expliquer à quoi ressemble l’état d’Alephium ? Que contient-il et en quoi est-il différent des autres ?
CW : L’état peut être défini comme un ensemble de variables décrivant un certain système (dans ce cas, la blockchain Alephium) à un moment précis. Chaque action, comme une transaction entre deux adresses ou une interaction avec un contrat intelligent, crée/met à jour l’état.
En fait, dans Alephium, il y a plusieurs types de données contenues dans l’état : Les ensembles UTXO (décrivant les soldes d’adresses), la logique des contrats intelligents (les “programmes”) et les données des contrats intelligents. Tous ces éléments décrivent l’état d’Alephium et sont stockés dans des arbres Merkle.
VM : Pouvez-vous nous en dire plus ? Où l’état est-il réellement stocké, et comment ? Pourquoi plusieurs arbres de Merkle ?
CW : Tout est stocké dans deux arbres de Merkle distincts :
- Un arbre de Merkle concerne les actifs des UTXO,
- Le deuxième arbre de Merkle concerne les états des contrats et stocke des variables et des données telles que le prix du BTC ou de l’ETH dans le cas d’un oracle, par exemple,
Nous aurions pu placer cette logique dans le même arbre que les états du contrat, mais il s’agit de types de données différents. En les séparant dans des arbres différents, nous pouvons effectuer des optimisations spécifiques. Par exemple, l’état ou les données du contrat seront généralement beaucoup plus mutables que la logique du contrat.
Un autre avantage de la séparation est qu’un grand arbre de Merkle entraînerait des problèmes de performance IO (Read/write input) : il serait beaucoup plus grand et risquerait de devenir un goulot d’étranglement, car vous accéderez plus souvent à la base de données. De nos jours, l’un des principaux goulots d’étranglement d’une blockchain de contrat intelligent est l’IO.
VM : Alephium est une blockchain shardée. Comment les Merkle Trees sont-ils stockés ? Y a-t-il un arbre de Merkle distinct pour chaque groupe ou chaque shard ?
CW : C’est par groupe. Chaque groupe a des états distincts pour les données. Lorsqu’un bloc est exécuté, il accède à ces états de groupe et les met à jour.
Les dépendances de chaque bloc peuvent être vérifiées afin de s’assurer qu’il n’y a pas de bifurcation. Cela permet d’éviter les doubles dépenses, et c’est suffisant.
VM : Si mon Uniswap se trouve sur le groupe un, shard deux, est-il confiné à cet endroit ? Peut-il être consulté directement par quelqu’un qui se trouve dans le groupe trois, sur les shards sept ou douze ?
CW : Les États sont isolés. Vous ne pouvez pas accéder à un groupe différent de votre groupe actuel. L’accès direct pourrait entraîner des problèmes de synchronisation et irait à l’encontre de l’objectif du sharding.Si vous avez besoin d’y accéder, vous devez le stocker. Il y a donc un compromis à faire : la ségrégation des données augmente les performances, mais en même temps, vous perdez quelque chose.
Ethereum a mené quelques expériences sur les transactions cross-shard, mais elles ne sont généralement pas pratiques car elles nécessitent au moins un protocole de validation en deux phases, voire en trois phases. Au départ, vous verrouillez les états, puis la transaction est validée dans un shard et vous effectuez ensuite votre opération sur un autre shard. Une fois la transaction terminée, les changements d’état sont renvoyés vers le serveur d’origine. Cette proposition de Vitalik me semble trop complexe. Il est essentiel de trouver un bon équilibre lors du développement d’un système, et je ne pense pas qu’il soit idéal d’essayer de soutenir des conceptions trop compliquées.
VM : Comment résoudre ce problème ? Je suis un développeur de contrats intelligents, comment décider où je les place ? Quels sont les facteurs à prendre en compte ?
CW : Il existe différentes conceptions. L’une d’entre elles consiste à stocker toutes les données relatives à un contrat intelligent particulier dans un seul groupe. Les utilisateurs devraient transférer leurs tokens à une adresse au sein de ce groupe pour interagir avec le contrat.
C’est un peu comme le fonctionnement des banques aujourd’hui : vous pouvez avoir des comptes dans plusieurs banques, mais vous devez transférer votre argent dans une banque spécifique pour faire des affaires avec elle. Dans cette conception, les utilisateurs doivent d’abord transférer leurs tokens de leur adresse dans un groupe à une adresse dans le groupe qui héberge le contrat intelligent, puis ils peuvent interagir avec le contrat. Notre algorithme de sharding permet d’effectuer des transactions atomiques cross-shard en une seule étape, ce qui améliore considérablement l’expérience de l’utilisateur.
Une autre solution consisterait à déployer le même contrat dans tous les groupes, mais elle présente certaines limites. Si l’on prend l’exemple d’Uniswap, cela diviserait votre liquidité, ce qui rendrait potentiellement le capital moins efficace qu’avec un seul pool de liquidité. Toutefois, un teneur de marché pourrait probablement combler cette lacune et assurer une grande liquidité entre les différents groupes.
Si le pool de liquidité est suffisamment profond, le fait de le diviser en quatre groupes ne posera pas de problème. Nous avons également des applications qui ne sont pas sensibles à la liquidité et qui n’ont pas besoin d’un pool de liquidité centralisé. Dans ce cas, vous pouvez simplement déployer le contrat dans différents groupes pour qu’ils y aient accès.
VM : En bref, ce n’est pas un problème. Pouvez-vous nous en dire plus sur les actifs cross-shard natifs, c’est une fonctionnalité d’interopérabilité géniale qui est absente de la plupart des algorithmes de sharding L2 et autres algorithmes basés sur les comptes ?
CW: La prise en charge des actifs inter-chaînes/shards est une exigence critique pour les solutions de mise à l’échelle, et Alephium excelle dans ce domaine. Lorsque vous avez plusieurs chaînes/shards avec la capacité d’émettre de nouveaux crypto-actifs, le pontage de ces actifs entre les shards devient un défi. Les protocoles L2 nécessitent un transfert complexe à travers leurs chaînes principales ou des ponts supplémentaires entre les L2, ce qui peut être complexe et se traduire par une expérience utilisateur sous-optimale.
Les protocoles de sharding offrent généralement une meilleure interopérabilité, mais leur prise en charge des actifs transfrontaliers varie. Les protocoles de sharding basés sur l’account model, en particulier, rencontrent des difficultés pour prendre en charge les actifs cross-shard sur la chaîne en raison des états shardés. Dans de tels modèles, les états ne sont pas partagés entre les shards, ce qui signifie que l’état d’un shard ne peut pas être directement utilisé dans un autre shard.
Les chercheurs d’Eth Core travaillent activement dans cette direction, mais toutes les solutions s’accompagnent de compromis, affectant soit l’expérience utilisateur (UX), soit l’expérience développeur (DevX). Cependant, la conception du sUTXO d’Alephium prend en charge les actifs natifs entre les différents shards. Cela signifie que l’on peut transférer des tokens entre différents shards en une seule étape, sans nécessiter de ponts ou d’outils supplémentaires. Cette capacité offre la meilleure expérience de sharding pour les utilisateurs et les développeurs.
