Extension de Layer 2 de Bitcoin: Analyse technique: preuve de validité et fraude

1 Introduction

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

1. Alice entre 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 et obtient y′. Si y et y′ sont égaux, Bob reconnaît alors l’entrée x et la sortie y fournies par Alice. Il s’agit d’un mécanisme de preuve de validité couramment utilisé, généralement appliqué dans le cadre du consensus de la chaîne de blocs, où Alice est un nœud empaqueteur de blocs, et Bob est un nœud participant au consensus.
2. Alice entre x, exécute le programme zk.prove, obtient le résultat y et la preuve de validité proof. Bob exécute le programme zk.verify en fonction de f, y et proof. Si le résultat est vrai, Bob reconnaît le résultat y d’Alice ; sinon, Bob ne reconnaît pas le résultat y d’Alice. C’est une forme de preuve de validité, et Bob peut être un contrat off-chain.
3. Alice entre 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 et obtient y’. S’ils sont égaux, rien ne se passe. Si y et y’ ne sont pas égaux, Bob défie Alice avec l’algorithme f. Les interactions entre Alice et Bob peuvent se dérouler en une ou plusieurs étapes. L’arbitrage est réalisé à travers un mécanisme de défi et de réponse. C’est une preuve de fraude, Bob est le challenger, écoute hors ligne et lance le défi en ligne.
4. Alice entre x, exécute le programme zk.prove, obtient le résultat y et la preuve proof. Bob exécute le programme zk.verify en fonction de f, y et de la preuve. Si le résultat est vrai, rien ne se passe ; si le résultat est faux, Bob met au défi Alice avec le programme de défi. L’interaction entre Alice et Bob peut consister en un ou plusieurs tours. La médiation est réalisée par un mécanisme de défi-réponse. Il s’agit d’une preuve de fraude, Bob étant le challenger, écoutant hors ligne et lançant un défi en ligne.

Pour les points 2, 3 et 4 ci-dessus, laissez x être les transactions Layer2 et l’état initial, f être le programme de consensus Layer2, laissez y être l’état final des transactions, correspondant à la solution d’extension Layer2 de la blockchain.

• Preuve de validité : Basée sur des hypothèses pessimistes, sa validité doit être prouvée avant l’acceptation, et elle prend effet immédiatement. Dans la preuve de validité, la preuve de la transition correcte de l’état L2 doit être fournie, incarnant une vision pessimiste du monde – ce n’est que si l’état est prouvé qu’il est correct qu’il sera accepté.
• preuve de fraude: Basé sur l’hypothèse optimiste, il est accepté par défaut sauf preuve du contraire. Il a une période de défi où il ne prend effet qu’après la fin de cette période. Dans la preuve de fraude, des preuves de transition d’état L2 incorrectes doivent être fournies, ce qui reflète une vision optimiste du monde - la transition d’état est considérée comme correcte sauf preuve du contraire.

Tableau 1: Méthodes pour établir la confiance

En outre, il est important de noter que :

• La distinction entre la preuve de fraude et la preuve de validité ne réside pas dans l’utilisation de systèmes de preuve ZK tels que SNARK ou STARK. Les systèmes de preuve ZK ne font que représenter la méthode de preuve adoptée, tandis que la fraude ou la validité représente le contenu de la preuve. Ainsi, le scénario 1 du tableau 1 est appelé preuve de validité.
• La preuve de validité a une meilleure validité, mais une complexité de vérification hors chaîne plus élevée ; tandis que la preuve de fraude a une complexité de vérification hors chaîne plus faible, mais une validité inférieure.
• Pour les cas 2 et 4 du tableau 1, en utilisant la technique de récursion ZK et de combinaison, il est possible de calculer et de compresser plusieurs f, réduisant ainsi considérablement le coût de vérification des calculs off-chain.

