Qu’est-ce que c’est que CatVM ?

Lecture 16 minutes

Taproot Wizards a publié hier un dessin animé intitulé CatVM. Je ne parlerai pas de livre blanc, ce sont de véritables documents académiques destinés aux adultes. Dans le dessin animé, entrecoupés de récits enfantins absurdes, se trouvaient quelques informations techniques précieuses concernant les différentes propositions de mise à l’échelle dans l’écosystème Bitcoin. Bien sûr, à la manière d’un véritable dessin animé, enterré entre exagération sauvage et embellissement.

L’objectif final du dessin animé était de proposer un nouveau mécanisme permettant d’entrer et de sortir des couches de mise à l’échelle construites sur Bitcoin. Pour démêler cette proposition réelle du dessin animé, nous devrons décomposer les deux éléments impliqués.

Les éléments de base

La première expérience OP_CAT de Rijndael consistait à construire un coffre-fort, un système qui permet à un utilisateur de créer une transaction « intermédiaire » intermédiaire pour retirer ses fonds du coffre-fort. Cela déclenche un timelock, pendant lequel ils peuvent à tout moment renvoyer leurs fonds vers le coffre-fort ou un portefeuille de stockage frigorifique sécurisé, et après le timelock, l’utilisateur peut librement retirer les fonds vers la destination qu’il a choisie au début du processus de retrait. Voici les seulement Il existe deux manières de dépenser les bitcoins envoyés au script du coffre-fort.

Expliquer tous les mécanismes de la façon dont cela est accompli est essentiellement un article en soi, donc je vais faire quelque chose que je ne fais habituellement pas et y renoncer en le qualifiant de « magique ». (Expliqué ici par Andrew Poelstra) Ce que cette « magie » vous permet de faire, en créant des signatures Schnorr non standard et avec l’aide de OP_CAT, c’est de construire la transaction contre laquelle la vérification de signature est effectuée sur la pile de script. Cela vous permet de garantir que certaines parties de la transaction sont exactement telles que définies à l’avance. Il vous permet également de placer le résultat d’une transaction précédente sur la pile lors du processus de création de la transaction qui la dépense, ce qui signifie que vous pouvez comparer les résultats de la transaction de dépense avec les résultats de la transaction précédente. Cela vous permet de garantir en les comparant que certaines parties des sorties de la transaction précédente correspondent à certaines parties des nouvelles sorties. C’est-à-dire le script, ou un montant. Vous pouvez ainsi « reporter » des parties des anciens résultats dans les nouveaux et appliquer cela.

Une autre chose que vous pouvez faire avec OP_CAT, qui n’a pas nécessité de bricolage et d’expérimentation de Rijndael pour le prouver, est de vérifier les branches d’arbres Merkle. Étant donné que vous pouvez empiler des éléments ensemble et que Bitcoin prend déjà en charge le hachage des données sur la pile, vous pouvez lentement créer une racine d’arbre Merkle à partir d’un nœud feuille avec les nœuds intérieurs. Hachez deux morceaux ensemble pour obtenir un hachage, hachez-le avec la paire de hachage, et ainsi de suite. Finalement, vous obtenez le hachage racine sur la pile. Vous pouvez ensuite le comparer avec OP_EQUAL à un hachage racine prédéfini dans le script de verrouillage.

Retrait unilatéral

Ces deux éléments de base suffisent à faciliter un mécanisme de retrait unilatéral d’un UTXO partagé en groupe. Une racine Merkle peut être intégrée dans une transaction à l’aide de OP_RETURN ou d’un autre mécanisme qui s’engage sur un nœud feuille pour chaque utilisateur. Le script UTXO peut être structuré de manière à ce que tout utilisateur disposant d’un solde puisse tenter de le retirer. Pour ce faire, ils fourniraient à la branche Merkle s’engageant sur le montant auquel ils ont droit, la preuve d’autorisation telle qu’une clé publique pour vérifier une signature, et construiraient la transaction sur la pile pour vérifier que les conditions appropriées sont remplies.

Semblable au coffre-fort OP_CAT de Rijndael, cette transaction de retrait fonctionnerait comme un point de transit. Les fonds des utilisateurs seraient limités par un délai et ils ne seraient pas en mesure d’effectuer le retrait avant son expiration. À tout moment avant l’expiration du délai, tout autre utilisateur peut créer une preuve de fraude pour arrêter le retrait et réinjecter les fonds dans le script UTXO du groupe. Ils peuvent le faire grâce à la capacité d’OP_CAT à vérifier les arbres Merkle. Si quelqu’un a déjà utilisé une branche Merkle spécifique pour retirer des fonds de l’UTXO, cela a été inclus dans un bloc quelque part. En construisant une transaction contenant la preuve SPV de cette transaction à l’intérieur d’un bloc réel, qui peut utiliser OP_LESSTHANOREQUAL pour vérifier que l’en-tête de bloc rencontre un minimum de difficulté, ils peuvent prouver sur la pile que la branche merkle était utilisée auparavant. Cela permet d’éviter les retraits en double.

De plus, comme vous pouvez utiliser l’astuce « CAT sur la pile » pour garantir que des éléments spécifiques d’une transaction précédente doivent être inclus dans la suivante, vous pouvez garantir que la racine Merkle actuelle est reportée dans la transaction suivante après une transaction réussie. retrait. Vous pouvez également garantir que les modifications résultant du retrait seront réinjectées dans le script de partage de groupe. Cela garantit qu’après qu’un utilisateur a retiré ses fonds, le changement UTXO est verrouillé avec un script qui permet à tout utilisateur restant de se retirer, et ainsi de suite. Tout utilisateur peut retirer unilatéralement ses fonds à tout moment et dans n’importe quel ordre, avec la garantie que le reste des fonds reste accessible au reste des utilisateurs.

