Bitcoin restrictions: une nouvelle direction pour la Programmabilité

La communauté Bitcoin a récemment engagé une discussion animée sur la réactivation des opcodes comme OP_CAT. Taproot Wizard a attiré beaucoup d'attention en lançant des Quantum Cats NFT et en affirmant avoir obtenu le numéro BIP-420. Les partisans affirment que l'activation d'OP_CAT pourrait permettre des "clauses restrictives", apportant ainsi des contrats intelligents et de la Programmabilité au Bitcoin.

"Clauses restrictives"(covenants) ce concept a suscité des discussions parmi les développeurs pendant des années. En plus de OP_CAT, il existe plusieurs solutions techniques pour mettre en œuvre des clauses restrictives, telles que OP_CTV, APO, OP_VAULT, etc. Alors, qu'est-ce que les "clauses restrictives" de Bitcoin ? Pourquoi suscitent-elles un intérêt aussi large et durable ? Quelles programmabilités peuvent-elles apporter à Bitcoin ? Quels sont les principes de conception sous-jacents ? Cet article présentera une introduction et une discussion générales sur ces questions.

Qu'est-ce que "clauses restrictives"

"Clauses restrictives" ( covenants ) sont un mécanisme permettant de définir des conditions pour les transactions Bitcoin futures. Les scripts Bitcoin actuels contiennent déjà certaines conditions restrictives, comme la nécessité de fournir une signature valide, de fournir un script conforme aux exigences, etc. Mais tant que l'utilisateur peut déverrouiller, il peut dépenser des UTXO n'importe où.

Et les clauses restrictives ont ajouté davantage de restrictions, par exemple en limitant la destination des dépenses ultérieures d'un UTXO, réalisant ainsi l'effet de "fonds dédiés" ; ou en limitant les conditions des autres entrées dans une transaction, etc.

Pour être plus précis, le script Bitcoin actuel possède également certaines fonctionnalités de clause de restriction, comme le verrouillage temporel basé sur des codes d'opération. En vérifiant les champs nLock ou nSequence de la transaction, il est possible d'imposer une restriction temporelle avant que la transaction ne soit dépensée. Mais actuellement, cela se limite principalement aux restrictions temporelles.

Les développeurs ont conçu ces contrôles de restriction non seulement pour limiter, mais aussi pour établir les règles d'exécution des transactions. Les utilisateurs ne peuvent exécuter des transactions que conformément aux règles prédéfinies, afin de compléter les processus commerciaux prévus.

Ainsi, les clauses de restriction peuvent paradoxalement débloquer davantage de cas d'utilisation.

Cas d'utilisation

Assurez-vous des pénalités de Staking

Un exemple intuitif des conditions restrictives est la transaction de slash de Babylon dans le staking de Bitcoin.

Le processus de staking de Bitcoin de Babylon consiste à ce que les utilisateurs envoient des actifs BTC dans un script spécial sur la chaîne principale, les conditions de dépense comprennent deux types :

1. Fin normale : Après un certain temps, l'utilisateur peut déverrouiller avec sa propre signature et terminer le processus d'unstake.