Actuellement, grâce aux contrats intelligents Turing complet de Solidity, les technologies de preuve de validité, de preuve de fraude et de preuve de validité sont largement utilisées dans l’extension Layer2 d’Ethereum. Cependant, dans le cadre de BTC, en raison des fonctionnalités limitées des opcodes de BTC, du nombre limité d’éléments de pile (seulement 1000) et d’autres restrictions, l’application de ces technologies est encore en phase d’exploration. Cet article résume les limites et les avancées technologiques du cadre BTC, étudie les technologies de preuve de validité et de preuve de fraude, et décrit la technique unique de segmentation de script dans le cadre BTC.

Limitations and Breakthroughs Under the 2 BTC Paradigm

Dans le cadre du BTC, il existe de nombreuses limites, mais celles-ci peuvent être surmontées par diverses méthodes ou technologies astucieuses. Par exemple, l’utilisation de Bit commitments peut briser la limitation d’état sans statut de l’UTXO, Taproot peut résoudre la limitation de l’espace de script, les sorties connectées peuvent surmonter la limitation du mode de consommation de l’UTXO, tandis que les smart contracts peuvent briser la limitation de la pré-authentification.

2.1 Modèle UTXO et restrictions de script

BTC utilise le modèle UTXO, où chaque UTXO est verrouillé dans un script de verrouillage qui définit les conditions requises pour dépenser cet UTXO. Il existe des limitations aux scripts BTC suivantes:

1. Le script BTC est sans état;
2. Pour le type de sortie P2TR, un maximum d’environ 4 millions de codes d’opération peuvent être inclus dans une seule transaction, remplissant tout le Bloc, tandis que pour les autres types de sortie, seuls 10 000 codes d’opération peuvent être utilisés;
3. Les moyens de consommation des UTXO individuels sont limités, et il manque d’exploration des moyens de consommation combinés;
4. La fonction de contrat flexible n’est pas prise en charge;
5. La limite de taille de la pile est de 1000 éléments au maximum (y compris altstack et stack), avec une taille maximale de 520 octets pour un seul élément.
6. Les opérations arithmétiques telles que l’addition et la soustraction sont limitées à des éléments de 4 octets et ne peuvent pas être étendues à des éléments longs de 20 octets ou plus, ce qui est nécessaire dans l’opération de chiffrement.
7. Les opcodes tels que OPMUL et OPCAT sont désactivés car il est extrêmement coûteux de les simuler à l’aide des opcodes existants, par exemple, la simulation d’un hash BLAKE3 coûterait environ 75 Ko de taille de script.

2.2 Promesse Bit: Dépasser les limitations de l’état sans UTXO

Actuellement, le script BTC est complètement sans état. Lors de l’exécution du script BTC, l’environnement d’exécution de chaque script est réinitialisé après son achèvement. Cela rend le script BTC incapable de prendre en charge nativement le partage de la même valeur x entre le script de contrainte 1 et le script de contrainte 2. Cependant, ce problème peut être résolu en utilisant certaines méthodes, l’idée principale étant de signer une valeur d’une certaine manière. Si une signature peut être générée pour une valeur, il est possible d’avoir un script BTC avec état. En d’autres termes, en vérifiant la signature de la valeur x dans les scripts 1 et 2, il est possible de s’assurer que la même valeur x est utilisée dans ces deux scripts. En cas de conflit de signatures, c’est-à-dire si deux valeurs différentes sont signées pour la même variable x, des sanctions peuvent être appliquées. Cette méthode est appelée Bit commitment.

Le principe promis par Bit est relativement simple. Chaque Bit correspond à deux valeurs de hachage différentes, hash0 et hash1. Si la valeur Bit à signer est 0, le pré-image de hash0 est révélé; Si la valeur Bit est 1, la pré-image de hash1 est révélée.

À titre d’exemple, pour un message Bit unique m ∈ {0,1}, l’engagement Bit correspondant déverrouille le script est composé uniquement de quelques pré-images : si la valeur de Bit est 0, alors le script de déverrouillage est preimage0 - “0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140” ; si la valeur de Bit est 1, alors le script de déverrouillage est preimage1 - “0x47c31e611a3bd2f3a7a42207613046703fa27496”. Ainsi, grâce à l’engagement Bit, il est possible de contourner la limitation non étatique de l’UTXO, de mettre en œuvre des scripts BTC étatiques, et de rendre possible toute une gamme de nouvelles fonctionnalités intéressantes.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // C’est hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Ceci est le hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// La valeur promise de Bit est maintenant sur la pile. Il peut être “0” ou “1”.

