Afin de créer le réseau interopérable de couche 2 le plus puissant et le plus sécurisé, Optimism Collective poursuit la décentralisation par de nombreuses voies différentes.
Le prochain système de sécurité d'OP Stack constituera une étape majeure vers la décentralisation technologique. La conception open source et modulaire d'OP Stack crée une étape sans précédent pour la décentralisation sociale de l'écosystème L2.
Dans cet article, nous explorons le principe de décentralisation sociale, comment l'architecture L2 permet à la couche 2 d'étendre ce principe pour inclure la diversité des attestations et la diversité des clients, et décrivons comment Optimism Collective exploite cette architecture pour construire son système de sécurité.
"Décentralisation sociale" inspirée par Ethereum
Le protocole Ethereum bénéficie de la décentralisation sociale, notamment en offrant des solutions optionnelles qui permettent à un large éventail de contributeurs de participer à la construction d'un réseau décentralisé robuste.
Pour les logiciels de nœuds, cela signifie une diversité de clients : plus vous avez de clients, moins un point de défaillance unique a d'impact sur le réseau du validateur.
Les principaux développeurs de Layer1 décrivent ce modèle de contribution comme un « bazar », bruyant et apparemment chaotique, mais très efficace et dynamique. En adoptant une approche radicalement ouverte du développement de protocoles, le plus grand nombre de contributeurs peut participer et améliorer le protocole.
Optimism Collective est dans une position unique pour mettre en œuvre et répéter l'approche d'Ethereum en matière de décentralisation sociale : OP Stack réalise la décentralisation sociale en fournissant des spécifications ouvertes et des logiciels open source sous la licence MIT, et Optimism Collective peut réaliser la décentralisation sociale en créant des itérations de super chaînes dessus.
Une compréhension plus détaillée de l'architecture L2
Ethereum a une spécification ouverte au niveau L1 et une architecture client modulaire qui sépare la couche consensus et la couche d'exécution.
OP-Stack implémente la même architecture sur L2 :
La couche de consensus est alimentée par op-node et Magi, deux clients qui suivent les entrées d'exécution L1 et exportent ;
La couche d'exécution est prise en charge par op-geth, op-erigon et op-reth ;
Cependant, l'architecture L2 ajoute une nouvelle couche à cette pile : la couche de preuve.
Il s'agit de la couche qui relie en toute sécurité les sorties L2 à L1. Tout comme avoir plusieurs clients est une bonne pratique pour garantir le consensus et l'exécution sur L1 et L2, pour la couche de validation de L2, disposer de plusieurs méthodes d'attestation peut garantir une sécurité optimale.
De la même manière que les validateurs de différents clients parviennent à un consensus, un quorum d'attestations en chaîne peut montrer que les revendications d'état L2 ont été vérifiées de différentes manières, réduisant considérablement le risque d'erreurs conduisant à un échec complet.
Il existe actuellement trois types courants de preuves : les attestations, les preuves d'erreurs (également appelées preuves de fraude) et les preuves de validité sans connaissance. Les deux derniers partagent un modèle commun en ce sens qu'ils expriment les transitions d'état L2 sous une forme synchrone et prouvent leur exécution à partir des données L1 et de l'état précédent L2 en entrée.
Isoler les composants du système de preuve pour obtenir une diversité de preuves
Montrez que le système peut être décomposé en composants indépendants :
Un « programme » qui définit les transitions d'état synchrones L2 ;
Une « machine virtuelle » (VM) pour exécuter et vérifier le programme ;
Un « oracle de pré-image » qui prend les données L1 et le pré-état L2 en entrée ;
De nombreuses preuves à connaissance nulle actuelles associent encore étroitement ces composants, créant un ZK-EVM qui s'exécute sur une seule donnée de transaction L1. Cependant, la pile OP les découple pour isoler la complexité et permettre la diversité des clients, rendant l'ensemble plus puissant.
Les preuves de fautes interactives ajoutent des jeux de bissection aux traces de machines virtuelles pour vérifier les preuves en chaîne, tandis que les preuves arithmétiques à connaissance nulle basées sur des machines virtuelles plient l'exécution et fournissent des preuves de validité. (Voir les preuves sans connaissance basées sur des machines virtuelles que Risc0 et O(1)-Labs conçoivent en réponse aux appels d'offres d'Optimism ZK).
Le programme définit la transition d'état réelle comme le « client » et l'acquisition d'entrée (données L1 et pré-état L2) comme le « serveur ». Le programme s'exécute indépendamment du serveur/client sans machine virtuelle, un peu comme un nœud blockchain classique, et partage beaucoup de code.
Par exemple, le client du programme opérationnel Go est construit en important le fork et l'EVM du nœud opérationnel depuis op-geth, tandis que le serveur obtient ses données des RPC Ethereum L1 et L2.
Aperçu fonctionnel de FPVM
La machine virtuelle à l'épreuve des pannes (FPVM) est l'un des modules de la pile à l'épreuve des pannes dans OP Stack.
Cette VM n'implémente rien de spécifique à Ethereum ou L2 autre que la fourniture des interfaces correctes (en particulier celles liées aux oracles de pré-image), et le client Fault Proofing Program (FPP) exécuté dans le FPVM doit exprimer la partie de conversion d'état L2.
Avec cette séparation, la machine virtuelle reste minimaliste : les modifications apportées au protocole Ethereum (comme l'ajout d'opcodes EVM) n'affectent pas la machine virtuelle.
Au lieu de cela, lorsque le protocole change, le FPP peut simplement être mis à jour pour importer les nouveaux composants de transition d'état dans le logiciel du nœud. Semblable à la lecture d'une nouvelle version du jeu sur la même console de jeu, le système d'attestation L1 peut être mis à jour pour attester de différents programmes.
La machine virtuelle est responsable de l'exécution des instructions de bas niveau et doit simuler FPP. Les exigences de la machine virtuelle sont moindres : les programmes sont exécutés de manière synchrone et toutes les entrées sont chargées via le même oracle de pré-image, mais tout cela doit encore être prouvé sur la chaîne EVM L1.
Pour ce faire, une seule instruction peut être prouvée à la fois. Le jeu de bissection réduira la tâche de prouver des traces d’exécution complètes à une seule instruction.
La preuve d'instruction peut être différente pour chaque FPVM, mais ressemble généralement à celle de Cannon, qui prouve l'instruction comme suit :
Pour exécuter cette instruction, la machine virtuelle simule quelque chose de similaire au cycle d'instruction d'un contexte de thread : l'instruction est lue depuis la mémoire, interprétée, et certaines modifications peuvent survenir dans le fichier de registre et la mémoire ;
Pour prendre en charge les besoins d'exécution de base du programme tels que les oracles de pré-image et l'allocation de mémoire, l'exécution prend également en charge un sous-ensemble d'appels système Linux. Les appels système de lecture/écriture permettent une interaction avec l'oracle de pré-image : le programme écrit le hachage sous forme de demande pour obtenir la pré-image, puis le lit par morceaux à la fois ;
Cannon, le premier FPVM, a implémenté la machine virtuelle MIPS de cette manière. Pour plus d'informations sur les machines virtuelles, consultez la documentation associée et les spécifications de Cannon. L'interface entre les programmes FPVM et FP est standardisée et documentée dans des spécifications.
De FPVM à ZKVM
Les preuves d'échec ne sont pas le seul type de preuve de transition d'état, les preuves de validité ZK sont une option attrayante en raison de leur potentiel de pontage rapide entre les chaînes (puisque les preuves de validité ZK n'ont pas de jeux de défi en chaîne, il n'y a pas de fenêtre de litige). Afin de prendre en charge la pile Ethereum avancée et d’héberger différentes implémentations client, nous devons toujours découpler la machine virtuelle et le programme.
C'est l'approche adoptée par le projet ZK RFP pour prouver qu'une machine virtuelle RISC-V (par Risc0) ou MIPS (par O(1) Labs) minimale peut héberger le même programme utilisé dans la preuve de panne.
La prise en charge de ZK-VM nécessite quelques ajustements mineurs pour permettre aux oracles de pré-image de charger des données de manière non interactive, mais en généralisant la machine virtuelle, ZK s'avère plus évolutif face aux changements de la pile OP.
Opportunités pour les contributeurs externes
OP Stack accueille des options supplémentaires de machines virtuelles et de programmes, ainsi que des systèmes de preuve indépendants supplémentaires, des preuves aux preuves sans connaissance. Tout comme la diversité des clients, la diversité des preuves est un effort collectif.
Les ajouts à la couche de preuve de la pile OP actuellement en cours incluent :
RISC-V FPVM « Asterisc » développé par protolambda et écrit en langage Go ;
Programme Rust FP basé sur Magi et op-reth construit par les contributeurs de Base et OP Labs ;
Programme Rust ZK basé sur zeth (branche ZK-reth) construit par Risc0 ;
À mesure que le canon, le programme opérationnel, le jeu de bissection et la créativité illimitée de la communauté open source évoluent, il y aura de nombreuses opportunités supplémentaires de contribuer à la pile via des implémentations de tests et la participation à des programmes de bug bounty.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Interprétation du système de sécurité qui sera lancé par OP Stack : Inspiré d'Ethereum, un grand pas vers la décentralisation technologique
Auteur : protolambda, chercheur à OP Labs
Compilé par : Frank, Foresight News
Afin de créer le réseau interopérable de couche 2 le plus puissant et le plus sécurisé, Optimism Collective poursuit la décentralisation par de nombreuses voies différentes.
Le prochain système de sécurité d'OP Stack constituera une étape majeure vers la décentralisation technologique. La conception open source et modulaire d'OP Stack crée une étape sans précédent pour la décentralisation sociale de l'écosystème L2.
Dans cet article, nous explorons le principe de décentralisation sociale, comment l'architecture L2 permet à la couche 2 d'étendre ce principe pour inclure la diversité des attestations et la diversité des clients, et décrivons comment Optimism Collective exploite cette architecture pour construire son système de sécurité.
"Décentralisation sociale" inspirée par Ethereum
Le protocole Ethereum bénéficie de la décentralisation sociale, notamment en offrant des solutions optionnelles qui permettent à un large éventail de contributeurs de participer à la construction d'un réseau décentralisé robuste.
Pour les logiciels de nœuds, cela signifie une diversité de clients : plus vous avez de clients, moins un point de défaillance unique a d'impact sur le réseau du validateur.
Les principaux développeurs de Layer1 décrivent ce modèle de contribution comme un « bazar », bruyant et apparemment chaotique, mais très efficace et dynamique. En adoptant une approche radicalement ouverte du développement de protocoles, le plus grand nombre de contributeurs peut participer et améliorer le protocole.
Optimism Collective est dans une position unique pour mettre en œuvre et répéter l'approche d'Ethereum en matière de décentralisation sociale : OP Stack réalise la décentralisation sociale en fournissant des spécifications ouvertes et des logiciels open source sous la licence MIT, et Optimism Collective peut réaliser la décentralisation sociale en créant des itérations de super chaînes dessus.
Une compréhension plus détaillée de l'architecture L2
Ethereum a une spécification ouverte au niveau L1 et une architecture client modulaire qui sépare la couche consensus et la couche d'exécution.
OP-Stack implémente la même architecture sur L2 :
La couche de consensus est alimentée par op-node et Magi, deux clients qui suivent les entrées d'exécution L1 et exportent ;
La couche d'exécution est prise en charge par op-geth, op-erigon et op-reth ;
Cependant, l'architecture L2 ajoute une nouvelle couche à cette pile : la couche de preuve.
Il s'agit de la couche qui relie en toute sécurité les sorties L2 à L1. Tout comme avoir plusieurs clients est une bonne pratique pour garantir le consensus et l'exécution sur L1 et L2, pour la couche de validation de L2, disposer de plusieurs méthodes d'attestation peut garantir une sécurité optimale.
De la même manière que les validateurs de différents clients parviennent à un consensus, un quorum d'attestations en chaîne peut montrer que les revendications d'état L2 ont été vérifiées de différentes manières, réduisant considérablement le risque d'erreurs conduisant à un échec complet.
Il existe actuellement trois types courants de preuves : les attestations, les preuves d'erreurs (également appelées preuves de fraude) et les preuves de validité sans connaissance. Les deux derniers partagent un modèle commun en ce sens qu'ils expriment les transitions d'état L2 sous une forme synchrone et prouvent leur exécution à partir des données L1 et de l'état précédent L2 en entrée.
Isoler les composants du système de preuve pour obtenir une diversité de preuves
Montrez que le système peut être décomposé en composants indépendants :
De nombreuses preuves à connaissance nulle actuelles associent encore étroitement ces composants, créant un ZK-EVM qui s'exécute sur une seule donnée de transaction L1. Cependant, la pile OP les découple pour isoler la complexité et permettre la diversité des clients, rendant l'ensemble plus puissant.
Les preuves de fautes interactives ajoutent des jeux de bissection aux traces de machines virtuelles pour vérifier les preuves en chaîne, tandis que les preuves arithmétiques à connaissance nulle basées sur des machines virtuelles plient l'exécution et fournissent des preuves de validité. (Voir les preuves sans connaissance basées sur des machines virtuelles que Risc0 et O(1)-Labs conçoivent en réponse aux appels d'offres d'Optimism ZK).
Le programme définit la transition d'état réelle comme le « client » et l'acquisition d'entrée (données L1 et pré-état L2) comme le « serveur ». Le programme s'exécute indépendamment du serveur/client sans machine virtuelle, un peu comme un nœud blockchain classique, et partage beaucoup de code.
Par exemple, le client du programme opérationnel Go est construit en important le fork et l'EVM du nœud opérationnel depuis op-geth, tandis que le serveur obtient ses données des RPC Ethereum L1 et L2.
Aperçu fonctionnel de FPVM
La machine virtuelle à l'épreuve des pannes (FPVM) est l'un des modules de la pile à l'épreuve des pannes dans OP Stack.
Cette VM n'implémente rien de spécifique à Ethereum ou L2 autre que la fourniture des interfaces correctes (en particulier celles liées aux oracles de pré-image), et le client Fault Proofing Program (FPP) exécuté dans le FPVM doit exprimer la partie de conversion d'état L2.
Avec cette séparation, la machine virtuelle reste minimaliste : les modifications apportées au protocole Ethereum (comme l'ajout d'opcodes EVM) n'affectent pas la machine virtuelle.
Au lieu de cela, lorsque le protocole change, le FPP peut simplement être mis à jour pour importer les nouveaux composants de transition d'état dans le logiciel du nœud. Semblable à la lecture d'une nouvelle version du jeu sur la même console de jeu, le système d'attestation L1 peut être mis à jour pour attester de différents programmes.
La machine virtuelle est responsable de l'exécution des instructions de bas niveau et doit simuler FPP. Les exigences de la machine virtuelle sont moindres : les programmes sont exécutés de manière synchrone et toutes les entrées sont chargées via le même oracle de pré-image, mais tout cela doit encore être prouvé sur la chaîne EVM L1.
Pour ce faire, une seule instruction peut être prouvée à la fois. Le jeu de bissection réduira la tâche de prouver des traces d’exécution complètes à une seule instruction.
La preuve d'instruction peut être différente pour chaque FPVM, mais ressemble généralement à celle de Cannon, qui prouve l'instruction comme suit :
Cannon, le premier FPVM, a implémenté la machine virtuelle MIPS de cette manière. Pour plus d'informations sur les machines virtuelles, consultez la documentation associée et les spécifications de Cannon. L'interface entre les programmes FPVM et FP est standardisée et documentée dans des spécifications.
De FPVM à ZKVM
Les preuves d'échec ne sont pas le seul type de preuve de transition d'état, les preuves de validité ZK sont une option attrayante en raison de leur potentiel de pontage rapide entre les chaînes (puisque les preuves de validité ZK n'ont pas de jeux de défi en chaîne, il n'y a pas de fenêtre de litige). Afin de prendre en charge la pile Ethereum avancée et d’héberger différentes implémentations client, nous devons toujours découpler la machine virtuelle et le programme.
C'est l'approche adoptée par le projet ZK RFP pour prouver qu'une machine virtuelle RISC-V (par Risc0) ou MIPS (par O(1) Labs) minimale peut héberger le même programme utilisé dans la preuve de panne.
La prise en charge de ZK-VM nécessite quelques ajustements mineurs pour permettre aux oracles de pré-image de charger des données de manière non interactive, mais en généralisant la machine virtuelle, ZK s'avère plus évolutif face aux changements de la pile OP.
Opportunités pour les contributeurs externes
OP Stack accueille des options supplémentaires de machines virtuelles et de programmes, ainsi que des systèmes de preuve indépendants supplémentaires, des preuves aux preuves sans connaissance. Tout comme la diversité des clients, la diversité des preuves est un effort collectif.
Les ajouts à la couche de preuve de la pile OP actuellement en cours incluent :
À mesure que le canon, le programme opérationnel, le jeu de bissection et la créativité illimitée de la communauté open source évoluent, il y aura de nombreuses opportunités supplémentaires de contribuer à la pile via des implémentations de tests et la participation à des programmes de bug bounty.