1. Introduction

Bitcoin est un actif numérique décentralisé, sécurisé et fiable. Cependant, il présente des limitations significatives qui l'empêchent de devenir un réseau évolutif pour les paiements et autres applications. Le problème de mise à l'échelle de Bitcoin est une préoccupation depuis sa création. Le modèle UTXO (Unspent Transaction Output) de Bitcoin traite chaque transaction comme un événement indépendant, conduisant à un système sans état qui manque de la capacité d'exécuter des calculs complexes dépendant de l'état. En conséquence, bien que Bitcoin puisse effectuer des scripts simples et des transactions multi-signatures, il peine à faciliter les interactions contractuelles complexes et dynamiques courantes sur les plateformes de blockchain étatiques. Cette limitation restreint significativement la gamme d'applications décentralisées (dApps) et d'instruments financiers complexes pouvant être développés sur Bitcoin, alors que les modèles de plateformes étatiques offrent un environnement plus diversifié pour déployer et exécuter des smart contracts riches en fonctionnalités.

Pour la mise à l'échelle de Bitcoin, les principales technologies incluent les canaux d'état, les sidechains et la validation côté client. Les canaux d'état offrent une solution de paiement sécurisée et diversifiée mais ont une capacité limitée à vérifier des calculs arbitrairement complexes. Cette limitation réduit leur applicabilité dans divers scénarios nécessitant une logique et des interactions complexes et conditionnelles. Les sidechains prennent en charge un large éventail d'applications et offrent une diversité au-delà des capacités de Bitcoin, mais elles ont une sécurité moindre. Cette différence de sécurité découle du fait que les sidechains utilisent des mécanismes de consensus indépendants, qui sont beaucoup moins robustes que le mécanisme de consensus de Bitcoin. La validation côté client, en utilisant le modèle UTXO de Bitcoin, peut gérer des transactions plus complexes, mais elle manque de vérification bidirectionnelle et de contraintes avec Bitcoin, ce qui entraîne une sécurité moindre. La conception hors chaîne des protocoles de validation côté client repose sur des serveurs ou une infrastructure de cloud, ce qui pourrait entraîner une centralisation ou une censure potentielle via des serveurs compromis. La conception hors chaîne de la validation côté client introduit également plus de complexité dans l'infrastructure de la blockchain, ce qui pourrait entraîner des problèmes de scalabilité.

En décembre 2023, Robin Linus, le chef de projet de ZeroSync, a publié un livre blanc intitulé «BitVM : Calculer n'importe quoi sur BitcoinCela a suscité une réflexion considérable sur l'amélioration de la programmabilité du Bitcoin. Le document propose une solution de contrat Bitcoin complète de Turing qui peut exécuter n'importe quelle computation complexe sur Bitcoin sans modifier les règles de consensus du réseau ou altérer les principes fondamentaux du Bitcoin. BitVM exploite les scripts Bitcoin et Taproot pour mettre en œuvre des Rollups optimistes. Il utilise des signatures Lamport (également connues sous le nom d'engagement bit) pour établir des connexions entre deux UTXOs Bitcoin, permettant ainsi des scripts Bitcoin étatiques. Un grand programme est engagé dans une adresse Taproot, et les opérateurs et validateurs s'engagent dans des interactions hors chaîne approfondies, laissant une empreinte minimale sur la blockchain. Si les deux parties coopèrent, toute computation complexe et étatique hors chaîne peut être exécutée sans laisser de trace sur la blockchain. Cependant, si les parties ne coopèrent pas, une exécution sur chaîne est nécessaire en cas de litige. Par conséquent, BitVM élargit considérablement les cas d'utilisation potentiels du Bitcoin, lui permettant de servir non seulement de monnaie, mais aussi de plateforme de vérification pour diverses applications décentralisées et tâches computationnelles complexes.