Actuellement, Bit s’engage à avoir deux façons de le réaliser :

• Signature à usage unique de Lamport : La signature à usage unique de Lamport repose sur un principe relativement simple, nécessitant uniquement l’utilisation d’une fonction de hachage, et est compatible avec BTC. Pour chaque bit du message, il est nécessaire de s’engager sur deux valeurs de hachage, ce qui entraîne une taille de données de signature relativement importante. Plus précisément, pour un message de longueur v bits, la clé publique a une longueur de 2v bits, tandis que la signature a une longueur de v bits.
• Signature Winternitz à usage unique : Comparé à la signature Lamport, la signature Winternitz réduit considérablement la longueur de la signature et de la Clé publique, mais augmente la complexité de la signature et de la vérification. Ce schéma permet de définir de manière flexible différentes longueurs de chaînes de hachage d, pour trouver un équilibre entre la longueur et la complexité. Par exemple, en définissant d = 15, la longueur de la Clé publique et de la signature peut être réduite d’environ 4 fois, mais la complexité de la vérification sera augmentée de 4 fois. Cela correspond en fait à un compromis entre l’espace de pile BTC et la taille du script. Lorsque d = 1, la signature Lamport peut être considérée comme un cas particulier de la signature Winternitz.

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 qu’il y a un coût à l’introduction de l’État par le biais d’engagements de bits. Par conséquent, dans l’implémentation de BitVM2, le message est d’abord haché pour obtenir une valeur de hachage de 256 bits, puis un engagement de bit est effectué sur cette 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：突破脚本空间限制

La mise à niveau du softfork Taproot de BTC a été activée en novembre 2021 et comprend trois propositions : la signature Schnorr (BIP 340), Taproot (BIP 341) et TapScript (BIP 342). Cette mise à niveau introduit un nouveau type de transaction - Pay-to-Taproot (P2TR) transaction. En combinant les avantages de Taproot, MAST (Merkle Abstract Syntax Tree) et la signature Schnorr, les transactions P2TR peuvent créer un format de transaction plus privé, plus flexible et évolutif.

P2TR supporte deux modes de dépense : via le chemin de la clé secrète ou le chemin du script. Selon les spécifications de Taproot (BIP 341), lorsqu’une dépense est effectuée via le chemin du script, la longueur du chemin de Merkle correspondant ne peut pas dépasser 128. Cela signifie que le nombre de tapleaf dans taptree ne peut pas dépasser 2^128. Depuis la mise à niveau de SegWit en 2017, le réseau BTC mesure la taille des blocs en unités de poids, avec un maximum de 4 millions d’unités de poids (environ 4 Mo). Lorsqu’une sortie P2TR est dépensée via le chemin du script, seule un seul script tapleaf doit être révélé, ce qui signifie qu’il n’y a qu’un seul script tapleaf dans le bloc. Par conséquent, pour les transactions P2TR, la taille maximale du script correspondant à chaque tapleaf peut atteindre environ 4 Mo. Cependant, selon la politique par défaut de BTC, de nombreux nœuds ne transmettent que des transactions de moins de 400 Ko ; les transactions plus volumineuses nécessitent une collaboration avec les mineurs pour être incluses dans les blocs.

L’espace de script apporté par Taproot rend plus précieuse l’utilisation de codes opérationnels existants pour simuler des opérations cryptographiques telles que la multiplication et le hash. Lors de la construction de calculs vérifiables basés sur P2TR, la taille du script n’est plus limitée à 4 Mo, mais peut être fractionnée en plusieurs sous-fonctions réparties dans plusieurs tapleaves, ce qui permet de dépasser la limite d’espace de script de 4 Mo. En réalité, le vérificateur Groth16 Algorithme de BitVM2 actuel est de taille jusqu’à 2 Go. Cependant, il peut être fractionné et réparti dans environ 1000 tapleaves, et combiné avec l’engagement Bit pour contraindre la cohérence entre les entrées et les sorties de chaque sous-fonction, garantissant ainsi l’intégrité et la correction de l’ensemble du calcul.

