Bitcoin est un actif numérique décentralisé, sécurisé et digne de confiance. Cependant, il présente des limites importantes qui l’empêchent de devenir un réseau évolutif pour les paiements et autres applications. Le problème de la mise à l’échelle du Bitcoin est une préoccupation depuis sa création. Le modèle Bitcoin UTXO traite chaque transaction comme un événement indépendant, ce qui donne lieu à un système sans état qui n'a pas la capacité d'effectuer des calculs complexes dépendant de l'état. Par conséquent, même si Bitcoin peut exécuter des scripts simples et des transactions multi-signatures, il a du mal à faciliter les interactions contractuelles complexes et dynamiques courantes sur les plates-formes blockchain avec état. Ce problème limite considérablement la portée des applications décentralisées (dApps) et des instruments financiers complexes qui peuvent être construits sur Bitcoin, tandis que les plates-formes de modèles d'état offrent un environnement plus diversifié pour le déploiement et l'exécution de contrats intelligents riches en fonctionnalités.
Pour l’expansion du Bitcoin, il existe principalement des technologies telles que les canaux d’État, les chaînes latérales et la vérification des clients. Parmi eux, les canaux étatiques proposent des solutions de paiement sécurisées et diversifiées, mais ils sont limités dans leur capacité à vérifier des calculs arbitrairement complexes. Cette limitation réduit son utilisation dans une variété de scénarios qui nécessitent une logique et des interactions complexes et conditionnelles. Les sidechains, bien qu’elles prennent en charge un large éventail d’applications et offrent une diversité de fonctionnalités au-delà de Bitcoin, ont une sécurité moindre. Cette différence de sécurité vient du fait que les sidechains utilisent des mécanismes de consensus indépendants, bien moins robustes que le mécanisme de consensus Bitcoin. La vérification côté client, utilisant le modèle Bitcoin UTXO, peut gérer des transactions plus complexes, mais elle n'a pas la capacité de contrainte de somme de contrôle bidirectionnelle avec Bitcoin, ce qui rend sa sécurité inférieure à celle de Bitcoin. La conception hors chaîne des protocoles de vérification des clients repose sur une infrastructure de serveur ou de cloud, ce qui peut conduire à 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 blockchain, ce qui pourrait entraîner des problèmes d’évolutivité.
En décembre 2023, Robin Linus, chef du projet ZeroSync, a publié un livre blanc intitulé « BitVM : Compute Anything On Bitcoin », qui a déclenché la réflexion de chacun sur l'amélioration de la programmabilité de Bitcoin. Cet article propose une solution de contrat Bitcoin qui peut atteindre l'exhaustivité de Turing sans changer le consensus du réseau Bitcoin, de sorte que tout calcul complexe puisse être vérifié sur Bitcoin sans changer les règles de base de Bitcoin. BitVM utilise pleinement Bitcoin Script et Taproot pour obtenir un cumul optimiste. Sur la base de la signature Lamport (également connue sous le nom d'engagement de bits), une connexion est établie entre deux UTXO Bitcoin pour implémenter des scripts Bitcoin avec état. En s'engageant dans un vaste programme dans une adresse Taproot, les opérateurs et les validateurs s'engagent dans de nombreuses interactions hors chaîne, ce qui se traduit par une petite empreinte en chaîne. Si les deux parties coopèrent, des calculs hors chaîne arbitrairement complexes et avec état peuvent être effectués sans laisser de trace sur la chaîne. Si les deux parties ne coopèrent pas, lorsqu'un litige survient, une exécution en chaîne est requise. En conséquence, BitVM élargit considérablement les cas d'utilisation potentiels de Bitcoin, permettant à Bitcoin de servir non seulement de monnaie mais également de plate-forme de vérification pour une variété d'applications décentralisées et de tâches informatiques complexes.
Cependant, bien que la technologie BitVM présente de grands avantages dans l’expansion du Bitcoin, elle n’en est qu’à ses débuts et il existe encore quelques problèmes en termes d’efficacité et de sécurité. Par exemple : (1) les défis et les réponses nécessitent de multiples interactions, ce qui entraîne des frais de traitement élevés et de longs cycles de défi ; (2) les données de signature unique de Lamport sont longues et la longueur des données doit être réduite ; (3) la fonction de hachage est complexe et nécessite une fonction de hachage compatible avec Bitcoin pour réduire les coûts ; (4) Le contrat BitVM existant est énorme et la capacité de bloc Bitcoin est limitée. Moins de s peuvent être utilisés pour implémenter moins de BitVM, économisant ainsi de l'espace de bloc Bitcoin et améliorant l'efficacité de BitVM ; (5 ) Le BitVM existant adopte un modèle d'autorisation. Seuls les membres de l'alliance peuvent lancer des défis, et il est limité à seulement deux parties. Il devrait être étendu à un modèle de défi multipartite sans autorisation pour réduire davantage l'hypothèse de confiance. A cette fin, cet article propose quelques idées d'optimisation pour améliorer encore l'efficacité et la sécurité de BitVM.
2.Principe BitVM
BitVM se positionne comme un contrat hors chaîne de Bitcoin et s'engage à promouvoir les fonctions du contrat Bitcoin. Actuellement, les scripts Bitcoin sont complètement apatrides, donc lorsqu'un script Bitcoin est exécuté, son environnement d'exécution est réinitialisé après chaque script. Il n'existe aucun moyen natif pour que le script 1 et le script 2 aient la même valeur x, et Bitcoin Script ne le prend pas en charge de manière native. Cependant, vous pouvez toujours utiliser les opcodes existants pour rendre le script Bitcoin avec état via la signature unique de Lamport. Par exemple, vous pouvez forcer x dans 1 et 2 à avoir la même valeur. Les participants peuvent être pénalisés s’ils signent des valeurs X contradictoires. Les calculs du programme BitVM s'effectuent hors chaîne, tandis que la vérification des résultats des calculs s'effectue en chaîne. Le bloc Bitcoin actuel a une limite de 1 Mo. Lorsque le calcul de vérification est trop complexe, la technologie OP peut être utilisée pour adopter le mode de réponse au défi afin de prendre en charge une vérification de calcul plus complexe.
Semblable à Optimistic Rollup et à la proposition MATT (Merkelize All The Things), le système BitVM est basé sur des protocoles de preuve de fraude et de défi-réponse, mais ne nécessite pas de modification 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.
Le prouveur valide octet par octet, mais vérifier tous les calculs en chaîne serait trop coûteux. Ainsi, le vérificateur effectue une série de défis soigneusement conçus pour réfuter succinctement les fausses affirmations du prouveur. Les prouveurs et les validateurs présignent conjointement une série de transactions de défi et de réponse qui sont utilisées pour résoudre les litiges, permettant ainsi une vérification informatique universelle sur Bitcoin.
Les composants clés de BitVM sont :
Engagements concernant les circuits : Les prouveurs et les vérificateurs compilent les programmes en grands circuits binaires. Le prouveur s'engage sur le circuit dans une adresse Taproot, et chaque script feuille sous cette adresse correspond à chaque porte logique du circuit. Le noyau est basé sur l'engagement de bits pour mettre en œuvre l'engagement de porte logique et l'engagement de circuit.
Défi et réponse : Les prouveurs et les vérificateurs pré-signent une série de transactions pour mettre en œuvre le jeu défi-réponse. Idéalement, cette interaction est effectuée hors chaîne, mais peut également être effectuée en chaîne lorsque le prouveur n'est pas coopératif.
Pénalité ambiguë : Si le prouveur fait une déclaration incorrecte, le vérificateur peut retirer le dépôt du prouveur après l'avoir contesté avec succès afin de contrecarrer le mauvais comportement du prouveur.
3.Optimisation BitVM
3.1 Réduire le nombre d'interactions OP basées sur ZK
Il existe actuellement 2 rollups courants : les rollups ZK et les rollups OP. Parmi eux, ZK Rollups s'appuie sur la vérification de la validité de ZK Proof, c'est-à-dire la preuve cryptographique de l'exécution correcte, et sa sécurité repose sur l'hypothèse de complexité informatique ; OP Rollups s'appuie sur Fraud Proof, en supposant que les états soumis sont corrects, en définissant La période de contestation est généralement de 7 jours et sa sécurité suppose qu'au moins une partie honnête du système puisse détecter l'état incorrect et soumettre une preuve de fraude. Supposons que le nombre maximum d'étapes du programme de défi BitVM est de 2 ^{ 32 } et que la mémoire requise est de 2 ^{ 32 }* 4 octets, soit environ 17 Go. Dans le pire des cas, cela prend environ 40 séries de défis et de réponses, soit environ six mois, et le script total fait environ 150 Ko. Il y a un sérieux manque d’incitations dans cette situation, mais cela n’arrive presque jamais dans la pratique.
Envisagez d'utiliser des preuves sans connaissance pour réduire le nombre de défis BitVM, améliorant ainsi l'efficacité de BitVM. Selon la théorie de la preuve à connaissance nulle, si les données Data satisfont à l'algorithme F, il est prouvé que la preuve satisfait à l'algorithme de vérification Verify, c'est-à-dire que l'algorithme de vérification renvoie True ; si les données Data ne satisfont pas à l'algorithme F, il est prouvé que la preuve ne satisfait pas à l'algorithme de vérification Verify, c'est-à-dire que l'algorithme de vérification génère False . Dans le système BitVM, si le challenger ne reconnaît pas les données soumises par le prouveur, un challenge est lancé.
Pour l'algorithme F, utilisez la méthode de dichotomie pour le diviser. Supposons qu'il faut 2 ^ n fois pour trouver le point d'erreur ; si la complexité de l'algorithme est trop élevée, n sera grand et cela prendra beaucoup de temps. Cependant, la complexité de l'algorithme de vérification Verify de la preuve sans connaissance est corrigée. L'ensemble du processus de preuve et de l'algorithme de vérification Verify est public et le résultat s'avère faux. L'avantage de la preuve sans connaissance est que la complexité informatique requise pour ouvrir l'algorithme de vérification Verify est bien inférieure à la méthode binaire pour ouvrir l'algorithme d'origine F. Par conséquent, avec l'aide d'une preuve de connaissance nulle, BitVM ne conteste plus l'algorithme d'origine F, mais l'algorithme de vérification Verify, réduisant ainsi le nombre de cycles de défi et raccourcissant le cycle de défi.
Enfin, bien que l'efficacité de la preuve sans connaissance et de la preuve contre la fraude dépende de différentes hypothèses de sécurité, elles peuvent être combinées pour créer une preuve de fraude ZK et réaliser une preuve ZK à la demande. Contrairement au ZK Rollup complet, qui n'a plus besoin de générer une preuve ZK pour chaque transition d'état, le modèle à la demande rend la preuve ZK requise uniquement en cas de défis, tandis que la conception entière du Rollup est toujours optimiste. Par conséquent, l’état résultant est toujours valide par défaut jusqu’à ce que quelqu’un le conteste. S'il n'y a pas de défi dans un certain état, il n'est pas nécessaire de générer une preuve ZK. Cependant, si un participant lance un défi, ZK Proof doit être généré pour garantir l'exactitude de toutes les transactions dans le bloc de défi. À l’avenir, nous pourrons explorer la génération de ZK Fraud Proof pour une seule instruction controversée afin d’éviter le coût de calcul lié à la génération permanente de ZK Proof.
3.2 Signature unique compatible Bitcoin
Dans le réseau Bitcoin, les transactions qui suivent les règles de consensus sont des transactions valides, mais en plus des règles de consensus, des règles de normalité sont également introduites. Les nœuds Bitcoin ne transmettent que les transactions standard de diffusion, la seule façon de conditionner les transactions valides mais non standard est de travailler directement 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 occupe la totalité du bloc. Mais la limite de standardité pour les transactions existantes est de 100 Ko. Selon les règles consensuelles, la taille maximale d'une transaction Segwit est de 4 Mo, ce qui correspond à la limite de poids. Cependant, la limite de standardité des transactions Segwit est de 400 Ko.
La signature Lamport est un composant de base de BitVM. Elle réduit la longueur de la signature et de la clé publique, ce qui contribue à réduire les données de transaction et ainsi les frais de traitement. La signature unique de Lamport nécessite l'utilisation d'une fonction de hachage (telle que la fonction de permutation unidirectionnelle f). Dans le schéma de signature unique de Lamport, la longueur du message est de v bits, la longueur de la clé publique est de 2 v bits et la longueur de la signature est également de 2 v bits. La signature et la clé publique sont longues et nécessitent une grande quantité de gaz de stockage. Par conséquent, il est nécessaire de trouver des schémas de signature dotés de fonctions similaires pour réduire la longueur des signatures et des clés publiques. Par rapport à la signature unique Lamport, la signature unique Winternitz a considérablement réduit la longueur de la signature et de la clé publique, mais augmente la complexité informatique de la signature et de la vérification de la signature.
Dans le schéma de signature unique de Winternitz, une fonction spéciale P est utilisée pour mapper un message de v bits en un vecteur s de longueur n. La valeur de chaque élément dans s est {0,..., d}. Le schéma de signature unique de Lamport est le schéma de signature unique de Winternitz dans le cas particulier de d = 1. Dans le schéma de signature unique de Winternitz, la relation entre n, d, v satisfait : n≈v/log 2(d+ 1). Lorsque d= 15, il y a n≈(v/4)+ 1. Pour une signature Winternitz contenant n éléments, la longueur de la clé publique et la longueur de la signature sont 4 fois plus courtes que dans le schéma de signature unique de Lamport. Cependant, la complexité de la vérification des signatures est multipliée par 4. L'utilisation de d= 15, v= 160, f=ripemd 160(x) dans BitVM pour implémenter la signature unique Winternitz peut réduire la taille de l'engagement en bits de 50 %, réduisant ainsi les frais de transaction de BitVM d'au moins 50 %. À l’avenir, tout en optimisant l’implémentation existante du Winternitz Bitcoin Script, des schémas de signature uniques plus compacts exprimés dans Bitcoin Script pourront être explorés.
3.3 Fonctions de hachage compatibles Bitcoin
Selon les règles de consensus, la taille maximale de P 2 TR est de 10 Ko et la taille maximale du témoin P 2 TR est la même que la taille maximale de la transaction Segwit, qui est de 4 Mo. Cependant, la limite supérieure de standardité du témoin P 2 TR est de 400 Ko.
Actuellement, le réseau Bitcoin ne prend pas en charge OP_CAT et les chaînes de caractères ne peuvent pas être épissées pour la vérification du chemin Merkle. Par conséquent, il est nécessaire d'utiliser les scripts Bitcoin existants pour implémenter une fonction de hachage compatible Bitcoin avec une taille et une taille de témoin optimales pour prendre en charge la fonction de vérification de la preuve d'inclusion Merkle.
BLAKE 3 est une version optimisée de la fonction de hachage BLAKE 2 et introduit le mode Bao Tree. Par rapport au BLAKE 2 basé sur s, le nombre de tours de sa fonction de compression est réduit de 10 à 7. La fonction de hachage BLAKE 3 divisera son entrée en morceaux consécutifs de 1024 octets, le dernier morceau peut être plus court mais pas vide. Lorsqu’il n’y a qu’un seul morceau, le morceau est le nœud racine et le seul nœud de l’arborescence. Organisez ces morceaux en tant que nœuds feuilles d'un arbre binaire, puis compressez chaque morceau indépendamment.
Lorsque BitVM est utilisé pour vérifier le scénario de preuve d'inclusion Merkle, l'entrée de l'opération de hachage est composée de deux valeurs de hachage de 256 bits, c'est-à-dire que l'entrée de l'opération de hachage est de 64 octets. Lors de l'utilisation de la fonction de hachage BLAKE 3, ces 64 octets peuvent être alloués au sein d'un seul bloc, et l'ensemble de l'opération de hachage BLAKE 3 n'a besoin d'appliquer la fonction de compression qu'une seule fois au bloc unique. Dans la fonction de compression de BLAKE 3, il faut exécuter la fonction round 7 fois et la fonction permutation 6 fois.
À l'heure actuelle, des opérations de base telles que XOR, l'addition modulaire et le décalage de bit vers la droite basés sur les valeurs u 32 ont été effectuées dans BitVM, et la fonction de hachage BLAKE 3 implémentée par le script Bitcoin peut être facilement assemblée. Utilisez 4 octets séparés dans la pile pour représenter u 32 mots pour implémenter u 32 additions, u 32 XOR au niveau du bit et u 32 rotations au niveau du bit requises par BLAKE 3. Le script Bitcoin actuel de la fonction de hachage BLAKE 3 totalise environ 100 Ko, ce qui est suffisant pour créer une version jouet de BitVM.
De plus, ces codes BLAKE 3 peuvent être divisés, permettant à Verifier et Prover de réduire considérablement les données en chaîne requises en divisant l'exécution dans le jeu défi-réponse en deux au lieu de l'exécuter entièrement. Enfin, utilisez le script Bitcoin pour implémenter des fonctions de hachage telles que Keccak-256 et Grøstl, sélectionnez la fonction de hachage la plus compatible avec Bitcoin et explorez d'autres nouvelles fonctions de hachage compatibles avec Bitcoin.
3.4 moins s BitVM
less s est une méthode d'exécution de contrats intelligents hors chaîne en utilisant les signatures Schnorr. Le concept des Scripless s est né de Mimblewimble, qui ne stocke pas de données permanentes hormis le noyau et sa signature.
Les avantages des moins de publicités sont la fonctionnalité, la confidentialité et l'efficacité.
**Caractéristiques : **moins de s peut augmenter la portée et la complexité des contrats intelligents. Les capacités de script Bitcoin sont limitées par le nombre d'OP_CODES activés dans le réseau, et moins de s déplacent la spécification et l'exécution des contrats intelligents de la chaîne vers des discussions uniquement entre les participants au contrat de conception, sans attendre qu'un fork du réseau Bitcoin les active. Nouvel opcode.
**Confidentialité :**Le déplacement de la spécification et de l'exécution des contrats intelligents de la chaîne vers la hors chaîne augmente la confidentialité. Sur la chaîne, de nombreux détails du contrat seront partagés avec l'ensemble du réseau, notamment le nombre et les adresses des participants ainsi que le montant du transfert. En déplaçant les contrats intelligents hors chaîne, le réseau sait seulement que les participants conviennent que les termes de leurs contrats ont été respectés et que les transactions sous-jacentes sont valides.
**Efficacité : **moins de s minimise la quantité de données vérifiées et stockées en chaîne. En déplaçant les contrats intelligents hors chaîne, les frais de gestion des nœuds complets seront réduits et les frais de transaction pour les utilisateurs seront également réduits.
less s est une approche de conception de protocoles cryptographiques sur Bitcoin qui évite d’avoir à exécuter des contrats intelligents explicites. L'idée principale est d'utiliser des algorithmes cryptographiques pour obtenir la fonctionnalité souhaitée plutôt que d'utiliser des scripts pour obtenir la fonctionnalité. Les signatures d'adaptateur et les multi-signatures sont les éléments constitutifs d'origine de less s. En utilisant moins de s, vous pouvez réaliser des transactions plus petites que les transactions régulières et réduire les frais de transaction.
Avec l'aide de less s, la multi-signature Schnorr et la signature d'adaptateur peuvent être utilisées, qui ne fournissent plus de valeurs de hachage et de pré-images de hachage comme la solution BitVM, et peuvent également réaliser l'engagement de la porte logique dans le circuit BitVM, économisant ainsi BitVM espace de script et amélioration de l'efficacité de BitVM. . Bien que le schéma less s existant puisse réduire l'espace de script BitVM, il nécessite une grande quantité d'interaction entre le prouveur et le challenger pour combiner la clé publique. À l'avenir, nous améliorerons cette solution et essaierons d'introduire les Scriptless dans des modules de fonction BitVM spécifiques.
3.5 Défi multipartite sans autorisation
La raison pour laquelle les défis BitVM actuels nécessitent une autorisation par défaut est que l'UTXO de Bitcoin ne peut être exécuté qu'une seule fois, permettant à un vérificateur malveillant de « gaspiller » le contrat en contestant un prouveur honnête. BitVM est actuellement limité au mode défi à deux. Un prouveur qui tente de faire le mal peut simultanément lancer un défi avec un vérificateur qu'il contrôle, « gaspillant » ainsi le contrat, faisant de l'acte maléfique un succès, et les autres vérificateurs ne peuvent pas empêcher le comportement. Par conséquent, basé sur Bitcoin, un protocole de défi OP multipartite sans autorisation doit être étudié, ce qui peut étendre le modèle de confiance 1 sur N existant de BitVM à 1 sur N. Parmi eux, N est beaucoup plus grand que n. En outre, il est nécessaire d'étudier et de résoudre le problème des challengers qui s'entendent avec les prouveurs ou qui contestent de manière malveillante les contrats « gaspillés ». En fin de compte, implémenter le protocole BitVM avec moins de confiance.
Défis multipartites sans autorisation, permettant à quiconque de participer sans liste d'autorisation. Cela signifie que les utilisateurs peuvent retirer des pièces de monnaie de L2 sans l'intervention d'un tiers de confiance. De plus, tout utilisateur souhaitant participer au protocole de contestation OP peut contester et supprimer les retraits invalides.
L'extension de BitVM à un modèle de défi multipartite sans autorisation nécessite de résoudre les attaques suivantes :
Attaque Sybil : Même si un attaquant forge plusieurs identités pour participer à un défi, une seule partie honnête peut toujours gagner le conflit. Si le coût pour une partie honnête de défendre le bon résultat est linéairement lié au nombre d’attaquants, alors lorsqu’un grand nombre d’attaquants sont impliqués, le coût pour gagner un différend devient irréaliste et vulnérable aux attaques des sorcières. Dans l'article Permissionless Refereed Tournaments, un algorithme de résolution des litiges révolutionnaire est proposé. Le coût d'un seul participant honnête remportant un litige augmente de manière logarithmique avec le nombre d'adversaires, plutôt que de manière linéaire.
Attaque différée : Une partie malveillante ou un groupe de parties malveillantes suit une certaine stratégie pour empêcher ou retarder la confirmation des résultats corrects (comme le retrait d'actifs vers L1) sur L1, et forcer les prouveurs honnêtes à dépenser les frais L1. Ce problème peut être atténué en exigeant que les challengers misent à l'avance. Si un challenger lance une attaque retardée, sa mise est perdue. Cependant, si un attaquant est prêt à sacrifier le staking dans certaines limites pour poursuivre une attaque retardée, il doit y avoir des contre-mesures pour réduire l’impact de l’attaque retardée. L'algorithme proposé dans l'article BoLD : Bounded Liquidity Delay in a Rollup Challenge Protocol fait en sorte que, quel que soit le montant de l'engagement que l'attaquant est prêt à perdre, l'attaque dans le pire des cas ne peut provoquer qu'une certaine limite supérieure de retard.
À l’avenir, nous explorerons le modèle de défi multipartite sans autorisation BitVM, adapté aux caractéristiques du Bitcoin et capable de résister aux problèmes d’attaque ci-dessus.
4. Conclusion
L'exploration de la technologie BitVM vient de commencer et, à l'avenir, d'autres directions d'optimisation seront explorées et mises en œuvre pour parvenir à l'expansion du Bitcoin et faire prospérer l'écosystème Bitcoin.
les références
BitVM : calculez n'importe quoi sur Bitcoin
BitVM：Contrats Bitcoin hors chaîne
Robin Linus sur BitVM
[bitcoin-dev] BitVM : calculez n'importe quoi sur Bitcoin
Le couple étrange : ZK et cumuls optimistes à une date d'évolutivité
Quelles sont les transactions et les limites de Bitcoin ?
BIP-342 : Validation des racines pivotantes
_linus/statut/1765337186222686347
Un cours d'études supérieures en cryptographie appliquée
BLAKE 3 : une fonction, rapide partout
[bitcoin-dev] Implémentation de Blake 3 dans Bitcoin
Introduction à moins de s
BitVM utilisant moins de s
Solutions pour retarder les attaques sur les rollups
Présentation de DAVE. La preuve de panne sans autorisation de Cartesi.
Retarder les attaques sur les rollups
Solutions pour retarder les attaques sur les rollups - Arbitrum Research
Notes sur les jeux informatiques interactifs multijoueurs
BoLD : retard de liquidité limité dans un protocole de défi de cumul
Tournois arbitrés sans autorisation
Lien d'origine
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Analyse du principe BitVM et considérations d'optimisation
Source originale : Groupe de recherche Bitlayer
Auteur original : Lynndell, Mutourend.
1. Introduction
Bitcoin est un actif numérique décentralisé, sécurisé et digne de confiance. Cependant, il présente des limites importantes qui l’empêchent de devenir un réseau évolutif pour les paiements et autres applications. Le problème de la mise à l’échelle du Bitcoin est une préoccupation depuis sa création. Le modèle Bitcoin UTXO traite chaque transaction comme un événement indépendant, ce qui donne lieu à un système sans état qui n'a pas la capacité d'effectuer des calculs complexes dépendant de l'état. Par conséquent, même si Bitcoin peut exécuter des scripts simples et des transactions multi-signatures, il a du mal à faciliter les interactions contractuelles complexes et dynamiques courantes sur les plates-formes blockchain avec état. Ce problème limite considérablement la portée des applications décentralisées (dApps) et des instruments financiers complexes qui peuvent être construits sur Bitcoin, tandis que les plates-formes de modèles d'état offrent un environnement plus diversifié pour le déploiement et l'exécution de contrats intelligents riches en fonctionnalités.
Pour l’expansion du Bitcoin, il existe principalement des technologies telles que les canaux d’État, les chaînes latérales et la vérification des clients. Parmi eux, les canaux étatiques proposent des solutions de paiement sécurisées et diversifiées, mais ils sont limités dans leur capacité à vérifier des calculs arbitrairement complexes. Cette limitation réduit son utilisation dans une variété de scénarios qui nécessitent une logique et des interactions complexes et conditionnelles. Les sidechains, bien qu’elles prennent en charge un large éventail d’applications et offrent une diversité de fonctionnalités au-delà de Bitcoin, ont une sécurité moindre. Cette différence de sécurité vient du fait que les sidechains utilisent des mécanismes de consensus indépendants, bien moins robustes que le mécanisme de consensus Bitcoin. La vérification côté client, utilisant le modèle Bitcoin UTXO, peut gérer des transactions plus complexes, mais elle n'a pas la capacité de contrainte de somme de contrôle bidirectionnelle avec Bitcoin, ce qui rend sa sécurité inférieure à celle de Bitcoin. La conception hors chaîne des protocoles de vérification des clients repose sur une infrastructure de serveur ou de cloud, ce qui peut conduire à 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 blockchain, ce qui pourrait entraîner des problèmes d’évolutivité.
En décembre 2023, Robin Linus, chef du projet ZeroSync, a publié un livre blanc intitulé « BitVM : Compute Anything On Bitcoin », qui a déclenché la réflexion de chacun sur l'amélioration de la programmabilité de Bitcoin. Cet article propose une solution de contrat Bitcoin qui peut atteindre l'exhaustivité de Turing sans changer le consensus du réseau Bitcoin, de sorte que tout calcul complexe puisse être vérifié sur Bitcoin sans changer les règles de base de Bitcoin. BitVM utilise pleinement Bitcoin Script et Taproot pour obtenir un cumul optimiste. Sur la base de la signature Lamport (également connue sous le nom d'engagement de bits), une connexion est établie entre deux UTXO Bitcoin pour implémenter des scripts Bitcoin avec état. En s'engageant dans un vaste programme dans une adresse Taproot, les opérateurs et les validateurs s'engagent dans de nombreuses interactions hors chaîne, ce qui se traduit par une petite empreinte en chaîne. Si les deux parties coopèrent, des calculs hors chaîne arbitrairement complexes et avec état peuvent être effectués sans laisser de trace sur la chaîne. Si les deux parties ne coopèrent pas, lorsqu'un litige survient, une exécution en chaîne est requise. En conséquence, BitVM élargit considérablement les cas d'utilisation potentiels de Bitcoin, permettant à Bitcoin de servir non seulement de monnaie mais également de plate-forme de vérification pour une variété d'applications décentralisées et de tâches informatiques complexes.
Cependant, bien que la technologie BitVM présente de grands avantages dans l’expansion du Bitcoin, elle n’en est qu’à ses débuts et il existe encore quelques problèmes en termes d’efficacité et de sécurité. Par exemple : (1) les défis et les réponses nécessitent de multiples interactions, ce qui entraîne des frais de traitement élevés et de longs cycles de défi ; (2) les données de signature unique de Lamport sont longues et la longueur des données doit être réduite ; (3) la fonction de hachage est complexe et nécessite une fonction de hachage compatible avec Bitcoin pour réduire les coûts ; (4) Le contrat BitVM existant est énorme et la capacité de bloc Bitcoin est limitée. Moins de s peuvent être utilisés pour implémenter moins de BitVM, économisant ainsi de l'espace de bloc Bitcoin et améliorant l'efficacité de BitVM ; (5 ) Le BitVM existant adopte un modèle d'autorisation. Seuls les membres de l'alliance peuvent lancer des défis, et il est limité à seulement deux parties. Il devrait être étendu à un modèle de défi multipartite sans autorisation pour réduire davantage l'hypothèse de confiance. A cette fin, cet article propose quelques idées d'optimisation pour améliorer encore l'efficacité et la sécurité de BitVM.
2.Principe BitVM
BitVM se positionne comme un contrat hors chaîne de Bitcoin et s'engage à promouvoir les fonctions du contrat Bitcoin. Actuellement, les scripts Bitcoin sont complètement apatrides, donc lorsqu'un script Bitcoin est exécuté, son environnement d'exécution est réinitialisé après chaque script. Il n'existe aucun moyen natif pour que le script 1 et le script 2 aient la même valeur x, et Bitcoin Script ne le prend pas en charge de manière native. Cependant, vous pouvez toujours utiliser les opcodes existants pour rendre le script Bitcoin avec état via la signature unique de Lamport. Par exemple, vous pouvez forcer x dans 1 et 2 à avoir la même valeur. Les participants peuvent être pénalisés s’ils signent des valeurs X contradictoires. Les calculs du programme BitVM s'effectuent hors chaîne, tandis que la vérification des résultats des calculs s'effectue en chaîne. Le bloc Bitcoin actuel a une limite de 1 Mo. Lorsque le calcul de vérification est trop complexe, la technologie OP peut être utilisée pour adopter le mode de réponse au défi afin de prendre en charge une vérification de calcul plus complexe.
Semblable à Optimistic Rollup et à la proposition MATT (Merkelize All The Things), le système BitVM est basé sur des protocoles de preuve de fraude et de défi-réponse, mais ne nécessite pas de modification 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.
Le prouveur valide octet par octet, mais vérifier tous les calculs en chaîne serait trop coûteux. Ainsi, le vérificateur effectue une série de défis soigneusement conçus pour réfuter succinctement les fausses affirmations du prouveur. Les prouveurs et les validateurs présignent conjointement une série de transactions de défi et de réponse qui sont utilisées pour résoudre les litiges, permettant ainsi une vérification informatique universelle sur Bitcoin.
Les composants clés de BitVM sont :
3.Optimisation BitVM
3.1 Réduire le nombre d'interactions OP basées sur ZK
Il existe actuellement 2 rollups courants : les rollups ZK et les rollups OP. Parmi eux, ZK Rollups s'appuie sur la vérification de la validité de ZK Proof, c'est-à-dire la preuve cryptographique de l'exécution correcte, et sa sécurité repose sur l'hypothèse de complexité informatique ; OP Rollups s'appuie sur Fraud Proof, en supposant que les états soumis sont corrects, en définissant La période de contestation est généralement de 7 jours et sa sécurité suppose qu'au moins une partie honnête du système puisse détecter l'état incorrect et soumettre une preuve de fraude. Supposons que le nombre maximum d'étapes du programme de défi BitVM est de 2 ^{ 32 } et que la mémoire requise est de 2 ^{ 32 }* 4 octets, soit environ 17 Go. Dans le pire des cas, cela prend environ 40 séries de défis et de réponses, soit environ six mois, et le script total fait environ 150 Ko. Il y a un sérieux manque d’incitations dans cette situation, mais cela n’arrive presque jamais dans la pratique.
Envisagez d'utiliser des preuves sans connaissance pour réduire le nombre de défis BitVM, améliorant ainsi l'efficacité de BitVM. Selon la théorie de la preuve à connaissance nulle, si les données Data satisfont à l'algorithme F, il est prouvé que la preuve satisfait à l'algorithme de vérification Verify, c'est-à-dire que l'algorithme de vérification renvoie True ; si les données Data ne satisfont pas à l'algorithme F, il est prouvé que la preuve ne satisfait pas à l'algorithme de vérification Verify, c'est-à-dire que l'algorithme de vérification génère False . Dans le système BitVM, si le challenger ne reconnaît pas les données soumises par le prouveur, un challenge est lancé.
Pour l'algorithme F, utilisez la méthode de dichotomie pour le diviser. Supposons qu'il faut 2 ^ n fois pour trouver le point d'erreur ; si la complexité de l'algorithme est trop élevée, n sera grand et cela prendra beaucoup de temps. Cependant, la complexité de l'algorithme de vérification Verify de la preuve sans connaissance est corrigée. L'ensemble du processus de preuve et de l'algorithme de vérification Verify est public et le résultat s'avère faux. L'avantage de la preuve sans connaissance est que la complexité informatique requise pour ouvrir l'algorithme de vérification Verify est bien inférieure à la méthode binaire pour ouvrir l'algorithme d'origine F. Par conséquent, avec l'aide d'une preuve de connaissance nulle, BitVM ne conteste plus l'algorithme d'origine F, mais l'algorithme de vérification Verify, réduisant ainsi le nombre de cycles de défi et raccourcissant le cycle de défi.
Enfin, bien que l'efficacité de la preuve sans connaissance et de la preuve contre la fraude dépende de différentes hypothèses de sécurité, elles peuvent être combinées pour créer une preuve de fraude ZK et réaliser une preuve ZK à la demande. Contrairement au ZK Rollup complet, qui n'a plus besoin de générer une preuve ZK pour chaque transition d'état, le modèle à la demande rend la preuve ZK requise uniquement en cas de défis, tandis que la conception entière du Rollup est toujours optimiste. Par conséquent, l’état résultant est toujours valide par défaut jusqu’à ce que quelqu’un le conteste. S'il n'y a pas de défi dans un certain état, il n'est pas nécessaire de générer une preuve ZK. Cependant, si un participant lance un défi, ZK Proof doit être généré pour garantir l'exactitude de toutes les transactions dans le bloc de défi. À l’avenir, nous pourrons explorer la génération de ZK Fraud Proof pour une seule instruction controversée afin d’éviter le coût de calcul lié à la génération permanente de ZK Proof.
3.2 Signature unique compatible Bitcoin
Dans le réseau Bitcoin, les transactions qui suivent les règles de consensus sont des transactions valides, mais en plus des règles de consensus, des règles de normalité sont également introduites. Les nœuds Bitcoin ne transmettent que les transactions standard de diffusion, la seule façon de conditionner les transactions valides mais non standard est de travailler directement 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 occupe la totalité du bloc. Mais la limite de standardité pour les transactions existantes est de 100 Ko. Selon les règles consensuelles, la taille maximale d'une transaction Segwit est de 4 Mo, ce qui correspond à la limite de poids. Cependant, la limite de standardité des transactions Segwit est de 400 Ko.
La signature Lamport est un composant de base de BitVM. Elle réduit la longueur de la signature et de la clé publique, ce qui contribue à réduire les données de transaction et ainsi les frais de traitement. La signature unique de Lamport nécessite l'utilisation d'une fonction de hachage (telle que la fonction de permutation unidirectionnelle f). Dans le schéma de signature unique de Lamport, la longueur du message est de v bits, la longueur de la clé publique est de 2 v bits et la longueur de la signature est également de 2 v bits. La signature et la clé publique sont longues et nécessitent une grande quantité de gaz de stockage. Par conséquent, il est nécessaire de trouver des schémas de signature dotés de fonctions similaires pour réduire la longueur des signatures et des clés publiques. Par rapport à la signature unique Lamport, la signature unique Winternitz a considérablement réduit la longueur de la signature et de la clé publique, mais augmente la complexité informatique de la signature et de la vérification de la signature.
Dans le schéma de signature unique de Winternitz, une fonction spéciale P est utilisée pour mapper un message de v bits en un vecteur s de longueur n. La valeur de chaque élément dans s est {0,..., d}. Le schéma de signature unique de Lamport est le schéma de signature unique de Winternitz dans le cas particulier de d = 1. Dans le schéma de signature unique de Winternitz, la relation entre n, d, v satisfait : n≈v/log 2(d+ 1). Lorsque d= 15, il y a n≈(v/4)+ 1. Pour une signature Winternitz contenant n éléments, la longueur de la clé publique et la longueur de la signature sont 4 fois plus courtes que dans le schéma de signature unique de Lamport. Cependant, la complexité de la vérification des signatures est multipliée par 4. L'utilisation de d= 15, v= 160, f=ripemd 160(x) dans BitVM pour implémenter la signature unique Winternitz peut réduire la taille de l'engagement en bits de 50 %, réduisant ainsi les frais de transaction de BitVM d'au moins 50 %. À l’avenir, tout en optimisant l’implémentation existante du Winternitz Bitcoin Script, des schémas de signature uniques plus compacts exprimés dans Bitcoin Script pourront être explorés.
3.3 Fonctions de hachage compatibles Bitcoin
Selon les règles de consensus, la taille maximale de P 2 TR est de 10 Ko et la taille maximale du témoin P 2 TR est la même que la taille maximale de la transaction Segwit, qui est de 4 Mo. Cependant, la limite supérieure de standardité du témoin P 2 TR est de 400 Ko.
Actuellement, le réseau Bitcoin ne prend pas en charge OP_CAT et les chaînes de caractères ne peuvent pas être épissées pour la vérification du chemin Merkle. Par conséquent, il est nécessaire d'utiliser les scripts Bitcoin existants pour implémenter une fonction de hachage compatible Bitcoin avec une taille et une taille de témoin optimales pour prendre en charge la fonction de vérification de la preuve d'inclusion Merkle.
BLAKE 3 est une version optimisée de la fonction de hachage BLAKE 2 et introduit le mode Bao Tree. Par rapport au BLAKE 2 basé sur s, le nombre de tours de sa fonction de compression est réduit de 10 à 7. La fonction de hachage BLAKE 3 divisera son entrée en morceaux consécutifs de 1024 octets, le dernier morceau peut être plus court mais pas vide. Lorsqu’il n’y a qu’un seul morceau, le morceau est le nœud racine et le seul nœud de l’arborescence. Organisez ces morceaux en tant que nœuds feuilles d'un arbre binaire, puis compressez chaque morceau indépendamment.
Lorsque BitVM est utilisé pour vérifier le scénario de preuve d'inclusion Merkle, l'entrée de l'opération de hachage est composée de deux valeurs de hachage de 256 bits, c'est-à-dire que l'entrée de l'opération de hachage est de 64 octets. Lors de l'utilisation de la fonction de hachage BLAKE 3, ces 64 octets peuvent être alloués au sein d'un seul bloc, et l'ensemble de l'opération de hachage BLAKE 3 n'a besoin d'appliquer la fonction de compression qu'une seule fois au bloc unique. Dans la fonction de compression de BLAKE 3, il faut exécuter la fonction round 7 fois et la fonction permutation 6 fois.
À l'heure actuelle, des opérations de base telles que XOR, l'addition modulaire et le décalage de bit vers la droite basés sur les valeurs u 32 ont été effectuées dans BitVM, et la fonction de hachage BLAKE 3 implémentée par le script Bitcoin peut être facilement assemblée. Utilisez 4 octets séparés dans la pile pour représenter u 32 mots pour implémenter u 32 additions, u 32 XOR au niveau du bit et u 32 rotations au niveau du bit requises par BLAKE 3. Le script Bitcoin actuel de la fonction de hachage BLAKE 3 totalise environ 100 Ko, ce qui est suffisant pour créer une version jouet de BitVM.
De plus, ces codes BLAKE 3 peuvent être divisés, permettant à Verifier et Prover de réduire considérablement les données en chaîne requises en divisant l'exécution dans le jeu défi-réponse en deux au lieu de l'exécuter entièrement. Enfin, utilisez le script Bitcoin pour implémenter des fonctions de hachage telles que Keccak-256 et Grøstl, sélectionnez la fonction de hachage la plus compatible avec Bitcoin et explorez d'autres nouvelles fonctions de hachage compatibles avec Bitcoin.
3.4 moins s BitVM
less s est une méthode d'exécution de contrats intelligents hors chaîne en utilisant les signatures Schnorr. Le concept des Scripless s est né de Mimblewimble, qui ne stocke pas de données permanentes hormis le noyau et sa signature.
Les avantages des moins de publicités sont la fonctionnalité, la confidentialité et l'efficacité.
less s est une approche de conception de protocoles cryptographiques sur Bitcoin qui évite d’avoir à exécuter des contrats intelligents explicites. L'idée principale est d'utiliser des algorithmes cryptographiques pour obtenir la fonctionnalité souhaitée plutôt que d'utiliser des scripts pour obtenir la fonctionnalité. Les signatures d'adaptateur et les multi-signatures sont les éléments constitutifs d'origine de less s. En utilisant moins de s, vous pouvez réaliser des transactions plus petites que les transactions régulières et réduire les frais de transaction.
Avec l'aide de less s, la multi-signature Schnorr et la signature d'adaptateur peuvent être utilisées, qui ne fournissent plus de valeurs de hachage et de pré-images de hachage comme la solution BitVM, et peuvent également réaliser l'engagement de la porte logique dans le circuit BitVM, économisant ainsi BitVM espace de script et amélioration de l'efficacité de BitVM. . Bien que le schéma less s existant puisse réduire l'espace de script BitVM, il nécessite une grande quantité d'interaction entre le prouveur et le challenger pour combiner la clé publique. À l'avenir, nous améliorerons cette solution et essaierons d'introduire les Scriptless dans des modules de fonction BitVM spécifiques.
3.5 Défi multipartite sans autorisation
La raison pour laquelle les défis BitVM actuels nécessitent une autorisation par défaut est que l'UTXO de Bitcoin ne peut être exécuté qu'une seule fois, permettant à un vérificateur malveillant de « gaspiller » le contrat en contestant un prouveur honnête. BitVM est actuellement limité au mode défi à deux. Un prouveur qui tente de faire le mal peut simultanément lancer un défi avec un vérificateur qu'il contrôle, « gaspillant » ainsi le contrat, faisant de l'acte maléfique un succès, et les autres vérificateurs ne peuvent pas empêcher le comportement. Par conséquent, basé sur Bitcoin, un protocole de défi OP multipartite sans autorisation doit être étudié, ce qui peut étendre le modèle de confiance 1 sur N existant de BitVM à 1 sur N. Parmi eux, N est beaucoup plus grand que n. En outre, il est nécessaire d'étudier et de résoudre le problème des challengers qui s'entendent avec les prouveurs ou qui contestent de manière malveillante les contrats « gaspillés ». En fin de compte, implémenter le protocole BitVM avec moins de confiance.
Défis multipartites sans autorisation, permettant à quiconque de participer sans liste d'autorisation. Cela signifie que les utilisateurs peuvent retirer des pièces de monnaie de L2 sans l'intervention d'un tiers de confiance. De plus, tout utilisateur souhaitant participer au protocole de contestation OP peut contester et supprimer les retraits invalides.
L'extension de BitVM à un modèle de défi multipartite sans autorisation nécessite de résoudre les attaques suivantes :
À l’avenir, nous explorerons le modèle de défi multipartite sans autorisation BitVM, adapté aux caractéristiques du Bitcoin et capable de résister aux problèmes d’attaque ci-dessus.
4. Conclusion
L'exploration de la technologie BitVM vient de commencer et, à l'avenir, d'autres directions d'optimisation seront explorées et mises en œuvre pour parvenir à l'expansion du Bitcoin et faire prospérer l'écosystème Bitcoin.
les références
Lien d'origine