1. Introduction
Le modèle de sortie de transaction non dépensée (UTXO) de Bitcoin, bien qu'élégant pour le transfert concurrent de monnaie, présente des limitations significatives pour la mise en œuvre de contrats intelligents complexes avec état, en raison de l'absence d'état mutable partagé. Les covenants émergent comme une primitive linguistique cruciale proposée pour étendre le langage de script Bitcoin, permettant à une transaction d'imposer des contraintes sur les scripts des transactions de dépense futures. Cet article comble le manque de modèles formels et abstraits pour les covenants, qui ont été principalement décrits depuis leur apparition vers 2013 sous un angle technique et orienté implémentation. En fournissant une base formelle, ce travail vise à simplifier le raisonnement sur les propriétés des contrats, à permettre la spécification de cas d'utilisation avancés au-delà des capacités actuelles de Bitcoin, et à faciliter la conception d'abstractions de programmation de plus haut niveau.
2. Le modèle Bitcoin pur
L'article adapte une formalisation du modèle de transaction central de Bitcoin. Dans le modèle UTXO, l'état de la blockchain est défini par un ensemble de sorties de transaction non dépensées. Chaque sortie contient une valeur (montant de bitcoin) et un scriptPubKey (script de verrouillage) qui spécifie les conditions requises pour la dépenser. Une transaction de dépense fournit un scriptSig (script de déverrouillage) et référence l'UTXO qu'elle souhaite consommer. La validation implique l'exécution des scripts concaténés. De manière cruciale, le script Bitcoin standard est limité : il ne peut pas introspecter ou contraindre la structure de la transaction de dépense au-delà de la vérification de signature et de l'arithmétique/logique de base, empêchant la création de contrats qui imposent des protocoles en plusieurs étapes.
3. Modèle formel des covenants
La contribution principale est un modèle formel qui abstrait les opcodes de covenant proposés (comme OP_CHECKTEMPLATEVERIFY).
3.1. Primitives et syntaxe des covenants
Le modèle introduit des prédicats de covenant comme extensions du langage de script Bitcoin. Un covenant est essentiellement une contrainte $C(T_x, T_{next})$ qui s'évalue à vrai ou faux, où $T_x$ est la transaction actuelle en cours de dépense et $T_{next}$ est la transaction de dépense proposée. Le prédicat peut inspecter des champs de $T_{next}$, tels que ses scripts de sortie, ses montants ou ses verrous temporels (locktimes).
3.2. Sémantique opérationnelle
La règle de validation est étendue : pour une UTXO avec un covenant, la validation d'une transaction de dépense $T_{next}$ nécessite non seulement que son scriptSig satisfasse le scriptPubKey original, mais aussi que le prédicat de covenant $C$ soit vérifié pour la paire $(T_x, T_{next})$. Ceci est formellement défini à l'aide de règles de sémantique opérationnelle qui intègrent la vérification du covenant dans la logique de validation existante de Bitcoin.
3.3. Covenants récursifs et machines à états
Une variante puissante est le covenant récursif, où $C$ peut imposer que la sortie de $T_{next}$ contienne elle-même le même (ou un) covenant $C'$ apparenté. Cela permet la mise en œuvre de machines à états sur Bitcoin : chaque transaction représente une transition d'état, le covenant garantissant que les règles de la machine à états sont suivies à travers une chaîne de transactions. L'article formalise cela comme une séquence de transactions $T_1, T_2, ..., T_n$ où pour chaque $i$, $C(T_i, T_{i+1})$ est vérifié.
4. Spécification de contrats Bitcoin complexes
Le modèle formel est appliqué pour spécifier des contrats actuellement inexprimables ou lourds à mettre en œuvre dans le Bitcoin pur.
4.1. Coffres-forts et retraits différés
Les covenants peuvent créer des "coffres-forts" où les fonds volés peuvent être récupérés. Une transaction peut exiger que tout retrait important doive d'abord aller vers une sortie avec verrouillage temporel, permettant au propriétaire de l'annuler s'il n'était pas autorisé. Ceci est spécifié par un covenant qui vérifie le champ nLockTime et la structure de sortie de $T_{next}$.
4.2. Canaux de paiement et Lightning Network
Bien que le Lightning Network existe, les covenants peuvent simplifier et sécuriser sa construction sous-jacente. Ils peuvent imposer que la transaction de fermeture d'un canal doit être l'état le plus récent, empêchant la diffusion d'anciens états, en contraignant la transaction de dépense à correspondre à une mise à jour pré-signée.
4.3. Primitives de finance décentralisée (DeFi)
Des constructions DeFi simples comme la dette garantie ou les échanges non-custodiaux deviennent possibles. Un covenant peut verrouiller des fonds dans une transaction qui ne peut être dépensée que par une transaction présentant une preuve cryptographique valide de paiement d'une contrepartie ou de liquidation.
5. Primitives de langage de haut niveau
L'article discute de la manière dont les covenants peuvent servir de cible de compilation pour des langages de contrat de haut niveau. Des primitives comme "retirer après le temps T", "dépenser seulement si la contrepartie signe", ou "transiter de l'état A à l'état B" peuvent être directement mappées à des contraintes de covenant spécifiques, élevant le niveau d'abstraction pour les développeurs de contrats Bitcoin.
6. Idée centrale et perspective analytique
Idée centrale : Bartoletti et al. ne proposent pas simplement un autre opcode de covenant ; ils fournissent la théorie formelle manquante qui transforme une astuce ingénieuse en un paradigme de programmation légitime et analysable pour Bitcoin. C'est la clé qui déverrouille l'ingénierie systématique de contrats complexes et sécurisés sur les blockchains UTXO, dépassant le scripting ad-hoc.
Flux logique : L'argument est d'une simplicité convaincante : 1) Le modèle UTXO de Bitcoin manque d'état, limitant les contrats. 2) Les covenants proposés comme solution sont mal compris formellement. 3) Par conséquent, nous construisons un modèle formel. 4) En utilisant ce modèle, nous démontrons qu'il peut exprimer des cas d'utilisation complexes et précieux (coffres-forts, canaux, DeFi). 5) Ce formalisme permet alors naturellement la conception de langages de plus haut niveau. C'est un pipeline classique "la théorie permet la pratique" exécuté avec précision.
Forces et faiblesses : La force majeure est de combler le fossé entre la théorie cryptographique/des langages de programmation et l'ingénierie Bitcoin — un fossé qui a conduit à des bugs coûteux dans le modèle basé sur les comptes d'Ethereum. La sémantique formelle permet la vérification de propriétés, un avantage considérable. La faiblesse, implicitement reconnue, est l'économie politique de Bitcoin. Comme le note l'article, l'"approche extrêmement prudente" de Bitcoin rend le déploiement de nouveaux opcodes comme les covenants une tâche herculéenne, indépendamment de leur élégance formelle. Le succès des solutions de couche 2 comme Lightning sans covenants natifs soulève également des questions sur la nécessité par rapport à l'utilité. De plus, la sécurité du modèle repose sur l'hypothèse que les champs contraints (comme les hachages de script) sont suffisants ; des effets d'interaction imprévus avec d'autres opcodes pourraient subsister.
Perspectives actionnables : Pour les chercheurs, cet article est un plan : utiliser les méthodes formelles pour réduire les risques et clarifier les mises à niveau de la blockchain. Pour les développeurs, commencez à concevoir des cadres de contrat dès maintenant en supposant que les covenants existeront (comme on le voit sur Liquid ou Stacks). Pour les développeurs du protocole Bitcoin, l'article fournit la base rigoureuse nécessaire pour défendre la BIP 119 (OP_CTV) ou des propositions similaires — il transforme une demande de fonctionnalité en une spécification d'ingénierie. Le principal enseignement : l'avenir des contrats intelligents Bitcoin ne consiste pas à imiter Ethereum, mais à tirer parti du paradigme unique UTXO + covenants pour créer une nouvelle classe d'applications décentralisées, potentiellement plus sécurisées et évolutives.
7. Détails techniques et formalisation
Le modèle formel définit les transactions, les scripts et la validation de manière contextuelle. Un détail technique clé est la représentation de la contrainte de covenant. Soit $\texttt{tx}$ représentant une transaction. Un covenant peut être vu comme une fonction :
$\text{Covenant}_{\text{cond}} : \texttt{tx}_{\text{current}} \times \texttt{tx}_{\text{next}} \times \sigma \rightarrow \{\text{True}, \text{False}\}$
où $\sigma$ représente le contexte de validation (hauteur de bloc, etc.). Le prédicat $\text{cond}$ peut être une conjonction de vérifications sur les champs de $\texttt{tx}_{\text{next}}$ :
$\text{cond} \equiv (\texttt{hashOutputs}(\texttt{tx}_{\text{next}}) = H) \land (\texttt{nLockTime}(\texttt{tx}_{\text{next}}) > T) \land ...$
Cela correspond à des propositions comme OP_CHECKTEMPLATEVERIFY, qui pousse un hachage de parties spécifiées de la transaction de dépense sur la pile pour comparaison. La propriété récursive est formalisée en s'assurant qu'une sortie de $\texttt{tx}_{\text{next}}$ contient un script $S'$ qui impose lui-même un covenant $\text{Covenant}_{\text{cond}'}$.
8. Cadre d'analyse et exemple de cas
Exemple : Un contrat de coffre-fort simple
Objectif : Créer une UTXO qui peut être dépensée de deux manières : 1) Instantanément, mais uniquement vers une adresse spécifique de "stockage à froid". 2) Vers n'importe quelle adresse, mais seulement après un délai de 30 jours (permettant l'annulation en cas de vol).
Application du cadre utilisant le modèle formel :
1. Script de verrouillage initial (scriptPubKey) : Contient une condition de covenant $C_1$.
2. Covenant $C_1(T_{vault}, T_{spend})$ : Doit s'évaluer à Vrai. Il vérifie :
a) Chemin A (Instantané) : $\texttt{hashOutputs}(T_{spend}) = H_{cold}$ // La sortie doit correspondre au hachage de l'adresse de stockage à froid pré-engagée.
b) Chemin B (Différé) : $\texttt{nLockTime}(T_{spend}) \geq \text{currentBlock} + 4320$ (30 jours en blocs) ET $\texttt{hashOutputs}(T_{spend})$ peut être n'importe quoi.
3. Validation : Lors de la dépense de l'UTXO du coffre-fort avec $T_{spend}$, le nœud Bitcoin exécute le script. Il nécessite une signature du propriétaire du coffre-fort et vérifie que $C_1$ est vérifié pour la paire de transactions.
Cet exemple démontre comment le prédicat $C(T_x, T_{next})$ du modèle formel est instancié avec des vérifications concrètes sur les champs de la transaction suivante, permettant une propriété de sécurité (récupération après vol) impossible dans le Bitcoin de base.
9. Applications futures et orientations
La formalisation ouvre plusieurs voies futures :
- Compilateurs vérifiés : Construire des compilateurs depuis des langages de haut niveau (comme Simplicity ou des extensions de Miniscript) vers du script Bitcoin intégrant des covenants, avec des preuves formelles de correction.
- Covenants inter-chaînes : Explorer des covenants qui conditionnent les dépenses à des événements provenant d'autres blockchains ou oracles, en utilisant des preuves cryptographiques comme les SPV, comme suggéré par des travaux antérieurs sur les "ponts" et des recherches récentes sur les rollups.
- Covenants préservant la confidentialité : Intégrer les vérifications de covenant avec des preuves à divulgation nulle de connaissance (par exemple, en utilisant les signatures Taproot/Schnorr) pour masquer la logique du contrat tout en l'appliquant, une direction explorée dans des projets comme Ark.
- Analyse de sécurité formelle : Utiliser le modèle pour analyser systématiquement la sécurité des constructions de covenant proposées contre les attaques économiques et cryptographiques, similaire au travail effectué sur les contrats intelligents d'Ethereum par la communauté de l'IEEE Symposium on Security and Privacy.
- Simplification des protocoles de couche 2 : Reconcevoir des protocoles comme le Lightning Network ou les sidechains (Liquid) pour les rendre plus efficaces et minimiser la confiance en tirant parti des covenants natifs, réduisant le besoin de tours de guet complexes ou de fédérations.
10. Références
- M. Bartoletti, S. Lande, R. Zunino. Bitcoin covenants unchained. arXiv:2006.03918v2 [cs.PL]. 2020.
- S. Nakamoto. Bitcoin : A Peer-to-Peer Electronic Cash System. 2008.
- J. Poon, T. Dryja. The Bitcoin Lightning Network : Scalable Off-Chain Instant Payments. 2016.
- M. Moser, I. Eyal, E. G. Sirer. Bitcoin Covenants. Financial Cryptography 2016 Workshops.
- Bitcoin Improvement Proposal 119 (BIP 119). OP_CHECKTEMPLATEVERIFY.
- G. Wood. Ethereum : A Secure Decentralised Generalised Transaction Ledger. Ethereum Yellow Paper. 2014.
- A. Miller, et al. Hashed Timelock Contracts (HTLCs). 2017.
- R. O'Connor. Simplicity : A New Language for Blockchains. Proceedings of the 2017 Workshop on Programming Languages and Analysis for Security.
- Blockstream. Liquid Network. https://blockstream.com/liquid/
- IEEE Symposium on Security and Privacy. Multiple papers on smart contract security analysis. Various years.