Introduction

Vous avez peut-être entendu parler de la réactivation d’OP_CAT en tant que mise à niveau potentielle du langage de script de Bitcoin. Selon l'endroit où vous obtenez vos nouvelles, OP_CAT a été qualifié de « seulement 10 lignes de code », de « la meilleure façon de permettre l'expérimentation de covenants », de « trop puissant », de « dangereux et conduisant à une centralisation des mineurs » ou de « garanti de conduire à une fourchette souple controversée ». Je vais faire valoir que toutes ces perspectives sont erronées. OP_CAT est très utile, peut être utilisé comme un engagement, et non (à lui seul) comme le meilleur prochain mouvement pour Bitcoin. Rien de plus et rien de moins.

Pour cela, je vais explorer plusieurs sujets (apparemment disjoints), dont certains étaient nouveaux pour moi il y a quelques mois. Je vais essayer d'organiser cela de manière à fournir le contexte nécessaire en un seul endroit.

Comment et que fait OP_CAT

Introspection avec CAT

Abordons la question brûlante que beaucoup se posent lorsqu’ils sont exposés pour la première fois à OP_CAT. Comment quelques lignes de code combinant deux éléments de la pile en un seul (AB CAT -> AB) peuvent-elles permettre quelque chose d'intéressant ? Andrew Poelstra l'a expliqué avec éloquence dans des interviews récentes, et j'ai publié une explication brève et idiote :

Bitcoin est un peu bizarre, donc il peut aussi diviser les choses. Ensuite, SHA256 nous permet d'annuler les hachages. Ensuite, parce que la cryptographie n’est que mathématique et que nous savons comment la gérer, CAT nous permet d’extraire un hachage d’une vérification de signature. Et par conséquent, nous pouvons inspecter tout ce qui est haché dans une signature…

— Arrièreden | embrasser les fourchettes (@eardencode) 17 mai 2024

Le script Bitcoin étant strictement un langage de vérification, chaque opcode peut être utilisé en sens inverse ou direct. Un script peut recevoir un hachage et nécessiter une pré-image, ou recevoir une pré-image et nécessiter un hachage en utilisant OP_SHA256. Cet aperçu nous donne les deux premières parties du fonctionnement des clauses OP_CAT.

Si un script Bitcoin pouvait accéder à un hachage de la transaction qu'il vérifie, il pourrait exiger que la pile de dépenses fournisse la pré-image de hachage, la divise de la manière requise par le script, puis valide une partie particulière de cette pré-image. C’est exactement ce qu’est un engagement : valider une partie de la transaction en dépensant du bitcoin.

C'est très bien, mais Bitcoin n'a pas d'opcode tel que OP_TXHASH pour donner au script l'accès au hachage de la transaction. Ici, nous profitons de l'équation de vérification de signature BIP340 Schnorr pour exiger que l'utilisateur fournisse le hachage. Si l'utilisateur fournit une valeur qui sera un hachage de transaction valide si le script concatène l'octet 0x00 à la fin de celui-ci, cette valeur fera également partie d'une signature BIP340 valide (avec certains autres paramètres fixés) si le script concatène le l'octet 0x01.

La combinaison de ces techniques permet à OP_CAT de vérifier toute partie de sa transaction de dépense qui peut être signée, et même de revenir sur ses transactions parentes de certaines manières limitées. Avec un code soigné, on peut créer Purrfect Vaults, CatVM et bien plus encore.

Autres utilisations du CAT

Mais nous ne devrions pas. Construire ces choses avec OP_CAT entraîne des abominations difficiles à maintenir. Au lieu de cela, nous devrions utiliser OP_CAT pour ce à quoi il sert, et il y en a beaucoup : il permet l'équivalent de OP_CHECKSEPARATESIG, la vérification des preuves d'inclusion Merkle, la combinaison de données pour la vérification de signature avec OP_CHECKSIGFROMSTACK, et plus encore.

Problèmes avec le chat

Maintenant que nous savons ce que fait CAT, quel est le problème ? Pourquoi les gens (moi y compris) ont-ils dit que c’était une bête dangereuse ? En utilisant la technique d'introspection décrite ci-dessus, CAT permet deux constructions spécifiques : les dépôts de hachage et (soi-disant) les teneurs de marché automatisés (AMM). Jusqu’à récemment, ces deux éléments étaient considérés comme des risques importants liés à la centralisation du MEV vers le Bitcoin.

MEV, MEVil et centralisation des mineurs

