Bitcoin Covenants: OP_CAT (BIP 347)

Ceci est le cinquième article dans un série Une plongée profonde dans les propositions individuelles de l’alliance qui ont atteint un point de maturité méritant une ventilation approfondie.

OP_CAT, avancé pour la réactivation dans Tapscript par Ethan Heilman et Armin Sabouri dans BIP 347, n’est pas une alliance. C’était un OPCode qui a été initialement inclus dans la première version de Bitcoin pour manipuler les éléments de données sur la pile. Il a été désactivé en 2010 avec la libération de Bitcoin 0.3.10 ainsi qu’un certain nombre d’autres opcodes en raison des préoccupations des attaques de déni de service qui pourraient écraser les nœuds. Une limite maximale globale de 520 octets pour tout élément individuel sur la pile lors de l’exécution d’un script a également été ajoutée.

Vous devriez déjà avoir une compréhension de base du fonctionnement de l’évaluation du script sur la pile et des éléments de base d’une transaction Bitcoin, donc il n’y a pas vraiment beaucoup d’explications de requis nécessaire pour OP_CAT.

Bien que OP_CAT ne soit pas une alliance en soi, il peut imiter les clauses d’alliances dues à une bizarrerie dans le fonctionnement des signatures Schnorr. Ceci est un sujet joli en profondeur, entièrement expliqué ici par Andrew Poelstra de Blockstream, donc je vais simplement m’en tenir à une vue de haut niveau. Chaque courbe elliptique a un point de générateur, qui est essentiellement «0», qui est utilisé dans la courbe elliptique mathématiques pour la génération de clés et la signature. Avec Schnorr, vous pouvez signer en utilisant le point de générateur comme clé, et donner ou prendre quelques octets que vous devez signer à plusieurs reprises pour bien faire, la signature résultante est en fait le même hachage de la transaction que vous avez signée.

Mettez de côté la mécanique de la façon dont cela fonctionne mathématiquement pour l’instant, et n’oubliez pas plus tard que ces signatures «étranges» vous permettent d’obtenir les transactions actuelles TXID sur la pile.

Comment fonctionne OP_CAT

OP_CAT prend les deux premiers éléments de données sur la pile et les concaténe ensemble. Donc, si les deux premiers éléments de la pile sont «1» et «2», OP_CAT les supprime, puis met «12» sur la pile. C’est ça.

Qu’est-ce que OP_CAT utile pour

D’accord, alors quel est le problème? Pourquoi tout le monde panique sur OP_CAT même s’il est si simple que l’explication de la façon dont cela fonctionne n’a même pas pris un paragraphe complet à écrire?

Deux raisons, bien que compte tenu de la nature de l’OP_CAT, je ne peux donner aucune garantie, ce sont les deux seules raisons. OP_CAT permet la construction et la vérification des arbres Merkle directement sur la pile, ce qui ouvre la porte à un comportement et à une fonctionnalité intéressants. Il permet également l’émulation d’alliances permettant une introspection granulaire complète en raison des signatures de Schnorr «étranges» mentionnées ci-dessus.

La vérification de la preuve de Merkle est un composant clé de la racine de tapoot, mais la façon dont il est implémenté la vérification de l’arborescence de Merkle ne se produit que dans le contexte de la vérification qu’un chemin de dépenses de tapiscript est engagé dans la clé publique Schnorr racine dans le script de sortie de la pièce dépensée. La tapoot ne prend pas en charge la vérification générique de la preuve de Merkle.

OP_CAT le permet de manière totalement générique. Le simple fait de fournir les hachages de feuilles (ES), puis les nœuds de hachage intérieur dans le bon ordre et appeler OP_CAT successivement vous permettra de reconstruire un hachage racine Merkle, et de vous comparer à un hachage prédéfini dans le script. Vous pouvez le faire pour fournir des chemins de retrait unilatéraux pour les utxos partagés comme dans CATVM, vous pouvez effectuer des transactions en fonction d’autres transactions ayant été incluses dans un bloc avec un travail valide, vous pouvez effectuer une transaction dépendante de presque toutes les conditions pouvant être vérifiées avec une épreuve Merkle.

Maintenant, pour l’émulation d’alliance qui permet une introspection complète. Ce que vous essayez de faire, c’est garantir qu’une transaction doit avoir certaines caractéristiques pour être valides. N’oubliez pas maintenant que la signature «bizarre» obtient le hachage de la transaction sur la pile. Une signature de transaction n’est pas réellement effectuée sur la transaction brute, elle est effectuée sur son hachage. Cela nous permet de faire quelque chose d’intéressant.

Vous pouvez construire des scripts très compliqués et alambiqués à l’aide d’OP_CAT pour prendre les pièces brutes individuelles de la transaction dans le cadre du témoin, et les assembler lentement sur la pile avec OP_CAT. En cours de route, des éléments individuels de la transaction peuvent être vérifiés par rapport aux hachages prédéfinis en les hachant et en utilisant OP_EQUAL. À la fin du script, vous avez la transaction complète sur la pile elle-même, et vous pouvez y ajoutant les données nécessaires, puis la comparer, en la comparant à nouveau avec OP_EQUAL, cette fois contre la signature «bizarre». Si ce chèque passe, un chigage normal peut être exécuté et tant que la signature «bizarre» a été effectuée avec la transaction dépensée, tout s’exécute comme valide.

Les vérifications OP_EQUAL des pièces individuelles de la transaction en cours de route garantissent que ces pièces de la transaction sont exactement ce qu’elles devraient être. Si l’un d’eux échoue à la vérification, la transaction n’est pas valide. Cela applique les alliances émulées. À la fin, si le hachage de transaction construit avec OP_CAT et la correspondance de signature «bizarre», le Final Checkssig garantit que la transaction construite avec OP_CAT et vérifiée par rapport à l’alliance imitée correspond à la transaction réelle dépensée à l’époque.

Réflexions de clôture

OP_CAT souffle ouvre les portes de l’introspection et les données transmises transportant complètement. L’introspection peut être accomplie à n’importe quel degré granulaire souhaité, chaque domaine individuel de la transaction étant capable de se livrer indépendamment. Il permet toutes les mêmes capacités introspectives que Txhash, puis certains.

La capacité de vérifier les preuves génériques de Merkle est également une fonctionnalité puissante, mais remet en question comment cette capacité sera utilisée et quel type d’incitations qui pourraient créer. Des scripts Bitcoin pourraient être construits nécessitant une transaction effectuée sur des systèmes de blockchain externes, tant qu’ils utilisent des arbres Merkle construits avec les fonctions de hachage disponibles dans le script Bitcoin.

Bien que OP_CAT ne soit pas lui-même une alliance, il permet une émulation complète des alliances avec une empreinte de blockchain beaucoup moins efficace (et un potentiel pour les développeurs de faire des erreurs et de brûler de l’argent). C’est une proposition selon laquelle, malgré le fait d’être incroyablement simple, devrait être approché avec prudence étant donné l’espace de conception massif qu’il ouvre.