Rapport de recherche HashKey Capital : clauses restrictives, programmabilité de Bitcoin

原文作者：HashKey Capital Responsable de la recherche en investissement Jeffrey HU、HashKey Capital Investment Manager Harper LI

Récemment, il y a eu une vague de discussions dans la communauté Bitcoin sur la réactivation des opcodes tels que OP_CAT. Taproot Wizard a également attiré beaucoup d'attention en lançant les NFT Quantum Cats et en affirmant avoir obtenu un numéro BIP-420. Les partisans affirment que l'activation d'OP_CAT peut permettre des « engagements », des contrats intelligents ou la programmabilité de Bitcoin.

Si vous remarquez le mot « restrictions » et faites une petite recherche, vous constaterez qu’il s’agit d’un autre grand terrier de lapin. Les développeurs discutent depuis des années, en plus d'OP_CAT, il existe également OP_CTV, APO, OP_VAULT et d'autres techniques pour implémenter des clauses restrictives.

Alors, quelles sont exactement les « restrictions » de Bitcoin ? Pourquoi attire-t-il autant l’attention et les discussions des développeurs depuis plusieurs années ? Quel type de programmabilité peut-on obtenir avec Bitcoin ? Quel est le principe de conception derrière cela ? Cet article tente de donner une introduction et une discussion générales.

Que sont les « restrictions »

Les clauses restrictives, traduites par « restrictions » en chinois et parfois traduites par « contrats », sont un mécanisme qui peut fixer les conditions des futures transactions Bitcoin.

Le script Bitcoin actuel contient également des conditions restrictives, telles que la saisie d'une signature légale et l'envoi d'un script correspondant lors d'une dépense. Mais tant que l’utilisateur peut le déverrouiller, il peut dépenser l’UTXO où il le souhaite.

La clause de restriction vise à imposer davantage de restrictions en fonction de la manière de débloquer cette restriction, par exemple en limitant les dépenses après UTXO, ce qui vise à obtenir un effet similaire aux « fonds dédiés » ou à d'autres conditions d'entrée envoyées lors d'une attente de transaction ;

Plus strictement parlant, le script Bitcoin actuel a également certaines restrictions. Par exemple, le verrouillage temporel basé sur le code d'opération consiste à réaliser le délai avant que la transaction ne soit dépensée en introspectant le champ nLock ou nSequence de la transaction, mais c'est fondamentalement le cas. limité à des contraintes de temps.

Alors pourquoi les développeurs et les chercheurs conçoivent-ils ces contrôles de limites ? Parce que les clauses restrictives ne sont pas seulement des restrictions pour le plaisir, elles fixent également des règles pour l’exécution des transactions. De cette manière, les utilisateurs ne peuvent exécuter des transactions que selon des règles prédéfinies pour terminer le processus métier prédéterminé.

Contre-intuitivement, cela peut débloquer davantage de scénarios d’application.

Scénarios d'application

Assurer des pénalités de jalonnement

L’un des exemples les plus intuitifs de termes restrictifs est la transaction slash de Babylon dans le processus de jalonnement Bitcoin.

Le processus de jalonnement Bitcoin de Babylon permet aux utilisateurs d'envoyer leurs actifs BTC vers un script spécial sur la chaîne principale. Les conditions de dépense comprennent deux types :

• Fin heureuse : après un certain temps, l'utilisateur peut le déverrouiller avec sa signature, ce qui termine le processus de désactivation.

• Mauvaise fin : si un utilisateur commet des actes malveillants tels qu'une double signature sur une certaine chaîne PoS louée par Babylon, alors via EOTS (signatures uniques extractibles, signatures extractibles uniques), cette partie des actifs peut être déverrouillée. et Un acteur exécutif du réseau force l'envoi d'une partie des actifs à une adresse de gravure (slash)

来源：Bitcoin Staking : débloquer 21 millions de Bitcoins pour sécuriser l'économie de preuve de participation