Cependant, malgré les avantages de la technologie BitVM dans la mise à l'échelle de Bitcoin, elle en est encore à ses débuts et rencontre certains problèmes d'efficacité et de sécurité, tels que : (1) Les défis et les réponses nécessitent de multiples interactions, entraînant des frais de transaction élevés et des périodes de défi prolongées ; (2) Les signatures uniques de Lamport ont des longueurs de données importantes, nécessitant une réduction de la taille des données ; (3) La complexité de la fonction de hachage nécessite des fonctions de hachage favorables à Bitcoin pour réduire les coûts ; (4) Les contrats BitVM existants sont vastes, et la capacité des blocs Bitcoin est limitée, donc l'utilisation de scripts sans scripts pourrait aider à réaliser les scripts sans scripts BitVM, économisant ainsi de l'espace dans les blocs Bitcoin et améliorant l'efficacité de BitVM ; (5) Le BitVM actuel fonctionne sur un modèle de permission, les défis étant lancés uniquement par les membres du consortium et limités à deux parties, ce qui devrait être étendu à un modèle de défi multi-parties sans permission pour réduire davantage les hypothèses de confiance. Pour résoudre ces problèmes, l'article suggère plusieurs idées d'optimisation pour améliorer l'efficacité et la sécurité de BitVM.

2. Principe BitVM

BitVM est positionné comme un système de contrat hors chaîne pour Bitcoin, dans le but de faire avancer la fonctionnalité de contrat de Bitcoin. Actuellement, les scripts Bitcoin sont entièrement sans état, ce qui signifie que l'environnement d'exécution se réinitialise après chaque script. Il n'y a pas de moyen natif dans le script Bitcoin pour garantir que les scripts 1 et 2 ont la même valeur de x. Cependant, il est possible de rendre les scripts Bitcoin étatiques en utilisant des opcodes existants et des signatures à usage unique de Lamport, en imposant que x dans script1 et script2 soient les mêmes. Si les participants signent des valeurs conflictuelles de x, ils peuvent être pénalisés.

Les calculs BitVM se font hors chaîne, tandis que la vérification de ces calculs a lieu sur chaîne. Compte tenu de la limite de 1 Mo des blocs Bitcoin, lorsque la vérification de calculs complexes est nécessaire, la technologie OP peut être utilisée en mode challenge-réponse pour prendre en charge une vérification de calcul plus complexe.

Similaire à Optimistic Rollup et à la proposition MATT (Merkelize All The Things), le système BitVM est basé sur des preuves de fraude et des protocoles de défi-réponse mais ne nécessite pas de modifications des règles de consensus de Bitcoin. Les primitives sous-jacentes de BitVM sont simples, principalement basées sur des verrous de hachage, des verrous temporels et de grands arbres Taproot.

Les prouveurs s'engagent dans le programme octet par octet, mais vérifier toutes les calculs on-chain serait excessivement coûteux. Par conséquent, les vérificateurs mènent une série de défis soigneusement conçus pour réfuter de manière succincte les affirmations fausses des prouveurs. Les prouveurs et les vérificateurs co-signent une série de transactions de défi et de réponse pour résoudre les litiges, permettant ainsi la vérification générale des calculs sur Bitcoin.

Les composants clés de BitVM comprennent :

• Engagement de circuit : Les prouveurs et les vérificateurs compilent le programme dans un grand circuit binaire. Le prouveur s'engage à ce circuit dans une adresse Taproot, chaque script de feuille sous cette adresse correspondant à chaque porte logique dans le circuit. L'objectif est d'obtenir un engagement de porte logique basé sur un engagement de bit.
• Défi et réponse : Les prouveurs et les vérificateurs pré-signent une série de transactions pour mettre en œuvre le jeu de défi-réponse. Idéalement, cette interaction se produit hors chaîne, mais elle peut également être exécutée sur chaîne si le prouveur est non coopératif.
• Pénalité ambiguë : Si le prouveur fait des déclarations incorrectes, le vérificateur peut saisir le dépôt du prouveur après avoir réussi à contester, et à contrecarrer les actions malveillantes du prouveur.

3. Optimisations BitVM

Réduire les nombres d'interactions OP basés sur ZK 3.1

