Est-ce que OP_CAT se produit ? La proposition de clauses restrictives vient de recevoir le numéro BIP #347. Mais avant d’approfondir, explorons ce que sont les clauses restrictives et pourquoi les Bitcoiners peuvent les vouloir.

Bitcoin est-il un état idéal de l'argent électronique numérique ou voulons-nous plus de nos pièces en chaîne ?

Gratter la surface : limites des scripts Bitcoin

Pour comprendre les propositions d'alliance comme OP_CAT, il est crucial de comprendre les limites fondamentales du Bitcoin Script tel qu'il est aujourd'hui. Sous le capot, Bitcoin permet la création de contrats intelligents de base via des codes qui définissent les règles de verrouillage et de déverrouillage des fonds. Cependant, Bitcoin Script, en tant que langage de programmation, est assez limité à une logique de base qui n'entre en jeu que lors du déplacement de pièces dans une nouvelle transaction.

Dans Bitcoin aujourd'hui, il n'existe aucun moyen de préconfigurer ou de dicter les chemins de transaction de vos pièces, ou la vitesse à laquelle les pièces peuvent se déplacer au moment où elles sont verrouillées (à part les flux de travail piratés utilisant PSBT, les transactions Bitcoin partiellement signées, qui ne peuvent pas correctement inclure les frais de transaction, prouver la suppression en cas de non-utilisation ou empêcher la diffusion ultérieure).

Cette simplicité, bien que essentielle au modèle de sécurité de Bitcoin, introduit des limitations importantes dans la capacité du langage de script à prendre en charge même les contrats intelligents de base.

Modèle d'exécution linéaire

Une limitation de Bitcoin Script est son modèle opérationnel dans lequel les opcodes sont exécutés séquentiellement sans boucles.

À partir de cet exemple de transaction P2PKH, vous pouvez voir comment le script s'exécute de manière linéaire : dupliquer la clé publique, la hacher vers une adresse, vérifier le hachage par rapport au script de verrouillage et enfin vérifier la signature par rapport à la clé publique.

L'absence de boucle signifie que les scripts ne sont pas complets et leur fin est garantie, évitant ainsi des problèmes tels que des boucles infinies qui pourraient potentiellement arrêter ou ralentir considérablement le réseau. Bien que ce choix de conception permette de limiter statiquement l’utilisation des ressources, il limite également la capacité de Script à gérer des flux de travail complexes.

Manque d'arithmétique de base

Bitcoin Script contient un peu moins de 100 opcodes non triviaux et, de manière quelque peu surprenante, il n'est pas possible de multiplier, diviser ou combiner des objets sur la pile. Comme le savent de nombreux utilisateurs intéressés par OP_CAT, Satoshi a désactivé plusieurs opcodes dans Bitcoin en 2010, notamment OP_OR, OP_MUL (multiplier), OP_DIV (diviser) et OP_CAT (concaténer), entre autres. Les opcodes désactivés ont été supprimés car leurs implémentations d’origine présentaient des vulnérabilités exploitables susceptibles de compromettre la sécurité du réseau. Mais l’absence de ces opcodes rend difficile les calculs de base, ce qui pourrait être utile dans des scénarios simples comme le calcul des frais de transaction dans un contrat.

Manque de visibilité des données de transaction

En apparence, je pense que la plupart des gens supposent que les contrats intelligents Bitcoin sont capables de voir les montants de valeur et toute autre partie des données de transaction, puisque ces informations sont déjà visibles publiquement sur la blockchain. Mais contrairement à cette hypothèse, les contrats sur Bitcoin ne sont pas en mesure de définir des conditions de dépenses basées sur les données de transaction, car Bitcoin Script a une capacité très limitée à consulter les données de transaction.

Si le script avait la capacité d'interpréter plus de détails dans les données de transaction, nous pourrions créer des contrats beaucoup plus robustes qui pourraient faire toutes les choses amusantes comme imposer des conditions de dépenses spécifiques, créer des transactions en plusieurs étapes et activer des fonctionnalités de sécurité plus avancées telles que des coffres-forts.