Notez ici "l'envoi forcé", ce qui signifie que même si cet UTXO peut être déverrouillé, l'actif ne peut pas être envoyé ailleurs de manière arbitraire et ne peut être brûlé. Cela garantira que les utilisateurs malveillants ne pourront pas utiliser leurs signatures connues pour se transférer des actifs afin d'échapper à des sanctions.

Si cette fonction est implémentée après l'implémentation de restrictions telles que OP_CTV, des opcodes tels que OP_CTV peuvent être ajoutés à la branche « mauvaise fin » du script de jalonnement pour implémenter des restrictions.

Avant que OP_CTV ne soit activé, Babylon doit utiliser une méthode flexible, mise en œuvre conjointement par les utilisateurs + les comités, pour simuler l'effet de l'application des clauses de restriction.

contrôle des embouteillages

De manière générale, la congestion fait référence au moment où les frais de transaction sur le réseau Bitcoin sont très élevés et où davantage de transactions sont accumulées dans le pool de transactions en attente d'être regroupées. Par conséquent, si les utilisateurs souhaitent confirmer les transactions rapidement, ils doivent augmenter les frais de transaction.

À l’heure actuelle, si un utilisateur doit envoyer plusieurs transactions à plusieurs bénéficiaires, il devra augmenter les frais de traitement et supporter des coûts plus élevés. Dans le même temps, cela augmentera également les taux de traitement de l’ensemble du réseau.

S'il existe des restrictions, une solution consiste pour l'expéditeur à s'engager dans une transaction d'envoi par lots. Cette promesse peut faire croire à tous les destinataires que la transaction finale sera effectuée, et ils peuvent attendre que le taux de traitement soit faible avant d'envoyer des transactions spécifiques.

Comme le montre le graphique ci-dessous, lorsque la demande d’espace de bloc est élevée, il devient très coûteux d’effectuer des transactions. En utilisant OP_CHECKTEMPLATEVERIFY, les processeurs de paiement à gros volume peuvent regrouper tous leurs paiements en une seule transaction O(1) pour confirmation. Puis, au fil du temps, lorsque la demande d’espace de bloc diminue, les paiements peuvent être étendus à partir de cet UTXO.

Source : https://utxos.org/uses/scaling/

Ce scénario est un cas d'application typique proposé par la clause de restriction OP_CTV. D'autres cas d'application peuvent être trouvés sur https://utxos.org/uses/ En plus du contrôle de congestion ci-dessus, la page répertorie les paris Soft Fork, les options décentralisées, les chaînes d'entraînement, les canaux par lots, les canaux non interactifs, l'exploitation minière sans coordination et sans confiance. Pools, coffres-forts, limites de contrats HTLCS (Hashed Time Locked Contracts) plus sûrs, etc.

Sauter

Vault est un scénario d'application largement discuté dans les applications Bitcoin, notamment dans le domaine des clauses restrictives. Étant donné que les opérations quotidiennes nécessitent inévitablement un équilibre entre les besoins de conservation et d'utilisation des fonds, les gens espèrent disposer d'un type d'application de coffre-fort capable d'assurer la sécurité des fonds, et même de limiter la sécurité des fonds même si le compte est piraté (la clé privée est fuite). Utilisation des fonds.

Les applications de classe Vault peuvent être créées relativement facilement sur la base de techniques d'implémentation de restrictions.

Prenons l'exemple de la conception d'OP_VAULT : lorsque vous dépensez des fonds dans le coffre-fort, une transaction doit d'abord être envoyée à la chaîne. Cette transaction indique une intention de dépenser le coffre-fort, un « déclencheur », et fixe une condition en son sein :

• Si tout va bien, alors la deuxième transaction est celle où le retrait final est effectué. Après avoir attendu N blocs, les fonds peuvent être dépensés n'importe où

• S'il s'avère que cette transaction a été volée (ou a été forcée lors d'une « attaque à la clé »), elle peut être immédiatement envoyée à une autre adresse sécurisée (stockage plus sûr pour l'utilisateur) avant l'envoi de la transaction de retrait de N blocs.

Processus OP_VAULT, source : BIP-345

