1 Introduction

Pour un algorithme f, deux participants mutuellement méfiants, Alice et Bob, peuvent établir la confiance de la manière suivante :

1. Alice saisit x, exécute l'algorithme f et obtient le résultat y. Bob exécute également l'algorithme f avec la même entrée x, ce qui donne y′. Si y = y′, alors Bob reconnaît l'entrée x fournie par Alice et la sortie y. Il s'agit d'un mécanisme spécial de preuve de validité couramment utilisé dans le consensus blockchain, où Alice est le nœud qui emballe le bloc et Bob est le nœud participant au consensus.
2. Alice entre x, exécute le programme zk.prove sur l'algorithme f, et obtient le résultat y et la preuve proof. Bob exécute le programme zk.verify basé sur f, y et la preuve. Si le résultat est vrai, alors Bob reconnaît le résultat y d'Alice ; si le résultat est faux, alors Bob ne reconnaît pas le résultat y d'Alice. Il s'agit d'une preuve de validité, où Bob peut être un contrat sur chaîne.
3. Alice saisit x, exécute l'algorithme f et obtient le résultat y. Bob exécute également l'algorithme f avec la même entrée x, ce qui donne y'. Si y = y', rien n'est fait ; si y ≠ y', Bob défie Alice, le programme contesté étant f. Le nombre d'interactions entre Alice et Bob peut être unique ou multiple. L'arbitrage est réalisé grâce au processus de défi-réponse. Il s'agit d'une preuve de fraude, où Bob est le challenger, écoutant hors chaîne et défiant sur chaîne.
4. Alice entre x, exécute le programme zk.prove sur l'algorithme f et obtient le résultat y et la preuve proof. Bob exécute le programme zk.verify basé sur f, y et la preuve. Si le résultat est vrai, alors rien n'est fait ; si le résultat est faux, alors Bob met au défi Alice, avec le programme mis en cause étant zk.verify. Le nombre d'interactions entre Alice et Bob peut être unique ou multiple. L'arbitrage est réalisé grâce au processus de défi-réponse. Il s'agit d'une preuve de fraude, où Bob est le challenger, écoutant hors chaîne et mettant au défi sur la chaîne.

Pour les points 2, 3 et 4 ci-dessus, soit x les transactions Layer 2 et l'état initial, f le programme de consensus Layer 2 et y l'état final de la transaction, correspondant à la solution de mise à l'échelle de la couche 2 de la blockchain. Parmi eux :

• Preuve de validité : Basée sur une hypothèse pessimiste, elle doit être prouvée valide avant d'être acceptée, et elle prend effet immédiatement. Dans une preuve de validité, des preuves de transitions d'état L2 correctes doivent être fournies, reflétant une vision pessimiste du monde—seul un état prouvé correct sera accepté.
• Preuve de fraude : Sur la base d'une hypothèse optimiste, elle est acceptée par défaut sauf si quelqu'un prouve qu'elle est incorrecte. Elle dispose d'une période de défi, qui n'entre en vigueur qu'après la période de défi. Dans une preuve de fraude, il faut fournir des preuves de transitions d'état L2 incorrectes, reflétant une vision optimiste du monde - une transition d'état est considérée comme correcte sauf preuve du contraire.

Tableau 1 : Moyens d'établir la confiance

De plus, il est important de noter:

• La clé pour distinguer entre les preuves de fraude et les preuves de validité ne réside pas dans l'utilisation des systèmes de preuve ZK tels que SNARK/STARK. Le système de preuve ZK exprime la méthode de preuve utilisée, tandis que la fraude ou la validité représente le contenu prouvé. C'est pourquoi le scénario 1 dans le Tableau 1 est dit représenter une preuve de validité.
• Les preuves de validité ont une meilleure rapidité, mais la complexité de la vérification on-chain est relativement élevée ; les preuves de fraude ont une complexité de vérification on-chain plus faible, mais leur rapidité est relativement faible.
• Pour les cas 2 et 4 du Tableau 1, en utilisant la récursivité ZK et les techniques de combinaison, plusieurs f peuvent être calculées et compressées, ce qui réduit significativement le coût de vérification de la computation hors chaîne sur la chaîne.

