Covenants : la programmabilité du Bitcoin
TechFlow SélectionTechFlow Sélection
Covenants : la programmabilité du Bitcoin
Quelles sont exactement les « clauses limitatives » du bitcoin ?
Dédié à des analyses Web3 approfondiesAuteurs : Jeffrey HU, responsable de la recherche d'investissement chez HashKey Capital ; Harper LI, gestionnaire d'investissement chez HashKey Capital
Récemment, une discussion a émergé au sein de la communauté Bitcoin sur la réactivation d'opcodes tels qu'OP_CAT. Taproot Wizard a également attiré beaucoup d'attention en lançant les NFT Quantum Cats et en affirmant avoir obtenu le numéro BIP-420. Les partisans affirment que l'activation d'OP_CAT permettrait de mettre en œuvre des « covenants » (clauses restrictives), rendant ainsi Bitcoin programmable ou doté de contrats intelligents.
Si vous remarquez le terme « covenant » et effectuez une petite recherche, vous découvrirez qu'il s'agit d'un sujet bien plus vaste. Les développeurs en discutent depuis des années : outre OP_CAT, il existe d'autres technologies comme OP_CTV, APO, OP_VAULT, etc., toutes destinées à implémenter des covenants.
Qu'est-ce qu'un « covenant » sur Bitcoin exactement ? Pourquoi attire-t-il autant l'attention des développeurs depuis plusieurs années ? Quelles formes de programmabilité peut-il offrir à Bitcoin ? Et quel est le principe fondamental de son architecture ? Cet article propose un aperçu général et une discussion introductive.
Qu'est-ce qu'un « covenant » ?
Les « covenants », traduits en français par « clauses restrictives » ou parfois « pactes », sont un mécanisme permettant de fixer des conditions pour les futures transactions Bitcoin.
Actuellement, les scripts Bitcoin contiennent déjà certaines conditions restrictives, telles que la nécessité de fournir une signature valide ou un script conforme lors d'une dépense. Toutefois, tant que l'utilisateur peut déverrouiller les fonds, il peut envoyer cet UTXO n'importe où.
Un covenant va plus loin : au-delà des conditions de déblocage, il impose des restrictions supplémentaires sur la manière dont l'UTXO peut être dépensé ultérieurement, créant ainsi un effet de type « usage spécifique » ; il peut aussi imposer des conditions sur d'autres entrées dans une même transaction.
Plus précisément, les scripts Bitcoin actuels intègrent déjà certains covenants rudimentaires. Par exemple, les verrous temporels basés sur des opcodes exploitent l'introspection du champ nLock ou nSequence de la transaction pour limiter leur dépense avant un certain délai, mais ces restrictions se limitent essentiellement au temps.
Pourquoi les chercheurs et développeurs conçoivent-ils ces vérifications restrictives ? Car les covenants ne visent pas la restriction pour elle-même, mais définissent des règles d'exécution des transactions. Ainsi, les utilisateurs ne peuvent exécuter des transactions que selon des règles prédéfinies, permettant ainsi de mener à bien des processus métier spécifiques.
De manière contre-intuitive, cela permet en réalité d'ouvrir davantage de cas d'utilisation.
Cas d'utilisation
Garantir les pénalités du Staking
Un exemple très parlant de covenant est la transaction de slashing mise en œuvre par Babylon dans son processus de staking Bitcoin.
Dans le staking Bitcoin de Babylon, l'utilisateur envoie ses BTC sur la chaîne principale vers un script spécial avec deux conditions de dépense :
-
Fin heureuse : après un certain temps, l'utilisateur peut débloquer les fonds avec sa propre signature, complétant ainsi le retrait (unstake)
-
Mauvaise fin : si l'utilisateur commet une faute (double-signature, etc.) sur une blockchain PoS qui loue la sécurité de Babylon, alors grâce aux EOTS (signatures extractables à usage unique), les fonds peuvent être débloqués et une partie forcée vers une adresse de brûlage (slashing) par un acteur du réseau
Source : Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy
Notez ici le mot « forcé » : même si l'UTXO peut être déverrouillé, les fonds ne peuvent pas être envoyés librement, mais uniquement brûlés. Cela garantit qu'un utilisateur malveillant ne puisse pas utiliser sa signature connue pour transférer les fonds avant le slashing et ainsi échapper à la punition.
Une fois OP_CTV ou d'autres covenants activés, cette fonctionnalité pourrait être réalisée en ajoutant OP_CTV dans la branche « mauvaise fin » du script de staking.
Avant l'activation d'OP_CTV, Babylon doit recourir à une méthode détournée, combinant l'action de l'utilisateur et celle d'un comité pour simuler l'effet d'exécution forcée d'un covenant.
Contrôle de congestion
En général, la congestion survient lorsque les frais de transaction sur le réseau Bitcoin sont élevés et que de nombreuses transactions attendent dans la mempool. Pour confirmer rapidement une transaction, l'utilisateur doit alors augmenter ses frais.
Dans ce contexte, si un utilisateur doit envoyer plusieurs transactions à plusieurs destinataires, il doit supporter des coûts élevés. En outre, cela contribue à faire grimper encore davantage les frais moyens du réseau.
Grâce aux covenants, une solution consiste à ce que l'expéditeur s'engage préalablement sur une transaction de paiement groupé. Cet engagement rassure tous les destinataires : ils savent que leurs paiements seront bien effectués, et peuvent attendre une période de faibles frais avant d'envoyer les transactions individuelles.
Comme illustré ci-dessous, lorsque la demande d'espace dans les blocs est forte, les transactions deviennent très coûteuses. Grâce à OP_CHECKTEMPLATEVERIFY, un processeur de paiements massifs peut regrouper tous ses paiements en une seule transaction O(1) pour confirmation. Plus tard, lorsque la demande diminue, les paiements peuvent être extraits de cet UTXO.
Source : https://utxos.org/uses/scaling/
Ce scénario constitue l'un des cas d'usage typiques avancés pour justifier OP_CTV. D'autres exemples figurent sur https://utxos.org/uses/ : Paris sur bifurcation douce, Options décentralisées, Drivechains, Canaux groupés, Canaux non interactifs, Pools d'extraction sans confiance ni coordination, Vaults, Contrats Hashed Time-Locked (HTLC) plus sûrs, etc.
Coffres-forts (Vaults)
Les coffres-forts (vaults) constituent un cas d'usage fréquemment discuté dans les applications Bitcoin, particulièrement dans le domaine des covenants. En effet, l'équilibre entre sécurité de conservation et facilité d'utilisation étant inévitable, on souhaite disposer d'applications capables de protéger les fonds, voire de limiter leur utilisation même en cas de compromission du compte (fuite de clé privée).
Grâce aux technologies de mise en œuvre des covenants, de telles applications deviennent relativement faciles à construire.
Prenons l'exemple du design proposé par OP_VAULT : pour dépenser les fonds d’un coffre, une première transaction doit être publiée sur la chaîne. Elle exprime l'intention de dépenser (le « trigger ») et inclut certaines conditions :
-
Si tout va bien, une deuxième transaction effectue le retrait final. Après N blocs, les fonds peuvent être dépensés librement
-
Si l'on soupçonne que cette transaction a été volée (ou extorquée sous menace), avant que la transaction de retrait ne soit confirmée, les fonds peuvent être transférés vers une autre adresse sécurisée (mieux protégée par l'utilisateur)
Processus OP_VAULT, source : BIP-345
Il convient de noter qu'en l'absence de covenants, il est possible de concevoir un système de coffre-fort, par exemple en préparant les signatures nécessaires pour les dépenses futures, puis en détruisant la clé privée. Toutefois, cette méthode présente plusieurs limitations : garantir la destruction complète de la clé (semblable au trusted setup en preuve à divulgation nulle), montants et frais fixes à l'avance (pré-signature), manque de flexibilité, etc.
Comparaison entre OP_VAULT et coffre-fort par pré-signature, source : BIP-345
Canaux d'état plus robustes et flexibles
On considère généralement que les canaux d'état, y compris le réseau Lightning, offrent une sécurité proche de celle de la chaîne principale (sous réserve que les nœuds puissent observer l'état le plus récent et publier correctement cet état). Toutefois, avec les covenants, de nouvelles idées de conception peuvent rendre ces canaux encore plus robustes ou flexibles. Parmi les propositions notables figurent Eltoo et Ark.
Eltoo (aussi appelé LN-Symmetry) est un exemple emblématique. Ce schéma, jeu de mots sur « L2 », propose une couche d'exécution pour Lightning permettant à tout nouvel état de canal de remplacer l'état précédent, sans mécanisme de pénalité, évitant ainsi aux nœuds de Lightning de devoir conserver de nombreux états antérieurs pour se prémunir contre les attaques. Pour atteindre cet objectif, Eltoo repose sur une méthode de signature SIGHASH_NOINPUT, connue sous le nom d'APO (BIP-118).
Quant à Ark, il vise à réduire la difficulté liée à la liquidité entrante et à la gestion des canaux sur Lightning. Il s'agit d'un protocole de type joinpool : plusieurs utilisateurs peuvent accepter un fournisseur de services comme contrepartie pendant une période donnée, effectuant des transactions hors chaîne avec des UTXO virtuels (vUTXO), tout en partageant un seul UTXO sur chaîne pour réduire les coûts. Comme pour les vaults, Ark peut être implémenté sur le réseau Bitcoin actuel ; mais avec l'introduction de covenants, Ark pourrait réduire les interactions nécessaires via des modèles de transaction, permettant un retrait unilatéral plus décentralisé.
Aperçu des technologies de covenants
À partir des cas d'usage ci-dessus, on constate que le concept de covenant est plutôt un effet fonctionnel qu'une technologie unique, pouvant être implémenté de multiples façons. On peut les classer selon plusieurs dimensions :
-
Type : générique ou spécialisé
-
Méthode d’implémentation : basée sur des opcodes ou sur des signatures
-
Récursivité : récursive ou non récursive
La récursivité signifie que certains covenants peuvent restreindre non seulement la sortie suivante, mais aussi les sorties ultérieures, permettant ainsi d'imposer des restrictions au-delà d'une seule transaction, atteignant ainsi une profondeur transactionnelle plus importante.
Parmi les principales propositions de covenants, on trouve :
* Récursif : possible en combinaison avec OP_CAT
Conception des covenants
Comme indiqué précédemment, les scripts Bitcoin actuels restreignent principalement les conditions de déblocage, mais ne limitent pas la manière dont l'UTXO sera dépensé par la suite. Pour implémenter des covenants, posons-nous la question inverse : pourquoi les scripts Bitcoin actuels ne permettent-ils pas cela ?
La raison principale est que les scripts Bitcoin actuels ne peuvent pas lire le contenu de la transaction elle-même, c’est-à-dire qu’ils manquent d’« introspection ».
Si nous pouvions réaliser l’introspection de la transaction — inspecter n’importe quelle partie, y compris les sorties — alors les covenants deviendraient possibles.
Par conséquent, la conception des covenants tourne principalement autour de la manière d’activer cette introspection.
Basé sur opcode vs basé sur signature
L'idée la plus simple serait d'ajouter un ou plusieurs opcodes (un opcode avec différents paramètres, ou plusieurs opcodes à fonctions distinctes) capables de lire directement le contenu de la transaction. C'est l'approche basée sur les opcodes.
Une autre approche consiste à ne pas lire directement le contenu de la transaction dans le script, mais à exploiter le hachage du contenu de la transaction — si ce hachage a déjà été signé, alors en modifiant des opcodes comme OP_CHECKSIG pour vérifier cette signature, on peut indirectement réaliser l’introspection et donc les covenants. Cette méthode, dite « basée sur la signature », inclut notamment APO et OP_CSFS.
APO
SIGHASH_ANYPREVOUT (APO) est une proposition de nouveau mode de signature Bitcoin. La méthode la plus simple consiste à signer tous les éléments d'entrée et de sortie de la transaction, mais Bitcoin offre des options plus souples via SIGHASH, permettant de choisir sélectivement quelles parties signer.
Portée actuelle des signatures SIGHASH et combinaisons (source : Mastering Bitcoin, 2nd edition)
Comme illustré ci-dessus, outre ALL (toutes données), NONE signe uniquement les entrées, pas les sorties ; SINGLE signe uniquement la sortie correspondant au même index d'entrée. De plus, les modes SIGHASH peuvent être combinés, et avec le modificateur ANYONECANPAY, ils ne s'appliquent qu'à une seule entrée.
En revanche, APO signe uniquement les sorties, sans signer les entrées. Cela signifie qu’une transaction signée avec APO peut être attachée ultérieurement à n’importe quel UTXO satisfaisant les conditions.
Cette flexibilité constitue la base théorique d’APO pour implémenter les covenants :
-
Créer à l’avance une ou plusieurs transactions
-
Construire une clé publique qui ne peut produire qu’une seule signature, basée sur les informations de ces transactions
-
Tout fond envoyé à cette adresse publique ne pourra être dépensé que via les transactions prédéfinies
Notons que cette clé publique n’a pas de clé privée correspondante, garantissant ainsi que les fonds ne peuvent être dépensés que selon les transactions préétablies. En définissant à l’avance la destination des fonds dans ces transactions, on réalise un covenant.
On peut mieux comprendre cela en comparant avec les contrats intelligents Ethereum : un contrat permet de retirer des fonds uniquement sous certaines conditions, et non par simple signature d’un EOA. Bitcoin peut donc atteindre un effet similaire grâce à une amélioration du mécanisme de signature.
Toutefois, ce processus souffre d’un problème de dépendance circulaire : pour pré-signer une transaction, il faut connaître son contenu d’entrée.
Le sens d’APO et de SIGHASH_NOINPUT est précisément de résoudre ce problème : ils permettent de calculer la signature en ne connaissant que les sorties (ou en les spécifiant à l’avance).
OP_CTV
OP_CHECKTEMPLATEVERIFY (CTV), également connu sous le nom de BIP-119, adopte une approche par amélioration d’opcode. Il prend un hash d’engagement comme paramètre et exige que toute transaction exécutant cet opcode contienne un ensemble de sorties correspondant à cet engagement. CTV permettrait ainsi aux utilisateurs de Bitcoin de restreindre l’utilisation de leurs bitcoins.
Initialement proposé sous le nom d’OP_CHECKOUTPUTSHASHVERIFY (COSHV), ce projet se concentrait d’abord sur la création de transactions de contrôle de congestion, suscitant des critiques quant à son manque de généralité et à sa focalisation excessive sur ce seul cas d’usage.
Dans le cas de congestion mentionné plus haut, l’expéditrice Alice peut créer 10 sorties, les hacher, puis utiliser ce haché pour créer un script tapleaf incluant COSHV. Elle peut aussi utiliser les clés publiques des participants pour former la clé interne Taproot, leur permettant de coopérer au retrait sans révéler le chemin du script Taproot.
Alice fournit ensuite une copie des 10 sorties à chaque destinataire afin qu’ils puissent vérifier sa transaction de configuration. Plus tard, n’importe lequel d’entre eux pourra créer une transaction incluant les sorties engagées.
Durant tout ce processus, Alice peut transmettre ces 10 sorties via des méthodes de communication asynchrones existantes (email, cloud, etc.). Ainsi, les destinataires n’ont pas besoin d’être en ligne ni d’interagir entre eux.
Source :
https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
Comme APO, l’adresse peut être construite selon les conditions de dépense, permettant diverses formes de « serrures » : ajout de clés, verrous temporels, logique composée.
Source :
https://twitter.com/OwenKemeys/status/1741575353716326835
CTV va plus loin : il permet de vérifier si la transaction de dépense, après hachage, correspond bien à celle définie — utilisant ainsi les données de transaction comme « clé » du déverrouillage.
Reprenons l’exemple des 10 destinataires : chacun peut à son tour transmettre sa clé d’adresse, associée à une transaction signée mais non diffusée, à un nouveau groupe de destinataires, et ainsi de suite, formant une structure arborescente comme ci-dessous. Alice n’utilise qu’un seul UTXO sur la chaîne pour orchestrer des modifications de soldes impliquant de multiples utilisateurs.
Source :
https://twitter.com/OwenKemeys/status/1741575353716326835
Et si l'une des feuilles était un canal Lightning, un stockage froid ou un autre chemin de paiement ? L'arbre passerait d'une structure unidimensionnelle à une structure multidimensionnelle et multicouche, ouvrant des cas d'usage bien plus riches et flexibles.
Source :
https://twitter.com/OwenKemeys/status/1744181234417140076
Depuis sa proposition, CTV a changé de nom en 2019 (de COSHV à CTV), a reçu le numéro BIP-119 en 2020, a vu l’émergence d’un langage de programmation Sapio pour créer des contrats compatibles CTV, et a fait l’objet de nombreuses discussions communautaires en 2022-2023, notamment sur sa stratégie d’activation. Il reste aujourd’hui l’une des propositions de fork doux les plus débattues.
OP_CAT
Comme mentionné en introduction, OP_CAT est une autre proposition d’upgrade très suivie, permettant de concaténer deux éléments sur la pile. Bien que cela paraisse simple, OP_CAT offre une grande flexibilité dans les scripts.
Un exemple direct concerne les opérations sur les arbres de Merkle. Un arbre de Merkle consiste à concaténer deux éléments, puis à les hacher. Puisque les scripts Bitcoin disposent déjà d’opcodes comme OP_SHA256, l’ajout d’OP_CAT permettrait de valider des arbres de Merkle directement dans les scripts, offrant ainsi une forme de capacité de vérification légère (light client).
Autre fondation : l’amélioration des signatures Schnorr. On peut conditionner la signature de dépense à la concaténation de la clé publique de l’utilisateur et d’un nonce public. Si le signataire tente de signer une autre transaction pour dépenser ailleurs, il devra réutiliser le même nonce, exposant ainsi sa clé privée. OP_CAT permet donc d’engager le nonce, assurant ainsi la validité de la transaction signée.
D’autres cas d’usage incluent : Bistream, Arbres de signatures, Signatures Lamport résistantes aux ordinateurs quantiques, les coffres-forts, etc.
OP_CAT n’est pas une nouveauté : il existait dans les premières versions de Bitcoin, mais a été désactivé en 2010 car susceptible d’être exploité pour des attaques, comme documenté ici. Par exemple, répéter OP_DUP et OP_CAT peut facilement provoquer une explosion de la pile sur les nœuds complets, voir ce démo.
Cependant, la réactivation d’OP_CAT aujourd’hui ne poserait plus ce problème d’explosion, car la proposition actuelle limite son activation au tapscript, qui impose une taille maximale de 520 octets par élément de pile. Certains développeurs pensent que Satoshi Nakamoto a peut-être été trop strict en désactivant OP_CAT. Néanmoins, en raison de sa flexibilité, certains cas d’usage menant à des vulnérabilités pourraient encore exister et ne pas être entièrement anticipés.
En somme, OP_CAT attire beaucoup d’attention en raison de ses cas d’usage et de ses risques potentiels. Il a récemment fait l’objet d’un examen de PR et figure parmi les propositions d’amélioration les plus populaires actuellement.
Conclusion
« L’auto-discipline apporte la liberté ». Comme montré ci-dessus, les covenants permettent de restreindre directement dans les scripts Bitcoin la manière dont un UTXO peut être dépensé ultérieurement, implémentant ainsi des règles transactionnelles similaires aux contrats intelligents. Comparé à des solutions hors chaîne comme BitVM, cette approche est plus native sur Bitcoin, et peut améliorer les applications sur chaîne (contrôle de congestion), hors chaîne (canaux d’état), ainsi que de nouveaux axes comme la pénalité de staking.
La combinaison des covenants avec d’autres mises à niveau fondamentales pourrait libérer davantage de potentiel de programmabilité. Par exemple, la proposition récente de review sur les opérateurs 64 bits pourrait être combinée avec des propositions comme OP_TLUV ou d'autres covenants, permettant de programmer selon le nombre de satoshis présents en sortie.
Toutefois, les covenants pourraient aussi entraîner des abus ou des vulnérabilités imprévus, ce qui explique la prudence de la communauté. De plus, leur mise en œuvre nécessiterait un fork doux modifiant les règles de consensus. Étant donné le temps nécessaire pour l’activation de Taproot, les mises à niveau liées aux covenants prendront probablement également du temps.
Remerciements spéciaux
Merci à A Jian, Fisher et Ben pour leurs relectures et suggestions !
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