2.4 Connecteur de sortie: Dépasser les Limites du Mode de Dépense UTXO

Actuellement, le BTC propose deux modes de dépense natifs pour une seule sortie de transaction non dépensée (UTXO) : via un script ou une Clé publique. Ainsi, tant qu’une signature Clé publique correcte ou des conditions de script sont remplies, l’UTXO peut être dépensée. Deux UTXO peuvent être dépensées de manière indépendante et il n’est pas possible d’imposer des restrictions sur ces deux UTXO, ce qui signifie qu’il faut satisfaire des conditions supplémentaires pour les dépenser.

Cependant, le fondateur d’ARK, Burak, a intelligemment utilisé le drapeau SIGHASH pour réaliser une sortie de connecteur. En particulier, Alice peut créer une signature pour envoyer ses BTC à Bob. Comme une signature peut engager plusieurs entrées, Alice peut conditionner sa signature : elle n’est valide que si la deuxième entrée est consommée par la transaction Taketx. La deuxième entrée est appelée connecteur, elle relie UTXO A et UTXO B. En d’autres termes, la transaction Taketx n’est valide que si UTXO B n’est pas consommé par la transaction Challengetx. Ainsi, en détruisant la sortie du connecteur, on peut empêcher la validité de la transaction Taketx.

Figure 1: Schéma de sortie du connecteur

Dans le protocole BitVM2, la sortie du connecteur agit comme une fonction if…else. Une fois que la sortie du connecteur a été dépensée par une transaction, elle ne peut plus être dépensée par d’autres transactions, ce qui garantit son exclusivité. Dans le déploiement réel, pour permettre le cycle de challenge-réponse, des UTXO supplémentaires avec verrouillage temporel ont été introduits. De plus, la sortie du connecteur peut également être configurée avec différentes stratégies de dépense selon les besoins, par exemple permettre à l’une ou l’autre partie de dépenser dans le cas d’une transaction de défi, tandis que dans le cas d’une transaction de réponse, seul l’opérateur est autorisé à dépenser ou permettre à n’importe qui de dépenser après expiration du délai.

2.5 Contrat : Dépasser la limite de pré-signature

Pour l’instant, le script BTC limite principalement les conditions de déverrouillage, mais ne limite pas comment les sorties de transaction non dépensées (UTXO) peuvent être dépensées. Cela est dû au fait que le script BTC ne peut pas lire le contenu de la transaction elle-même, et ne peut donc pas réaliser l’introspection de la transaction. Si le script BTC pouvait inspecter n’importe quel contenu de la transaction (y compris les sorties), il pourrait alors implémenter des fonctionnalités de contrat.

Les contrats actuels peuvent être divisés en deux catégories :