Que faisons-nous à propos de cela?

Nous savons que Bitcoin a ces limites et, au fil des années, de nombreuses propositions différentes ont été discutées pour introduire (ou dans certains cas réintroduire) cette fonctionnalité. Des expériences plus larges avec Bitcoin Script, telles que Simplicity et autres, visent à fournir une alternative aux contraintes basées sur la pile. Les opcodes comme OP_MULTISHA256, OP_LESS et OP_LE32TOLE64 visent à améliorer les capacités arithmétiques de Bitcoin. Les propositions comme OP_CTV et OP_CAT qui traitent des opcodes d'introspection sont regroupées sous le terme covenants.

Alors, quelle est exactement la différence entre les contrats intelligents et les nouveaux contrats à terme ?

Contrats intelligents et clauses restrictives

Les contrats intelligents sont des transactions auto-exécutables qui transfèrent des fonds sans intermédiaires. Dans Bitcoin aujourd'hui, les contrats intelligents se limitent à l'acte de verrouiller et de déverrouiller Bitcoin avec Bitcoin Script. Les clauses visent à améliorer la fonctionnalité des contrats intelligents de Bitcoin en permettant aux utilisateurs de contrôler la manière dont leurs fonds sont dépensés lors de transactions futures.

En permettant à Script d'interpréter les données de transaction, nous créons efficacement un moyen d'utiliser ces données dans la logique contractuelle.

Ce ne sont là que quelques-uns des opcodes d'introspection les plus intéressants pour la fonctionnalité des alliances :

  1. OP_TXHASH : fournit le hachage des entrées (ou sorties) d'une transaction et donne à Script la possibilité de vérifier et d'appliquer des conditions basées sur les données de transaction.

  2. OP_CSFS + OP_CAT : les deux permettent ensemble aux scripts de vérifier les signatures par rapport à n'importe quelle donnée, pas seulement à la transaction elle-même. Cela signifie que Script peut vérifier les conditions basées sur des données de transaction ou des informations externes, élargissant ainsi les possibilités de validation au sein des scripts Bitcoin.

Ces deux opcodes sont intentionnellement larges, permettant des processus de validation complexes et des capacités d'introspection. D’autres ont une portée plus restreinte et sont conçus pour constituer une forme d’engagement plus limitée.

  1. OP_CHECKTEMPLATEVERIFY (CTV) : permet à une sortie de transaction d'intégrer un modèle d'une transaction de dépenses future, permettant ainsi des engagements de manière plus contrainte.

  2. OP_VAULT : active une forme spécifique d'engagement utilisée pour le « coffre-fort », qui permet aux utilisateurs de spécifier une destination de transaction mais de ne pas déplacer réellement les pièces sauf après un délai.

Ensuite, il y a OP_CAT à lui seul, qui n’est pas directement un opcode d’introspection…

  1. OP_CAT : permet à Script de concaténer deux éléments sur la pile, ce qui est utile pour combiner différentes informations dans un script.

OP_CAT ne semble pas avoir de capacités d’introspection, alors que se passe-t-il ici ?

OP_CAT : découvrir toutes les possibilités

Introspection des transactions

En 2021, Andrew Poelstra a écrit sur les astuces d'introspection OP_CAT dans un article de blog. Il a fourni des exemples spécifiques, mais a présumé que les lecteurs avaient une connaissance préalable de techniques similaires. Ici, je vais tenter de simplifier cette explication pour une meilleure compréhension.

Dans Bitcoin Script, il n'existe que trois opcodes principaux qui vous permettent d'introspecter les données de transaction : CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY et CHECKSIG. De plus, il existe des variantes telles que CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG et CHECKMULTISIGVERIFY, qui sont essentiellement des variantes mineures de CHECKSIG. Les deux premiers vous permettent uniquement de voir si le contrôle est vérifié, offrant ainsi une fonctionnalité assez étroite. CHECKSIG est similaire, mais la différence ici est qu'il vous permet de récupérer la signature et la clé publique sur la pile. Intéressant.

