La deuxième partie de la série consacrée à l'analyse approfondie de l'épreuve des fautes avec Coinbase se termine par la présentation de Cannon, la première machine virtuelle à l'épreuve des fautes (FPVM) de l'OP Stack, utilisée dans le cadre du jeu de litige.

Cette série est une collaboration entre l'équipe de sécurité blockchain (BlockSec) de Coinbase et OP Labs qui vise à fournir des informations approfondies sur tous les principaux composants des preuves de fautes. En partageant ces informations, nous espérons encourager autrui à en apprendre davantage sur l'architecture et les aspects techniques des preuves de fautes. Ensemble, nous pouvons progresser vers l'avenir décentralisé des blockchains OP Stack L2.

Dans cet article de blog, nous allons couvrir l'implémentation offchain de la machine virtuelle à l'épreuve des fautes Cannon (FPVM). Notez que les implémentations FPVM onchain et offchain forment ensemble Cannon. Cependant, nous les distinguerons en faisant en sorte que Cannon ne se réfère qu'à l'implémentation offchain dans ce post de blog.

Dans le post précédent, nous avons présenté MIPS.sol, la FPVM onchain. Cannon est la contrepartie offchain de MIPS.sol, écrit en Golang. Cependant, contrairement à MIPS.sol, l'implémentation offchain de Cannon est responsable de beaucoup plus d'étapes dans un jeu de dispute. En outre, Cannon est la seule FPVM utilisée pour les jeux de litige dans l'OP Stack.

Une fois de plus, examinons le processus de preuve de faute pour comprendre où se situe Cannon.

Dans le diagramme ci-dessus, recréé à partir de la vidéo Fault Proof Walkthrough de Clabby, nous pouvons voir que Cannon interagit avec OP-Challenger et OP-Program. OP-Challenger est le composant qui s'occupe de lancer des challenges et d'interagir avec un jeu de litige, et OP-Program s'occupe de la dérivation de la sortie L2 à partir des entrées L1. Toutefois, le diagramme est une simplification des interactions entre OP-Challenger, Cannon et OP-Program.

Au cours d'un jeu de litige actif, le jeu de bisection passe du pivotement sur les racines de sortie L2 aux hachages de témoins d'état. Cannon est chargé de générer des hachages de témoins d'état, qui sont l'engagement des résultats du calcul des instructions MIPS dans la FPVM. Cannon ne sera exécuté qu'une fois que le jeu de litige aura atteint ce point. Cette partie du jeu de bisection est connue sous le nom de trace d'exécution. Jusqu'à présent, OP-Challenger a consulté OP-Node pour les racines de sortie d'état et n'a pas utilisé OP-Program ou Cannon. Cependant, lorsqu'il sera temps d'exécuter Cannon pour le jeu de litige, le programme OP déjà compilé sera chargé dans la VM de Cannon qui commencera alors à exécuter les instructions MIPS.

Au cours de la partie du jeu de bisection consacrée à la trace d'exécution, Cannon exécutera de nombreuses instructions MIPS et fournira initialement des hachages de témoins d'état à OP-Challenger. Finalement, une seule instruction MIPS sera identifiée comme étant à l'origine du désaccord entre les participants au litige actif. Cannon va alors générer la preuve témoin, qui contient toutes les informations nécessaires pour exécuter l'instruction MIPS onchain dans MIPS.sol. L'état final de l'instruction MIPS sera alors utilisé pour résoudre le jeu de litige sur les fautes.

Cannon est composé de plusieurs fichiers Golang qui, ensemble, ont beaucoup plus de fonctionnalités que le MIPS.sol onchain. C'est nécessaire, car Cannon est responsable de plus de parties du jeu de litige que MIPS.sol. Ces fichiers Golang peuvent être regroupés en fonction des principaux composants de Cannon qu'ils mettent en œuvre, à savoir : le loader ELF (Executable and Linkable Format), la gestion de la mémoire et de l'état, MIPSEVM et la génération de preuves par témoins.

Le programme OP est le code qui sera compilé dans un fichier ELF qui, à son tour, contient des instructions MIPS à exécuter dans Cannon. Pour que le contenu du fichier ELF puisse être exécuté dans Cannon, il doit être chargé dans le MIPSEVM. Ce processus implique de parcourir les en-têtes ELF pour déterminer tous les programmes qui doivent être chargés dans l'espace mémoire 32 bits, de localiser les valeurs initiales du compteur de programme (PC) et du NextPC, d'instancier la stack, le heap et les pointeurs de segment de données en mémoire, et de patcher toutes les fonctions incompatibles. L'élimination d'une fonction incompatible consiste simplement à réécrire les premières instructions d'une fonction avec un retour au pointeur d'origine, puis une absence d'opération (NOP). Il est important de patcher le binaire chargé dans le MIPSEVM, car le FPVM est incapable d'effectuer de nombreux appels système et ne prend pas en charge des fonctions telles que la concurrence.