Il convient de noter qu'une application de coffre-fort peut également être créée sans restrictions. Une méthode réalisable consiste à utiliser la clé privée pour préparer les signatures pour les dépenses futures, puis à détruire la clé privée. Cependant, il existe encore de nombreuses limitations, telles que la nécessité de s'assurer que la clé privée a été détruite (similaire au processus de configuration fiable dans la preuve zéro connaissance), le montant et les frais de traitement sont déterminés à l'avance (en raison de la nécessité de pré-signature), et il y a un manque de flexibilité.

Comparaison de OP_VAULT et des processus de coffre-fort pré-signés, source : BIP-345

Des canaux étatiques plus robustes et flexibles

On peut généralement considérer que les canaux d'état, y compris le Lightning Network, ont presque la même sécurité que la chaîne principale (à condition que les nœuds puissent observer le dernier statut et puissent normalement publier le dernier statut sur la chaîne). Cependant, avec les restrictions en place, certaines nouvelles idées de conception de canaux d'état peuvent être plus robustes ou plus flexibles au-dessus du réseau Lightning. Les plus connus incluent Eltoo, Ark, etc.

Eltoo (également connu sous le nom de LN-Symmetry) est l'un des exemples les plus typiques. Cette solution technique est homophonique à "L2" et propose une couche d'exécution pour le réseau Lightning qui permet à tout état de canal ultérieur de remplacer l'état précédent sans avoir besoin d'un mécanisme de pénalité. Par conséquent, elle peut également éviter la nécessité d'une sauvegarde similaire à Lightning. Nœuds de réseau. Plusieurs états précédents pour empêcher votre adversaire de faire le mal. Afin d'obtenir l'effet ci-dessus, Eltoo a proposé la méthode de signature SIGHASH_NOINPUT, à savoir APO (BIP-118).

Ark vise à réduire la difficulté de gestion des liquidités entrantes et des canaux du Lightning Network. Il s'agit d'un protocole de type joinpool dans lequel plusieurs utilisateurs peuvent accepter un fournisseur de services comme contrepartie pendant une certaine période et effectuer des transactions UTXO virtuelles (vUTXO) en dehors de la chaîne, mais partager un UTXO sur la chaîne pour réduire les coûts. Semblable au coffre-fort, Ark peut également être implémenté sur le réseau Bitcoin actuel ; cependant, après avoir introduit des restrictions, Ark peut réduire la quantité d'interaction requise en fonction des modèles de transaction et obtenir une sortie unilatérale moins fiable.

Présentation technique des restrictions

Comme le montrent les applications ci-dessus, les clauses restrictives ressemblent plus à un effet qu'à une certaine technologie, il existe donc de nombreuses façons techniques de les mettre en œuvre. Si cela est classifié, cela pourrait inclure :

• Type : Type général, type spécial

• Méthode de mise en œuvre : Basée sur Opcode, basée sur la signature

• Récursivité : récursive, non récursive

Parmi eux, la récursivité fait référence à la mise en œuvre de certaines clauses restrictives. Vous pouvez également limiter la sortie suivante en limitant la sortie suivante. Les restrictions ajoutées peuvent dépasser une transaction et atteindre une profondeur de transaction plus élevée.

Certaines conceptions de clauses restrictives populaires incluent :

* Récursion : si combiné avec OP_CAT

La conception des restrictions

Comme le montre l’introduction précédente, le script Bitcoin actuel limite principalement les conditions de déverrouillage et ne limite pas la manière dont l’UTXO peut être dépensé davantage. Pour mettre en œuvre les restrictions, nous devons penser à l’envers : pourquoi le script Bitcoin actuel ne peut-il pas mettre en œuvre les restrictions ?

La raison principale est que le script Bitcoin actuel ne peut pas lire le contenu de la transaction lui-même, c'est-à-dire « l'introspection » de la transaction.

Si nous pouvions mettre en œuvre l'introspection des transactions, c'est-à-dire inspecter tout contenu de la transaction (y compris les résultats), alors nous pourrions implémenter des contraintes.