Traditionnellement, nous considérons la concaténation comme une fonction qui relie deux éléments ensemble, mais nous pouvons également l'utiliser pour séparer ou diviser un élément, dans ce cas : la signature en une paire (r, s).

Comment dérivons-nous la fonctionnalité OP_SPLIT d’OP_CAT ?

« Si vous avez un gros objet, vous pouvez le diviser en deux en demandant à l'utilisateur de prendre du temps pour fournir les deux morceaux. Vous les CAT ensemble et vérifiez essentiellement l’égalité. Vous pouvez toujours inverser chaque opération de cette façon. Avec CAT seul, vous pouvez séparer les signatures. — Andrew Poelstra, TABConf 2021

Que se passe-t-il ici?

En demandant à l'utilisateur de fournir la signature, la clé publique et la transaction, vous pouvez diviser la signature en ses composants, puis vérifier chaque partie indépendamment par rapport aux données de transaction. Cette technique peut être considérée comme une forme de fractionnement ou de combinaison, car elle valide que la signature et la clé publique sont bien les composants d'une transaction valide.

Comment tout cela nous amène-t-il à l’introspection ?

« Dans Taproot, où nous avons des signatures Schnorr utilisant OP_CAT et l'opcode de vérification de signature Schnorr, il s'avère qu'il est possible d'obtenir une forme d'engagement non récursif dans lequel vous obtenez littéralement un hachage de transaction. Pas même comme un drôle de hachage de transaction mutilé, mais un hachage SHA2 littéral de toutes les données de transaction sur la pile. — Andrew Poelstra, TABConf 2021

Poelstra continue en démontrant comment obtenir un hachage SHA2 pour les entrées ou sorties de transaction laissées sur la pile. Nous allons sauter les calculs lunaires ici, mais l'implication est qu'avec OP_CAT nous pouvons contraindre certaines parties d'une transaction comme exigence du script de déverrouillage. Nous pouvons limiter l'adresse d'envoi ou la valeur envoyée pour cette transaction, le hachage de la transaction servant de clé pour la déverrouiller.

coffres

L'utilisation des mêmes techniques nous permet d'effectuer une introspection des transactions et nous donne rapidement une version de base des coffres-forts. Suivant la logique décrite dans le blog de Poelstra, un développeur du nom de Rijndael a prouvé que nous pouvions le faire avec OP_CAT seul dans son implémentation de Purrfect Vaults.

"Reconstruire un TXID sur la pile pour introspecter les transactions précédentes était en fait plus facile que prévu." -Rijndael

Avec les coffres-forts, les utilisateurs précisent la prochaine adresse à laquelle leurs fonds doivent être envoyés, fournissant ainsi des mécanismes de récupération des fonds en cas de compromission de clé et réduisant l'incitation au vol de clé privée.

Arbres Merkle pour script

Dans Bitcoin aujourd’hui, les Merkle Trees sont la structure de données utilisée pour la vérification des données, la synchronisation et plus ou moins « enchaîner » les transactions et les blocs de la blockchain. L'opcode OP_CAT, qui permet la concaténation de deux variables de pile, lorsqu'il est utilisé avec les hachages SHA256 de clés publiques, facilite un processus simple de vérification de l'arborescence Merkle pour les scripts. Cette approche, initialement proposée par Pieter Wuille en 2015, a été mise en œuvre avec succès dans le réseau Liquid.

Imaginez une structure arborescente regorgeant de diverses conditions de dépenses, telles que des préimages de hachage, des timelocks et des clés publiques, appelées signatures d'arborescence.

Signatures des arbres

OP_CAT permet la création de Signatures d'Arbre qui :

«…Fournissez un script multisignature dont la taille peut être logarithmique en nombre de clés publiques et peut encoder des conditions de dépense au-delà de n-of-m. Par exemple, une transaction d’une taille inférieure à 1 Ko pourrait prendre en charge des signatures d’arborescence avec un millier de clés publiques. Cela permet également des conditions de dépenses logiques généralisées. — Ethan Heilman, auteur du BIP, sur la liste de diffusion Bitcoin-dev

