La première partie de la série consacrée à l'épreuve des fautes avec Coinbase examine le contrat intelligent FPVM MIPS.sol et son fonctionnement au sein du système à l'épreuve des fautes de l'OP Stack.

La série consacrée à l'épreuve des fautes est une collaboration entre l'équipe Blockchain Security (BlockSec) de Coinbase et OP Labs qui vise à fournir des informations approfondies sur tous les principaux composants de l'épreuve des fautes. En partageant ces informations, nous espérons encourager les intéressés à en apprendre davantage sur l'architecture et les aspects techniques des systèmes à l'épreuve des fautes. Ensemble, nous évoluerons vers l'avenir décentralisé des blockchains OP Stack L2.

Dans cet article de blog, nous allons couvrir le contrat intelligent MIPS.sol de la Machine Virtuelle à l'épreuve des fautes (FPVM).

Le contrat intelligent MIPS.sol est une implémentation onchain d'une machine virtuelle (VM) qui englobe l'architecture de jeu d'instructions (ISA) 32 bits, Big-Endian, MIPS III. Ce contrat intelligent est la contrepartie de l'implémentation golang hors chaîne MIPSEVM de la même ISA. Ensemble, les implémentations onchain et off-chain de la VM constituent Cannon, le premier FPVM développé par l'OP.

Cannon est une instance de FPVM, qui est utilisée dans le cadre du mécanisme de règlement des conflits pour les blockchains L2 à rollup optimiste qui utilisent l'OP Stack. Le système de contestation lui-même est modulaire, ce qui permet d'utiliser n'importe quel FPVM ; cependant, Cannon est actuellement le seul FPVM implémenté et sera donc utilisé dans toutes les contestations.

Prenons un peu de recul et voyons brièvement où se situe le contrat MIPS.sol dans le processus à l'épreuve des fautes.

Dans le diagramme ci-dessus, recréé à partir de la vidéo Fault Proof Walkthrough de Clabby, nous pouvons voir que le contrat MIPS.sol interagit avec deux autres contrats : FaultDisputeGame.sol et PreimageOracle.sol. FaultDisputeGame.sol est l'instance déployée d'un Fault Dispute Game pour un conflit actif. PreimageOracle.sol est l'instance déployée d'un Oracle de pré-images qui stockera les pré-images pour tous les jeux de conflit qui utilisent le même FPVM. Dans notre cas, il y a donc un seul contrat PreimageOracle.sol pour tous les jeux qui utilisent MIPS.sol comme FPVM.

Le contrat MIPS.sol est appelé par une instance en cours d'exécution d'un jeu de dispute, et n'est appelé que lorsqu'un jeu de dispute atteint un leaf node dans l'arbre de transition d'état qui fait actuellement l'objet d'une dispute. Un leaf node représente une instruction MIPS unique (dans le cas où nous utilisons Cannon comme FPVM) qui peut alors être exécutée sur la chaîne. Étant donné l'état pre, qui est l'état L2 convenu précédemment jusqu'à cette instruction, et l'état de l'instruction à exécuter dans le contrat MIPS.sol, le jeu de dispute de fautes peut déterminer le véritable état post. Ce véritable état post sera alors utilisé pour résoudre le jeu de dispute de faute en comparant l'état post contesté au leaf node avec l'état post proposé par l'adversaire dans l'instance du jeu de dispute.

Il existe un seul point d'entrée au contrat intelligent MIPS.sol : la fonction step(). C'est cette fonction qui est appelée par le jeu de dispute en cours, qui exécutera une seule instruction MIPS sur la chaîne. À un niveau élevé, les opérations suivantes seront effectuées :

1. Les données relatives à l'état d'exécution de la VM sont analysées et chargées dans la mémoire. Ces données sont générées par la contrepartie Cannon golang que les participants au jeu exécutent hors chaîne via l'OP-Challenger.

2. L'entrée de la preuve mémoire est lue et vérifiée. Cette preuve mémoire indique un emplacement dans la mémoire à partir duquel l'instruction MIPS suivante doit être chargée et exécutée.

3. L'instruction MIPS suivante est exécutée. La majorité de la logique du contrat MIPS.sol gère l'exécution d'une instruction MIPS conformément à la spécification MIPS III. Lors du traitement des instructions MIPS, la seule instruction qui ne suit pas une spécification stricte est l'instruction SYSCALL (appel système). Le comportement des appels système est propre au système d'exploitation et, dans le cas de MIPS.sol, les appels système qui peuvent être effectués ne représentent qu'une fraction de l'ensemble des appels système. L'objectif principal des appels système est de gérer les lectures du contrat PreimageOracle.sol et de simuler les écritures dans le contrat.