Cannon stocke et maintient l'ensemble de l'espace d'adressage mémoire de 32 bits disponible pour le MIPSEVM. Il n'y a pas de restriction sur la taille de la mémoire stockée hors chaîne, mais pour MIPS.sol, il n'est pas possible de stocker l'ensemble de l'espace d'adressage mémoire de 32 bits. Par conséquent, la mémoire est stockée dans une structure de données binaire de type Merkle tree au sein de Cannon. Pour le MIPSEVM, cette structure de données est abstraite grâce à l'utilisation des fonctions GetMemory(), ReadMemoryRange() et SetMemory(). Au moment de générer la preuve témoin, Cannon codera jusqu'à deux preuves Merkle en mémoire pour que MIPS.sol les utilise lors de l'exécution d'une instruction MIPS.

Cannon contient le MIPSEVM, qui implémente l'architecture du jeu d'instructions (ISA) 32 bits, Big-Endian, MIPS III. Contrairement à MIPS.sol, MIPSEVM exécute de nombreuses instructions MIPS et est également responsable du suivi des accès à la mémoire, qui sera utilisé pour coder la deuxième preuve en mémoire. Cependant, les implémentations des VM offchain et onchain doivent produire exactement les mêmes résultats avec les mêmes instructions, la même mémoire et le même état des registres. Cela est essentiel pour garantir que l'état final attendu du MIPSEVM est le même que l'état final réel généré par MIPS.sol, qui sera utilisé pour résoudre le jeu de litige.

Une fois qu'une seule instruction MIPS a été identifiée comme étant à l'origine du désaccord entre les participants d'un jeu de litige sur les fautes, Cannon génère la preuve testimoniale afin que la même instruction puisse être exécutée onchain dans MIPS.sol. Les informations suivantes sont encodées dans la preuve témoin : l'état d'exécution de la VM, la preuve de mémoire pour l'adresse de l'instruction à exécuter et une preuve de mémoire supplémentaire requise uniquement pour le chargement, le stockage ou certaines instructions d'appel système. En outre, si l'instruction MIPS nécessite une pré-image, Cannon communiquera également une clé de pré-image et un décalage à OP-Challenger afin qu'elle puisse être postée sur PreimageOracle.sol.

Ceci conclut notre plongée dans Cannon. En plus de cet article de blog, Coinbase a créé une documentation approfondie qui fournit plus de détails sur chacun des composants de Cannon. Consultez-la sur Fault Proof VM - Cannon | Optimism Docs, et si vous êtes intéressé par la spécification technique officielle d'Optimism pour Cannon, vous pouvez la consulter ici : Spécification technique de Cannon.

https://blog.oplabs.co/fault-proof-deep-dive-part-2-cannon/

La deuxième partie de la série consacrée à l'analyse approfondie de l'épreuve des fautes avec Coinbase se termine par la présentation de Cannon, la première machine virtuelle à l'épreuve des fautes (FPVM) de l'OP Stack, utilisée dans le cadre du jeu de litige.

Cette série est une collaboration entre l'équipe de sécurité blockchain (BlockSec) de Coinbase et OP Labs qui vise à fournir des informations approfondies sur tous les principaux composants des preuves de fautes. En partageant ces informations, nous espérons encourager autrui à en apprendre davantage sur l'architecture et les aspects techniques des preuves de fautes. Ensemble, nous pouvons progresser vers l'avenir décentralisé des blockchains OP Stack L2.

Dans cet article de blog, nous allons couvrir l'implémentation offchain de la machine virtuelle à l'épreuve des fautes Cannon (FPVM). Notez que les implémentations FPVM onchain et offchain forment ensemble Cannon. Cependant, nous les distinguerons en faisant en sorte que Cannon ne se réfère qu'à l'implémentation offchain dans ce post de blog.

Dans le post précédent, nous avons présenté MIPS.sol, la FPVM onchain. Cannon est la contrepartie offchain de MIPS.sol, écrit en Golang. Cependant, contrairement à MIPS.sol, l'implémentation offchain de Cannon est responsable de beaucoup plus d'étapes dans un jeu de dispute. En outre, Cannon est la seule FPVM utilisée pour les jeux de litige dans l'OP Stack.

Une fois de plus, examinons le processus de preuve de faute pour comprendre où se situe Cannon.

Dans le diagramme ci-dessus, recréé à partir de la vidéo Fault Proof Walkthrough de Clabby, nous pouvons voir que Cannon interagit avec OP-Challenger et OP-Program. OP-Challenger est le composant qui s'occupe de lancer des challenges et d'interagir avec un jeu de litige, et OP-Program s'occupe de la dérivation de la sortie L2 à partir des entrées L1. Toutefois, le diagramme est une simplification des interactions entre OP-Challenger, Cannon et OP-Program.

Au cours d'un jeu de litige actif, le jeu de bisection passe du pivotement sur les racines de sortie L2 aux hachages de témoins d'état. Cannon est chargé de générer des hachages de témoins d'état, qui sont l'engagement des résultats du calcul des instructions MIPS dans la FPVM. Cannon ne sera exécuté qu'une fois que le jeu de litige aura atteint ce point. Cette partie du jeu de bisection est connue sous le nom de trace d'exécution. Jusqu'à présent, OP-Challenger a consulté OP-Node pour les racines de sortie d'état et n'a pas utilisé OP-Program ou Cannon. Cependant, lorsqu'il sera temps d'exécuter Cannon pour le jeu de litige, le programme OP déjà compilé sera chargé dans la VM de Cannon qui commencera alors à exécuter les instructions MIPS.