Il existe deux principaux types de Rollups : ZK Rollups et Optimistic Rollups (OP Rollups). Les ZK Rollups reposent sur la vérification de la validité des preuves de connaissance nulle (ZK), qui sont des preuves cryptographiques d'exécution correcte. Leur sécurité dépend des hypothèses de complexité computationnelle. Les Optimistic Rollups reposent sur les Preuves de Fraude, en supposant que tous les états soumis sont corrects et en fixant généralement une période de défi d'environ sept jours. Leur sécurité suppose qu'au moins une partie honnête du système peut détecter l'état incorrect et soumettre une preuve de fraude.

En supposant que le nombre maximal d'étapes pour le programme de défi de BitVM est de 2^{32}, il aurait besoin d'environ 17 Go de mémoire (2^{32}×4 octets). Dans le pire des cas, environ 40 tours de défis et de réponses pourraient prendre environ six mois, avec une taille de script totale d'environ 150 Ko. Un tel scénario fournirait des incitations insuffisantes, mais il se produit rarement en pratique.

Utiliser des preuves de connaissance nulle pour réduire le nombre de défis dans BitVM pourrait améliorer son efficacité. Selon la théorie de la preuve de connaissance nulle, si les données satisfont à un algorithme F, alors la preuve satisfait l'algorithme de vérification Verify, renvoyant True. En revanche, si les données ne satisfont pas F, alors la preuve ne satisfera pas Verify, renvoyant False. Dans le système BitVM, si le challenger n'accepte pas les données du prouveur, un défi est lancé.

Pour l'algorithme F, en utilisant une approche de recherche binaire, en supposant que 2^n itérations sont nécessaires pour trouver le point d'erreur. Si la complexité de l'algorithme est trop élevée, n est grand et cela prend beaucoup de temps pour terminer. Cependant, la complexité de l'algorithme de vérification de Preuve de Connaissance Nulle Verify est fixe. En révélant publiquement la preuve et le processus de vérification Verify, il est possible de voir une sortie de Faux. L'avantage des Preuves de Connaissance Nulle réside dans la plus faible complexité de calcul requise pour ouvrir l'algorithme de vérification Verify par rapport à l'ouverture de l'algorithme original F en utilisant la recherche binaire. Ainsi, avec les Preuves de Connaissance Nulle, BitVM ne remet plus en question l'algorithme original F, mais plutôt l'algorithme de vérification Verify, réduisant le nombre de tours de défi et raccourcissant la période de défi.

Bien que la validité des preuves de zéro-connaissance et des preuves de fraude repose sur des hypothèses de sécurité différentes, elles peuvent être combinées pour construire une preuve de fraude ZK et mettre en œuvre une preuve ZK à la demande. Contrairement à un ZK Rollup complet, le modèle à la demande nécessite une preuve ZK uniquement lorsqu'un défi est lancé, en maintenant une conception optimiste où l'état généré est considéré comme valide jusqu'à ce qu'il soit contesté. Si un état n'est pas contesté, aucune preuve ZK n'est nécessaire. Cependant, si un défi est lancé, une preuve ZK doit être générée pour la véracité de toutes les transactions au sein du bloc contesté. À l'avenir, il pourrait être possible de générer des preuves de fraude ZK pour des instructions individuelles contestées, évitant ainsi le coût computationnel de générer continuellement des preuves ZK.

3,2 signatures uniques compatibles avec Bitcoin

Dans le réseau Bitcoin, les transactions qui suivent les règles de consensus sont considérées comme valides, mais au-delà de ces règles, il existe un concept supplémentaire de standardisation. Les nœuds Bitcoin ne propagent et ne diffusent que des transactions standard, et la seule façon pour des transactions valides mais non standard d'être incluses dans un bloc est une collaboration directe avec les mineurs.

Selon les règles de consensus, la taille maximale des transactions héritées (non-Segwit) est de 1 Mo, ce qui pourrait remplir un bloc entier. Cependant, la limite de standardité pour les transactions héritées est fixée à 100 ko. Pour les transactions Segwit, la taille maximale autorisée par les règles de consensus est de 4 Mo, connue sous le nom de limite de poids, mais leur limite de standardité est de 400 ko.