Par conséquent, les idées de conception des clauses restrictives se concentrent principalement sur la manière de réaliser l’introspection.

Basé sur un opcode ou basé sur une signature

L'idée la plus simple et la plus grossière est d'ajouter un ou plusieurs opcodes (c'est-à-dire un opcode + plusieurs paramètres, ou plusieurs opcodes avec différentes fonctions) pour lire directement le contenu de la transaction. C'est l'idée basée sur les codes d'opération.

Une autre idée est que vous ne pouvez pas lire et vérifier directement le contenu de la transaction elle-même dans le script, mais vous pouvez utiliser le hachage du contenu de la transaction - si le hachage a été signé, modifiez-le simplement dans le script tel que OP_CHECKSIG After en vérifiant cette signature, nous pouvons indirectement mettre en œuvre une introspection et des restrictions sur les transactions. Cette idée est basée sur un design signature. Comprenant principalement APO et OP_CSFS, etc.

OU

SIGHASH_ANYPREVOUT (APO) est une méthode de signature Bitcoin proposée. La manière la plus simple de signer est de s'engager à la fois sur l'entrée et la sortie de la transaction, mais Bitcoin propose également une méthode plus flexible, à savoir SIGHASH, qui s'engage de manière sélective sur l'entrée ou la sortie d'une transaction.

La gamme de signature actuelle de SIGHASH et ses combinaisons pour l'entrée et la sortie des transactions (source "Mastering Bitcoin, 2nd"

Comme le montre la figure ci-dessus, en plus de ALL qui s'applique à toutes les données, la méthode de signature NONE s'applique uniquement à toutes les entrées et n'est pas utilisée pour la sortie ; SINGLE est basé sur cela et s'applique uniquement aux sorties avec le même numéro de séquence d'entrée. De plus, SIGHASH peut également être combiné. Après avoir superposé le modificateur ANYONECANPAY, il n'est applicable qu'à une seule entrée.

SIGHASH d'APO signe uniquement la sortie, pas la partie d'entrée. Cela signifie que les transactions signées avec APO peuvent être ultérieurement attachées à tout UTXO qui remplit les conditions.

Cette flexibilité constitue la base théorique sur laquelle l’APO peut mettre en œuvre des clauses restrictives :

• Une ou plusieurs transactions peuvent être créées à l'avance

• En utilisant les informations de ces transactions, une clé publique qui ne peut obtenir qu'une signature est construite.

• De cette façon, tous les actifs envoyés à cette adresse de clé publique ne peuvent être dépensés que via des transactions pré-créées.

Il convient de noter que, comme cette clé publique n'a pas de clé privée correspondante, il est garanti que ces actifs ne peuvent être dépensés que par le biais de transactions pré-créées. Ensuite, nous pouvons stipuler la destination des actifs dans ces transactions pré-créées pour mettre en œuvre des conditions restrictives.

Nous pouvons mieux comprendre en comparant les contrats intelligents d'Ethereum : ce que nous pouvons réaliser grâce aux contrats intelligents, c'est que ce n'est qu'en remplissant certaines conditions que nous pouvons retirer de l'argent de l'adresse du contrat, au lieu de le dépenser arbitrairement avec une signature EOA. De ce point de vue, Bitcoin peut obtenir cet effet grâce à l’amélioration du mécanisme de signature.

Mais le problème avec le processus ci-dessus est qu’il existe des dépendances circulaires dans le calcul, car l’entrée doit être connue pour pré-signer et créer la transaction.

L'importance d'APO et SIGHASH_NOINPUT dans la mise en œuvre de cette méthode de signature est qu'elle peut résoudre ce problème de dépendance circulaire. Lors du calcul, il vous suffit de connaître (spécifier) ​​toutes les sorties de la transaction.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), BIP-119, adopte une approche Opcode améliorée. Il prend un hachage d'engagement comme paramètre et exige que toute transaction qui exécute l'opcode contienne un ensemble de sorties correspondant à cet engagement. Grâce à CTV, les utilisateurs de Bitcoin seront autorisés à limiter la façon dont ils utilisent leur Bitcoin.

La proposition a été initialement lancée sous le nom OP_CHECKOUTPUTSHASHVERIFY (COSHV) et s'est concentrée dès le début sur la capacité de créer des transactions de contrôle de la congestion. Les critiques de la proposition ont donc également porté sur le fait que le système n'était pas assez général et trop spécifique aux cas d'utilisation du contrôle de la congestion.

Dans le cas d'utilisation du contrôle de congestion mentionné ci-dessus, l'expéditeur Alice pourrait créer et hacher 10 sorties et utiliser le résumé résultant pour créer un script tapleaf contenant COSHV. Alice peut également utiliser les clés publiques des participants pour former une clé interne Taproot, leur permettant de collaborer sur les dépenses sans révéler le chemin du script Taproot.

Alice donne ensuite à chaque destinataire une copie des 10 sorties afin qu'ils vérifient chacun la transaction de configuration d'Alice. Lorsqu'ils souhaitent ensuite dépenser le paiement, l'un ou l'autre peut créer une transaction contenant le résultat promis.

Tout au long du processus, à mesure qu'Alice crée et envoie la transaction de configuration, Alice peut envoyer ces 10 copies de la sortie via des méthodes de communication asynchrones existantes, telles que le courrier électronique ou les lecteurs cloud. Cela signifie que les destinataires n'ont pas besoin d'être en ligne ni d'interagir les uns avec les autres.

Source : https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

Semblable à l'APO, les adresses peuvent également être construites en fonction des conditions de dépenses, et les « verrous » peuvent être créés de différentes manières, notamment en ajoutant d'autres clés, des verrous temporels et une logique combinable.

Source : https://twitter.com/OwenKemeys/status/1741575353716326835

Sur cette base, CTV a proposé de vérifier si la transaction de dépenses hachée correspond à celle définie, c'est-à-dire que les données de transaction peuvent être utilisées comme clé pour ouvrir le « verrou ».

Nous pouvons continuer à étendre l'exemple ci-dessus de 10 récepteurs. Le destinataire peut en outre définir sa clé d'adresse sur une transmission signée mais non diffusée et l'envoyer au prochain lot d'adresses de récepteur, et ainsi de suite, formant un système comme le montre la figure ci-dessous. .arborescence. Alice peut créer un changement de solde de compte impliquant plusieurs utilisateurs en utilisant seulement 1 espace de bloc utxo sur la chaîne.

Source : https://twitter.com/OwenKemeys/status/1741575353716326835

Et que se passe-t-il si l’une des feuilles est un canal Lightning, un entrepôt frigorifique ou un autre moyen de paiement ? Ensuite, cet arbre passera d’un arbre de dépenses unidimensionnel et multi-niveaux à un arbre de dépenses multidimensionnel et multi-niveaux, et les scénarios qu’il peut prendre en charge seront plus riches et plus flexibles.

Source : https://twitter.com/OwenKemeys/status/1744181234417140076

Depuis que CTV a été proposé, il a subi un changement de nom de COSHV en 2019, s'est vu attribuer le BIP-119 en 2020 et est devenu un langage de programmation Sapio pour prendre en charge les contrats CTV. En 22 et 23, il a fait l'objet de nombreuses discussions. mises à jour et mises à jour de la communauté. Le débat sur son plan d'activation est toujours l'une des propositions de mise à niveau du soft fork les plus discutées dans la communauté.

OP_CAT

Comme présenté au début, OP_CAT est également une proposition de mise à niveau qui attire actuellement beaucoup d'attention. La fonction qu'elle implémente est de concaténer (concatenante) deux éléments dans la pile. Bien que cela semble simple, OP_CAT peut être très flexible pour implémenter de nombreuses fonctions dans des scripts.

L'exemple le plus direct est celui des opérations liées aux arbres Merkle. L'arbre Merkle peut être compris comme deux éléments d'abord épissés puis hachés. Actuellement, il existe des codes d'opération de hachage tels que OP_SHA 256 dans le script Bitcoin, donc si OP_CAT peut être utilisé pour fusionner deux éléments, la fonction de vérification de l'arbre Merkle peut être implémentée dans le script, qui a également une vérification client légère pour un certain mesure.

Les bases de mise en œuvre supplémentaires incluent également des améliorations des signatures Schnorr : les conditions de signature de dépenses du script peuvent être définies sur l'épissage de la clé publique et du nom occasionnel public de l'utilisateur, puis si le signataire souhaite signer une autre transaction, les fonds seront dépensés ailleurs ; pour utiliser le même nom occasionnel et provoquer la fuite de la clé privée. Autrement dit, l'engagement à l'occasion est réalisé via OP_CAT, garantissant ainsi la validité de la transaction signée.

D'autres scénarios d'application d'OP_CAT incluent : Bistream, signature d'arbre, signature Lamport à résistance quantique, coffre-fort, etc.

OP_CAT en soi n'est pas une fonctionnalité nouvelle. Elle existait dans les premières versions de Bitcoin, mais a été désactivée en 2010 car elle pouvait être exploitée par des attaques. Par exemple, la réutilisation de OP_DUP et OP_CAT peut facilement faire exploser la pile complète de nœuds lors du traitement de tels scripts, voir cette démo.

Mais la réactivation d'OP_CAT ne provoquera-t-elle pas le problème d'explosion de pile mentionné ci-dessus ? Étant donné que la proposition OP_CAT actuelle implique uniquement son activation dans tapscript, ce qui limite chaque élément de pile à 520 octets maximum, le problème précédent d'explosion de pile ne se posera pas. Certains développeurs pensent également que l'interdiction directe d'OP_CAT par Satoshi est peut-être trop sévère. Cependant, en raison de la flexibilité d'OP_CAT, certains scénarios d'application pouvant conduire à des vulnérabilités ne peuvent actuellement pas être épuisés.

Par conséquent, compte tenu des scénarios d'application et des risques potentiels, OP_CAT a récemment reçu beaucoup d'attention et a également fait l'objet d'examens de relations publiques. Il s'agit actuellement de l'une des propositions de mise à niveau les plus populaires.

Conclusion

"L'autodiscipline apporte la liberté." Comme le montre l'introduction ci-dessus, des clauses restrictives peuvent être directement mises en œuvre dans les scripts Bitcoin pour limiter les dépenses de transaction supplémentaires, obtenant ainsi des règles de transaction similaires aux effets des contrats intelligents. Par rapport aux méthodes hors chaîne telles que BitVM, cette méthode de programmation peut être vérifiée de manière plus native sur Bitcoin et peut également améliorer les applications sur la chaîne principale (contrôle de la congestion), les applications hors chaîne (canaux d'état) et d'autres nouvelles orientations d'application ( pénalités de mise, etc.).

