Depuis que la communauté Bitcoin a entamé des discussions sur l’ajout des covenants (une sorte de condition de dépense), nous avons assisté à un regain d’intérêt à l’égard des covenants déjà déployés sur le réseau Liquid.
Nous allons donc en profiter pour examiner l’état actuel des covenants sur Liquid en les comparant aux principales propositions sur Bitcoin et en examinant leurs cas d'utilisation respectifs.
Historique des covenants sur Liquid
Les covenants sur Liquid remontent au déploiement de la première sidechain Elements Alpha. Cette sidechain a introduit les opcodes OP_CHECKSIGFROMSTACK (CSFS), OP_DETERMINISTICRANDOM et plusieurs autres dans Elements. Alpha a également activé des versions améliorées d'opcodes qui avaient été désactivés dans les premières versions de Bitcoin, tels que OP_CAT — un opcode jouissant d’un certain regain de popularité sur les médias sociaux. Ces nouveaux opcodes ont encore amélioré l'expressivité de la version de Bitcoin Script disponible dans Elements, ainsi permis une preuve concept du coffre-fort Möser-Eyal-Sirer développé en utilisant CSFS pour illustrer les nouvelles possibilités.
L'un des enseignements tirés de la mise en œuvre de CSFS est qu'il rend les covenants plus complexes en exigeant que les données de transaction soient transférées sur la pile lors de l'exécution d'une dépense. Il a été aussi observé qu'avec les covenants CSFS, les données de transaction qui constituent le hachage de la signature doivent être reconstruites sur la pile, ce qui peut obliger les développeurs à pousser des données sans rapport avec les entrées/sorties de la transaction qui les intéressent.
Pour simplifier la construction des covenants, plus de 30 nouveaux opcodes appelés opcodes d'introspection ont été introduits dans la mise à jour Taproot de Liquid pour une approche plus modulaire. Les opcodes d'introspection avec CSFS, par exemple, permettent d'inspecter de manière plus granulaire des parties de la transaction pendant une dépense en les plaçant sur la pile. Cela permet d'alléger l'assemblage des données partielles de la transaction via le témoin et, par conséquent, le hachage de la signature sur la pile.
Les différentes propositions
Actuellement, la communauté Bitcoin discute d'une liste de propositions de covenants potentielles, notamment SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, l'opcode MATT OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT et OP_CHECKTEMPLATEVERIFY (CTV). Simplicity, un langage de script de nouvelle génération qui pourrait mettre en œuvre des fonctionnalités similaires aux covenants à un niveau inférieur, est également une voie potentielle pour Bitcoin (nous y reviendrons plus tard).
Christian Lewe, de l'équipe Blockstream Research, présente Simplicity et explique comment son utilisation de combinateurs et de jets pourrait permettre l’utilisation de covenants populaires tels que CTV et APO avec un embranchement convergent.
On a beaucoup parlé de l'opcode VAULT, qui a été créé afin de faciliter la sécurisation des bitcoins pour les utilisateurs. Cet opcode permettrait de verrouiller les jetons avec une adresse qui ne peut être utilisée que pour deux adresses : un portefeuille connecté après un verrouillage temporel ou un portefeuille hors-ligne à tout moment. Plusieurs autres propositions ont été faites, mais elles dépendent de l'adoption préalable de CTV.
CTV est un opcode qui prend un hachage de la pile et le compare à un hachage d'un sous-ensemble spécifié des données de la transaction de dépense. Sa flexibilité permet de nouvelles applications, y compris, mais sans s'y limiter, le contrôle de la congestion, les chambres fortes et les pools de paiement rudimentaires.
Outre les opcodes, des propositions ont été faites pour que les sighashs puissent permettre les covenants. Les deux propositions les plus populaires à cet effet sont APO et SIGHASH_GROUP. APO est une évolution de l'opcode SIGHASH_NOINPUT, qui est largement reconnu comme une condition préalable à la mise en œuvre d'eltoo. L'une des nombreuses améliorations rendues possibles par eltoo est l'élimination du mécanisme de pénalité qui oblige l'autre partie à renoncer à des fonds lorsqu'elle diffuse un état de canal obsolète. Cela permet de rendre le réseau Lightning plus convivial et plus efficace.
Obtenir une fonctionnalité similaire avec les opcodes Liquid
Bien que Liquid ne dispose pas des opcodes CTV et VAULT, il dispose de CSFS et CAT pour les covenants. En utilisant ces opcodes avec les opcodes d'introspection susmentionnés, les développeurs profitent de nouvelles possibilités pour des processus financiers avec des fonctionnalités similaires à CTV et VAULT pour améliorer la sidechain.
Par exemple, Burak, développeur Liquid chevronné et créateur du protocole de couche 2 Ark, a fait la démonstration d'une émulation de VAULT à l'aide des opcodes Liquid lors d'une discussion avec James O'Beirne sur X.
De même, CSFS a permis d'obtenir la fonctionnalité APO. Cette démo utilise divers opcodes qui permettraient des protocoles de couche 2 comme eltoo sur Liquid, mais ajoute en complexité et augmente la taille des transactions par rapport à l'utilisation proposée de l'alliance de type APO. De plus, la construction ne s'applique pas aux transactions Taproot.
Les opcodes Liquid en action
De nombreuses applications ont déjà mis en œuvre des opcodes covenants sur Liquid. Steven Roose, un partisan des covenants qui a récemment défini une spécification pour l'OP_TXHASH, a développé une application pour les obligations de fidélité sur Liquid. Ce covenant est placé sur des fonds qui seraient brûlés si la preuve d'une double dépense était présentée au témoin.
Le Fuji USD (FUSD) de Fuji Money, une stablecoin algorithmique développée par Vulpem Ventures, est un autre exemple notable. Il s'appuie uniquement sur les informations de l'oracle pour maintenir son ancrage et peut être émis de manière décentralisée. Il utilise une combinaison de vérifications de signatures et d'opcodes d'introspection pour y parvenir et tout est vérifiable sur la chaîne.
Les contrats d'option et les prêts confidentiels basés sur des actifs sont d'autres applications des covenants sur Liquid. L'équipe de recherche de Blockstream a publié l'année dernière un livre blanc (voir l'article de blog qui l'accompagne) sur les contrats d’options, expliquant comment un tel contrat pourrait être construit en utilisant le nouvel ensemble d'opcodes introspectifs. Ces nouveaux opcodes permettent aux utilisateurs de créer des jetons représentant les deux côtés d'un contrat d'option d'achat et de vendre la position opposée qu'ils souhaitent prendre. Les contrats établis de cette manière permettent également des ventes partiels, ce qui signifie que l'utilisateur qui a créé le contrat peut vendre des positions représentant un multiple d'un montant minimum de l'actif collatéral spécifié par l'utilisateur, appelé "taille du contrat".
Apprenez s’en plus sur les conventions d'opcode disponibles sur Liquid et sur la façon dont elles permettent les swaps atomiques. La vidéo couvre l'histoire des swaps atomiques, donne des exemples de certains services et produits qui les utilisent et présente le code nécessaire pour faire ces types de covenants en utilisant une bibliothèque appelée LiquidJS.
Pourquoi pas sur Liquid ?
Alors que l'écosystème Bitcoin continue à débattre sainement sur les opcodes covenant, Liquid propose son propre ensemble d'outils, répondant à des objectifs similaires mais avec des implémentations distinctes. Au fur et à mesure que le dialogue évolue, il sera intéressant d'observer l'interaction entre les propositions natives Bitcoin et les fonctionnalités liées aux covenants déjà appliquées sur Liquid, ainsi que l'émulation des propositions de covenants Bitcoin mises en œuvre à l'aide d'Elements Script.
Une autre nouvelle technologie à l'horizon est Simplicity, un langage de programmation vérifiable pour la blockchain. Le langage Simplicity est défini par des opérations à la sémantique très étroite qui peuvent constituer des programmes expressifs lorsqu'elles sont assemblés. Le langage est également vérifiable, ce qui signifie que des méthodes peuvent être établies pour prouver mathématiquement les affirmations faites sur les programmes Simplicity.
La nature expressive de Simplicity permet de transférer à partir de Script, de manière transparente, les opcodes covenant ce qui garantit une plus grande fiabilité et moins de comportements inattendus. Sanket Kanjalkar, chercheur dans le domaine Bitcoin, a déjà effectué ce travail pour CTV. En utilisant s-lang, un langage de programmation plus lisible centré sur Bitcoin qui se compile en Simplicity, il a pu reproduire la sémantique dans une preuve de concept que tout le monde peut tester dès aujourd'hui.
Les développeurs Bitcoin auront bientôt la possibilité d'utiliser s-lang dans un environnement réel grâce à l'intégration de Simplicity par Liquid, prévue pour le deuxième trimestre 2024. s-lang apportera la construction d'applications plus complexes à Liquid, telles que les coffres-forts et la délégation. Le projet est acessible en suivant ce lien.
Liquid innove depuis longtemps et adopte des technologies qui sont ensuite portées sur Bitcoin. C’est une plateforme pour ceux qui cherchent à démontrer la viabilité de leurs propositions est de les essayer directement sur Liquid pour les valider - comme il a été démontré que de nombreux opcodes liés aux covenants peuvent être émulés en utilisant les opcodes d'introspection existants de Liquid.
Ainsi, la prochaine fois que quelqu'un proposera un nouveau covenant, il conviendra de se poser la question suivante : pourquoi ne pas d'abord l'essayer sur le Liquid ?
Une version précédente de cet article a été publiée sur Bitcoin Magazine: https://bitcoinmagazine.com/technical/before-they-were-cool-covenants-in-production-on-liquid