Les signatures de Lamport sont un composant fondamental de BitVM, et réduire la longueur des signatures et des clés publiques aide à réduire la taille des données de transaction, réduisant ainsi les frais de transaction. Les signatures à usage unique de Lamport nécessitent une fonction de hachage (comme une fonction de permutation à sens unique f). Dans un schéma de signature à usage unique de Lamport, la longueur du message est de v bits, et les longueurs de la clé publique et de la signature sont toutes deux de 2v bits. Ces longues signatures et clés publiques consomment une quantité significative de gas de stockage. Par conséquent, il est nécessaire d'explorer des schémas de signature qui peuvent réduire la longueur des signatures et des clés publiques. Par rapport aux signatures à usage unique de Lamport, les signatures à usage unique de Winternitz réduisent considérablement les longueurs des signatures et des clés publiques, mais augmentent la complexité computationnelle de la signature et de la vérification.

Dans le schéma de signature à usage unique de Winternitz, une fonction spéciale P mappe un message de v bits à un vecteur s de longueur n, chaque élément de s prenant une valeur dans {0,…,d}. Le schéma de signature à usage unique de Lamport est un cas particulier du schéma de Winternitz, où d=1. Dans le schéma de Winternitz, la relation entre n, d et v est approximativement n≈v/log2(d+1). Lorsque d=15, n≈(v/4)+1. Pour une signature de Winternitz avec n éléments, les longueurs de clé publique et de signature sont quatre fois plus courtes que celles du schéma de signature à usage unique de Lamport, mais la complexité de la vérification est quatre fois plus élevée. En utilisant d=15, v=160, f=ripemd160(x) dans BitVM pour les signatures à usage unique de Winternitz, la taille de l'engagement de bits peut être réduite de 50%, réduisant ainsi les frais de transaction de BitVM d'au moins 50%. À l'avenir, tout en optimisant l'implémentation du script Bitcoin de Winternitz existant, l'exploration de schémas de signature à usage unique plus compacts pouvant être exprimés dans le script Bitcoin pourrait être poursuivie.

3.3 Fonctions de hachage compatibles avec Bitcoin

Selon les règles de consensus, la taille maximale pour un script P2TR est de 10 ko, et la taille maximale pour un témoin de script P2TR est la même que la taille maximale d'une transaction Segwit, qui est de 4 Mo. Cependant, la limite de normalité pour un témoin de script P2TR est de 400 ko.

Actuellement, le réseau Bitcoin ne prend pas en charge OP_CAT, ce qui rend impossible la concaténation de chaînes pour la vérification du chemin de Merkle. Par conséquent, il est nécessaire de mettre en œuvre une fonction de hachage compatible avec Bitcoin en utilisant le script Bitcoin existant, de la manière la plus efficace en termes de taille à la fois pour la taille du script et pour la taille du témoin du script, afin de prendre en charge la vérification de la preuve d'inclusion de Merkle.

BLAKE3 est une version optimisée de la fonction de hachage BLAKE2 et introduit un mode arbre Bao. Par rapport à BLAKE2s, le nombre de tours de sa fonction de compression a été réduit de 10 à 7. La fonction de hachage BLAKE3 divise son entrée en morceaux de 1024 octets, le dernier morceau pouvant être plus court mais non vide. Lorsqu'il n'y a qu'un seul morceau, il sert de nœud racine et de seul nœud de l'arbre. Ces morceaux sont disposés en tant que nœuds feuilles d'un arbre binaire, et chaque morceau est compressé indépendamment.

Lorsque BitVM est utilisé pour vérifier les preuves d'inclusion de Merkle, l'entrée pour l'opération de hachage se compose de deux valeurs de hachage de 256 bits concaténées, totalisant 64 octets. Avec la fonction de hachage BLAKE3, ces 64 octets peuvent tenir dans un seul chunk, ce qui signifie que l'opération de hachage BLAKE3 n'a besoin d'appliquer la fonction de compression qu'une seule fois à ce seul chunk. Dans la fonction de compression de BLAKE3, sept fonctions de tour et six fonctions de permutation sont nécessaires.