• Pré-signature : Basé sur les capacités de script BTC existantes, il construit un contrat de réservation à fonction limitée à l’aide de pré-signatures. Cela signifie que les participants doivent concevoir et signer à l’avance toutes les transactions futures possibles, les verrouiller sur des Clé privée spécifiques et des taux de frais. Certains schémas exigent même que les participants génèrent des Clé privée à court terme pour toutes les transactions pré-signées. Une fois les pré-signatures terminées, ces Clé privée à court terme sont sécurisées et supprimées pour empêcher les attaquants de les obtenir et de voler des fonds. Cependant, ce processus doit être répété à chaque ajout de nouveaux participants ou à chaque mise à jour, entraînant des coûts de maintenance élevés. Par exemple, Lightning Network utilise la pré-signature pour implémenter des contrats bilatéraux et utilise la technologie de contrat de verrouillage temporel hashé (HTLC) pour la fonction de routage de plusieurs contrats bilatéraux, permettant ainsi une stratégie d’extension avec un minimum de confiance. Cependant, Lightning Network nécessite des pré-signatures pour plusieurs transactions et est limité à deux parties, ce qui le rend fastidieux à utiliser ; dans BitVM1, des centaines de transactions doivent être pré-signées à chaque initialisation, tandis que dans BitVM2 optimisé, le nombre de transactions à pré-signer à chaque initialisation atteint également plusieurs dizaines. Dans BitVM1 et BitVM2, seuls les opérateurs impliqués dans la pré-signature sont admissibles pour le remboursement. Si n participants sont impliqués dans la pré-signature et que chaque participant doit pré-signer m transactions, la complexité de pré-signature de chaque participant sera n * m.
• Introduction des codes opérationnels de contrat : L’introduction de nouveaux codes opérationnels de fonctionnalités de contrat peut considérablement réduire la complexité de la communication et les coûts de maintenance entre les participants du contrat Goutte, offrant ainsi une manière plus flexible de mettre en œuvre les contrats pour BTC. Par exemple, le code opérationnel OPCAT est utilisé pour concaténer des chaînes d’octets. Bien que sa fonction soit simple, elle est très puissante et peut considérablement réduire la complexité de BitVM ; le code opérationnel OPTXHASH permet un contrôle plus précis des opérations à l’intérieur du contrat. S’il est utilisé dans BitVM, il peut prendre en charge un plus large éventail d’opérateurs, ce qui améliore considérablement la sécurité de BitVM et réduit au minimum la confiance requise. De plus, la méthode de présignature implique essentiellement que les opérateurs dans BitVM ne peuvent utiliser que le processus de remboursement, ce qui entraîne une efficacité d’utilisation des capitaux plus faible ; cependant, avec les nouveaux codes opérationnels de contrat, il est possible de payer directement les utilisateurs de sortie à partir du pool de fonds peg-in, ce qui améliore encore l’efficacité des capitaux. Par conséquent, un modèle de contrat flexible permettra de surmonter efficacement les limitations traditionnelles de présignature.

3 BTC Layer2 扩容：preuve de validité和fraud proof

preuve de validité et fraud proof peuvent tous deux être utilisés pour l’extension de couche 2 de BTC, les principales différences sont indiquées dans le tableau 2.

表 2：preuve de validité与fraud proof

En utilisant Bit Promises, Taproot, les pré-signatures et les sorties de connecteurs, il est possible de construire une preuve de fraude basée sur BTC. De plus, en introduisant des opérations de contrat (comme OP_CAT), il est également possible de construire une preuve de validité basée sur Taproot pour BTC. De plus, la preuve de fraude peut être divisée en preuve de fraude autorisée et preuve de fraude non autorisée en fonction de l’utilisation du système monter à bord par Bob. Dans la preuve de fraude autorisée, seuls certains groupes spécifiques peuvent défier Bob, tandis que dans la preuve de fraude non autorisée, n’importe quel tiers peut défier Bob. La sécurité de la preuve de fraude non autorisée est supérieure à celle de la preuve de fraude autorisée car elle réduit le risque de collusion entre les participants.

En fonction du nombre d’interactions de challenge-réponse entre Alice et Bob, la preuve de fraude peut être divisée en preuve de fraude à un seul tour et preuve de fraude à plusieurs tours, comme le montre la figure 2.

Figure 2: Preuve de fraude à un tour et preuve de fraude à plusieurs tours

Comme le montre le tableau 3, la preuve de fraude peut être réalisée à travers différents modèles d’interaction, y compris le modèle d’interaction en une seule étape et le modèle d’interaction en plusieurs étapes.

Tableau 3 : Interaction à un seul tour et interaction à plusieurs tours

Dans le paradigme d’extension Layer2 de BTC, BitVM1 utilise un mécanisme de preuve de fraude à plusieurs tours, tandis que BitVM2 utilise un mécanisme de preuve de fraude à un tour. Bitcoin-circle stark, quant à lui, utilise une preuve de validité. Parmi ces mécanismes, BitVM1 et BitVM2 peuvent être implémentés sans modifier le protocole BTC, tandis que bitcoin-circle stark nécessite l’introduction d’un nouvel OP_CODE OP_CAT.

