BitVM 2 : ouvrir le terrain de jeu
En octobre dernier, Robin Linus de Zerosync a largué une petite bombe sous la forme de BitVM. L’une des critiques les plus anciennes adressées au Bitcoin est qu’il n’est pas possible de créer des programmes arbitraires pour contrôler la manière dont l’argent est dépensé ou bloqué. Bitcoin n'a qu'une programmabilité très limitée dans son langage de script, et les primitives disponibles sont extrêmement limitées. Vous pouvez vérifier une signature, vous pouvez ajouter un timelock à quelque chose, vous pouvez manipuler des données de quelques manières simples, mais c'est tout.
Vous pouvez programmer un Bitcoin UTXO pour exiger une vérification de signature, une vérification de timelock, etc. Mais vous ne pouvez pas le programmer pour qu'il se déverrouille en fonction de conditions arbitraires. L'idée de Robin avec BitVM était qu'une seule primitive dans le domaine informatique pouvait être appliquée dans le script Bitcoin : une porte NAND, l'une des primitives de base de l'informatique au niveau physique/électrique. Tous les calculs possibles peuvent être construits à partir de portes NAND.
OP_BOOLAND est une opération ANDinverse. Ensemble, cela vous permet d'appliquer directement une seule opération NAND dans le script. En combinaison avec des hashlocks, un script de porte NAND peut être créé dans lequel chaque champ d'entrée et de sortie a deux hashlocks possibles pour « déverrouiller » ce chemin de dépense, chacun poussant un 1 ou un 0 à la pile pour effectuer l'opération NAND. Chaque script a également un chemin où si vous pouvez révéler les deux pré-images à une seule valeur binaire, vous pouvez immédiatement réclamer les fonds. Ainsi, une fois que quelqu'un a décidé quoi saisir dans la porte NAND, il ne peut pas changer d'avis sans perdre de l'argent.
Une quantité massive de scripts de porte NAND peuvent tous être compactés dans un arbre racine pivotante, et une fois que quelqu'un s'engage sur les valeurs de bits hors chaîne pour entrer dans ce calcul, l'autre partie peut les contester à n'importe quelle étape individuelle du calcul pour prouver que c'est le cas. étant exécuté correctement sur la chaîne. Chaque « défi » permet à la partie contestée de prouver que la porte individuelle a été calculée correctement, sinon l'autre partie peut réclamer les fonds après un délai. En faisant ainsi des allers-retours si un calcul est contesté, il est garanti que le tricheur finira par être attrapé et perdra des fonds.
Les limites
La principale limitation de BitVM est que seules les personnes impliquées dans la création d'un contrat BitVM peuvent participer et que les rôles sont très limités. Il y a le prouveur, la personne affirmant comment le calcul s'est produit hors chaîne, et le vérificateur, la personne qui peut contester le calcul et forcer sa preuve en chaîne si le prouveur ne termine pas le calcul hors chaîne ou essaie de mentir sur les résultats.
L'une des raisons de la conception de BitVM était d'établir des liens bidirectionnels avec des sidechains ou d'autres systèmes. Le système offre une primitive très puissante dans ce cas d'utilisation, la possibilité d'imposer réellement des fonds à une partie ou à l'autre sur la base de l'exactitude d'un calcul arbitraire, c'est-à-dire un contrôle de validité pour savoir si un pegout est valide selon les règles des sidechains.. Le problème est que seules les personnes qui détiennent les clés de cet UTXO BitVM peuvent réellement dire « Hé, vous trichez ! » quand quelqu'un l'est, et s'engager dans le protocole de défi. En fin de compte, cela rend le système toujours fiable.
Une autre limitation est que le protocole de réponse au défi peut être très long. Si quelqu'un se rend compte que le résultat du calcul va lui faire perdre de l'argent et qu'il cesse de répondre, le vérificateur doit essentiellement deviner où se trouve la porte NAND individuelle dans le calcul sur lequel le prouveur devrait mentir et révéler les deux pré-images à un peu qui donnerait les fonds au vérificateur. Jusqu'à ce que cette porte spécifique soit contestée en chaîne, le prouveur peut toujours répondre correctement à un défi et le faire traîner. Cela peut prendre beaucoup de temps et être inefficace.
Certaines améliorations ont été apportées à cette conception depuis la proposition initiale visant à permettre à plusieurs vérificateurs d'exister dans le système avec le prouveur, afin de créer un modèle de confiance 1 sur n dans lequel un seul vérificateur est requis pour contester un prouveur malhonnête. Cependant, cela nécessite l'instanciation de plusieurs instances BitVM en parallèle, ce qui augmente donc les inefficacités de la conception bipartite d'origine.
Bitvm2
Robin a récemment proposé un schéma de conception pour BitVM 2. Ce schéma cherche à faire quelques compromis par rapport à la conception originale dans le but d'atténuer ses deux défauts majeurs. BitVM 2 raccourcit la longueur du protocole de défi/réponse, passant d'une série indéterminée de transactions pouvant atteindre plusieurs dizaines dans le pire des cas, à deux tours dans le défi/réponse. De plus, grâce à l'utilisation de sorties de connecteur, cela permet à quiconque d'agir en tant que vérificateur. Il n’est pas nécessaire que quelqu’un soit membre impliqué dans la création de BitVM pour contester un prouveur malhonnête.
Le changement fondamental ici consiste à s'éloigner de l'utilisation directe des portes NAND de script pour implémenter directement la trace informatique brute, et à les utiliser pour implémenter un vérificateur général de preuve de connaissance zéro SNARK (l'une des primitives de base que Robin avait prévu dès le début d'implémenter en utilisant BitVM). ). Au lieu de placer l'entrée brute dans la trace informatique brute et de l'exécuter porte par porte dans leurs propres scripts tapleaf, l'entrée de l'instance BitVM 2 serait simplement une entrée de preuve de connaissance nulle en combinaison avec une sortie affirmée du calcul.
En plus de faire abstraction de l'implémentation du calcul avec un ZKP, les scripts tapleaf sont massivement étendus d'une seule porte NAND par feuille à une sous-fonction entière du vérificateur ZKP. Au lieu que le protocole de réponse au défi soit basé sur le fait que le vérificateur devine à quelle porte NAND le prouveur a tenté de tricher, en contestant sélectivement une seule porte, le vérificateur peut prouver que la sortie d'une sous-fonction entière est invalide en fonction de l'entrée.
Tout comme BitVM 1, le contrat est pré-négocié à l'aide de transactions pré-signées et de scripts de branchement. Les fonds liés au BitVM sont envoyés à un multisig n sur n qui signe deux transactions d'exécution possibles, une dans laquelle aucun défi ne se produit et une dans laquelle un défi se produit. Pour démarrer le processus d'exécution du contrat, le prouveur lance une transaction de lancement. Cette transaction de lancement s'engage sur la valeur de sortie « y » qu'ils prétendent que le calcul produit et comprend trois sorties : une sortie verrouillée dans le temps qui est incluse dans la transaction d'exécution sans défi, une sortie de connecteur A et une sortie de connecteur B, qui sont toutes deux sont également dépensés dans la transaction sans contestation.
C'est ici que la conception permet à quiconque de participer en tant que vérificateur. La sortie du connecteur A possède une deuxième transaction pré-signée qui peut la dépenser, la transaction de défi. Il s’agit d’une transaction pré-signée qui verse au prouveur une caution en bitcoin, mais la sortie du connecteur A n’est pas suffisante pour la financer. Littéralement, n'importe qui peut ajouter ses propres entrées pour financer la transaction et dépenser la sortie du connecteur A, ce qui invalide la transaction de retrait sans défi pour le prouveur (l'une des entrées dont elle n'a pas besoin n'existe pas).
Cela force le chemin du défi. La sortie du connecteur B peut également être dépensée à l'aide d'une transaction pré-signée, la transaction assert, vers la sortie de chaque sous-fonction de l'ensemble du contrat BitVM 2. Cela nécessite une transaction volumineuse avec beaucoup de données, mais rappelez-vous que le résultat final « y » que le prouveur prétend que le calcul produit était déjà engagé dans la transaction de lancement. Cela crée deux sorties. L’une est une sortie temporisée, l’autre est une sortie de connecteur C. Ces deux sorties, en plus de la sortie initiale liée aux fonds, sont toutes dépensées lors de la deuxième transaction de retrait réussie pour le prouveur après le timelock.
La sortie du connecteur C peut également être dépensée par toute personne pouvant prouver que toute sortie de sous-fonction dans le contrat BitVM 2 produit une sortie invalide. Cela nécessite une transaction très volumineuse, car le script nécessaire pour prouver qu'une section entière du calcul BitVM est incorrecte est énorme, mais dans cette seule transaction, un vérificateur peut réclamer les pièces dans la sortie du connecteur avec une preuve valide. Cela invalide la deuxième transaction de retrait pour le prouveur et brûle effectivement les pièces. La seule façon de les récupérer à ce stade est que le prouveur et tous les vérificateurs du multisig de financement n-sur-n d'origine coopèrent tous pour les récupérer. La sortie du connecteur B dans la transaction de lancement peut également être dépensée après un délai d'attente beaucoup plus long que le retrait sans défi pour invalider à la fois la transaction sans défi et la transaction d'assertion, brûlant ainsi les pièces liées.
Cela réduit ce qui pourrait être une chaîne ridicule de transactions dans la proposition originale de BitVM pour faire respecter le résultat correct du contrat, à un maximum de quatre transactions (bien que très massives, certes), tout en rendant littéralement l'ensemble des vérificateurs pour l'instance BitVM 2. toute personne possédant du bitcoin qui financera la transaction de défi.
BitVM 2 pourrait constituer une percée significative par rapport à la vague de rollups et autres couches 2 visant à utiliser BitVM comme cheville à double sens. L'opérateur d'un rollup (le prouveur dans BitVM) peut utiliser ses propres fonds pour couvrir les retraits des utilisateurs rattachés au système, et retirer périodiquement ces fonds de BitVM pour se compenser. Tout utilisateur ou partie intéressée pourrait alors le pénaliser en brûlant ses fonds s'il pouvait prouver que l'opérateur ne traitait pas correctement tous les retraits.
Il est important de noter qu'en fin de compte, la sécurité d'une instance BitVM 2 est assurée par le détenteur de clé n sur n, même si les personnes qui n'y participent pas peuvent toujours contester le prouveur en tant que vérificateur. Mais comme le prouveur dispose d'une sortie efficace en l'absence de challenger et que n'importe qui peut financer la transaction de défi pour agir en tant que vérificateur, le multisig de financement n sur n pourrait suivre une cérémonie de configuration et de suppression de clé similaire au lancement de Zcash pour améliorer sa sécurité.
BitVM 2 constituera probablement une avancée significative en termes d'amélioration de la flexibilité et du modèle de confiance des chevilles bidirectionnelles utilisant BitVM. Une fois de plus, Robin s'est révélé être un véritable sorcier.