BitVM a déjà mis en œuvre des opérations de base telles que XOR, l'addition modulaire et le décalage de bits à droite basé sur des valeurs u32, ce qui rend facile l'assemblage d'une fonction de hachage BLAKE3 en utilisant un script Bitcoin. La pile utilise quatre octets séparés pour représenter des mots u32, facilitant l'addition u32, le XOR bit à bit u32 et les rotations bit à bit u32 nécessaires pour BLAKE3. La fonction de hachage BLAKE3 dans le script Bitcoin fait actuellement environ 100 ko, suffisant pour construire une version de jouet de BitVM.

De plus, en divisant ces codes BLAKE3, le Vérificateur et le Prouveur peuvent réduire de manière significative les exigences en données on-chain en divisant l'exécution en un jeu de défi-réponse au lieu de le réaliser entièrement. Enfin, la mise en œuvre de fonctions de hachage comme Keccak-256 et Grøstl dans le script Bitcoin permettra d'identifier la fonction de hachage la plus adaptée à Bitcoin et d'explorer d'autres nouvelles fonctions de hachage conviviales pour Bitcoin.

3.4 Scripts sans script BitVM

Les scripts sans script sont une méthode d'exécution de contrats intelligents hors chaîne en utilisant des signatures Schnorr. Le concept de scripts sans script est apparu dans Mimblewimble, où aucune donnée permanente n'est stockée autre que le noyau et sa signature.

Les avantages des scripts sans script incluent la fonctionnalité, la confidentialité et l'efficacité :

• Fonctionnalité : Les scripts sans script peuvent étendre la portée et la complexité des contrats intelligents. Les capacités du script Bitcoin sont limitées par le nombre d'OP_CODES activés sur le réseau. En revanche, les scripts sans script déplacent la spécification et l'exécution des contrats intelligents hors chaîne pour les discussions entre les seules parties contractantes, sans attendre que le réseau Bitcoin se bifurque pour activer de nouveaux opcodes.
• Confidentialité : Déplacer la spécification et l'exécution des contrats intelligents de la chaîne à la chaîne améliore la confidentialité. Sur la chaîne, de nombreux détails du contrat sont partagés avec l'ensemble du réseau, y compris le nombre de participants, les adresses et le montant transféré. Déplacer les contrats intelligents hors chaîne signifie que le réseau sait seulement que les participants ont convenu que les termes du contrat sont satisfaits et que les transactions associées sont valides.
• Efficacité : Les scripts sans script minimisent la quantité de données à vérifier et à stocker on-chain. En déplaçant les contrats intelligents off-chain, les coûts administratifs pour les nœuds complets sont réduits, et les frais de transaction pour les utilisateurs sont également réduits.

Les scripts sans script représentent une manière de concevoir des protocoles cryptographiques sur Bitcoin qui évite d'exécuter des contrats intelligents explicites. L'idée principale est d'utiliser des algorithmes cryptographiques pour obtenir la fonctionnalité souhaitée au lieu d'utiliser des scripts. Les signatures d'adaptateur et les multisignatures sont des éléments constitutifs fondamentaux des scripts sans script. Avec les scripts sans script, les transactions peuvent être plus petites que les transactions conventionnelles, réduisant ainsi les frais de transaction.

Les scripts sans script peuvent être utilisés pour mettre en œuvre des engagements de portes logiques dans le circuit BitVM, économisant ainsi de l'espace de script BitVM et améliorant l'efficacité de BitVM, en utilisant des signatures multi-signatures Schnorr et des signatures d'adaptateur au lieu de fournir des valeurs de hachage et des pré-images comme la solution BitVM. Bien que les schémas actuels de scripts sans script puissent réduire l'espace de script BitVM, ils exigent une interaction étendue entre le prouveur et le contestataire pour combiner les clés publiques. Les améliorations futures viseront à intégrer les scripts sans script dans des modules fonctionnels BitVM spécifiques.