Pour la plupart des tâches de calcul, le signet, le testnet et le mainnet de BTC ne prennent pas en charge complètement les scripts de 4 Mo, il est donc nécessaire d’utiliser la technique de fractionnement de script, c’est-à-dire de diviser le script de calcul complet en blocs de moins de 4 Mo et de les distribuer dans différents Tapleaf.

3.1 Preuve de fraude à plusieurs tours BTC

Comme le montre le tableau 3, le fraud proof à plusieurs tours est adapté à ceux qui souhaitent réduire les calculs d’arbitrage off-chain, ou qui ne peuvent pas localiser immédiatement le segment de calcul problématique. Comme son nom l’indique, le fraud proof à plusieurs tours nécessite une interaction à plusieurs tours entre les validateurs et les validateurs pour identifier le segment de calcul problématique, puis arbitrer en fonction de ces segments.

Le Livre blanc précoce de BitVM de Robin Linus (communément appelé BitVM1) a utilisé plusieurs preuves de fraude. En supposant que chaque période de défi dure une semaine et utilise une méthode de recherche binaire pour localiser le segment de calcul problématique, le délai de réponse au défi off-chain du validateur Groth16 pourrait s’étendre jusqu’à 30 semaines, ce qui entraînerait une faible réactivité. Bien qu’il existe actuellement des équipes travaillant sur des méthodes de recherche n-aire plus efficaces que la recherche binaire, leur réactivité reste nettement inférieure au cycle de preuve de fraude unique de 2 semaines.

Actuellement, plusieurs fraud proof dans BTC utilisent des défis autorisés, tandis qu’un seul fraud proof implémente une méthode sans défi autorisé, réduisant ainsi le risque de collusion entre les participants et renforçant la sécurité. Pour ce faire, Robin Linus a pleinement exploité les avantages de Taproot pour optimiser BitVM1, réduisant non seulement le nombre d’interactions à un tour, mais étendant également la méthode de défi de manière non autorisée, même si cela augmentait le coût du calcul d’arbitrage off-chain.

3.2 Bitcoin的一轮fraud proof

Dans ce modèle, la validation de la preuve de fraude ne nécessite qu’une seule interaction entre le fraudeur et les validateurs. Les validateurs n’ont besoin de lancer qu’un seul défi, tandis que le fraudeur n’a besoin que de répondre une fois. Dans sa réponse, le fraudeur doit fournir des preuves pour démontrer que ses calculs sont corrects. Si les validateurs trouvent des incohérences dans les preuves, le défi est réussi ; sinon, le défi échoue. Les caractéristiques de la preuve de fraude en une seule interaction sont présentées dans le tableau 3.

Figure 3: fraud proof à un seul tour

Le 15 août 2024, Robin Linus a publié un Livre blanc technique intitulé “BitVM2: Connecter BTC à la deuxième couche”, qui a mis en œuvre une méthode de bridges cross-chain utilisant une méthode de fraude proof à un seul tour similaire à celle illustrée dans la figure 3.

3.3 Utilisation de OP_CAT de BTC preuve de validité

OP_CAT est une partie du langage de script de BTC lors de sa sortie, mais a été désactivé en 2010 en raison de failles de sécurité. Malgré cela, la communauté BTC a discuté pendant des années de la possibilité de réactiver OP_CAT. Actuellement, OP_CAT est attribué au numéro 347 et est activé sur le réseau signet de BTC.

La principale fonction de OP_CAT est de fusionner les deux éléments de la pile et de renvoyer le résultat sur la pile. Cette fonctionnalité ouvre de nouvelles possibilités pour les contrats sur BTC et les validateurs STARK :

