La voie vers le calcul universel sur Bitcoin : concevoir STARK pour l'extension de la capacité de Bitcoin
TechFlow SélectionTechFlow Sélection
La voie vers le calcul universel sur Bitcoin : concevoir STARK pour l'extension de la capacité de Bitcoin
Cet article abordera la tâche de mise en œuvre du calcul universel sur Bitcoin et les différentes étapes impliquées.
Dédié à des analyses Web3 approfondiesAuteur : StarkWare
Traduction : Communauté Starknet Chinoise
1. Introduction
Dans cet article, nous discuterons de la tâche consistant à réaliser le calcul universel sur Bitcoin et des différentes étapes impliquées. En effet, permettre l'exécution d'une logique arbitraire dans les scripts Bitcoin est un objectif attrayant, car cela ouvrirait la voie aux applications non détenues (non-custodial) et à la finance décentralisée.
Jusqu'à présent, en raison de deux limitations sévères — la longueur limitée des scripts Bitcoin et l'expressivité réduite des opcodes — le calcul universel sur Bitcoin était presque considéré comme impossible. La première interdit toute transaction comportant autre chose que de courts scripts, tandis que la seconde limite ce que les opcodes du script peuvent calculer. Ces deux contraintes ont ensemble créé une situation très contraignante pour la faisabilité du calcul sur Bitcoin, car de nombreuses applications ne pouvaient être réalisées sous ces conditions.
Cependant, au cours des dernières années, cette situation s'est nettement améliorée. En effet, avec la mise à niveau Taproot en 2021, la restriction sur la longueur des scripts a été levée, permettant aux scripts Bitcoin de devenir significativement plus longs (en fait, les scripts Taproot autorisent même parfois le paiement en chaîne uniquement sur une partie du script, bien que nous n'aborderons pas cette caractéristique ici). De plus, afin de résoudre la limitation d'expressivité des opcodes, nous avons découvert qu'un seul opcode simple suffit pour obtenir effectivement une expressivité infinie.
Cet opcode s'appelle OP_CAT, désactivé depuis 2012 dans les scripts Bitcoin. Il s'agit d'un opcode très simple qui permet de concaténer des éléments sur la pile, nécessitant seulement 13 lignes de code pour être activé de manière non intrusive via un fork doux. Qu’un opcode apparemment aussi modeste puisse libérer un tel potentiel est remarquable, et c’est précisément l’objectif central de cet article que d’en expliquer les raisons.
Nous allons maintenant examiner en détail le processus de calcul sur Bitcoin, en commençant par sa mise en œuvre et ses limites.
Ensuite, nous présenterons deux outils — les Covenants et les preuves STARK — et démontrerons que si ceux-ci peuvent fonctionner dans les scripts Bitcoin, ils permettront le calcul universel sur Bitcoin. De plus, nous argumenterons dans cet article que grâce aux preuves STARK, ce calcul peut acquérir plusieurs propriétés utiles supplémentaires :
-
Évolutivité — Le traitement des transactions et des calculs en chaîne devient possible avec des frais extrêmement faibles.
-
Expressivité — La logique peut être programmée dans différents langages de programmation plus puissants que le script Bitcoin. Cela est crucial pour l'ergonomie et la sécurité de la programmation sur Bitcoin.
-
Sécurité en chaîne — Quel que soit le calcul effectué, le script Bitcoin valide uniquement la preuve mathématique du calcul délégué.
-
Flexibilité — Le calcul sur Bitcoin peut stocker un état global, permettant ainsi un large éventail d'applications.
Enfin, nous discuterons d’OP_CAT et de la manière dont il permet la mise en œuvre de ces outils. Nous mentionnerons également certains efforts que nous avons entrepris dans ce domaine et aborderons les perspectives futures.
Note : Cet article simplifie certains aspects techniques afin de fournir un modèle mental clair. Lorsqu’il s’agit de mettre en œuvre concrètement les idées présentées, « le diable se cache dans les détails ».
2. Modèle UTXO et scripts de verrouillage
Cette section présente brièvement le modèle UTXO de Bitcoin, selon lequel chaque UTXO est verrouillé derrière un script de verrouillage. Si vous êtes déjà familier avec cela, vous pouvez passer directement à la section suivante.
La première étape pour comprendre les transactions Bitcoin consiste à noter qu’elles sont structurées et traitées selon le modèle des sorties de transaction non dépensées (UTXO), illustré à la figure 1. Une transaction Bitcoin peut avoir plusieurs entrées et sorties, chacune représentant une certaine quantité de bitcoins pouvant être dépensée par une autre transaction. Inversement, les entrées d’une transaction représentent la dépense d’une sortie d’une autre transaction Bitcoin. Bien entendu, la somme totale des bitcoins dans les entrées doit être approximativement égale à celle des sorties (la différence correspond aux frais payés aux mineurs).
Figure 1 : Transactions dans le modèle UTXO. Chaque entrée et sortie de transaction est associée à une certaine quantité de bitcoins, où le montant cumulé des sorties ne peut excéder celui des entrées. Les sorties de transaction non dépensées (UTXO) sont indiquées en bleu.
Chaque sortie de transaction est verrouillée par un script de verrouillage (scriptPubKey), qui accepte ou rejette une entrée donnée (scriptSig), fournie par ce que l’on appelle le dépensier. Ainsi, pour transférer des fonds depuis un UTXO, vous devez pouvoir générer le bon scriptSig et inclure cet UTXO comme entrée dans la transaction que vous créez.
Par défaut, le script de verrouillage vérifie simplement une signature numérique par rapport à une clé publique codée en dur, définissant ainsi la propriété des bitcoins verrouillés. Plus généralement, dès qu’un UTXO existe, on peut dire que la personne capable de fournir le bon scriptSig est le propriétaire des bitcoins verrouillés derrière le script correspondant. Par conséquent, le solde total de chaque propriétaire de Bitcoin est déterminé par l’accumulation de tous les UTXO liés à ce propriétaire (par exemple, tous les UTXO signés numériquement par la même personne).
3. Limitations des scripts Bitcoin
La section précédente a décrit brièvement les scripts de verrouillage en général et leur interaction avec les transactions et Bitcoin lui-même. Cette section met l’accent sur le script de verrouillage proprement dit et son contenu.
Les scripts de verrouillage sur Bitcoin sont écrits dans un langage basé sur une pile, similaire à Forth, appelé « script Bitcoin ». Comme le script Bitcoin ne dispose pas de boucles, nous mesurons le coût d’un script par le nombre d’opcodes requis, car la longueur du script est proportionnelle à son temps d’exécution. À la figure 2, nous pouvons voir un schéma d’un programme simple qui vérifie si la somme de deux entrées vaut 12.
Figure 2* : Programme simple vérifiant si la somme de deux valeurs d’entrée est égale à 12. L’exécution du programme se fait en concaténant le scriptSig avec le script de verrouillage lui-même, puis en traitant les opcodes de gauche à droite. Le scriptSig pousse uniquement des éléments sur la pile. (a) Première étape du calcul. (b)* Pendant le calcul. (c) Dernière étape du calcul (le script de verrouillage accepte l’entrée).
Nous devons souligner que les scripts Bitcoin présentent de nombreuses limitations, rendant difficile, voire impossible, le développement de logiques simples. Ces limitations comprennent :
-
Une limite de taille de pile à 1000 éléments maximum.
-
L’absence d’opcode de multiplication (en fait, même la multiplication d’entiers de 31 octets nécessite environ 14 000 opcodes pour être simulée).
-
Pour les sorties de type Pay2Taproot (après la mise à niveau Taproot), le nombre total d’opcodes pouvant tenir dans une seule transaction est d’environ 4 millions, occupant tout un bloc ; pour les autres types de sorties, cette limite est de 10 000 opcodes.
-
Les opérations arithmétiques (addition, soustraction) sont limitées aux éléments de 4 octets.
La restriction de 4 octets mentionnée ci-dessus pose un problème particulier. Cela signifie en pratique que vous ne pouvez pas modifier des éléments longs, tels que ceux de 20 octets ou plus nécessaires aux opérations cryptographiques.
Par exemple, une opération très courante comme la concaténation de données suivie d’une opération cryptographique est impossible à réaliser, sous réserve d’ignorer l’opcode de hachage et de le simuler comme une opération sur des données représentées par un tableau d’éléments de 4 octets. Ce dernier cas est extrêmement coûteux, car une seule opération de hachage peut nécessiter des dizaines de milliers d’opcodes pour être simulée.
Enfin, notons que la difficulté de développement sur script Bitcoin rend naturellement le code plus sujet aux erreurs et vulnérabilités.
4. Défis liés au maintien de l’état dans les scripts Bitcoin
Bien que la section précédente ait montré les lacunes importantes des scripts Bitcoin, nous pensons que la limitation principale des scripts de verrouillage Bitcoin réside dans le fait qu’ils ne peuvent lire que les entrées du dépensier. Cela entraîne deux restrictions sévères :
-
Les scripts Bitcoin ne sont pas étatiques. Autrement dit, ils ne peuvent ni lire ni écrire dans des unités de stockage. Par analogie avec la machine virtuelle Ethereum, il n’existe aucun opcode équivalent à SLOAD/SSTORE, une fonctionnalité fondamentale pour le calcul universel.
-
Les scripts Bitcoin ne peuvent pas imposer comment les bitcoins seront dépensés (à quelques exceptions près). Cela peut être résolu grâce aux Covenants, qui confèrent cette capacité au script de verrouillage. (Vous pouvez imaginer une application simple comme une caisse-forte en chaîne, fonctionnant en restreignant les adresses autorisées à dépenser. Plus généralement, les Covenants constituent un outil extrêmement puissant avec un large champ d’applications.)
Nous verrons ensuite que grâce à la construction de Covenants, nous pouvons déjà obtenir la gestion d’état. Intuitivement, cela vient du fait que vous pouvez utiliser les Covenants pour simuler en lecture et écriture un stockage dans les données mêmes de la transaction.
En réalité, ce qui précède ne couvre pas encore entièrement la complexité des scripts Bitcoin. Mais au moins, nous pouvons affirmer que programmer en script Bitcoin n’est pas chose aisée. Les scripts Bitcoin sont soumis à des contraintes très strictes :
-
Limite de 1000 éléments maximum dans la pile.
-
Multiplication et autres opérations simples doivent être simulées avec de nombreux opcodes. Généralement, vous devez écrire votre logique dans le langage fastidieux du script Bitcoin.
-
Vous devez manipuler des éléments encodés en 4 octets. En particulier, vous ne pouvez pas opérer ni modifier les entrées des opcodes cryptographiques.
-
Votre logique ne peut pas conserver d’état et doit s’adapter à une seule transaction.
-
Une fois authentifiée, votre logique ne peut pas contrôler la manière dont les bitcoins sont dépensés.
De plus, la programmation sous ces contraintes est sujette aux erreurs et vulnérabilités.
Bien que des applications très simples comme les paiements puissent satisfaire ces contraintes, toute application légèrement plus complexe rencontre des obstacles. Dans les sections suivantes, nous verrons comment les Covenants et les preuves STARK peuvent nous aider à surmonter ces limitations. Nous discuterons également de la manière dont OP_CAT peut aider les scripts Bitcoin à réaliser ces fonctionnalités.
5. Réalisation de contrats intelligents sur Bitcoin via les Covenants
Dans cette section, nous verrons comment les Covenants dans Bitcoin permettent de préserver l’état logique, et expliquerons plus largement à quoi ressemblent les « contrats intelligents » sur Bitcoin. Ici, un contrat intelligent désigne une logique étatique contenant une série de fonctions qui peuvent être appelées selon des règles prédéfinies, transformant l’état vers de nouveaux états valides.
Plus précisément, un contrat Bitcoin requiert les fonctionnalités suivantes :
-
Logique et état persistants
-
Capacité à contrôler les changements d’état/logique
Comme mentionné précédemment, ces fonctionnalités peuvent être réalisées grâce aux Covenants. Rappelons que par défaut, un script de verrouillage ne peut lire que les données directement fournies en entrée (scriptSig). Cependant, grâce aux Covenants, le script de verrouillage peut lire tous les champs de données de la transaction du dépensier, les champs de données de la transaction contenant le script de verrouillage, voire d’autres transactions. La figure 3 illustre les différents champs accessibles au script de verrouillage lorsqu’on utilise des Covenants.
Figure 3 : Certains champs de données (flèches rouges) auxquels le script de verrouillage (représenté comme un cadenas) peut accéder. Outre les données de la transaction du dépensier, le script de verrouillage peut lire les données de sa propre transaction (tx1) et celles d’une autre transaction (tx2) également dépensée par le dépensier.
Nous pensons que les Covenants tels que décrits ci-dessus suffisent à construire des contrats intelligents universels sur Bitcoin. En effet, la méthode générale consiste à encoder l’état directement dans les données de la transaction et à vérifier la validité de sa transition vers une nouvelle valeur. Pour ce faire, notre transaction aura deux sorties :
-
La première sortie conserve la logique du contrat (via le script de verrouillage) ainsi que les fonds verrouillés dans le contrat.
-
La deuxième sortie conserve l'état actuel du contrat intelligent. Le script de verrouillage de cet UTXO stocke uniquement l’état et n’est jamais dépensé (les bitcoins qu’il verrouille sont en réalité nuls).
La logique du script de verrouillage appliquera les règles suivantes :
-
La transaction du dépensier doit avoir exactement la même forme (deux sorties uniquement, tous les fonds verrouillés dans la première sortie) ;
-
La première sortie doit avoir la même logique de script de verrouillage ;
-
La deuxième sortie doit représenter un état valide ;
-
Les entrées fournies au script de verrouillage actuel doivent convaincre ce script que la transition de l’état actuel vers le nouvel état est valide (la validité étant définie par le concepteur de la logique).
La figure 4 illustre schématiquement cette structure. Comme l’a écrit Weikeng Chen, plusieurs personnes ont proposé des noms formels pour cette structure, et « state caboose » se distingue comme candidat. Un caboose est un wagon ferroviaire attaché à l’arrière d’un train de marchandises, servant d’espace de travail et de logement pour le personnel.
Figure 4 : Contrat intelligent sur Bitcoin implémenté via des Covenants, suivant le modèle de conception « state caboose ». Le script de verrouillage garantit que la transaction du dépensier a la même forme, le même script de verrouillage, et comporte un nouvel état S’ valide, dont la transition depuis l’état précédent S est elle-même valide.
Prenons un exemple simple : imaginez un contrat intelligent compteur. Son état s’incrémente toujours de la valeur fournie par le dépensier, ce qui revient à appeler une fonction « cumulative ». Ce contrat compteur est illustré à la figure 5.
Figure 5 : Un contrat intelligent simple qui ajoute les entrées (scriptSig) à son état.
Enfin, notons que pour « appeler le contrat » et le faire passer à un nouvel état valide, l’utilisateur doit créer une nouvelle transaction de dépense à chaque appel. Contrairement aux contrats intelligents Ethereum, les contrats Bitcoin sont essentiellement séquentiels, exigeant que la transaction engage à la fois l’état actuel et le nouvel état. Cette propriété séquentielle doit être prise en compte lors de la conception de contrats intelligents sur Bitcoin. Bien qu’il existe des solutions possibles pour atténuer cette contrainte, elles ne seront pas abordées ici.
Globalement, nous avons vu que les Covenants permettent de réaliser des contrats intelligents sur Bitcoin. Théoriquement, lorsque les calculs sont répartis sur suffisamment de transactions, des calculs de durée arbitraire peuvent être effectués sur Bitcoin. Toutefois, l’utilisation exclusive des Covenants reste soumise à la plupart des limitations des scripts Bitcoin : taille limitée de la pile, nombre d’opcodes restreint, et nécessité de programmer selon les contraintes du langage du script Bitcoin.
Dans les sections suivantes, nous explorerons comment le système de preuves STARK peut atténuer ces limitations en réduisant l’empreinte blockchain du calcul sur Bitcoin et en permettant d’écrire des scripts dans des langages totalement différents. Cette approche améliore considérablement l’efficacité et la sécurité de la programmation.
6. Vérificateur STARK pour Bitcoin
Le but de cette section est d’explorer comment effectuer des calculs sur Bitcoin tout en minimisant au maximum la quantité réelle de calcul effectuée dans le script Bitcoin. Notre approche générale repose sur la délégation de calcul : le calcul est déplacé hors chaîne (plusieurs entités pouvant y participer), seule la phase de vérification ayant lieu dans le script Bitcoin en chaîne.
Cela soulève une question : comment garantir que le calcul hors chaîne a été correctement exécuté ? En réalité, une solution naturelle à ce problème est un système de preuve. En termes simples, un système de preuve permet à Alice (le prouveur) de convaincre Bob (le vérificateur) de la véracité d’un énoncé en fournissant une « preuve », avec deux caractéristiques clés :
-
Le vérificateur accomplit beaucoup moins de travail que s’il devait vérifier l’énoncé sans aide.
-
Le vérificateur est protégé contre la tromperie : le prouveur ne peut pas le convaincre d’un énoncé faux.
L’énoncé à prouver peut être presque n’importe quoi, allant de la solution d’un problème difficile à, plus pertinent ici, un exemple de calcul délégué. Plus précisément, Alice prouvera à Bob que f(x)=y, sans que Bob ait besoin de calculer lui-même f(x), comme illustré à la figure 6.
Figure 6 : Système de preuve pour délégation de calcul. Le prouveur calcule y=f(x) et persuade le vérificateur de la justesse de cet énoncé. Le point clé est que si y≠f(x), le prouveur ne peut pas convaincre le vérificateur.
Notre méthode pour réduire l’empreinte du calcul sur la blockchain consiste donc à implémenter un vérificateur de système de preuve dans le script Bitcoin. Ainsi, pour appeler un contrat intelligent, l’appelant fournira une preuve de transition d’état valide, et le contrat intelligent Bitcoin vérifiera la justesse de cette preuve, plutôt que de vérifier directement la transition d’état (voir figure 7).
En outre, cette approche offre un avantage crucial : la logique du script Bitcoin peut rester fixe, indépendante de l’application, ce qui réduit grandement les risques d’erreurs et simplifie l’audit. Cela découle d’un fait simple : le même algorithme de vérification peut valider des énoncés y=f(x) ou y=g(x) sans connaître à l’avance la fonction à calculer.
Figure 7 : Contrat intelligent sur Bitcoin via des Covenants, suivant le modèle « state caboose » de la figure 4, mais doté d’un vérificateur. Cette fois, le script de verrouillage ne vérifie plus directement si la transition de S à S’ est valide, mais valide la preuve de cette transition.
Bien qu’il existe de nombreux systèmes de preuve, nous choisissons d’utiliser le système de preuve STARK (STARK), car il présente plusieurs caractéristiques attrayantes :
-
Sécurité post-quantique
-
Pas de configuration de confiance requise
-
N’introduit aucune hypothèse cryptographique supplémentaire pour Bitcoin
-
Meilleure évolutivité
-
Éprouvé en production, faisant confiance à plus de mille milliards de dollars de règlements
Enfin, comparé à d'autres systèmes de preuve ⬇️
STARK est amical pour Bitcoin, car son composant vérificateur est plus facile à implémenter dans les scripts Bitcoin. Fondamentalement, cela provient du fait que STARK repose principalement sur le hachage, impliquant très peu d’opérations algébriques par rapport aux preuves basées sur des couplages.
Le coût élevé des opérations algébriques dans le script Bitcoin explique pourquoi STARK est adapté à Bitcoin. De plus, la variante Circle-STARK, grâce à son petit champ, est particulièrement adaptée à Bitcoin.
Ainsi, puisque le vérificateur Bitcoin peut relativement facilement valider n’importe quel calcul, nous pouvons choisir quel type de calcul valider. Notamment, cela peut même être un type d’exécution CPU. De plus, nous pouvons concevoir des langages de programmation de haut niveau au-dessus du CPU. Pour cela, chez StarkWare, nous avons développé Cairo, un langage de programmation sécurisé, ergonomique, similaire à Rust, spécialement conçu pour des preuves et vérifications efficaces. Prouver l’exécution de Cairo sur Bitcoin apporterait de grands avantages.
Globalement, en combinant les vérificateurs STARK et les Covenants, nous pouvons réaliser le calcul universel sur Bitcoin. De plus, ce calcul présente les propriétés supplémentaires suivantes :
-
Évolutivité — Le traitement des transactions et des calculs en chaîne devient possible avec des frais extrêmement faibles.
-
Expressivité — La logique peut être programmée dans des langages différents, plus puissants que le script Bitcoin. Cela est crucial pour l’ergonomie et la sécurité de la programmation sur Bitcoin.
-
Sécurité en chaîne — Quel que soit le calcul, le script Bitcoin valide uniquement la preuve mathématique du calcul délégué.
-
Flexibilité — Le calcul sur Bitcoin peut stocker un état global, permettant ainsi de nombreuses applications.
7. Utilisation d’OP_CAT pour la concaténation et autres fonctionnalités
Comme mentionné ci-dessus, OP_CAT est un opcode simple, actuellement désactivé, qui permet de concaténer des éléments sur la pile dans les scripts Bitcoin. L’importance de cet opération simple ne peut être sous-estimée, car elle permet simultanément la mise en œuvre des Covenants et des STARK sur Bitcoin. Voici comment :
-
STARK — Ce n’est pas surprenant. En effet, STARK consiste essentiellement à concaténer des données, puis à les hacher. Comme le hachage est une opération native du script Bitcoin, contrairement aux opérations algébriques, cela permet d’économiser considérablement. Les principales opérations de hachage dans STARK sont la vérification de chemin Merkle (voir figure 8) et la transformation Fiat-Shamir. (En outre, la variante Circle-STARK a un champ de seulement 31 octets, respectant ainsi la limite de 4 octets du script Bitcoin, ce qui en fait un algorithme particulièrement adapté.)
-
Covenants — En 2021, Andrew Poelstra a présenté une idée remarquable : OP_CAT peut permettre de réaliser des Covenants sur Bitcoin via ce que l’on appelle la technique Schnorr, où l’algorithme Schnorr est utilisé pour la signature numérique dans les sorties de type Pay2Taproot (pour d’autres types, on peut utiliser une technique ECDSA similaire, observée par Robin Linus). En bref, pour implémenter des Covenants, nous devons utiliser OP_CHECKSIG, le seul opcode capable de placer des données liées à la transaction du dépensier sur la pile. Ce processus n’est pas trivial, mais avec quelques manipulations, vous pouvez accéder à toutes les données nécessaires.
Concernant ce dernier point, le stockage d’état dans les sorties Pay2Taproot pose certains problèmes techniques. Toutefois, d’autres types de sorties peuvent être utilisés pour stocker l’état, comme Pay2WitnessScriptHash. Cela conduit à la technique du « state caboose » mentionnée précédemment (figures 4 et 5), avec deux sorties dans la transaction.
Figure 8 : *Vérification de chemin Merkle, impliquant des opérations de hachage et de concaténation. Les parties du chemin Merkle (chaînes bleues) sont concaténées puis hachées. Une vérification d’égalité avec la racine Merkle suit. L’opération OP_CAT est notée ||.*
8. État actuel et perspectives futures
Dans un projet open source dirigé par Weikeng Chen et Pinghzou Yuan, nous collaborons pour développer le Bitcoin Wildlife Sanctuary. Deux projets principaux sont inclus :
-
Le vérificateur Circle-STARK, dont une démonstration fonctionnelle peut valider sur le symbole Bitcoin une preuve STARK d’un énoncé simple (relatif aux nombres de Fibonacci). Vous pouvez suivre ses progrès via cette adresse.
-
Un cadre pour Covenants, déjà appliqué à travers un exemple simple de Covenant compteur. Le vérificateur utilise également ce cadre.
Grâce à ces efforts, notre objectif est d’apporter à Bitcoin des contrats intelligents OP_CAT efficaces, sécurisés et conviviaux pour les développeurs. Nous pensons que cela représente un avenir prometteur et passionnant pour le domaine du calcul sur Bitcoin.
9. Conclusion
En résumé, à travers cet article, nous avons appris que :
-
Les Covenants sont un outil puissant des scripts Bitcoin, permettant de créer des contrats intelligents sur Bitcoin. Ils
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
@StarkWareLtd