Cela permettrait la validation de tout contenu haché dans l'arborescence, en maintenant l'intégrité et la fiabilité des données sans ajouter de volume ou de surcharge inutile à la blockchain.

Qu’y a-t-il d’intéressant dans tout cela ?

Engagements récursifs

Si vous avez la possibilité d'examiner une transaction et d'appliquer des contraintes à certaines parties de celle-ci, vous pouvez définir des conditions qui se répercutent sur plusieurs transactions, créant ainsi une chaîne de restrictions continues. Ce concept est appelé alliance récursive. OP_CAT est une proposition unique car elle nous donne autant de puissance pour seulement 10 nouvelles lignes de code. Il a la capacité de répondre aux trois limitations initiales que nous avons évoquées au début de l'article : la visibilité des données de transaction, une meilleure fonctionnalité mathématique et son modèle d'exécution linéaire.

Même si OP_CAT peut sembler simple au premier abord, il libère un potentiel important lorsqu'il est exploité de manière créative. Il sert de base à encore plus de fonctionnalités bien au-delà de la portée de cette discussion, comme les signatures Post-Quantum Lamport.

Est-ce sécuritaire ?

Avant que OP_CAT ne soit initialement supprimé, lorsqu'il était combiné avec OP_DUP (dupliquer) et utilisé de manière répétitive pour dupliquer une valeur initialement de 1 octet sur la pile, l'utilisation de la mémoire pouvait exploser. Cela aurait pu être utilisé comme une attaque par déni de service (DoS) en raison d'une consommation accrue de mémoire. La nouvelle proposition empêche trivialement cette attaque en imposant une limite de 520 octets aux éléments de la pile.

Y a-t-il un risque qu’un contrat soit éternel ?

Si nous entendons par là, OP_CAT modifie-t-il le modèle d'exécution du script pour signifier qu'il ne limite plus statiquement son utilisation des ressources (en fonction linéaire de la taille du script) ? Non.

Les engagements créeraient-ils un marché pour d’autres pièces en plus du Bitcoin ?

Si vous avez un engagement récursif, oui, vous pouvez techniquement créer des applications complexes de couche 2, notamment des NFT, des échanges décentralisés et des chats quantiques. Cependant, cela n’est pas anodin. Il est difficile d’imaginer qu’un marché sérieux fasse cela.

Pouvez-vous « altérer » de manière permanente les pièces en utilisant CAT ?

Dans le cas des pièces colorées et des NFT, en émettant ces actifs, l'utilisateur « brûle » effectivement un satoshi, le marquant d'une manière qui signifie la propriété de l'actif de « couche 2 ». Ce processus est connu sous le nom de « altération » des pièces de monnaie. Mais seul le propriétaire d’une pièce peut marquer sa pièce, et les portefeuilles Bitcoin ne la reconnaîtront plus (à moins que leurs auteurs n’ajoutent explicitement du code pour l’activer). Les pièces résultantes ne seraient pas acceptées par les portefeuilles Bitcoin. Ils seraient probablement acceptés par les portefeuilles cryptocat ou quelque chose comme ça, mais cela n'a pas d'importance pour la plupart des utilisateurs de Bitcoin.

Cela créerait-il un problème MEV sur Bitcoin ?

Un point clé de distinction entre Bitcoin et Ethereum est la visibilité des transactions. Contrairement à Ethereum, tous les aspects du contrat ne sont pas nécessairement transparents, ce qui signifie que les mineurs de Bitcoin n’ont pas la même capacité à voir l’état du contrat interne et à les anticiper.

La principale préoccupation d'OP_CAT par les Bitcoiners soucieux de l'économie est le potentiel de valeur extractible par les mineurs (MEV). Comme discuté plus en détail dans mon précédent article sur le sujet. De nombreux utilisateurs craignent que si nous rendons les contrats de couche 2 techniquement possibles, le MEV deviendra inévitable. Mais est-ce vrai ? Plus précisément, la faisabilité technique des pièces de couche 2 sur Bitcoin implique-t-elle leur création et leur adoption inévitables ?