• Contrat : Andrew Poelstra a proposé CAT et Schnorr Tricks I, qui utilisent les technologies OP_CAT et Schnorr pour mettre en œuvre des contrats sur BTC. L’algorithme Schnorr est une signature numérique applicable aux types de sortie P2TR ; pour les autres types de sortie, une technique similaire à ECDSA peut être utilisée, comme indiqué dans le contrat utilisant CAT et ECDSA. Avec le contrat OP_CAT, le vérificateur STARK Algorithme peut être décomposé en plusieurs transactions, vérifiant progressivement toute la preuve STARK.
• Vérificateur STARK : La principale fonction du vérificateur STARK est de lier les données ensemble et de les hasher. Contrairement aux opérations algébriques, le hash est une opération native dans le script BTC qui peut réduire considérablement les frais. Par exemple, OP_SHA256 est un seul code opération en forme native, tandis que sa version simulée nécessite des centaines de codes opération. Les principales opérations de hash dans STARK incluent la vérification du chemin de Merkle et la transformation Fiat-Shamir. Par conséquent, OP_CAT est très compatible avec l’algorithme du vérificateur STARK.

3.4 Technique de division de script BTC

Bien que la charge de calcul requise pour la preuve de validation soit beaucoup plus faible que celle de l’exécution directe du calcul d’origine f après la preuve SNARK/STARK, la quantité de scripts requise pour implémenter le validateur Algorithme dans un script BTC reste énorme. Actuellement, la taille des scripts des validateurs Groth16 et Fflonk optimisés dépasse tous les deux 2 Go en utilisant les opcodes BTC existants, tandis qu’un seul bloc BTC a une taille de seulement 4 Mo, ce qui rend impossible l’exécution du script de validation complet dans un seul bloc. Cependant, depuis la mise à niveau Taproot, BTC prend en charge l’exécution de scripts via tapleaf, ce qui permet de diviser le script de validation en plusieurs blocs, chacun étant construit comme un tapleaf pour construire un taptree. La cohérence entre les blocs peut être garantie par un engagement de bits.

Dans le cas du contrat OP_CAT, le vérificateur STARK peut être divisé en plusieurs transactions standard de moins de 400 Ko, ce qui permet de réaliser la validation complète de la preuve de validité STARK sans avoir besoin de coopérer avec des mineurs.

Ce chapitre se concentrera sur la technique de division du script BTC dans des conditions existantes, sans introduire ou activer de nouveaux opcodes.

Lors de la division de scripts, il est nécessaire de trouver un équilibre entre les informations suivantes :

• La taille du script d’un seul bloc ne doit pas dépasser 4 Mo et doit inclure des scripts de promesse d’entrée, des signatures de transaction, etc.
• La taille maximale de la pile d’un bloc ne doit pas dépasser 1000. Par conséquent, la pile de chaque bloc ne doit contenir que les éléments nécessaires pour garantir un espace de pile suffisant pour l’optimisation de la taille du script, car le blanchiment de capitaux de Bitcoin n’est pas lié à la taille de la pile.
• Sur Bitcoin, les coûts d’engagement sont élevés. Il est donc conseillé de réduire autant que possible le nombre d’entrées et de sorties entre deux blocs adjacents, actuellement 1 bit correspond à 26 octets.
• Pour faciliter l’audit, les fonctionnalités de chaque bloc doivent être aussi claires que possible.

Actuellement, les méthodes de scission de script peuvent être classées en trois catégories suivantes :