La partie VM

Les lecteurs doivent être familiers avec l’idée de base de BitVM. Vous pouvez prendre un calcul arbitraire et le diviser en chacun de ses éléments constitutifs et les intégrer dans un grand arbre à racine pivotante, transformant ce calcul en un jeu de défi/réponse de va-et-vient. Cela vous permet de verrouiller Bitcoin avec des conditions plus compliquées que celles directement prises en charge par le script Bitcoin lui-même. La seule véritable lacune est la nécessité d’élaborer une quantité massive de transactions pré-signées pour faciliter cela.

L’obligation d’utiliser des transactions pré-signées est telle que dans la dynamique défi/réponse, vous pouvez garantir que les pièces sont réinvesties dans le grand arbre racine pivotante qui les code, à moins qu’une condition de sortie dans un sens ou dans l’autre ne soit atteinte. OP_CAT et la possibilité de « reporter » les données des transactions précédentes vous permettent de garantir cela sans avoir besoin de transactions pré-signées.

Ainsi, non seulement ce système permet à tout utilisateur de quitter unilatéralement par lui-même, mais il permet également aux conditions de verrouillage prises en charge par une deuxième couche qui ne sont pas prises en charge par le script Bitcoin d’être réellement appliquées dans le processus de retrait. Autrement dit, si certaines pièces étaient grevées par un contrat intelligent, la couche de base ne comprend pas, puis étaient retirées de la deuxième couche, ces conditions plus compliquées pourraient toujours être réglées correctement sur la couche de base au fur et à mesure du retrait des pièces.

La pièce manquante

Une chose qu’OP_CAT ne permet pas est de mettre à jour une racine d’arbre Merkle représentant les soldes des utilisateurs hors chaîne de manière vérifiable. Cela peut permettre à un État déjà engagé de faciliter les retraits unilatéraux, mais c’est parce qu’une section entière de l’arbre est en fait mise en chaîne et vérifiée. Mettre à jour cette racine hors chaîne signifie par définition que vous ne mettez pas les données en chaîne. Cela représente un problème. Il n’y a aucun moyen avec CAT de vérifier efficacement que toutes les modifications apportées à l’arborescence Merkle ont été correctement autorisées par les utilisateurs concernés.

Il faut faire confiance à quelqu’un et, de par la nature des choses, être capable de dépenser l’UTXO comme et où il le souhaite, pour remplacer efficacement une ancienne racine d’état par une nouvelle pour représenter tous les changements d’équilibre hors chaîne. Un nouvel opcode en plus de OP_CAT, tel que OP_ZKVERIFY, serait nécessaire pour le faire sans confiance.

Ce ne serait pas la fin du monde sans OP_ZKVERIFY. L’entité mettant à jour la racine Merkle pour les transferts hors chaîne pourrait être un multisig n sur n, avec 100 % des participants tenus d’approuver toute modification de racine. Cela se résume au même modèle de confiance que les chevilles basées sur BitVM, où tant qu’un seul participant honnête existe, les fonds de personne ne peuvent être volés. Il s’agit cependant d’une nette amélioration par rapport aux conceptions BitVM existantes en ce qui concerne le processus de retrait.

Dans les chevilles BitVM, les utilisateurs ne disposent pas de mécanisme de retrait unilatéral. Il faut faire confiance aux opérateurs de chevilles pour effectuer les retraits des utilisateurs, sachant qu’ils peuvent récupérer les fonds qu’ils ont dépensés en toute confiance auprès de la cheville BitVM. Bien que les incitations soient très solides, cela nécessite toujours que les utilisateurs obtiennent la permission de quelqu’un d’autre pour quitter le système, ils ne peuvent pas le faire eux-mêmes. Avec CatVM, les utilisateurs peuvent récupérer leurs fonds unilatéralement et un opérateur n’est pas tenu de présenter ses propres liquidités pour traiter les retraits.

Emballer

Dans l’ensemble, la conception est incomplète en termes de construction. Ce n’est pas quelque chose que j’appellerais une couche 2 en soi. Il s’agit du cœur de l’un, du mécanisme et de la structure permettant de verrouiller les fonds dans une couche 2, ainsi que du processus permettant aux utilisateurs de retirer leurs fonds. Il a certainement beaucoup de flexibilité et d’utilité.

Dans le pire des cas, les utilisateurs n’ont besoin de l’autorisation de personne pour récupérer leurs fonds en toute sécurité sur la chaîne. Cela permet également une programmabilité plus flexible des fonds, tout en continuant à faire appliquer ces conditions à la couche de base en cas de sortie unilatérale dans le pire des cas. Si un jour nous obtenons finalement quelque chose comme OP_ZKVERIFY, la progression de l’état hors chaîne peut devenir un processus réellement sans confiance.

Je ne m’attends pas à des démos concrètes dans un avenir proche, mais c’est certainement une bonne idée à mon avis et quelque chose qui mérite d’être pris en considération. Cela montre également que les sorciers font un peu plus que simplement pomper des fichiers JPEG stupides.

Source https://bitcoinmagazine.com/technical/what-the-heck-is-catvm

Crypto Week

Avertissement : Crypto Week ne fournit pas de conseils financiers de quelque manière que ce soit. Nous ne vous recommandons pas d'investir de l'argent dans une crypto-monnaie ou un actif financier sans avoir effectué des recherches approfondies. Nous ne sommes pas responsables de vos décisions financières de quelque manière que ce soit.

Derniers articles de Featured Posts