Comme on le sait bien, les preuves de fraude sont une solution technique largement utilisée dans l'espace blockchain. Elles ont été initiées dans la communauté Ethereum et ont été adoptées par des solutions bien connues de la couche 2 d'Ethereum telles que Arbitrum et Optimism. Après l'essor de l'écosystème Bitcoin en 2023, Robin Linus a proposé une solution appelée BitVM, qui, basée sur les technologies Bitcoin existantes comme Taproot, se concentre sur les preuves de fraude et fournit un nouveau modèle de sécurité pour la couche 2 de Bitcoin ou les ponts.

BitVM a lancé plusieurs versions théoriques, de la première BitVM0, qui utilisait des circuits de logique gate comme primitives, aux versions ultérieures comme BitVM2, qui se concentrait sur les Preuves de Fraude ZK et les circuits de vérification Groth16. Les chemins d'implémentation technique liés à BitVM ont évolué et mûri, attirant l'attention de nombreux professionnels de l'industrie. Des projets tels que Bitlayer, Citrea, BOB, Fiamma et Goat Network utilisent tous BitVM comme l'une de leurs technologies de base, mettant en œuvre différentes versions basées sur cette fondation.

Compte tenu de la rareté et de la complexité des explications publiquement disponibles sur BitVM, nous avons lancé une série d'articles visant à populariser les connaissances sur BitVM. Compte tenu du lien profondément enraciné entre BitVM et les preuves de fraude, cet article se concentrera sur les preuves de fraude et les preuves de fraude ZK, en utilisant un langage simple et compréhensible pour expliquer ces concepts.