Le terme MEV (Miner Extractable Value) est un peu déroutant. Dans l’interprétation la plus simple, cela inclurait les frais de transaction, que nous souhaitons bien sûr payer aux mineurs pour aider à garantir la sécurité du bitcoin à long terme. MEV est généralement utilisé pour désigner la valeur supplémentaire que les mineurs peuvent extraire de leurs blocs au-delà des frais visibles sur le réseau de relais public. Cela pourrait prendre la forme de paiements hors bande, de mineurs participant à des contrats et de réorganisation des transactions d'une manière qui leur favorise, ou même de vol pur et simple de biens et de services par des mineurs de blocs miniers qui réorganisent et doublent un paiement confirmé à un commerçant. Toutes ces formes de MEV peuvent être considérées comme généralement mauvaises pour les participants au réseau, car les mineurs utilisent leur position dans le réseau à leur propre avantage au détriment des autres participants du réseau. Cependant, le MEV à lui seul ne présente pas de problème systémique en favorisant la centralisation des mineurs, mais seulement un problème local pour les participants spécifiquement concernés.

MEVil est un terme qui est parfois utilisé pour désigner MEV qui pilote la centralisation des mineurs – je préfère le terme centralisateur MEV et je l'utiliserai à l'avenir. Plusieurs choses sont nécessaires pour transformer le MEV en MEV centralisateur :

1. Il doit être suffisamment difficile à extraire pour qu'un générateur de modèles de blocs open source ne puisse raisonnablement l'extraire.

2. La valeur totale extractible doit croître avec le taux de hachage Bitcoin d’un mineur

3. La valeur extractible doit justifier le coût de l'extraction

Si toutes ces exigences sont remplies, seul un mineur suffisamment important sera incité à commencer à extraire le MEV. Une fois qu’ils le feront, ils seront en mesure de dépasser la croissance de leurs pairs plus petits grâce aux revenus supplémentaires extraits. Plus l’extraction du MEV est coûteuse (au point qu’il n’en vaut la peine pour aucun mineur), plus la pression centralisatrice qu’il crée est forte.

Éviter de centraliser le MEV est alors (dans un sens) simple : assurez-vous que toutes les opportunités de MEV existantes sur Bitcoin sont soit si faciles à extraire que tout le monde le fait, soit coûtent plus cher à extraire qu'elles ne valent (soit parce qu'elles sont si petites, soit parce qu'elles sont si petites). parce qu'ils sont très chers).

Pour plus d'informations, consultez le message récent de @TheBlueMatt.

Hashrate Escrows (née Drivechains)

Il y a de nombreuses années (avant le Lightning Network ou des idées comme Ark, Timeout Trees, roll-ups, BitVM ou CatVM), les sidechains étaient considérées comme la solution de mise à l'échelle ultime pour Bitcoin. L'idée était conceptuellement simple : les blocs Bitcoin doivent rester limités en taille pour toutes les raisons habituelles de décentralisation, mais nous pouvons attacher des chaînes latérales au Bitcoin et celles-ci peuvent avoir des blocs plus rapides, des blocs plus gros, plus de calculs, ou autre. En pratique, cependant, la mise en œuvre de sidechains n’a pas été si simple. Le règlement final de Bitcoin est fondamentalement lié à une preuve de travail, un coût infalsifiable pour réorganiser les transactions, comment une sidechain en hérite-t-elle ? De plus, comment le bitcoin peut-il être transféré vers et depuis la sidechain ? La proposition la plus connue pour répondre à ces deux questions s'appelle Drivechains (BIP 300 et 301). Je ne vous ennuierai pas avec les détails des Drivechains, mais il suffit de dire qu'il n'y a que deux résultats à de tels systèmes de sidechain : soit ils sont relativement inutilisés (et donc inutiles), soit ils sont largement utilisés et deviennent de facto une taille de bloc. augmentation pour le bitcoin. Une augmentation de facto de la taille des blocs de ce type est une forme de centralisation du MEV où seuls les grands mineurs seront en mesure de participer de manière rentable aux opportunités de revenus supplémentaires offertes par les blocs de sidechain potentiellement importants et complexes.

Les dépôts de hashrate, qui peuvent être construits avec OP_CAT, ne constituent qu'une petite partie des propositions de Drivechains. Il s'agit d'un système de restriction des retraits des sidechains en utilisant un compteur dont la valeur ne peut être modifiée que par les mineurs, commence à une valeur élevée et doit atteindre zéro avant qu'un retrait sidechain puisse être traité. Il s’agit apparemment d’un transfert « sans confiance » depuis une sidechain, mais cela crée en réalité une fédération de mineurs contrôlant tous les bitcoins détenus dans les sidechains.