4. Les résultats de l'instruction peuvent être écrits dans un registre ou dans la mémoire. Dans le cas de l'écriture dans la mémoire, une deuxième preuve de mémoire aura été fournie en entrée par le jeu de dispute. La seconde preuve de mémoire doit coïncider avec l'emplacement de la mémoire qui devrait être inscrit, et le contrat intelligent MIPS.sol utilisera la nouvelle valeur et la preuve de mémoire pour calculer la nouvelle racine merkle de la mémoire.

À la fin de l'instruction MIPS, un hachage d'état sera renvoyé à l'instance de jeu de dispute. Le hachage d'état est le hachage keccak256 de l'état d'exécution de la VM dont le premier octet ne correspond pas au hachage mais est remplacé par une valeur indiquant l'état de la VM. Le jeu de dispute utilisera le hachage d'état et l'état de la VM pour résoudre la dispute.

Comme mentionné précédemment, le contrat MIPS.sol interagit avec deux autres contrats intelligents : FaultDisputeGame.sol et PreimageOracle.sol. Le contrat FaultDisputeGame.sol fournit l'état d'exécution actuel de la VM et jusqu'à deux preuves de mémoire. Le contrat PreimageOracle.sol fournit des pré-images qui peuvent être utilisées par MIPS.sol pour aider à déterminer le véritable état de la L2. Le contenu dérivé d'une pré-image peut inclure des données provenant à la fois de L1 et L2, qui peuvent être des en-têtes de blocs, des transactions, des reçus, l'état d'un contrat, etc.

Ensemble, ces deux contrats fournissent toutes les informations nécessaires à l'exécution d'une instruction MIPS. Le contrat MIPS.sol ne stocke aucune information sur l'exécution d'une instruction. Ainsi, le contrat peut être utilisé par n'importe quel Fault Dispute Game sans qu'il soit nécessaire de réinitialiser des valeurs. Par conséquent, le contrat MIPS.sol garantit uniquement que la racine merkle calculée à partir des preuves en mémoire fournies est égale à la racine merkle dans l'état d'exécution de la VM. Dans le cas contraire, c'est au contrat FaultDisputeGame.sol de garantir l'exactitude des informations fournies et des actions entreprises par un participant au jeu de litige.

Ceci conclut notre exploration approfondie du contrat intelligent MIPS.sol. En plus de cet article de blog, Coinbase a créé une documentation approfondie qui fournit des détails sur chaque fonction du contrat intelligent, énumère les instructions MIPS prises en charge par la FPVM, et plus encore.

A consulter sur le site Fault Proofs - MIPS.sol | Optimism Docs.

La première partie de la série consacrée à l'épreuve des fautes avec Coinbase examine le contrat intelligent FPVM MIPS.sol et son fonctionnement au sein du système à l'épreuve des fautes de l'OP Stack.

La série consacrée à l'épreuve des fautes est une collaboration entre l'équipe Blockchain Security (BlockSec) de Coinbase et OP Labs qui vise à fournir des informations approfondies sur tous les principaux composants de l'épreuve des fautes. En partageant ces informations, nous espérons encourager les intéressés à en apprendre davantage sur l'architecture et les aspects techniques des systèmes à l'épreuve des fautes. Ensemble, nous évoluerons vers l'avenir décentralisé des blockchains OP Stack L2.

Dans cet article de blog, nous allons couvrir le contrat intelligent MIPS.sol de la Machine Virtuelle à l'épreuve des fautes (FPVM).

Le contrat intelligent MIPS.sol est une implémentation onchain d'une machine virtuelle (VM) qui englobe l'architecture de jeu d'instructions (ISA) 32 bits, Big-Endian, MIPS III. Ce contrat intelligent est la contrepartie de l'implémentation golang hors chaîne MIPSEVM de la même ISA. Ensemble, les implémentations onchain et off-chain de la VM constituent Cannon, le premier FPVM développé par l'OP.

Cannon est une instance de FPVM, qui est utilisée dans le cadre du mécanisme de règlement des conflits pour les blockchains L2 à rollup optimiste qui utilisent l'OP Stack. Le système de contestation lui-même est modulaire, ce qui permet d'utiliser n'importe quel FPVM ; cependant, Cannon est actuellement le seul FPVM implémenté et sera donc utilisé dans toutes les contestations.

Prenons un peu de recul et voyons brièvement où se situe le contrat MIPS.sol dans le processus à l'épreuve des fautes.

Dans le diagramme ci-dessus, recréé à partir de la vidéo Fault Proof Walkthrough de Clabby, nous pouvons voir que le contrat MIPS.sol interagit avec deux autres contrats : FaultDisputeGame.sol et PreimageOracle.sol. FaultDisputeGame.sol est l'instance déployée d'un Fault Dispute Game pour un conflit actif. PreimageOracle.sol est l'instance déployée d'un Oracle de pré-images qui stockera les pré-images pour tous les jeux de conflit qui utilisent le même FPVM. Dans notre cas, il y a donc un seul contrat PreimageOracle.sol pour tous les jeux qui utilisent MIPS.sol comme FPVM.