2. Fin de la punition : si un utilisateur a des comportements malveillants tels que des doubles signatures sur la chaîne PoS de sécurité Babylon, alors via EOTS(, une signature unique peut être extraite pour déverrouiller les actifs, et des rôles d'exécution dans le réseau enverront de force une partie des actifs à l'adresse de combustion )slash(.

Ici, "envoi forcé" signifie que même si le UTXO peut être débloqué, cet actif ne peut pas être envoyé à d'autres endroits à sa guise, il ne peut être que brûlé. Cela garantit que les utilisateurs malveillants ne peuvent pas devancer en renvoyant l'actif à eux-mêmes avec une signature connue, échappant ainsi à la punition.

Après la mise en œuvre des clauses restrictives telles que OP_CTV, il est possible d'ajouter des codes d'opération pertinents dans la branche "fin de la punition" du script de staking pour mettre en œuvre les restrictions.

Avant l'activation de OP_CTV, Babylon doit simuler l'effet d'application des conditions restrictives par une méthode de contournement exécutée conjointement par les utilisateurs et le comité.

![Détails sur les Covenants : comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-409951d98817702c2c2c9185b417ff9e.webp(

) contrôle de congestion

En cas de congestion du réseau, un grand nombre de transactions en attente s'accumulent dans le pool de transactions, et les utilisateurs doivent augmenter les frais de transaction pour obtenir une confirmation rapide. Si un utilisateur doit envoyer plusieurs transactions à plusieurs destinataires, il doit supporter des coûts plus élevés, ce qui augmente encore le taux de frais de transaction sur l'ensemble du réseau.

Avec les clauses de restriction, l'expéditeur peut d'abord s'engager dans une transaction d'envoi en masse. Cet engagement permet à tous les destinataires de croire que la transaction finale sera exécutée, et ils peuvent attendre que le taux de frais de transaction diminue avant d'envoyer la transaction spécifique.

Lorsque la demande d'espace de bloc est élevée, les transactions deviennent coûteuses. En utilisant OP_CHECKTEMPLATEVERIFY, les processeurs de paiement en gros peuvent agréger tous les paiements dans une seule transaction O###1( pour confirmation. Par la suite, lorsque la demande d'espace de bloc diminue, les paiements peuvent être extraits de ce UTXO.

C'est l'un des cas d'application typiques proposés par la clause de restriction OP_CTV.

![Explication des Covenants : comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-163ceda005acef4c7986cd940c4f0945.webp(

) coffre-fort

Le coffre-fort ###vault( est un scénario largement discuté dans les applications Bitcoin, notamment dans le domaine des conditions restrictives. Les opérations quotidiennes nécessitent un équilibre entre la conservation des fonds et les besoins d'utilisation, les gens espèrent avoir une sorte d'application de coffre-fort : capable de garantir la sécurité des fonds, même si le compte est piraté ) et que la clé privée est divulguée (, elle peut également limiter l'utilisation des fonds.

Basé sur la technologie des clauses restrictives, il est relativement facile de construire des applications de type coffre-fort.

Prenons l'exemple du plan OP_VAULT : lors de l'utilisation des fonds du coffre-fort, il est nécessaire d'envoyer d'abord une transaction sur la chaîne pour indiquer l'intention )"trigger"(, et de définir les conditions :

• Normalement : la deuxième transaction est la transaction de retrait finale. Après avoir attendu N blocs, les fonds peuvent être dépensés davantage à n'importe quelle adresse.

• Situation exceptionnelle : si une transaction volée ) ou une transaction sous contrainte ( est détectée, il est possible d'envoyer immédiatement les fonds à une adresse plus sécurisée avant l'envoi de la transaction de retrait dans N blocs.

Il est important de noter que même sans clauses restrictives, il est possible de construire une application de garde. Une méthode consiste à préparer la signature des dépenses futures avec une clé privée, puis à détruire la clé privée. Cependant, cette méthode présente encore des limites, telles que la nécessité de s'assurer que la clé privée a été détruite, le montant et les frais devant être déterminés à l'avance, ce qui manque de flexibilité.

![Détails sur les Covenants : comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(

) un canal d'état plus robuste et flexible

Le canal d'état ###, y compris le réseau Lightning (, peut être considéré comme ayant une sécurité presque identique à celle de la chaîne principale, tant que l'état le plus récent est observable par les nœuds et que la publication de l'état le plus récent sur la chaîne fonctionne correctement. Avec les clauses restrictives, certains nouveaux designs de canaux d'état peuvent être plus robustes ou flexibles sur la base du réseau Lightning, les plus connus étant Eltoo, Ark, etc.

Eltoo), également appelé LN-Symmetry(, est un exemple typique. Il propose une couche d'exécution pour le réseau Lightning, permettant à tout état de canal ultérieur de remplacer un état précédent sans mécanisme de pénalité, évitant ainsi aux nœuds du réseau Lightning de devoir conserver plusieurs états précédents pour prévenir les actes malveillants de la part des adversaires. Eltoo propose le mode de signature SIGHASH_NOINPUT, c'est-à-dire APO)BIP-118( pour réaliser cet effet.

Ark vise à réduire la difficulté de la liquidité entrante et de la gestion des canaux sur le réseau Lightning. C'est un protocole sous forme de joinpool, où plusieurs utilisateurs peuvent accepter un fournisseur de services en tant que contrepartie pendant une certaine période, pour effectuer des transactions virtuelles UTXO)vUTXO( hors chaîne, tout en partageant un UTXO sur la chaîne pour réduire les coûts. Semblable à un coffre-fort, Ark peut également être réalisé sur le réseau Bitcoin actuel ; mais après l'introduction de clauses restrictives, Ark peut réduire le volume d'interaction requis basé sur des modèles de transaction, permettant une sortie unilatérale plus décentralisée.

![Détails sur les Covenants : Comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(

Aperçu technique des conditions restrictives

D'après les applications mentionnées ci-dessus, les clauses restrictives ressemblent davantage à un effet qu'à une technologie spécifique, il existe donc plusieurs manières de les mettre en œuvre. On peut les classer selon plusieurs dimensions :

• Type : Général, Spécial
• Mode de mise en œuvre : basé sur les codes d'opération, basé sur la signature
• Récursivité : récursif, non récursif

Parmi eux, la récursivité signifie que la mise en œuvre de certaines clauses restrictives peut être réalisée en limitant la sortie de la transaction suivante afin de restreindre la sortie de la transaction suivante, permettant ainsi de mettre en œuvre des restrictions sur plusieurs transactions.

Les principales conceptions des clauses de restriction comprennent :

• OP_CTV: type général, basé sur le code d'opération, non récursif
• APO : type général, basé sur une signature, non récursif
• OP_VAULT: Spécial, basé sur des codes d'opération, non récursif
• OP_CAT: type générique, basé sur des codes opérationnels, récursif ) si combiné avec OP_CAT (

![Détails sur les Covenants : comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(

Conception des clauses restrictives

Le script Bitcoin actuel limite principalement les conditions de déverrouillage, sans restreindre comment les UTXO peuvent être dépensés par la suite. Pour mettre en œuvre des conditions restrictives, il est nécessaire de réfléchir à pourquoi le script actuel ne peut pas réaliser cette fonctionnalité.

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

Si l'on peut réaliser l'introspection des transactions - vérifier tout ce qui concerne la transaction ( y compris la sortie ), alors il serait possible de mettre en œuvre des conditions restrictives.

Par conséquent, la conception des clauses de limitation tourne principalement autour de la manière de réaliser l'introspection.

( basé sur le code d'opération vs basé sur la signature

La pensée la plus directe est d'ajouter un ou plusieurs codes d'opération ) un code d'opération + plusieurs paramètres, ou plusieurs codes d'opération de différentes fonctions ###, pour lire directement le contenu des transactions. C'est l'idée basée sur les codes d'opération.

Une autre approche consiste à ne pas lire et vérifier directement le contenu des transactions dans le script, mais à utiliser le hachage du contenu des transactions - si ce hachage a été signé, il suffit de modifier dans le script des opérations telles que OP_CHECKSIG pour vérifier cette signature, ce qui permet d'implémenter indirectement l'introspection des transactions et les clauses restrictives. Cela repose sur une conception basée sur la signature, qui comprend principalement APO et OP_CSFS.

( APO

SIGHASH_ANYPREVOUT)APO### est un type de signature proposé pour Bitcoin. La manière la plus simple de signer est de s'engager sur les entrées et les sorties de la transaction, mais Bitcoin offre une méthode plus flexible, à savoir SIGHASH, qui permet de s'engager de manière sélective sur les entrées ou les sorties de la transaction.

Le SIGHASH d'APO ne signe que les sorties et ne signe pas la partie des entrées. Cela signifie qu'une transaction signée avec la méthode APO peut ensuite être attachée à n'importe quel UTXO qui répond aux conditions.

Cette flexibilité est la base théorique de la mise en œuvre des clauses restrictives par l'APO :

• Vous pouvez créer à l'avance une ou plusieurs transactions
• Construire une clé publique qui ne peut produire qu'une seule signature à partir de ces informations de transaction.
• Ainsi, tout actif envoyé à cette adresse de clé publique ne peut être dépensé que par une transaction préalablement créée.

Il est important de noter que, comme cette clé publique n'a pas de clé privée correspondante, il peut être garanti que ces actifs ne peuvent être dépensés que par des transactions préalablement créées. Nous pouvons alors spécifier la destination des actifs dans ces transactions préalablement créées, ce qui permet de mettre en œuvre des conditions restrictives.

Nous pouvons comprendre en comparant les contrats intelligents d'Ethereum : grâce aux contrats intelligents, nous pouvons réaliser que nous ne pouvons retirer des fonds de l'adresse du contrat que sous certaines conditions, et non simplement dépenser à volonté avec une signature EOA. Sous cet angle, le Bitcoin peut atteindre cet effet grâce à l'amélioration du mécanisme de signature.

Mais le problème dans le processus ci-dessus est qu'il existe une dépendance cyclique lors du calcul, car il est nécessaire de connaître le contenu d'entrée pour pré-signer et créer la transaction.

Le sens de la mise en œuvre des signatures APO et SIGHASH_NOINPUT réside dans la capacité à résoudre ce problème de dépendance circulaire ; lors du calcul, il suffit de connaître toutes les sorties de la transaction spécifiée par (.

![Explication des Covenants : Comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp(

) OP_CTV

OP_CHECKTEMPLATEVERIFY(CTV), c'est BIP-119, qui utilise un code opération amélioré.