Vous pourriez imaginer créer de simples contrats de swap ou des NFT relativement inefficaces, mais construire quelque chose d'aussi complexe que des DEX avec des teneurs de marché automatiques semble extrêmement improbable et n'est jamais quelque chose que nous avons vu sur Liquid malgré la « possibilité technique » de cela.

Alors OP_CAT est-il vraiment parfait ?

A peine, loin de là. Certaines personnes aimeraient voir des clauses récursives, tandis que d’autres ne veulent tout simplement pas voir Bitcoin changer du tout.

Une faction de Bitcoiners, les «ossificationnistes», plaide pour la préservation du Bitcoin dans son état actuel et considère toute mise à niveau du protocole avec scepticisme. Ils craignent particulièrement que des changements importants, comme l’introduction de clauses, ne compromettent la décentralisation du réseau. Leur argument repose sur la conviction qu’il est préférable de s’en tenir étroitement à la vision originale de Bitcoin. L’ironie étant qu’OP_CAT faisait initialement partie de Bitcoin, alimente un contre-argument. Certains pensent que le retour d’OP_CAT pourrait en fait réaligner Bitcoin avec la vision initiale de Satoshi.

Si vous souhaitez voir certaines des fonctionnalités de sécurité que les clauses récursives pourraient rendre possibles, OP_CAT serait bien, mais certainement pas aussi bien qu'un langage de script à part entière de type Lisp. Le problème ici est qu’il s’agirait d’un changement massif pour Bitcoin, qui ne trouvera probablement pas sa place de sitôt.

Ou peut-être que vous êtes à l'autre bout du fil et que vous préféreriez la simplicité des éléments non récursifs comme OP_CTV ou OP_VAULT. Les clauses non récursives sont plus simples et plus faciles à raisonner, sans risquer de créer une chaîne de contraintes incontrôlée.

Et si une version des clauses récursives était inévitable ?

Au fil des années, les développeurs ont remarqué que presque toutes les extensions de la logique de validation des transactions pouvaient être utilisées pour émuler les fonctionnalités d'OP_CAT.

Dans l'univers Script, il existe deux domaines, basés sur la taille des éléments de la pile. Pour les éléments de pile de plus de 4 octets, vous pouvez comparer l'égalité, interpréter une signature comme clé ou la hacher. Pour les éléments de pile inférieurs ou égaux à 4 octets, vous pouvez les traiter comme des objets permettant d'effectuer des opérations arithmétiques ou de branchement. Avec un processeur RISC-V exécuté sur un BitVM, vous pouvez littéralement tout faire. Tout ce qui vous permet d'émuler OP_CAT, de diviser des éléments de pile ou de les concaténer réunit ces deux domaines, afin que vous puissiez « faire n'importe quoi » avec Script.

Des chercheurs comme Andrew Poelstra s'attendent à ce que nous puissions créer des alliances récursives avec à peu près n'importe quel nouvel opcode. Si cela est vrai, cela justifierait la recherche d’un moyen de bien les faire.

OP_CAT est-elle la voie à suivre probable pour les alliances ?

Si les engagements ne sont pas seulement intéressants, mais inévitables, comment pouvons-nous garantir qu’ils sont mis en œuvre de manière à ce que davantage d’utilisateurs de Bitcoin envoient sans confiance, comme Satoshi l’avait initialement envisagé ? Même si les ossificationnistes restent divisés, OP_CAT continue de s’imposer comme un concurrent sérieux dans le débat sur les alliances.

OP_CAT n'est pas le ciseau le plus élégant, mais c'est celui avec le meilleur rapport puissance/complexité, ce qui permettrait aux développeurs de créer de nouvelles fonctionnalités étonnantes.

Ceci est un article invité de Kiara Bickers. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.

Source : Bitcoin Magazine

Le post OP_CAT : La solution idéale pour les alliances ? est apparu en premier sur Crypto Breaking News.