Le contrat MIPS.sol est appelé par une instance en cours d'exécution d'un jeu de dispute, et n'est appelé que lorsqu'un jeu de dispute atteint un leaf node dans l'arbre de transition d'état qui fait actuellement l'objet d'une dispute. Un leaf node représente une instruction MIPS unique (dans le cas où nous utilisons Cannon comme FPVM) qui peut alors être exécutée sur la chaîne. Étant donné l'état pre, qui est l'état L2 convenu précédemment jusqu'à cette instruction, et l'état de l'instruction à exécuter dans le contrat MIPS.sol, le jeu de dispute de fautes peut déterminer le véritable état post. Ce véritable état post sera alors utilisé pour résoudre le jeu de dispute de faute en comparant l'état post contesté au leaf node avec l'état post proposé par l'adversaire dans l'instance du jeu de dispute.

Il existe un seul point d'entrée au contrat intelligent MIPS.sol : la fonction step(). C'est cette fonction qui est appelée par le jeu de dispute en cours, qui exécutera une seule instruction MIPS sur la chaîne. À un niveau élevé, les opérations suivantes seront effectuées :

1. Les données relatives à l'état d'exécution de la VM sont analysées et chargées dans la mémoire. Ces données sont générées par la contrepartie Cannon golang que les participants au jeu exécutent hors chaîne via l'OP-Challenger.

2. L'entrée de la preuve mémoire est lue et vérifiée. Cette preuve mémoire indique un emplacement dans la mémoire à partir duquel l'instruction MIPS suivante doit être chargée et exécutée.

3. L'instruction MIPS suivante est exécutée. La majorité de la logique du contrat MIPS.sol gère l'exécution d'une instruction MIPS conformément à la spécification MIPS III. Lors du traitement des instructions MIPS, la seule instruction qui ne suit pas une spécification stricte est l'instruction SYSCALL (appel système). Le comportement des appels système est propre au système d'exploitation et, dans le cas de MIPS.sol, les appels système qui peuvent être effectués ne représentent qu'une fraction de l'ensemble des appels système. L'objectif principal des appels système est de gérer les lectures du contrat PreimageOracle.sol et de simuler les écritures dans le contrat.

4. Les résultats de l'instruction peuvent être écrits dans un registre ou dans la mémoire. Dans le cas de l'écriture dans la mémoire, une deuxième preuve de mémoire aura été fournie en entrée par le jeu de dispute. La seconde preuve de mémoire doit coïncider avec l'emplacement de la mémoire qui devrait être inscrit, et le contrat intelligent MIPS.sol utilisera la nouvelle valeur et la preuve de mémoire pour calculer la nouvelle racine merkle de la mémoire.

À la fin de l'instruction MIPS, un hachage d'état sera renvoyé à l'instance de jeu de dispute. Le hachage d'état est le hachage keccak256 de l'état d'exécution de la VM dont le premier octet ne correspond pas au hachage mais est remplacé par une valeur indiquant l'état de la VM. Le jeu de dispute utilisera le hachage d'état et l'état de la VM pour résoudre la dispute.

Comme mentionné précédemment, le contrat MIPS.sol interagit avec deux autres contrats intelligents : FaultDisputeGame.sol et PreimageOracle.sol. Le contrat FaultDisputeGame.sol fournit l'état d'exécution actuel de la VM et jusqu'à deux preuves de mémoire. Le contrat PreimageOracle.sol fournit des pré-images qui peuvent être utilisées par MIPS.sol pour aider à déterminer le véritable état de la L2. Le contenu dérivé d'une pré-image peut inclure des données provenant à la fois de L1 et L2, qui peuvent être des en-têtes de blocs, des transactions, des reçus, l'état d'un contrat, etc.

Ensemble, ces deux contrats fournissent toutes les informations nécessaires à l'exécution d'une instruction MIPS. Le contrat MIPS.sol ne stocke aucune information sur l'exécution d'une instruction. Ainsi, le contrat peut être utilisé par n'importe quel Fault Dispute Game sans qu'il soit nécessaire de réinitialiser des valeurs. Par conséquent, le contrat MIPS.sol garantit uniquement que la racine merkle calculée à partir des preuves en mémoire fournies est égale à la racine merkle dans l'état d'exécution de la VM. Dans le cas contraire, c'est au contrat FaultDisputeGame.sol de garantir l'exactitude des informations fournies et des actions entreprises par un participant au jeu de litige.

Ceci conclut notre exploration approfondie du contrat intelligent MIPS.sol. En plus de cet article de blog, Coinbase a créé une documentation approfondie qui fournit des détails sur chaque fonction du contrat intelligent, énumère les instructions MIPS prises en charge par la FPVM, et plus encore.

A consulter sur le site Fault Proofs - MIPS.sol | Optimism Docs.