3.5 Défis multi-parties sans permission

Le défi BitVM actuel nécessite une autorisation car un UTXO Bitcoin ne peut être exécuté qu'une fois, ce qui conduit à une situation où un vérificateur malveillant pourrait "gaspiller" le contrat en défiant un prouveur honnête. BitVM est actuellement restreint à un modèle de défi bipartite. Un prouveur malveillant pourrait utiliser un vérificateur sous son contrôle pour initier un défi et "gaspiller" le contrat, assurant ainsi le succès de son action malveillante tandis que d'autres vérificateurs ne peuvent pas empêcher ce comportement. Par conséquent, en plus de Bitcoin, il est nécessaire de rechercher un protocole de défi OP multi-parties sans autorisation qui pourrait étendre le modèle de confiance existant 1-sur-n de BitVM à 1-sur-N, où N est beaucoup plus grand que n. De plus, il est important de traiter les problèmes de collusion entre les challengers et les prouveurs ou les défis malveillants qui "gaspillent" les contrats pour parvenir à un protocole BitVM plus minimisé en termes de confiance.

Un défi multi-parties sans permission permet à quiconque de participer sans liste blanche, ce qui signifie que les utilisateurs peuvent effectuer des retraits de la L2 sans l'intervention d'un tiers de confiance. De plus, tout utilisateur souhaitant participer au protocole de défi OP peut remettre en question et supprimer les retraits invalides.

Étendre BitVM en un modèle de défi multi-parties sans permission implique de traiter les attaques suivantes :

• Attaques Sybil : même si un attaquant crée plusieurs identités pour participer à la contestation, un seul participant honnête devrait toujours être en mesure de gagner la contestation. Si le coût pour un participant honnête de défendre le résultat correct augmente linéairement avec le nombre d’attaquants, le coût pour le participant honnête de gagner le litige devient peu pratique et vulnérable aux attaques Sybil lorsqu’il implique un grand nombre d’attaquants. L’article «Tournois arbitres sans permissionpropose un algorithme de résolution des litiges qui modifie les règles du jeu, où le coût pour un seul participant honnête de remporter le litige croît de manière logarithmique, et non linéaire, avec le nombre d'adversaires.
• Attaques différées : un individu ou un groupe d’acteurs malveillants suit une stratégie pour empêcher ou retarder la confirmation du résultat correct (comme le retrait d’actifs vers L1) sur L1, forçant le prouveur honnête à dépenser des frais de transaction L1. Pour atténuer ce problème, les challengers pourraient être tenus de faire une mise initiale. Si un challenger lance une attaque à retardement, sa mise sera perdue. Cependant, si les attaquants sont prêts à sacrifier leur mise dans une certaine mesure pour poursuivre des attaques à retardement, il devrait y avoir des stratégies pour réduire l’impact de ces attaques. L’algorithme proposé dans l’article «BoLD: Délai de Liquidité Bornée dans un Protocole de Défi Rollup” garantit que le retard maximal causé par l'attaquant est limité, quelle que soit la quantité de jetons que l'attaquant est prêt à perdre.

À l'avenir, il y aura une exploration d'un modèle de défi multi-parties sans permission BitVM qui est résistant à ces attaques et adapté aux caractéristiques du Bitcoin.

4. Conclusion

L'exploration de la technologie BitVM ne fait que commencer, et à l'avenir, davantage d'optimisations seront explorées et mises en pratique pour réaliser la mise à l'échelle de Bitcoin et enrichir l'écosystème Bitcoin.

Avertissement：

1. Cet article est repris de [ @Bitlayer/bitvm-et-ses-considerations-d-optimisation-007da599d8ac">Bitlayer], Tous les droits d'auteur appartiennent à l'auteur original [BITLynndell et Mutourend]. Si des objections sont soulevées concernant cette réimpression, veuillez contacter le Porte Apprendreéquipe et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les vues et opinions exprimées dans cet article sont uniquement celles 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 sont interdits.