Actuellement, grâce aux contrats intelligents Turing-complets de Solidity, les preuves de fraude et les technologies de preuve de validité sont largement utilisées dans l'évolutivité de la couche 2 d'Ethereum. Cependant, dans le paradigme Bitcoin, limité par la fonctionnalité opcode limitée de Bitcoin, les 1000 éléments de pile et d'autres restrictions, l'application de ces technologies est encore à l'étape exploratoire. Cet article résume les limites et les technologies innovantes dans le contexte de l'évolutivité de la couche 2 de Bitcoin, étudie les technologies de preuve de validité et de preuve de fraude, et présente la technologie unique de segmentation de script dans le paradigme Bitcoin.

2 Limitations et percées sous le paradigme Bitcoin

Il y a de nombreuses limitations dans le paradigme Bitcoin, mais diverses méthodes ou techniques astucieuses peuvent être utilisées pour les surmonter. Par exemple, l'engagement de bits peut contourner la limitation sans état de l'UTXO, Taproot peut contourner les limitations de l'espace de script, la sortie du connecteur peut contourner les limitations de la méthode de dépense de l'UTXO et les contrats peuvent contourner les limitations de la pré-signature.

Modèle UTXO 2.1 et limitations de script

Bitcoin adopte le modèle UTXO, où chaque UTXO est verrouillé dans un script de verrouillage qui définit les conditions qui doivent être remplies pour dépenser cet UTXO. Les scripts Bitcoin ont les limitations suivantes:

1. Les scripts Bitcoin sont sans état;
2. Pour les types de sortie P2TR, le nombre maximal d'opcodes pouvant être pris en charge dans une seule transaction est d'environ 4 millions, remplissant tout le bloc, tandis que pour les autres types de sortie, il n'y a que 10 000 opcodes;
3. Les méthodes de dépense d'un seul UTXO sont limitées, manquant d'exploration des méthodes de dépense combinées;
4. Les fonctions de contrat flexibles ne sont pas prises en charge;
5. La taille de la pile est limitée à un maximum de 1000 éléments (altstack + pile), et la taille maximale d'un seul élément est de 520 octets;
6. Les opérations arithmétiques (telles que l'addition et la soustraction) sont limitées aux éléments de 4 octets. Ils ne peuvent pas être modifiés en éléments longs, tels que 20 octets ou plus, qui sont nécessaires pour les opérations cryptographiques.
7. Les opcodes tels que OPMUL et OPCAT ont été désactivés, et les simuler avec les opcodes existants entraîne des coûts extrêmement élevés, comme simuler un hachage BLAKE3 d'un tour, avec une taille de script d'environ 75K.

2.2 Engagement Bit : Dépasser la limitation sans état de l'UTXO

Actuellement, les scripts Bitcoin sont entièrement sans état. Lors de l'exécution d'un script Bitcoin, son environnement d'exécution est réinitialisé après chaque script. Cela conduit à l'incapacité des scripts Bitcoin de prendre en charge nativement les scripts de contrainte 1 et 2 ayant la même valeur x. Cependant, ce problème peut être contourné grâce à certaines méthodes, l'idée centrale étant de signer une valeur d'une certaine manière. Si une signature peut être créée pour une valeur, il est possible d'obtenir des scripts Bitcoin étatiques. C'est-à-dire qu'en vérifiant la signature de la valeur x dans les scripts 1 et 2, il est possible d'imposer l'utilisation de la même valeur x dans les deux scripts. Si une signature en conflit est présente, ce qui signifie que deux valeurs différentes sont signées pour la même variable x, une pénalité peut être appliquée. Cette solution est connue sous le nom d'engagement de bit.

Le principe de l'engagement de bit est relativement simple. Un bit fait référence à la définition de deux valeurs de hachage différentes, hach0 et hach1, pour chaque bit dans le message à signer. Si la valeur du bit à signer est 0, le pré-image0 de hach0 est révélé; si la valeur du bit à signer est 1, le pré-image1 de hach1 est révélé.

En prenant un seul message de bit m ∈{0,1} comme exemple, le script de déverrouillage d'engagement de bit correspondant est juste quelques préimages : si la valeur du bit est 0, le script de déverrouillage correspondant est preimage0—"0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140" ; si la valeur du bit est 1, le script de déverrouillage correspondant est preimage1—"0x47c31e611a3bd2f3a7a42207613046703fa27496". Par conséquent, avec l'engagement de bit, il est possible de contourner la limitation sans état de l'UTXO et d'atteindre des scripts Bitcoin étatiques, rendant possible diverses nouvelles fonctionnalités intéressantes.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Ceci est le hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Ceci est hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// La valeur de l'engagement de bits est maintenant sur la pile. Soit «0» soit «1».

Actuellement, il existe 2 implémentations d'engagement de bits :

• Signature à usage unique de Lamport : Le principe est relativement simple et ne nécessite que l'utilisation de fonctions de hachage, ce qui le rend compatible avec Bitcoin. Pour chaque bit du message, deux valeurs de hachage doivent être engagées, ce qui entraîne des données de signature relativement importantes. En d'autres termes, pour un message de longueur v bits, la longueur de la clé publique est de 2v bits, et la longueur de la signature est de v bits.
• Signature à usage unique de Winternitz : Comparé aux signatures Lamport, il réduit significativement la longueur des signatures et des clés publiques mais augmente la complexité de la signature et de la vérification. Ce schéma permet de paramétrer de manière flexible les longueurs de chaînes de hachage différentes d, équilibrant ainsi longueur et complexité. Par exemple, en fixant d = 15, la longueur de la clé publique et de la signature est réduite d'environ 4 fois, mais la complexité de la vérification augmentera de 4 fois. Il s'agit essentiellement d'un compromis entre l'espace de la pile de Bitcoin et la taille du script. Les signatures Lamport peuvent être considérées comme un cas particulier des signatures Winternitz lorsque d = 1.

Actuellement, la bibliothèque BitVM2 implémente les signatures Winternitz basées sur la fonction de hachage Blake3. La longueur de la signature correspondant à un seul bit est d’environ 26 octets. Par conséquent, on peut voir que l’introduction de l’état par le biais de l’engagement binaire est coûteuse. Ainsi, dans l’implémentation BitVM2, le message est d’abord haché pour obtenir une valeur de hachage de 256 bits, puis l’engagement de bits est effectué sur la valeur de hachage pour économiser la surcharge, plutôt que de s’engager directement sur chaque bit du message plus long d’origine.

2.3 Taproot: Dépasser les Limitations de l'Espace de Script

La mise à niveau du soft fork Bitcoin Taproot, activée en novembre 2021, comprend trois propositions : les signatures Schnorr (BIP 340), Taproot (BIP 341) et TapScript (BIP 342). Elle introduit un nouveau type de transaction - les transactions Pay-to-Taproot (P2TR). Les transactions P2TR peuvent créer un format de transaction plus privé, flexible et évolutif en combinant les avantages de Taproot, MAST (Merkel Abstract Syntax Tree) et des signatures Schnorr.

P2TR prend en charge deux méthodes de dépense : dépenser selon le chemin de clé ou le chemin de script.

Selon les dispositions de Taproot (BIP 341), lors des dépenses via le chemin de script, le chemin de Merkle correspondant ne peut pas dépasser une longueur maximale de 128. Cela signifie que le nombre de feuilles de robinet dans l'arbre de robinet ne peut pas dépasser 2^128. Depuis la mise à niveau de SegWit en 2017, le réseau Bitcoin mesure la taille des blocs en unités de poids, avec un support maximal de 4 millions d'unités de poids (environ 4 Mo). Lorsqu'une sortie P2TR est dépensée via le chemin de script, il suffit de révéler un seul script de feuille de robinet, ce qui signifie que le bloc est emballé avec un seul script de feuille de robinet. Cela implique que pour les transactions P2TR, la taille du script correspondant à chaque feuille de robinet peut être maximale d'environ 4 Mo. Cependant, selon la politique par défaut de Bitcoin, de nombreux nœuds ne transmettent que des transactions de moins de 400 Ko ; les transactions plus volumineuses doivent collaborer avec les mineurs pour être emballées.

L'espace de script premium apporté par Taproot le rend plus précieux pour simuler des opérations cryptographiques telles que la multiplication et le hachage à l'aide des opcodes existants.

Lors de la création d’un calcul vérifiable basé sur P2TR, la taille de script correspondante n’est plus limitée à la contrainte de 4 Mo, mais peut être divisée en plusieurs sous-fonctions réparties sur plusieurs feuilles de contact, brisant ainsi la limite d’espace de script de 4 Mo. En fait, l’algorithme de vérification Groth16 implémenté dans le BitVM2 actuel a une taille allant jusqu’à 2 Go. Cependant, il peut être divisé et distribué sur environ 1000 feuilles pivotantes, et en le combinant avec l’engagement de bits, la cohérence entre les entrées et les sorties de chaque sous-fonction peut être contrainte, garantissant l’intégrité et l’exactitude de l’ensemble du calcul.

2.4 Connecteur de sortie: Dépassement des limites de la méthode de dépense UTXO

Actuellement, Bitcoin offre deux méthodes de dépenses natives pour un seul UTXO : dépenser par script ou par clé publique. Par conséquent, tant que la signature de clé publique correcte ou les conditions de script sont remplies, l'UTXO peut être dépensé. Deux UTXOs peuvent être dépensés indépendamment, et aucune restriction ne peut être ajoutée pour contraindre les deux UTXOs, ce qui signifie que des conditions supplémentaires doivent être remplies pour qu'ils soient dépensés.

Cependant, Burak, le fondateur du protocole Ark, a intelligemment utilisé l’indicateur SIGHASH pour obtenir une sortie de connecteur. Plus précisément, Alice peut créer une signature pour envoyer ses BTC à Bob. Cependant, étant donné que la signature peut s’engager sur plusieurs entrées, Alice peut définir sa signature comme étant conditionnelle : la signature est valide pour la transaction Taketx si et seulement si cette transaction consomme la deuxième entrée. La deuxième entrée s’appelle le connecteur, reliant UTXO A et UTXO B. En d’autres termes, la transaction Taketx est valide si et seulement si UTXO B n’a pas été dépensé par le Challengetx. Par conséquent, en détruisant la sortie du connecteur, l’efficacité de la transaction Taketx peut être bloquée.

Figure 1: Illustration de sortie de connecteur

Dans le protocole BitVM2, la sortie du connecteur agit comme une fonction if...else. Une fois que la sortie du connecteur est dépensée par une transaction, elle ne peut pas être dépensée par une autre transaction pour garantir sa dépense exclusive. Dans le déploiement pratique, pour permettre une période de challenge-réponse, des UTXOs supplémentaires avec une verrouillage temporel sont introduits. De plus, la sortie du connecteur correspondante peut également être configurée avec différentes stratégies de dépense selon les besoins, telles que permettre à n'importe quelle partie de dépenser dans le cas de transactions de challenge, tout en permettant seulement à l'opérateur de dépenser ou permettant à n'importe qui de dépenser après un délai d'attente pour les transactions de réponse.

2.5 Contrats : Surmonter les limitations de la pré-signature

Actuellement, les scripts Bitcoin limitent principalement les conditions de déverrouillage, sans restreindre la façon dont le UTXO peut être dépensé ultérieurement. En effet, les scripts Bitcoin ne peuvent pas lire le contenu de la transaction elle-même, ce qui signifie qu'ils ne peuvent pas réaliser d'introspection de transaction. Si les scripts Bitcoin pouvaient vérifier n'importe quel contenu de la transaction (y compris les sorties), la fonctionnalité du contrat pourrait être réalisée.

Les implémentations de contrat actuelles peuvent être divisées en deux catégories:

• Pré-signature : Sur la base des capacités de script Bitcoin existantes, des contrats prédéterminés à fonctionnalités limitées sont construits par le biais de la pré-signature. Cela signifie qu’il faut concevoir et signer à l’avance toutes les transactions futures possibles, en enfermant les participants dans des clés privées et des taux de frais spécifiques. Certains systèmes exigent même que les participants génèrent des clés privées à court terme pour toutes les transactions pré-signées. Une fois la pré-signature terminée, ces clés privées à court terme sont supprimées en toute sécurité, ce qui empêche les attaquants de les obtenir et de voler des fonds. Cependant, chaque fois qu’un nouveau participant est ajouté ou qu’une opération est mise à jour, le processus ci-dessus doit être répété, ce qui entraîne des coûts de maintenance élevés. Par exemple, le Lightning Network réalise des contrats bipartites par le biais de la pré-signature et utilise la technologie HTLC (Hash Time-Locked Contracts) pour mettre en œuvre des fonctions de routage pour plusieurs contrats bipartites, ce qui permet d’obtenir une stratégie de mise à l’échelle minimisée par la confiance. Cependant, le Lightning Network nécessite la pré-signature de plusieurs transactions et est limité à deux parties, ce qui le rend quelque peu encombrant ; dans BitVM1, des centaines de transactions doivent être pré-signées à chaque initialisation, tandis que dans BitVM2 optimisé, le nombre de transactions qui doivent être pré-signées à chaque initialisation atteint également des dizaines. Dans BitVM1 et BitVM2, seuls les opérateurs participant à la pré-signature sont éligibles au remboursement. Si n participants sont impliqués dans la pré-signature, et que chaque participant doit pré-signer m transactions, la complexité de la pré-signature pour chaque participant sera n * m.
• Présentation des opcodes de contrat: L'introduction de nouveaux opcodes de fonction de contrat peut réduire considérablement la complexité de communication et les coûts de maintenance entre les participants au contrat, ce qui permet d'introduire une méthode d'implémentation de contrat plus flexible pour Bitcoin. Par exemple, OPCAT: utilisé pour concaténer des chaînes d'octets. Bien que sa fonction soit très simple, elle est très puissante et peut réduire considérablement la complexité de BitVM; OPTXHASH: permet un meilleur contrôle granulaire des actions au sein du contrat. S'il est utilisé dans BitVM, il peut prendre en charge un ensemble plus large d'opérateurs, améliorant ainsi considérablement les hypothèses de sécurité de BitVM et minimisant la confiance. De plus, la méthode de présignature signifie intrinsèquement que les opérateurs dans BitVM ne peuvent adopter qu'un processus de remboursement, ce qui entraîne une utilisation plus faible du capital; tandis qu'avec les nouveaux opcodes de contrat, il serait peut-être possible de payer directement à partir du pool de fonds de peg-in aux utilisateurs de sortie, améliorant ainsi davantage l'efficacité du capital. Par conséquent, un modèle de contrat flexible permettra de surmonter efficacement les limites traditionnelles de la présignature.

3 Bitcoin Layer2 Scaling: Preuves de validité et preuves de fraude

Les preuves de validité et les preuves de fraude peuvent être utilisées pour l'évolutivité de Bitcoin L2, les principales différences sont présentées dans le tableau 2.

Table 2: Preuve de validité vs Preuve de fraude

Sur la base de l’engagement des bits, de la racine pivotante, de la pré-signature et de la sortie du connecteur, des preuves de fraude basées sur Bitcoin peuvent être construites. Sur la base de la racine pivotante, les preuves de validité basées sur Bitcoin peuvent également être construites en introduisant des opcodes de contrat, tels que OP_CAT. De plus, selon que Bob dispose ou non d’un système d’admission, les preuves de fraude peuvent être divisées en preuves de fraude autorisées et preuves de fraude sans autorisation. Dans les preuves de fraude autorisées, seuls des groupes spécifiques peuvent agir en tant que Bob pour lancer des contestations, tandis que dans les preuves de fraude sans autorisation, n’importe quel tiers peut agir en tant que Bob pour lancer des contestations. La sécurité des preuves de fraude sans autorisation est supérieure à celle des preuves autorisées, ce qui réduit le risque de collusion entre les participants autorisés.

Selon le nombre d'interactions de défi-réponse entre Alice et Bob, les preuves de fraude peuvent être divisées en preuves de fraude à un tour et en preuves de fraude à plusieurs tours, comme le montre la figure 2.

Figure 2: Preuves de fraude à un tour vs preuves de fraude à plusieurs tours

Comme indiqué dans le Tableau 3, les preuves de fraude peuvent être mises en œuvre à travers différents modèles d'interaction, y compris les modèles d'interaction à un tour et les modèles d'interaction à plusieurs tours.

Table 3: Interaction en un tour vs Interaction en plusieurs tours

Dans le paradigme de mise à l'échelle Layer 2 de Bitcoin, BitVM1 adopte un mécanisme de preuve de fraude multi-tours, tandis que BitVM2 utilise un mécanisme de preuve de fraude à un tour, et bitcoin-circle stark utilise des preuves de validité. Parmi ceux-ci, BitVM1 et BitVM2 peuvent être mis en œuvre sans apporter de modifications au protocole Bitcoin, tandis que bitcoin-circle stark nécessite l'introduction d'un nouveau code d'opération OP_CAT.

Pour la plupart des tâches de calcul, le signet, le testnet et le mainnet de Bitcoin ne peuvent pas représenter entièrement un script de 4 Mo, ce qui rend nécessaire l'utilisation de la technologie de fractionnement de script, c'est-à-dire diviser le script de calcul complet en morceaux plus petits que 4 Mo, répartis sur divers tapleafs.

3.1 Preuves de fraude à plusieurs tours sur Bitcoin

Comme indiqué dans le tableau 3, les preuves de fraude à plusieurs tours conviennent aux scénarios où l'on souhaite réduire le calcul d'arbitrage en chaîne et/ou où il n'est pas possible de localiser les segments de calcul problématiques en une seule étape. Les preuves de fraude à plusieurs tours, comme leur nom l'indique, nécessitent plusieurs tours d'interaction entre le prouveur et le vérificateur pour localiser les segments de calcul problématiques, suivis d'un arbitrage basé sur les segments identifiés.

Le premier livre blanc de BitVM de Robin Linus (communément appelé BitVM1) utilisait des preuves de fraude à plusieurs tours. En supposant que chaque période de défi dure une semaine et en utilisant une méthode de recherche binaire pour localiser les segments de calcul problématiques, la période de réponse au défi sur la chaîne pour le vérificateur Groth16 pourrait s'étendre jusqu'à 30 semaines, ce qui entraînerait une mauvaise rapidité. Bien qu'il y ait actuellement des équipes de recherche sur des méthodes de recherche n-aires plus efficaces que la recherche binaire, leur rapidité est toujours nettement inférieure par rapport au cycle de 2 semaines dans les preuves de fraude à un seul tour.

Actuellement, les preuves de fraude à plusieurs tours dans le paradigme Bitcoin utilisent des défis autorisés, tandis que les preuves de fraude à un tour ont adopté une méthode de défi sans autorisation, réduisant ainsi le risque de collusion entre les participants et améliorant ainsi la sécurité. À cette fin, Robin Linus a pleinement exploité les avantages de Taproot pour optimiser BitVM1. Non seulement le nombre de tours d'interaction a été réduit à un, mais la méthode de défi a également été étendue à une approche sans autorisation, bien que cela entraîne une augmentation du calcul d'arbitrage sur chaîne.

3.2 Preuves de fraude en une étape sur Bitcoin

Dans ce modèle, la vérification des preuves de fraude peut être effectuée au moyen d'une seule interaction entre le prouveur et le vérificateur. Le vérificateur n'a besoin que d'initier un seul défi, et le prouveur n'a besoin que de répondre une fois. Dans cette réponse, le prouveur doit fournir des preuves affirmant que son calcul est correct. Si le vérificateur trouve des incohérences dans ces preuves, le défi est réussi ; sinon, il échoue. Les caractéristiques des preuves de fraude interactives en une seule étape sont présentées dans le tableau 3.

Figure 3: Preuve de fraude en un tour

Le 15 août 2024, Robin Linus a publié le document technique BitVM2: Pont entre Bitcoin et les couches secondaires, qui a mis en œuvre un pont inter-chaînes en utilisant une méthode de preuve de fraude à un tour similaire à celle illustrée dans la figure 3.

3.3 Preuve de validité sur Bitcoin avec OP_CAT

OPCAT faisait partie du langage de script original lors de la sortie de Bitcoin, mais a été désactivé en 2010 en raison de vulnérabilités de sécurité. Cependant, la communauté Bitcoin discute de sa réactivation depuis des années. OPCAT s'est vu attribuer le numéro 347 et a été activé sur le signet de Bitcoin.

La fonction principale d'OP_CAT est de combiner deux éléments de la pile et de pousser le résultat fusionné de nouveau sur la pile. Cette fonctionnalité ouvre la possibilité de contrats et de vérificateurs STARK sur Bitcoin :

• Contrats : Andrew Poelstra a proposé CAT et Schnorr Tricks I, en utilisant les techniques OPCAT et Schnorr pour mettre en œuvre des contrats sur Bitcoin. L’algorithme de Schnorr est une signature numérique pour les types de sortie P2TR ; pour d’autres types de sortie, des techniques ECDSA similaires peuvent être utilisées, comme on l’a vu dans les conventions avec CAT et ECDSA. À l’aide des contrats OPCAT, l’algorithme STARK Verifier peut être divisé en plusieurs transactions, vérifiant progressivement l’ensemble de la preuve STARK.
• Vérificateur STARK : Le vérificateur STARK connecte essentiellement les données entre elles et les hache. Contrairement aux opérations algébriques, le hachage est une opération de script Bitcoin native qui permet d’économiser une quantité importante de frais généraux. Par exemple, OPSHA256 est un opcode unique dans sa forme native, tandis qu’une version simulée nécessite des centaines d’opcodes K. Les principales opérations de hachage dans STARK consistent à vérifier les chemins de Merkle et les transformations de Fiat-Shamir. Par conséquent, OPCAT est très convivial pour l’algorithme STARK Verifier.

3.4 Technologie de division de script Bitcoin

Bien que la charge de calcul requise pour exécuter l'algorithme de vérification correspondant afin de vérifier la preuve après la preuve SNARK/STARK soit beaucoup plus petite que celle requise pour exécuter directement le calcul original f, la quantité de script nécessaire lors de sa conversion pour implémenter l'algorithme de vérification dans le script Bitcoin reste énorme. Actuellement, en se basant sur les opcodes Bitcoin existants, la taille du script vérificateur optimisé Groth16 et la taille du script vérificateur Fflonk sont toutes les deux supérieures à 2 Go. Cependant, la taille d'un seul bloc Bitcoin est seulement de 4 Mo, ce qui rend impossible l'exécution de l'ensemble du script vérificateur dans un seul bloc. Cependant, depuis la mise à niveau de Taproot, Bitcoin prend en charge l'exécution de scripts par tapleaf, ce qui permet de diviser le script vérificateur en plusieurs morceaux, chaque morceau servant de tapleaf pour construire un taptree. La cohérence des valeurs entre les morceaux peut être assurée grâce à l'engagement de bits.

En présence de contrats OP_CAT, le vérificateur STARK peut être divisé en plusieurs transactions standard inférieures à 400 Ko, ce qui permet d’effectuer l’ensemble de la vérification de la preuve de validité STARK sans avoir besoin de collaborer avec les mineurs.

Cette section se concentre sur la technologie de division pertinente des scripts Bitcoin dans les conditions existantes sans introduire ou activer de nouveaux opcodes.

Lors de la division du script, les dimensions d'information suivantes doivent être équilibrées :

• La taille d’un script à un seul bloc ne doit pas dépasser 4 Mo et doit inclure des scripts d’engagement de bits d’entrée, des signatures de transaction et d’autres espaces.
• La taille de la pile maximale d'un seul fragment ne doit pas dépasser 1000. Par conséquent, la pile de chaque fragment ne doit conserver que les éléments nécessaires pour réserver suffisamment d'espace de pile pour l'optimisation de la taille du script, car les frais de transaction Bitcoin ne dépendent pas de la taille de la pile utilisée.
• L’engagement de bits sur Bitcoin coûte cher. Par conséquent, le nombre de bits dans l’entrée et la sortie entre deux blocs adjacents doit être minimisé, car actuellement, 1 bit correspond à 26 octets.
• Pour faciliter l'audit, la fonctionnalité de chaque fragment doit être aussi claire que possible.

Actuellement, les méthodes de division de script peuvent être divisées en trois catégories principales suivantes :

• Fractionnement automatique : cette méthode recherche une approche de fractionnement dans laquelle la taille du script est d’environ 3 Mo et la taille de la pile est réduite en fonction de la taille de la pile et de la taille du script. Les avantages de cette méthode sont qu’elle est indépendante des algorithmes de vérification spécifiques et qu’elle peut être étendue au fractionnement de script pour n’importe quel calcul. Les inconvénients sont les suivants : (1) l’ensemble du bloc logique doit être marqué séparément, par exemple OP_IF blocs de code qui ne peuvent pas être divisés ; sinon, le résultat de l’exécution du script fractionné sera incorrect ; (2) le résultat d’exécution d’un bloc peut correspondre à plusieurs éléments de la pile, ce qui nécessite le marquage du nombre d’éléments de la pile qui doivent appliquer un engagement de bits en fonction de la logique de calcul réelle ; (3) la lisibilité de la fonctionnalité logique implémentée par chaque script de bloc est médiocre, ce qui rend l’audit difficile ; (4) La pile peut contenir des éléments qui ne sont pas nécessaires pour le morceau suivant, ce qui gaspille de l’espace dans la pile.
• Fractionnement fonctionnel : cette méthode se divise en fonction de diverses sous-fonctions fonctionnelles dans le calcul, avec des valeurs d’entrée et de sortie claires pour les sous-fonctions. Tout en divisant le script, il implémente également les scripts d’engagement de bits nécessaires pour chaque bloc, en veillant à ce que la taille totale du script des blocs finaux soit inférieure à 4 Mo et que la taille de la pile soit inférieure à 1000. Les avantages sont : une fonctionnalité claire, une logique claire pour chaque segment, une bonne lisibilité et une facilité d’audit. Les inconvénients sont les suivants : l’expression de la logique de calcul d’origine peut ne pas correspondre à la logique au niveau du script, et les sous-fonctions de calcul d’origine peuvent être optimales mais ne pas représenter l’optimalité au niveau du script.
• Fractionnement manuel : Dans cette méthode, les points de fractionnement ne sont pas basés sur des sous-fonctions fonctionnelles, mais sont définis manuellement. Ceci est particulièrement adapté aux cas où la taille d’une seule sous-fonction dépasse 4 Mo. Les avantages sont les suivants : il permet de diviser manuellement des sous-fonctions de taille de script lourde, telles que celles liées aux calculs Fq12 ; Une logique claire pour chaque morceau, une bonne lisibilité et une facilité d’audit. Les inconvénients sont les suivants : limités par les capacités de réglage manuel, lorsque le script global a été optimisé, les points de fractionnement manuels précédemment définis peuvent ne pas être optimaux et doivent être réajustés.

Par exemple, après plusieurs rounds d'optimisation, la taille du script du vérificateur Groth16 a été réduite d'environ 7 Go à environ 1,26 Go. En plus de cette optimisation computationnelle globale, chaque morceau peut également être optimisé individuellement pour utiliser pleinement l'espace de la pile. Par exemple, en introduisant de meilleurs algorithmes basés sur des tables de recherche et en chargeant et déchargeant dynamiquement la table de recherche, la taille du script de chaque morceau peut être encore réduite.

Les coûts de calcul et les environnements d'exécution des langages de programmation web2 sont complètement différents de ceux des scripts Bitcoin, il n'est donc pas possible de simplement traduire les implémentations existantes pour divers algorithmes en scripts Bitcoin. Par conséquent, des optimisations spécifiques au scénario Bitcoin doivent être prises en compte :

• Recherchez des algorithmes qui optimisent la localité de la mémoire, même au détriment d'une charge de calcul supplémentaire, pour réduire le nombre de bits d'entrée/sortie entre les morceaux, ce qui permet de réduire la quantité de données requises pour les engagements dans la conception de transaction assertTx de BitVM2.
• Utilisez la commutativité des opérations liées (par exemple, les opérations logiques), comme x&y = y&x, pour économiser près de la moitié de la table de recherche.
• Actuellement, la taille du script correspondant aux opérations de Fq12 est grande; envisagez d'utiliser les schémas Fiat-Shamir, Schwartz-Zipple et d'engagement polynomial pour réduire significativement la complexité de calcul des opérations d'extension Fq12.

4 Summary

Cet article présente d'abord les limites des scripts Bitcoin et discute de l'utilisation des engagements Bitcoin pour surmonter la limitation UTXO sans état, de l'utilisation de Taproot pour briser les limitations d'espace de script, de l'utilisation de sorties de connecteur pour contourner les restrictions de méthode de dépense UTXO et de l'utilisation de contrats pour surmonter les limites de pré-signature. Il fournit ensuite un aperçu complet et un résumé des caractéristiques des preuves de fraude et des preuves de validité, des caractéristiques des preuves de fraude autorisées et non autorisées, des distinctions entre les preuves de fraude à un tour et à plusieurs tours, et de la technologie de division de script Bitcoin.

Avertissement :

1. Cet article est repris de [AICOIN]. Tous les droits d'auteur appartiennent à l'auteur original [mutourend et lynndell, Bitlayer Labs]. Si vous avez des objections à cette réimpression, veuillez contacter le Gate Learnl'équipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.