(Mécanisme de preuve de fraude interactive du principe de l'optimisme)

OutputRoot et StateRoot

Optimism est un projet de Rollup Optimiste bien connu, et son infrastructure se compose d'un séquenceur (avec des modules principaux comprenant op-node, op-geth, op-batcher et op-proposer) et de contrats intelligents sur la chaîne Ethereum.

Après que le séquenceur a traité un lot de données de transaction, ces données DA seront envoyées à Ethereum. Tant que vous êtes capable d'exécuter un client de nœud Optimism, vous pouvez télécharger les données chargées par le séquenceur sur votre machine locale. Vous pouvez ensuite exécuter ces transactions localement et calculer le hachage de l'ensemble d'état actuel d'Optimism (comprenant, entre autres, le solde actuel de chaque compte, etc.).

Si le séquenceur télécharge un hachage d'état incorrect sur Ethereum, le hachage d'état que vous calculez localement sera différent. Dans ce cas, vous pouvez relever un défi à travers le système de preuve de fraude. En fonction du jugement, le système imposera des restrictions ou des pénalités au séquenceur ou ne prendra aucune mesure.

Lorsqu'on mentionne le terme « ensemble d'états », les blockchains basées sur l'EVM utilisent couramment une structure de données similaire à un arbre de Merkle pour enregistrer l'ensemble d'états, appelé le Trie de l'état mondial. Après l'exécution d'une transaction, l'état de certains comptes changera, et le Trie de l'état mondial changera également, entraînant un changement dans son hachage final. Ethereum fait référence au hachage final du Trie de l'état mondial comme le StateRoot, qui représente les changements dans l'ensemble d'états.

Le diagramme suivant illustre la structure de l'état de la racine d'Ethereum. Comme nous pouvons le voir, les soldes des différents comptes, le hachage du code associé aux comptes de contrats intelligents et d'autres données sont tous agrégés dans le World State Trie, à partir duquel la stateRoot est calculée.

Le système de compte et la structure de données d'Optimism sont généralement cohérents avec ceux d'Ethereum, utilisant également le champ StateRoot pour représenter les modifications apportées à l'ensemble d'états. Le séquenceur OP télécharge périodiquement un champ clé appelé OutputRoot sur Ethereum, qui est calculé en fonction du StateRoot et de deux autres champs.

Revenons à la question initiale, lorsque vous exécutez le client du nœud OP et calculez localement le StateRoot et le OutputRoot actuel, si vous constatez que les résultats que vous avez calculés ne correspondent pas à ceux téléchargés par le séquenceur OP, vous pouvez initier une preuve de fraude. Alors, quel est le mécanisme spécifique derrière cela? Ci-dessous, nous introduirons séquentiellement la vérification de l'état de la machine virtuelle MIPS et les preuves de fraude interactives.

Machine virtuelle MIPS et arbre de Merkle de mémoire

Comme mentionné précédemment, supposez que vous constatiez que l'OutputRoot soumis par le séquenceur OP est incorrect et que vous souhaitez initier un « défi ». Le processus de défi nécessite de compléter une série d'interactions on-chain, après quoi les contrats intelligents pertinents détermineront si le séquenceur OP a téléchargé un OutputRoot incorrect.

Pour vérifier la justesse de l'OutputRoot on-chain en utilisant des contrats intelligents, la méthode la plus simple serait de mettre en œuvre un client de nœud OP sur la chaîne Ethereum, en utilisant les mêmes paramètres d'entrée que le séquenceur OP, exécutant le même programme et vérifiant si le résultat calculé correspond. Cette approche est appelée un programme de preuve de fraude. Bien qu'il soit relativement facile à mettre en œuvre hors chaîne, il est très difficile à exécuter sur la chaîne Ethereum en raison de deux problèmes :

1. Les contrats intelligents sur Ethereum ne peuvent pas automatiquement obtenir les paramètres d'entrée nécessaires pour les preuves de fraude.

2. La limite de gas de bloc d'Ethereum est limitée, et elle ne prend pas en charge les tâches computationnelles très complexes. Ainsi, nous ne pouvons pas mettre en œuvre entièrement le client OP node on-chain.

Le premier problème revient à exiger que le contrat intelligent on-chain lise des données off-chain, ce qui peut être résolu en utilisant une solution similaire à un oracle. OP a déployé le contrat PreimageOracle sur la chaîne Ethereum, et les contrats liés à la preuve de fraude peuvent lire les données nécessaires à partir de ce contrat. Théoriquement, n'importe qui peut télécharger des données sur ce contrat, mais le système de preuve de fraude d'OP a un moyen de vérifier si les données sont nécessaires, bien que ce processus ne sera pas élaboré ici, car il n'est pas crucial pour le sujet central de cet article.

Pour le deuxième problème, l'équipe de développement d'OP a écrit une machine virtuelle MIPS en Solidité pour implémenter certaines des fonctions du client du nœud OP qui sont suffisantes pour le système de preuve de fraude. MIPS est une architecture courante d'ensemble d'instructions de CPU, et le code du séquenceur OP est écrit dans des langages de haut niveau comme Golang/Rust. Nous pouvons compiler les programmes Golang/Rust en programmes MIPS et les traiter à travers la machine virtuelle MIPS sur la chaîne Ethereum.

L'équipe de développement d'OP a écrit un programme simplifié en Golang pour la preuve de fraude, qui imite essentiellement les modules dans le nœud OP qui exécutent des transactions, génèrent des blocs et produisent l'OutputRoot. Cependant, ce programme simplifié ne peut toujours pas être "exécuté complètement". En d'autres termes, chaque bloc OP contient de nombreuses transactions. Après le traitement de ce lot de transactions, un OutputRoot est généré. Bien que vous sachiez que l'OutputRoot de la hauteur du bloc est incorrect, il serait irréaliste d'exécuter toutes les transactions de ce bloc on-chain pour prouver que l'OutputRoot correspondant est incorrect. De plus, lors de l'exécution de chaque transaction, une série d'opcodes MIPS est traitée en séquence. Il serait peu pratique d'exécuter cette série complète d'opcodes sur la machine virtuelle MIPS implémentée dans un contrat on-chain, car la surcharge computationnelle et la consommation de gaz seraient trop grandes.

(Principe de fonctionnement de l'ensemble d'instructions MIPS)

Pour remédier à cela, l'équipe d'Optimism a conçu un système interactif anti-fraude visant à analyser en profondeur le flux de traitement des transactions d'OP. En observant l'ensemble du processus de calcul de l'OutputRoot, le système identifie à quel opcode MIPS l'erreur a été commise par la machine virtuelle MIPS du séquenceur OP. Si une erreur est confirmée, on peut en conclure que l'OutputRoot fourni par le séquenceur est invalide.

Ainsi, la question devient claire : le processus de regroupement des transactions du séquenceur OP en blocs peut être décomposé en un traitement ordonné d'un grand nombre de codes d'opération MIPS. Après l'exécution de chaque code d'opération MIPS, le hachage d'état de la machine virtuelle change. Ces enregistrements peuvent être regroupés dans un arbre de Merkle.

Dans le processus interactif de preuve de fraude, l'objectif est de déterminer après quel code opération MIPS le hachage d'état de la machine virtuelle du séquenceur OP est devenu incorrect, puis de reproduire l'état de la machine virtuelle MIPS on-chain, d'exécuter le code opération et d'observer si le hachage d'état résultant correspond à celui soumis par le séquenceur. Comme seul un code opération MIPS est exécuté on-chain, la complexité est faible et le processus de calcul peut être terminé sur la chaîne Ethereum. Cependant, pour y parvenir, nous devons télécharger les informations d'état de la machine virtuelle MIPS, telles que des données de mémoire partielles, sur la chaîne.

En termes de mise en œuvre du code, les contrats intelligents sur la chaîne Ethereum liés à la preuve de fraude compléteront le processus d'exécution final de l'opcode MIPS via une fonction appelée Step :

Les paramètres dans la fonction ci-dessus, _stateData et _proof, représentent les éléments de données dépendants pour l'exécution d'un seul code d'opération MIPS, tels que l'état du registre de la machine virtuelle MIPS, le hachage de l'état de la mémoire, etc. Le diagramme est montré ci-dessous :

Nous pouvons entrer ces paramètres d'environnement de machine virtuelle MIPS via _stateData et _proof, exécuter une seule instruction MIPS on-chain et obtenir un résultat autorisé. Si le résultat autorisé obtenu on-chain diffère du résultat soumis par le séquenceur, cela indique que le séquenceur est malveillant.

Nous faisons généralement référence au hachage de _stateData en tant que statehash, qui peut être grossièrement compris comme le hachage de l'état entier de la machine virtuelle MIPS. Parmi les plusieurs champs de _stateData, memRoot est la conception la plus ingénieuse. Comme nous le savons, lors de l'exécution d'un programme, une grande quantité de mémoire est utilisée, et le CPU interagit avec les données à certaines adresses mémoire en lisant et en écrivant. Par conséquent, lorsque nous exécutons un opcode MIPS on-chain à travers la fonction VM.Step, nous devons fournir des données à partir de certaines adresses mémoire dans la machine virtuelle MIPS.

OP utilise une architecture 32 bits pour la machine virtuelle MIPS, et sa mémoire contient 2^27 adresses, qui peuvent être organisées dans un arbre de Merkle binaire à 28 niveaux. Les nœuds feuilles au niveau le plus bas numérotent 2^27, chaque feuille enregistrant les données d'une adresse mémoire spécifique de la machine virtuelle. Le hash calculé à partir de toutes les données dans les feuilles est memRoot. Le diagramme ci-dessous montre la structure de l'arbre de Merkle qui enregistre les données de la mémoire de la machine virtuelle MIPS :

Nous devons fournir le contenu à partir de certaines adresses mémoire, et ce contenu est téléchargé sur la chaîne Ethereum à travers le champ _proof dans la fonction d'étape. De plus, une preuve de Merkle basée sur l'arbre de Merkle de la mémoire doit être téléchargée pour prouver que les données que vous (ou le séquenceur) avez fournies existent effectivement dans l'arbre de Merkle de la mémoire, plutôt que d'être fabriquées.

Preuve de fraude interactive

Dans la section précédente, nous avons abordé le deuxième problème en complétant l'exécution sur chaîne des opcodes MIPS et la vérification de l'état de la machine virtuelle. Mais comment le challenger et le séquenceur peuvent-ils identifier l'instruction d'opcode MIPS spécifiquement contestée ?

De nombreuses personnes ont peut-être lu des explications simples sur les preuves de fraude interactives en ligne et entendu parler de l'approche de recherche binaire qui les sous-tend. L'équipe OP a développé un protocole appelé le Jeu de Contestation de Faute (FDG). Le protocole FDG inclut deux rôles : le challenger et le défenseur.

Si nous constatons que l'OutputRoot soumis par le séquenceur on-chain est incorrect, nous pouvons agir en tant que challenger dans le FDG, le séquenceur agissant en tant que défenseur. Pour aider à localiser l'opcode MIPS qui doit être traité on-chain, le protocole FDG exige que les participants construisent localement un arbre de Merkle appelé GameTree, dont la structure spécifique est la suivante:

Nous pouvons voir que le GameTree est assez complexe, avec une structure hiérarchique imbriquée, composée d'un arbre de premier niveau et de sous-arbres de deuxième niveau. En d'autres termes, les nœuds feuilles de l'arbre de premier niveau contiennent un sous-arbre.

Comme mentionné précédemment, chaque bloc généré par le séquenceur contient un OutputRoot, et les nœuds feuilles de l'arbre de premier niveau dans le GameTree représentent les OutputRoots de différents blocs. Le challenger et le défenseur doivent interagir au sein de l'arbre de Merkle formé par les OutputRoots pour déterminer quel OutputRoot de bloc est en litige.

Une fois que le bloc contesté est identifié, nous plongeons dans le deuxième niveau de l'arbre de jeu. L'arbre de deuxième niveau est également un arbre de Merkle, avec ses nœuds feuilles étant les hachages d'état de la machine virtuelle MIPS, comme introduit précédemment. Dans le cas de preuve de fraude, le challenger et le défenseur auront des incohérences dans les nœuds feuilles de l'arbre de jeu qu'ils construisent localement. Le hachage d'état après le traitement d'un code opérationnel particulier sera différent.

Après de multiples interactions on-chain, les parties finissent par cerner précisément l'opcode en litige, déterminant l'opcode MIPS spécifique qui doit être exécuté on-chain.

À ce stade, nous avons terminé l'ensemble du processus de preuve de fraude interactive. Pour résumer, les deux mécanismes principaux de la preuve de fraude interactive sont :

1. Le FDG (jeu de litige de panne) localise d'abord l'opcode MIPS qui doit être exécuté on-chain, ainsi que les informations sur l'état de la VM à ce moment-là;

2. La machine virtuelle MIPS implémentée sur la chaîne Ethereum exécute l'opcode, produisant le résultat final.

Preuve de fraude ZK

Preuve de fraude ZK Comme nous pouvons le voir, l'approche traditionnelle de la preuve de fraude implique des interactions très complexes, nécessitant de multiples tours d'interaction dans le processus FDG et la relecture d'instructions individuelles on-chain. Cependant, cette solution présente plusieurs défis :

Plusieurs rounds d'interaction doivent être déclenchés sur la chaîne Ethereum, ce qui entraîne des dizaines d'interactions engendrant des coûts en gaz importants. 2. Le processus interactif de preuve de fraude prend beaucoup de temps, et une fois que l'interaction commence, le Rollup ne peut pas traiter les transactions normalement. 3. La mise en œuvre d'une VM spécifique on-chain pour rejouer les instructions est assez complexe, avec une grande difficulté de développement.

Pour résoudre ces problèmes, Optimism a introduit le concept de preuve de fraude ZK. L'idée principale est que lorsqu'un défi est lancé, le challenger spécifie la transaction qu'il pense devoir être rejouée on-chain. Le séquenceur Rollup fournit une preuve ZK pour la transaction contestée, qui est ensuite vérifiée par un contrat intelligent sur la chaîne Ethereum. Si la vérification est réussie, on conclut qu'il n'y a pas eu d'erreurs dans le traitement de la transaction et que le nœud Rollup n'est pas en faute.

Sur le schéma, le Challengerfait référence à la partie qui relève le défi et la Défenseurest le séquenceur OP. Dans des circonstances normales, le séquenceur OP génère des blocs en fonction des transactions reçues et soumet les engagements d'état de différents blocs à Ethereum. Ces engagements d'état peuvent simplement être vus comme les valeurs de hachage des blocs. Le Challenger peut contester en fonction du hachage du bloc. Après avoir accepté le défi, le Défenseur génère une preuve ZK pour démontrer que les résultats de génération de blocs sont corrects. Dans le diagramme,Bonsaiest en fait un outil de génération de preuve ZK. Par rapport aux preuves de fraude interactives, le plus grand avantage de la preuve de fraude ZK est qu'elle remplace plusieurs tours d'interaction par un seul tour de génération de preuve ZK et de vérification on-chain. Cela permet de gagner beaucoup de temps et de réduire les coûts en gaz. De plus, contrairement aux ZK Rollups, les OP Rollups basés sur la preuve de fraude ZK ne nécessitent pas la génération de preuves à chaque fois qu'un bloc est produit. Au lieu de cela, ils ne génèrent une preuve ZK que temporairement en cas de contestation, ce qui réduit également les coûts de calcul pour les nœuds Rollup.

Le concept de ZK Fraud Proof est également adopté par BitVM2. Les projets utilisant BitVM2, tels que Bitlayer, Goat Network, ZKM et Fiama, mettent en œuvre le programme de vérification de preuve ZK à travers les scripts Bitcoin, simplifiant considérablement la taille des programmes à intégrer on-chain. En raison de limitations d'espace, cet article n'abordera pas en détail ce sujet. Restez à l'écoute pour notre prochain article sur BitVM2 pour mieux comprendre son parcours d'implémentation!

Avertissement :

1. Cet article est reproduit à partir de [GateGodRealmX], le droit d'auteur appartient à l'auteur original [Shew & Noah], si vous avez des objections à la reproduction, veuillez contacter le Portail Apprendrel'équipe, et l'équipe le traitera dès que possible selon les procédures pertinentes.

2. Avertissement : Les points de vue et opinions exprimés dans cet article ne représentent que les opinions personnelles de l'auteur et ne constituent aucun conseil en investissement.

3. D'autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn et ne sont pas mentionnées dansGate, l'article traduit ne peut être reproduit, distribué ou plagié.