Au cours de la partie du jeu de bisection consacrée à la trace d'exécution, Cannon exécutera de nombreuses instructions MIPS et fournira initialement des hachages de témoins d'état à OP-Challenger. Finalement, une seule instruction MIPS sera identifiée comme étant à l'origine du désaccord entre les participants au litige actif. Cannon va alors générer la preuve témoin, qui contient toutes les informations nécessaires pour exécuter l'instruction MIPS onchain dans MIPS.sol. L'état final de l'instruction MIPS sera alors utilisé pour résoudre le jeu de litige sur les fautes.

Cannon est composé de plusieurs fichiers Golang qui, ensemble, ont beaucoup plus de fonctionnalités que le MIPS.sol onchain. C'est nécessaire, car Cannon est responsable de plus de parties du jeu de litige que MIPS.sol. Ces fichiers Golang peuvent être regroupés en fonction des principaux composants de Cannon qu'ils mettent en œuvre, à savoir : le loader ELF (Executable and Linkable Format), la gestion de la mémoire et de l'état, MIPSEVM et la génération de preuves par témoins.

Le programme OP est le code qui sera compilé dans un fichier ELF qui, à son tour, contient des instructions MIPS à exécuter dans Cannon. Pour que le contenu du fichier ELF puisse être exécuté dans Cannon, il doit être chargé dans le MIPSEVM. Ce processus implique de parcourir les en-têtes ELF pour déterminer tous les programmes qui doivent être chargés dans l'espace mémoire 32 bits, de localiser les valeurs initiales du compteur de programme (PC) et du NextPC, d'instancier la stack, le heap et les pointeurs de segment de données en mémoire, et de patcher toutes les fonctions incompatibles. L'élimination d'une fonction incompatible consiste simplement à réécrire les premières instructions d'une fonction avec un retour au pointeur d'origine, puis une absence d'opération (NOP). Il est important de patcher le binaire chargé dans le MIPSEVM, car le FPVM est incapable d'effectuer de nombreux appels système et ne prend pas en charge des fonctions telles que la concurrence.

Cannon stocke et maintient l'ensemble de l'espace d'adressage mémoire de 32 bits disponible pour le MIPSEVM. Il n'y a pas de restriction sur la taille de la mémoire stockée hors chaîne, mais pour MIPS.sol, il n'est pas possible de stocker l'ensemble de l'espace d'adressage mémoire de 32 bits. Par conséquent, la mémoire est stockée dans une structure de données binaire de type Merkle tree au sein de Cannon. Pour le MIPSEVM, cette structure de données est abstraite grâce à l'utilisation des fonctions GetMemory(), ReadMemoryRange() et SetMemory(). Au moment de générer la preuve témoin, Cannon codera jusqu'à deux preuves Merkle en mémoire pour que MIPS.sol les utilise lors de l'exécution d'une instruction MIPS.

Cannon contient le MIPSEVM, qui implémente l'architecture du jeu d'instructions (ISA) 32 bits, Big-Endian, MIPS III. Contrairement à MIPS.sol, MIPSEVM exécute de nombreuses instructions MIPS et est également responsable du suivi des accès à la mémoire, qui sera utilisé pour coder la deuxième preuve en mémoire. Cependant, les implémentations des VM offchain et onchain doivent produire exactement les mêmes résultats avec les mêmes instructions, la même mémoire et le même état des registres. Cela est essentiel pour garantir que l'état final attendu du MIPSEVM est le même que l'état final réel généré par MIPS.sol, qui sera utilisé pour résoudre le jeu de litige.

Une fois qu'une seule instruction MIPS a été identifiée comme étant à l'origine du désaccord entre les participants d'un jeu de litige sur les fautes, Cannon génère la preuve testimoniale afin que la même instruction puisse être exécutée onchain dans MIPS.sol. Les informations suivantes sont encodées dans la preuve témoin : l'état d'exécution de la VM, la preuve de mémoire pour l'adresse de l'instruction à exécuter et une preuve de mémoire supplémentaire requise uniquement pour le chargement, le stockage ou certaines instructions d'appel système. En outre, si l'instruction MIPS nécessite une pré-image, Cannon communiquera également une clé de pré-image et un décalage à OP-Challenger afin qu'elle puisse être postée sur PreimageOracle.sol.

Ceci conclut notre plongée dans Cannon. En plus de cet article de blog, Coinbase a créé une documentation approfondie qui fournit plus de détails sur chacun des composants de Cannon. Consultez-la sur Fault Proof VM - Cannon | Optimism Docs, et si vous êtes intéressé par la spécification technique officielle d'Optimism pour Cannon, vous pouvez la consulter ici : Spécification technique de Cannon.

https://blog.oplabs.co/fault-proof-deep-dive-part-2-cannon/