Si la technologie de mise en œuvre des clauses de restriction peut être combinée avec certaines mises à niveau sous-jacentes, cela libérera davantage le potentiel de la programmabilité. Par exemple, la proposition d'opérateur 64 bits récemment examinée pourrait être combinée davantage avec l'OP_TLUV proposé ou d'autres contraintes qui peuvent être programmées en fonction du nombre de satoshis générés par la transaction.

Cependant, des conditions restrictives peuvent également conduire à des abus imprévus ou à des failles, c'est pourquoi la communauté est également plus prudente à ce sujet. En outre, la mise à niveau des clauses de restriction nécessite également une mise à niveau douce des règles de consensus. En raison de la situation lors de la mise à niveau de la racine pivotante, les mises à niveau liées aux restrictions peuvent également prendre du temps.

Merci à Ajian, Fisher et Ben pour leur critique et leurs suggestions sur cet article !

Documents de référence https://utxos.org/

https://bitcoincovenants.com/

Une collection de ressources liées aux alliances :

https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068

https://anyprevout.xyz/

BIP 345 : proposition OP_VAULT : https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/

https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final2 8.pdf

https://maltemoeser.de/paper/covenants.pdf

https://bitcoinops.org/en/topics/op_cat/

OP_CAT :

https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md

Astuces CAT et Schnorr : https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298