• Automatique Splittage: Cette méthode cherche un moyen de diviser le script de manière à ce que sa taille soit d’environ 3MB, et de minimiser la taille de la pile sur la base de la taille du script. Ses avantages sont son indépendance vis-à-vis de l’Algorithme de validateur spécifique, et sa capacité à être étendue à tout script de calcul. Les inconvénients comprennent : (1) Chaque bloc logique doit être marqué individuellement, par exemple, les blocs de code OP_IF qui ne peuvent pas être divisés; sinon, le résultat de l’exécution du script de fractionnement pourrait être incorrect; (2) Le résultat de l’exécution du bloc peut correspondre à plusieurs éléments sur la pile, nécessitant de marquer le nombre d’éléments de la pile nécessaires à l’engagement de bits réels selon la logique de calcul; (3) La lisibilité de la fonction logique de chaque script de bloc est faible, rendant l’audit difficile; (4) La pile peut contenir des éléments non nécessaires au bloc suivant, gaspillant de l’espace de pile.
• Découpage des fonctions : cette méthode consiste à découper les sous-fonctions fonctionnelles dans le calcul, en précisant les entrées et les sorties des sous-fonctions. En découpant le script, assurez-vous de réaliser les scripts d’engagement nécessaires pour chaque bloc, afin de garantir que la taille totale du script final soit inférieure à 4 Mo et que la taille de la pile soit inférieure à 1000. Les avantages sont la clarté des fonctions, une logique claire, une bonne lisibilité et une facilité d’audit. L’inconvénient est que la logique de calcul originale peut ne pas correspondre à la logique au niveau du script, les sous-fonctions originales peuvent être optimales mais ne représentent pas nécessairement l’optimalité au niveau du script.
• La division manuelle : Ce méthode ne divise pas en fonction de sous-fonctions, mais est définie manuellement. Cette méthode est particulièrement adaptée lorsque la taille d’une seule sous-fonction dépasse 4 Mo. L’avantage est qu’elle permet de diviser manuellement de grandes sous-fonctions de script, telles que celles liées au calcul Fq12 ; chaque bloc est logique, facile à lire et à auditer. L’inconvénient est qu’elle est limitée par la capacité d’optimisation manuelle. Une fois le script optimisé dans son ensemble, les points de division manuelle définis précédemment peuvent ne plus être optimaux et doivent être ajustés.

Par exemple, après plusieurs optimisations, la taille du script du validateur Groth16 est passée d’environ 7 Go à environ 1,26 Go. En plus de l’optimisation globale du calcul, chaque bloc peut également être optimisé individuellement pour tirer pleinement parti de l’espace de la pile. Par exemple, en introduisant un algorithme de table de recherche plus efficace et en chargeant et déchargeant dynamiquement la table de recherche, la taille du script de chaque bloc peut être encore réduite.

En raison des coûts de calcul et de l’environnement d’exécution des langages de programmation Web2, qui diffèrent complètement du script BTC, il n’est pas possible de simplement convertir les implémentations existantes de l’algorithme en script BTC. Par conséquent, il est nécessaire de prendre en compte des optimisations spécifiques au scénario BTC:

• Recherchez un Algorithme qui peut optimiser la localité de la mémoire, même si cela peut ajouter une certaine charge de calcul, pour réduire le nombre de bits d’entrée/sortie entre les blocs, réduisant ainsi la quantité de données requise pour l’engagement dans la conception de transactions assertTx de Goutte BitVM2.
• Utilisez la commutativité des opérations associées (par exemple, les opérations logiques) telles que x&y = y&x pour économiser près de la moitié de l’espace de la table de recherche.
• Actuellement, la taille du script opéré par Fq12 est assez grande ; il peut être envisagé d’utiliser les schémas Fiat-Shamir, Schwartz-Zipple et d’engagement polynômial pour augmenter considérablement la complexité de calcul de l’extension Fq12,01928374656574839201.

4 Résumé

Cet article examine d’abord les limites du script BTC et discute de plusieurs solutions : utiliser les engagements BTC pour surmonter les limitations de l’UTXO, utiliser Taproot pour surmonter les limitations de l’espace de script, contourner les méthodes de dépense de l’UTXO en connectant les sorties, et résoudre les limitations de la présignature par le biais de contrats. Ensuite, l’article donne un aperçu complet des caractéristiques des preuves de fraude et de validité, y compris les caractéristiques des preuves de fraude avec et sans permission, les différences entre les preuves de fraude à un tour et à plusieurs tours, et les techniques de division de script BTC connexes.

Déclaration :

1. Cet article est repris de [aicoin]，著作权归属原作者[mutourend & lynndell, Bitlayer Labs]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. Avis de non-responsabilité : Les opinions exprimées dans cet article ne représentent que l’opinion personnelle de l’auteur et ne constituent pas un conseil en investissement.
3. Les autres versions linguistiques de l’article sont traduites par l’équipe de Gate Learn. Sans mention de Gate.io, il est interdit de copier, diffuser ou plagier l’article traduit.