By Bitcoin Magazine - il y a 6 mois - Temps de lecture : 6 minutes
Avant qu'ils ne soient cool : les engagements en production Nn Liquid
Depuis le Bitcoin La communauté s'est lancée dans des discussions autour de l'optimisation des clauses restrictives, il y a eu un intérêt croissant pour en savoir plus sur leurs compromis et les clauses déjà déployées sur le Réseau liquide.
À la lumière de ce regain d'intérêt et pour encourager de nouvelles discussions, passons en revue certaines des offres actuelles de Liquid, en les comparant aux principales propositions sur Bitcoin et examiner leurs cas d'utilisation respectifs.
Historique des engagements sur les liquides
Les Covenants sur Liquid remontent au déploiement de la première sidechain Elements, Alpha. Cette sidechain a introduit les opcodes OP_CHECKSIGFROMSTACK (CSFS) et OP_DETERMINISTICRANDOM ainsi qu'un certain nombre d'autres dans Elements. Alpha a également activé des versions corrigées des opcodes désactivés au début Bitcoin tels que OP_CAT— un opcode que beaucoup choisissent de revisiter dans le cadre du dialogue croissant sur les réseaux sociaux. Ces nouveaux opcodes ont encore amélioré l'expressivité de la version de Bitcoin Script disponible dans Elements et une preuve de concept Voûte Möser-Eyal-Sirer a été développé en utilisant CSFS pour illustrer les nouvelles possibilités.
L'un des enseignements tirés de la mise en œuvre du CSFS est qu'il rend les clauses restrictives plus complexes en exigeant que les données de transaction soient poussées sur la pile lors de l'exécution d'une dépense liée à une clause contractuelle. L'expérience des développeurs a également montré qu'avec les clauses CSFS, les données de transaction qui composent le hachage de signature doivent être reconstruites sur la pile, ce qui oblige potentiellement les développeurs à transmettre des données sans rapport avec les entrées/sorties de transaction qui les intéressent.
Pour simplifier la construction des alliances, plus de 30 nouveaux opcodes appelés opcodes d'introspection ont été introduits dans Liquid's Taproot améliorer pour une approche plus modulaire. Les opcodes d'introspection avec CSFS, par exemple, permettent d'inspecter des parties plus granulaires de la transaction lors d'une dépense en la plaçant sur la pile. Cela allège la responsabilité d'assembler des données de transaction partielles via le témoin et, par conséquent, le hachage de signature sur la pile.
Principales propositions du Pacte
Actuellement, la Bitcoin La communauté discute d'une longue liste de propositions d'alliances potentielles, notamment SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, l'opcode MATT OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT et OP_CHECKTEMPLATEVERIFY (CTV). Simplicité, un langage de script de nouvelle génération qui pourrait implémenter des fonctionnalités similaires à celles de nombreux covenants à un niveau inférieur, constitue également une voie potentielle pour Bitcoin (nous y reviendrons plus tard).
On a beaucoup parlé de l'opcode VAULT, qui a été créé pour répondre au besoin de moyens plus simples de sécuriser bitcoin pour les utilisateurs. Cet opcode permettrait de verrouiller les pièces dans une adresse qui ne peut être dépensée que vers deux adresses : un portefeuille chaud après un timelock ou immédiatement un portefeuille froid. Plusieurs autres variantes de schémas ont été proposées, mais elles dépendent d'abord de l'adoption du CTV.
CTV est un opcode qui lit 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é promet de permettre un ensemble diversifié d'applications, notamment : le contrôle de la congestion, les coffres-forts et les pools de paiement rudimentaires.
Outre les opcodes, il y a eu des propositions de sighashs pour activer 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 aussi. 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 à ses fonds lors de la diffusion d'un état de chaîne obsolète. Cela permet de créer un réseau Lightning plus convivial et plus efficace.
Obtenir des fonctionnalités similaires avec les opcodes liquides
Bien que Liquid n'ait pas les opcodes CTV et VAULT, il a CSFS et CHAT pour les alliances. En utilisant ces opcodes plus étroitement définis avec les opcodes d'introspection susmentionnés, les développeurs ont ouvert de nouvelles possibilités financières avec des fonctionnalités similaires à CTV et VAULT pour augmenter la sidechain.
Par exemple, Burak, développeur chevronné de Liquid et créateur du protocole de couche 2 Ark, a démontré une émulation de VAULT en utilisant les opcodes Liquid covenant dans une discussion avec James O'Beirne sur X.
De même, un moyen d'obtenir la fonctionnalité APO a été rendu possible avec CSFS. Ce demo a utilisé divers opcodes qui permettraient aujourd'hui des protocoles de couche 2 comme eltoo sur Liquid, mais souffre d'une complexité accrue et d'une taille de transaction plus grande par rapport à l'utilisation proposée du contrat de type APO. De plus, la construction ne s’applique pas aux transactions Taproot, ce qui introduirait sa propre forme de complexité supplémentaire.
Opcodes liquides en action
De nombreuses applications ont déjà profité des opcodes covenant sur Liquid. Steven Roose, un partisan du Pacte qui a récemment défini une spécification pour l'OP_TXHASH précédemment imaginé, a développé un application pour les obligations de fidélité sur Liquid. Cette alliance concerne les fonds qui seraient brûlés si la preuve d'une double dépense était présentée au témoin.
Argent FujiLe Fuji USD (FUSD) de , un stablecoin algorithmique développé par Vulpem Ventures, est un autre exemple notable. Il s'appuie uniquement sur les informations Oracle pour maintenir son ancrage et peut être émis de manière décentralisée. Il utilise un combinaison de vérifications de signature et d'opcodes d'introspection pour y parvenir, et le plus important est que tout est auditable sur la chaîne.
Les autres applications des covenants sur Liquid comprennent les contrats d'options et prêts confidentiels sur actifs. L'équipe de Blockstream Research a publié un whitepaper l'année dernière (voir ci-joint blog récents) à propos du premier, expliquant comment un tel contrat d'options pourrait être construit à l'aide du nouvel ensemble d'opcodes introspectifs. Ces nouveaux opcodes permettent aux utilisateurs de créer en toute confiance des jetons représentant les deux côtés d'un contrat d'option d'achat couvert et de vendre la position opposée qu'ils souhaitent prendre. Les contrats conclus de cette manière prennent également en charge les exécutions partielles, ce qui signifie que l'utilisateur qui a créé le contrat peut vendre des positions représentant un multiple d'un montant minimum spécifié par l'utilisateur de l'actif de garantie, appelé « taille du contrat ».
Pourquoi pas d’abord sur les liquides ?
L' Bitcoin L'écosystème continue d'avoir un débat sain concernant 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 fascinant d'assister à l'interaction entre BitcoinLes propositions natives de Liquid et les fonctionnalités déjà concrètes et actives liées aux alliances et l'émulation de Bitcoin propositions d'alliance mises en œuvre à l'aide d'Elements Script.
Une autre nouvelle technologie à l’horizon est Simplicité, un langage de programmation vérifiable pour le blockchain. Le langage Simplicity est défini par des opérations avec une sémantique très étroite qui peuvent créer des programmes expressifs lorsqu'ils sont composés ensemble. 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 aux opcodes covenant de Script d'être portés de manière transparente, garantissant une plus grande fiabilité et moins de comportements inattendus. Bitcoin chercheur Sanket Kanjalkar a déjà fait ce travail pour CTV. En utilisant argot, un plus lisible BitcoinLangage de programmation centré sur la simplicité, il a pu reproduire la sémantique dans une preuve de concept exploitable et accessible à tous aujourd'hui.
Bitcoin les développeurs 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 2. s-lang apportera la construction d'applications plus complexes à Liquid, telles que les coffres-forts et la délégation. Le projet de PR est disponible pour examen à l'adresse suivante lien.
Avec son longue histoire de Liquid en tant que l'un des premiers à adopter des idées qui ont ensuite été portées sur Bitcoin, une suggestion pour ceux qui cherchent à démontrer la viabilité de leurs propositions est de l'essayer en direct sur Liquid pour valider d'abord les idées, car il a été démontré que plusieurs opcodes liés aux covenants sont émulables à l'aide des opcodes Liquid covenant et d'introspection existants.
Ainsi, la prochaine fois que quelqu'un suggère une nouvelle alliance, cela vaut la peine de se demander : pourquoi ne pas l'essayer d'abord sur Liquid ?
Il s'agit d'un message par guest Randy Naar. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou Bitcoin .
Source primaire: Bitcoin Magazine