Depuis le développement des propositions Drivechains, il est devenu (à notre détriment) courant de désigner toute proposition pouvant être utilisée pour créer un retrait basé sur un compteur contrôlé par les mineurs sous le nom de « Drivechains ». Espérons que l'on comprenne à ce stade pourquoi ce raccourci inapproprié n'est d'aucune utilité : les chaînes d'entraînement sont soit sans valeur, soit dangereuses, mais les dépôts de hashrate ne sont qu'un moyen de transférer le contrôle du résultat d'une transaction à la fédération implicite de mineurs.

Jetons et AMM

Jetons

Pour des raisons qui ne me seront jamais tout à fait claires, les humains aiment les bons jetons (ou les mauvais jetons ou en réalité juste les jetons). Presque depuis le début du Bitcoin, on a discuté de la manière d'intégrer d'autres jetons dans le protocole, depuis les pièces colorées et la contrepartie, jusqu'aux plus récents actifs Taproot et runes. Tous ces protocoles ont une chose en commun : ils nécessitent un index externe des transactions Bitcoin qui soit connaît des données externes, soit traite les données de la séquence de transactions Bitcoin afin de déterminer les transformations des jetons au sein du protocole. Le point saillant de cet article est que les scripts de verrouillage Bitcoin ignorent complètement l'existence des jetons, et même les nœuds Bitcoin qui valident les transactions ignorent les jetons (c'est-à-dire même si un script de verrouillage Bitcoin avait un accès complet à l'ensemble complet de Bitcoin UTXO). , il n'a pu découvrir l'état d'aucun de ces jetons).

Teneurs de marché automatisés (AMM)

Sur d'autres systèmes de blockchain, il est courant que des contrats appelés AMM soient utilisés pour (par exemple) fixer le rapport entre deux jetons en achetant et en vendant à un prix fixe. Les règles qui peuvent être codées dans un AMM dépassent le cadre de cet article. Il suffit de dire que les AMM créent d’énormes opportunités pour le MEV et que les relations d’échange privées nécessaires pour maximiser les rendements de ce MEV centralisent également le MEV. Cela a souvent été utilisé comme argument contre la création de scripts Bitcoin plus expressifs – nous voulons sincèrement éviter d’exposer le réseau Bitcoin aux caprices de la centralisation du MEV. Cependant, comme je l’ai décrit ci-dessus, il n’existe tout simplement aucun moyen pratique pour les scripts Bitcoin, aussi expressifs soient-ils, d’évaluer l’état d’un jeton autre que Bitcoin. Les scripts Bitcoin ne peuvent pas localiser un sat rare. Ils ne parviennent pas à trouver un équilibre runique. Ils ne peuvent pas identifier un actif Taproot.

Sans accès à aucune information sur la disposition des actifs non Bitcoin, le concept même d'un AMM basé sur un script Bitcoin cesse d'avoir du sens. Les emplacements des jetons peuvent être attestés par une signature d'un oracle, mais les attestations d'oracle ne constituent pas un AMM. Ils peuvent être utilisés pour faciliter des métiers manuels spécifiques, mais pas pour un système automatisé durable. De plus, un tel système basé sur Oracle pourrait être construit aujourd’hui sans aucune modification du Bitcoin.

Conclusion

Comme vous pouvez le voir, espérons-le, CAT n’est pas une bête si effrayante. Ce n’est pas vraiment une bête du tout. Il n’a ni capacité infinie ni pouvoirs magiques. C'est juste un petit opcode qui peut être très utile. La seule chose que nous voulons probablement éviter est d'activer OP_CAT sans un autre moyen d'effectuer une introspection des transactions, comme OP_TXHASH, OP_TX ou les deux. Même son activation avec LNHANCE constitue une amélioration par rapport à OP_CAT seul, car elle réduit la taille et la complexité des scripts nécessaires à la réalisation de nombreux protocoles d'introspection OP_CAT.

Je pense qu'à ce stade, le "CAT introduit tout infini" a été réduit à ~ rien.

Il introduit une introspection utile d'une manière merdique que personne ne devrait utiliser. Pour aider les gens à ne pas l'utiliser, nous devrions activer CAT avec TXHASH ou similaire.https://t.co/nvnxYn66Um https://t.co/1Ag5TwjuUw

— Arrièreden | embrasser les fourchettes (@eardencode) 17 mai 2024

Ceci est un article invité de Brandon Black. 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 message OP_CAT et Infinite Nothing est apparu en premier sur Crypto Breaking News.