Est-il vraiment surprenant, étant donné que les chats ont essentiellement dominé Internet au cours des deux dernières décennies, que les mèmes de chats aient finalement envahi l’espace Bitcoin également au cours des dernières semaines ? Les chats sont le mème le plus viral sur Internet, il n’est donc pas du tout choquant que les sorciers Taproot se soient penchés sur lui, renforcés par le trolling Luke sur ses « choix alimentaires ».
La question doit cependant être posée : les campagnes mèmes sont-elles vraiment la façon dont nous voulons procéder pour décider et discuter des changements consensuels apportés à un protocole aussi précieux que Bitcoin ? J’ai vu de nombreux clips vidéo, des campagnes pour sortir dans le monde et « éduquer » les gens sur OP_CAT, et tout le système « Quest » lancé par Taproot Wizards… mais la réalité est que la grande majorité de ce contenu que j’ai ce que j’ai vu a été incroyablement superficiel.
Rijndael, « Artificier » chez Taproot Wizards et l’une des rares personnes, sinon la seule, à bricoler et à jouer avec OP_CAT pour créer des exemples de cas d’utilisation, a réalisé une démonstration d’un script de convention basé sur OP_CAT.
Ce script impose l’envoi d’une quantité spécifique de Bitcoin à une adresse spécifique, et par consensus, il n’existe aucun autre moyen de dépenser ces pièces sauf avec une transaction qui répond à ces conditions exactes. Regardez la taille de ce script :
OP_TOALTSTACK OP_CAT OP_CAT OP_CAT OP_CAT de890a8209d796493ee7bac9a58b62fbced10ccb7311e24f26c461c079ead08c OP_SWAP OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT 54617053696768617 368 OP_SHA256 OP_DUP OP_ROT OP_CAT OP_CAT OP_SHA256 424950303334302f6368616c6c656e6765 OP_SHA256 OP_DUP OP_ROT 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2 815b16f81798 OP_DUP OP_DUP OP_TOALTSTACK 2 OP_ROLL OP_CAT OP_CAT OP_CAT OP_CAT OP_SHA256 OP_FROMALTSTACK OP_SWAP OP_CAT OP_FROMALTSTACK OP_DUP 1 OP_CAT OP_ROT OP_EQUALVERIFY 2 OP_CAT 79be667ef9dcbbac55a06295ce870b07 029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG
C’est ce qu’il faut pour émuler CHECKTEMPLATEVERIFY. Le script équivalent utilisant CTV serait simplement :
CTV.
Je demande quelle est la valeur de quelque chose comme OP_CAT pour émuler le cas de modèles de clauses de base (des choses nécessitant qu’une transaction de dépense remplisse certaines conditions définies à l’avance pour être valides) comme celle-ci ? Nous savons exactement comment gérer les systèmes appliquant un modèle aux transactions dépensant une sortie verrouillée sur un engagement de modèle, et avons plusieurs propositions pour eux. CTV, TXHASH, OP_TX et même APO peuvent émuler ces schémas en insérant une signature dans la sortie de verrouillage d’une transaction au prix de 64 octets supplémentaires.
Quelle est l’utilité réelle d’OP_CAT pour « expérimenter » pour répondre aux besoins d’une classe de cas d’utilisation dont la conception est suffisamment mature pour qu’il existe au moins 4 propositions d’engagement qui peuvent gérer ces cas d’utilisation avec une infime fraction du coût des données ? « Oh, nous voulons expérimenter CAT parce qu’il est flexible ! » Vous souhaitez utiliser 30 appels OP pour faire quelque chose qui peut être fait en un seul ? Est-ce une raison pour adopter un changement consensuel en faveur du Bitcoin ? La logique de cela est plus qu’absurde.
Minimiser les risques
Dans le vide, OP_CAT est vendu comme « une simple concaténation de deux chaînes », et de nombreux mèmes tentent de le formuler comme « en quoi cela peut-il être dangereux ? Il s’agit d’un récit extrêmement fallacieux entourant la proposition, et il ignore complètement la façon dont elle interagit avec d’autres aspects existants et futurs du scénario.
En particulier, CSFS + CAT ouvre une énorme quantité de possibilités en termes de ce qui peut être fait avec le script Bitcoin, mais toutes ne sont pas nécessairement positives. CSFS vous permet de vérifier une signature sur un élément de données arbitraire au cours de l’exécution d’un script, et CAT vous permet de « coller » différents éléments de données ensemble sur la pile. Ces deux choses créent un massif espace de conception pour ce qu’il est possible de faire avec Bitcoin.
Un exemple concret serait la possibilité d’imposer des montants, ou des relations entre différents montants, d’entrées et de sorties spécifiques dans une transaction. CAT vous permet de créer un hachage de transaction à partir d’éléments individuels de la pile, et CSFS vous permet de vérifier une signature par rapport à une clé publique dans le script de verrouillage par rapport à des éléments arbitraires de cette transaction au fur et à mesure de sa construction. Cela pourrait à terme permettre la création d’UTXO à durée indéterminée que tout le monde peut dépenser, à condition que la transaction de dépense réponde à certains critères, comme l’envoi d’un montant spécifique de pièces à une adresse spécifique. Combinez cela avec la réalité des actifs basés sur OP_RETURN, et cela commence à entrer sur le territoire des échanges décentralisés (DEX).
Certains des pires problèmes de distorsion des incitations qui se sont concrétisés sur d’autres blockchains proviennent en fin de compte de la création de DEX sur ces chaînes. Disposer d’une fonctionnalité d’échange directe et non interactive sur la blockchain est l’une des pires formes de MEV, en particulier lorsqu’il existe la possibilité pour les mineurs de verrouiller leurs bénéfices sur plusieurs transactions au cours d’un seul bloc, plutôt que d’avoir à supporter réellement les bénéfices. risque d’une position sur plusieurs blocs avant de la clôturer et de réaliser un profit.
Une partie du mouvement derrière Taproot Wizards consiste à « ramener l’innovation ». C’est-à-dire que les leçons apprises au pays du shitcoin reviennent au Bitcoin, même si je rejette fermement l’idée selon laquelle quoi que ce soit d’utile ait été développé sur d’autres pièces au cours de la dernière décennie autre que le concept de base de zéro preuve de connaissance, ce mantra qui devient de plus en plus fort ignore un énorme élément de cette dynamique, même si vous n’êtes pas d’accord avec mon point de vue : il y a des leçons à tirer sur ce qu’il ne faut PAS faire ainsi que sur ce qu’il faut faire.
Les DEX font partie des choses à NE PAS faire. Rien n’a provoqué autant de chaos, de volatilité dans la dynamique des frais (que nous devons atténuer au fil du temps pour la durabilité des deuxièmes couches), et tout simplement un chaos d’incitations concernant les couches de consensus de base de ces protocoles et leur degré de centralisation. L’idée selon laquelle nous devrions nous précipiter pour apporter ce type de problèmes au Bitcoin, ou les exacerber en introduisant un moyen d’y intégrer sans confiance l’actif Bitcoin de manière plus dynamique et plus flexible, est franchement insensée. Pour moi, cela parle d’un grand nombre de personnes qui n’ont rien appris en regardant ce qui s’est passé sur d’autres blockchains au cours de la dernière demi-décennie.
Enchaîné à jamais par le chat
En regardant la dynamique ci-dessus entre CSFS + CAT, il convient de souligner que la récente proposition LNHANCE de Reardencode (CTV + CSFS + Internal Key) offre un chemin pour nous donner Eltoo pour Lightning d’une manière qui est en réalité plus efficace en termes d’espace de bloc que l’utilisation d’APO. Si cette argumentation, et s’appuyant sur une preuve de concept, finit par convaincre les développeurs Lightning qui souhaitent une symétrie LN afin de simplifier la gestion des canaux Lightning et la maintenance de l’implémentation, nous pourrions très bien finir par obtenir CSFS dans le processus. Si OP_CAT était actif avant cela, il n’y a aucun moyen d’éviter la combinaison des types d’effets secondaires néfastes des deux propositions.
Cela serait vrai pour chaque proposition de soft fork à l’avenir si OP_CAT était un jour activé. Il serait impossible d’échapper aux effets secondaires ou aux cas d’utilisation permis en combinant OP_CAT avec les nouvelles propositions à venir. En soi, OP_CAT est maladroit, inefficace et plutôt inutile. Mais en combinaison avec d’autres PO, il commence à devenir bêtement flexible et puissant. Il s’agirait d’une dynamique à laquelle nous ne pourrions jamais échapper, et les fonctionnalités qui pourraient s’avérer essentielles à l’avenir pour l’évolutivité de Bitcoin pourraient inévitablement entraîner d’énormes inconvénients et risques simplement en raison de l’existence d’OP_CAT.
Est-ce une réalité dans laquelle nous voulons entrer simplement à cause d’une campagne mème ? Parce que les gens veulent bricoler des moyens extrêmement inefficaces de faire les choses au lieu d’examiner des propositions beaucoup plus efficaces et spécialement conçues ? Je dirais non.
Les campagnes mèmes peuvent être amusantes, je le sais. Ils favorisent un sentiment de communauté et d’implication, c’est une partie inhérente et incontournable d’Internet et des nombreuses cultures qui y existent. Mais ce n’est pas ainsi que nous devrions décider du processus de développement du Bitcoin. Ils peuvent être amusants, et ils peuvent même être vicieusement sauvages en poignardant directement le cœur des sujets sur lesquels les gens dansent ou tergiversent. Mais ils sont atroces à capturer les nuances et la complexité à bien des égards.
Essayer d’orienter le consensus d’un réseau comme Bitcoin uniquement sur la valeur d’un mème, plutôt que sur une considération raisonnée des propositions et de leurs implications, est un désastre imminent. Le conservatisme et la prudence du développement du Bitcoin sont ce qui l’a maintenu à l’avant-garde de cet espace, alors que les shitcoins sont venus et disparus, implosant dans les conséquences de leur attitude de développement insouciante. Même si Bitcoin a cruellement besoin de sortir de son ornière actuelle de stagnation et de manque de progrès, se tourner vers des mèmes et des vidéoclips non critiques n’est pas la façon d’y parvenir. Cela risque de détruire ce qui a fait la valeur initiale du Bitcoin, sa base solide et conservatrice.