
Subscribe to omahs

Subscribe to omahs
<100 subscribers
<100 subscribers
Share Dialog
Share Dialog


Une mise à jour sur la décentralisation technique et le premier système Fault Proof de l'OP Stack.
Bedrock a été lancé, l'écosystème Superchain se développe, et maintenant les développeurs d'OP Labs, de Coinbase Base et du collectif Optimism se concentrent sur la décentralisation de l'OP Stack ! Nous avons hâte de partager plus d'informations sur la conception du premier système Fault Proof de l'OP Stack, sur la façon dont il permettra au collectif de faire des progrès significatifs vers la décentralisation technique, et sur le prochain niveau de personnalisation disponible pour le système Fault Proof de l'OP Stack.
En février, nous avons décrit l’OP Stack et le chemin d’Optimism vers la décentralisation technique. Le plan comprend des étapes de décentralisation de base comme les propositions de sortie sans permission et la décentralisation des ponts. Ces étapes ont été incluses dans le plan afin que nous puissions progresser sur la décentralisation même si l'itération sur les preuves de fautes prenait du temps.
Maintenant que Bedrock a été lancé, nous sommes vraiment ravis d'annoncer que des progrès significatifs ont été réalisés sur le système Fault Proof de l'OP Stack. Cela signifie que la livraison des preuves de fautes est la prochaine étape majeure à attendre dans l'écosystème Optimism !
Voici un aperçu des composants du système Fault Proof :
Le FPP, ou " op-program ", agit comme un programme déterministe qui est alimenté par les données L1. Il récupère les données nécessaires et vérifie l'existence d'éventuelles défaillances. Il peut également définir l'hôte qui prélève les informations.
La FPVM, alias "Cannon", exécute le programme opérationnel. Cannon est écrit en Go et émule une machine MIPS, qui exécute la machine virtuelle Ethereum L2 (EVM) telle que définie par l'op-program, tout en étant elle-même prouvable dans l'EVM L1. Ce niveau d'abstraction permet au système de maintenir un contrôle et un suivi précis de chaque étape d'instruction. Il peut récupérer les données nécessaires (pré-images) ou s'exécuter avec des données pré-chargées.
Un jeu de dispute permet de résoudre les désaccords sur les résultats du programme d'exploitation. L'objectif est de réduire le désaccord au point exact de la trace de l'instruction. La résolution du jeu de litige repose sur l'identification de la première revendication incontestée, sur la base de laquelle la validité de la revendication racine peut être déterminée.
Le premier jeu de dispute qui sera intégré aux traces de dispute générées par Cannon et l'op-program est un jeu de Bisection (mais de nombreux autres jeux de dispute sont possibles !).
Nous sommes impatients de proposer une version alpha du système de preuve de défaillance sur le Testnet, afin que les développeurs de l'écosystème puissent tester et essayer de casser le MVP, et commencer à réfléchir à la construction de preuves de défaillance alternatives ou d'autres composants modulaires. 👀 👀 👀
C'est bien cela ! Le système à l'épreuve des pannes a été conçu pour mettre en évidence la puissance de la modularité de l'OP Stack. Ainsi, il est facile pour les créateurs d'écosystèmes de concevoir des composants à l'épreuve des pannes OP Stack personnalisés, des schémas de preuve aux machines virtuelles, et même des jeux de dispute uniques. En modularisant le programme à l'épreuve des fautes (FPP) et la machine virtuelle à l'épreuve des fautes (FPVM), il devient possible d'améliorer chaque composant en parallèle, ce qui accroît les performances et l'innovation du système. Nous espérons que cela contribuera à jeter les bases d'un écosystème dynamique de systèmes de preuve d'EVM à source ouverte.
Le système Fault Proof est essentiel pour permettre la décentralisation des protocoles. D'un point de vue technique, il permettra un pontage sécurisé sans solution de repli centralisée. En outre, son caractère open-source et sa norme de mise en œuvre minimale facilitent la mise en œuvre de multiples applications du protocole. Ces mises en œuvre multiples permettent d'assurer la sécurité et sont une condition préalable à l'atteinte de l'étape 2 de la décentralisation technique.
Mais au-delà de cela, le fait d'avoir des implémentations multiples maintenues par des membres distincts de la communauté est essentiel pour la décentralisation sociale. La décentralisation sociale est une stratégie sous-estimée, mais vitale pour toute blockchain. Plus il y a de clients, de mécanismes de preuve, de jeux de dispute et d'autres infrastructures construits et maintenus par différents contributeurs, plus le protocole est décentralisé. En faisant de la modularité un élément clé de la conception du système de preuve de faille, on multiplie les possibilités pour les développeurs du collectif de participer à la création et à la maintenance d’OP Mainnet et de la Superchain.
Un autre avantage de la conception modulaire des preuves est qu'elle crée une voie claire pour ajouter des preuves à connaissance nulle (ZKP) à l'OP Stack. La séparation entre FPP et FPVM signifie que le même programme opérationnel peut être exécuté à la fois dans un FPVM et dans un ZKVM. Ainsi, tant que les développeurs de ZKP ciblent une spécification de VM compatible, ils n'ont pas besoin de comprendre le fonctionnement interne du FPP.
De même, les développeurs qui optimisent le FPP n'ont pas besoin de comprendre le fonctionnement interne de la ZKVM. Cette réduction de la complexité et cette séparation des préoccupations sont la clé du développement rapide du ZKP par l'OP Stack. Suivez ce RFP pour des développements amusants de ZKP de l'OP Stack ! Ces ZKP de l'OP Stack permettront de réaliser des preuves de validité basées sur le ZK et d'alimenter des ponts à faible latence entre les chaînes. Ces ponts sont essentiels pour débloquer la composabilité de la Superchain et donc pour atteindre l'objectif d'une Superchain unifiée et interconnectée.
L'OP Stack est la clé pour garantir que l'infrastructure de la Superchain, y compris le Fault Proof System, est composable, polyvalente et à l'épreuve du temps. Le système à l'épreuve des pannes représente une étape majeure vers une Superchain plus décentralisée et plus efficace. Ce système permettra aux développeurs de personnaliser plus facilement leur travail et aux utilisateurs de l'écosystème de bénéficier d'une sécurité et de performances accrues.
Il n'est jamais trop tôt pour commencer à réfléchir à la manière dont vous pourriez contribuer à l'OP Stack et aider à sécuriser la Superchain. Le tableau de bord des contributions de l'écosystème Optimism est plein d'inspiration et de guides sur la façon de commencer à contribuer au collectif.
Une mise à jour sur la décentralisation technique et le premier système Fault Proof de l'OP Stack.
Bedrock a été lancé, l'écosystème Superchain se développe, et maintenant les développeurs d'OP Labs, de Coinbase Base et du collectif Optimism se concentrent sur la décentralisation de l'OP Stack ! Nous avons hâte de partager plus d'informations sur la conception du premier système Fault Proof de l'OP Stack, sur la façon dont il permettra au collectif de faire des progrès significatifs vers la décentralisation technique, et sur le prochain niveau de personnalisation disponible pour le système Fault Proof de l'OP Stack.
En février, nous avons décrit l’OP Stack et le chemin d’Optimism vers la décentralisation technique. Le plan comprend des étapes de décentralisation de base comme les propositions de sortie sans permission et la décentralisation des ponts. Ces étapes ont été incluses dans le plan afin que nous puissions progresser sur la décentralisation même si l'itération sur les preuves de fautes prenait du temps.
Maintenant que Bedrock a été lancé, nous sommes vraiment ravis d'annoncer que des progrès significatifs ont été réalisés sur le système Fault Proof de l'OP Stack. Cela signifie que la livraison des preuves de fautes est la prochaine étape majeure à attendre dans l'écosystème Optimism !
Voici un aperçu des composants du système Fault Proof :
Le FPP, ou " op-program ", agit comme un programme déterministe qui est alimenté par les données L1. Il récupère les données nécessaires et vérifie l'existence d'éventuelles défaillances. Il peut également définir l'hôte qui prélève les informations.
La FPVM, alias "Cannon", exécute le programme opérationnel. Cannon est écrit en Go et émule une machine MIPS, qui exécute la machine virtuelle Ethereum L2 (EVM) telle que définie par l'op-program, tout en étant elle-même prouvable dans l'EVM L1. Ce niveau d'abstraction permet au système de maintenir un contrôle et un suivi précis de chaque étape d'instruction. Il peut récupérer les données nécessaires (pré-images) ou s'exécuter avec des données pré-chargées.
Un jeu de dispute permet de résoudre les désaccords sur les résultats du programme d'exploitation. L'objectif est de réduire le désaccord au point exact de la trace de l'instruction. La résolution du jeu de litige repose sur l'identification de la première revendication incontestée, sur la base de laquelle la validité de la revendication racine peut être déterminée.
Le premier jeu de dispute qui sera intégré aux traces de dispute générées par Cannon et l'op-program est un jeu de Bisection (mais de nombreux autres jeux de dispute sont possibles !).
Nous sommes impatients de proposer une version alpha du système de preuve de défaillance sur le Testnet, afin que les développeurs de l'écosystème puissent tester et essayer de casser le MVP, et commencer à réfléchir à la construction de preuves de défaillance alternatives ou d'autres composants modulaires. 👀 👀 👀
C'est bien cela ! Le système à l'épreuve des pannes a été conçu pour mettre en évidence la puissance de la modularité de l'OP Stack. Ainsi, il est facile pour les créateurs d'écosystèmes de concevoir des composants à l'épreuve des pannes OP Stack personnalisés, des schémas de preuve aux machines virtuelles, et même des jeux de dispute uniques. En modularisant le programme à l'épreuve des fautes (FPP) et la machine virtuelle à l'épreuve des fautes (FPVM), il devient possible d'améliorer chaque composant en parallèle, ce qui accroît les performances et l'innovation du système. Nous espérons que cela contribuera à jeter les bases d'un écosystème dynamique de systèmes de preuve d'EVM à source ouverte.
Le système Fault Proof est essentiel pour permettre la décentralisation des protocoles. D'un point de vue technique, il permettra un pontage sécurisé sans solution de repli centralisée. En outre, son caractère open-source et sa norme de mise en œuvre minimale facilitent la mise en œuvre de multiples applications du protocole. Ces mises en œuvre multiples permettent d'assurer la sécurité et sont une condition préalable à l'atteinte de l'étape 2 de la décentralisation technique.
Mais au-delà de cela, le fait d'avoir des implémentations multiples maintenues par des membres distincts de la communauté est essentiel pour la décentralisation sociale. La décentralisation sociale est une stratégie sous-estimée, mais vitale pour toute blockchain. Plus il y a de clients, de mécanismes de preuve, de jeux de dispute et d'autres infrastructures construits et maintenus par différents contributeurs, plus le protocole est décentralisé. En faisant de la modularité un élément clé de la conception du système de preuve de faille, on multiplie les possibilités pour les développeurs du collectif de participer à la création et à la maintenance d’OP Mainnet et de la Superchain.
Un autre avantage de la conception modulaire des preuves est qu'elle crée une voie claire pour ajouter des preuves à connaissance nulle (ZKP) à l'OP Stack. La séparation entre FPP et FPVM signifie que le même programme opérationnel peut être exécuté à la fois dans un FPVM et dans un ZKVM. Ainsi, tant que les développeurs de ZKP ciblent une spécification de VM compatible, ils n'ont pas besoin de comprendre le fonctionnement interne du FPP.
De même, les développeurs qui optimisent le FPP n'ont pas besoin de comprendre le fonctionnement interne de la ZKVM. Cette réduction de la complexité et cette séparation des préoccupations sont la clé du développement rapide du ZKP par l'OP Stack. Suivez ce RFP pour des développements amusants de ZKP de l'OP Stack ! Ces ZKP de l'OP Stack permettront de réaliser des preuves de validité basées sur le ZK et d'alimenter des ponts à faible latence entre les chaînes. Ces ponts sont essentiels pour débloquer la composabilité de la Superchain et donc pour atteindre l'objectif d'une Superchain unifiée et interconnectée.
L'OP Stack est la clé pour garantir que l'infrastructure de la Superchain, y compris le Fault Proof System, est composable, polyvalente et à l'épreuve du temps. Le système à l'épreuve des pannes représente une étape majeure vers une Superchain plus décentralisée et plus efficace. Ce système permettra aux développeurs de personnaliser plus facilement leur travail et aux utilisateurs de l'écosystème de bénéficier d'une sécurité et de performances accrues.
Il n'est jamais trop tôt pour commencer à réfléchir à la manière dont vous pourriez contribuer à l'OP Stack et aider à sécuriser la Superchain. Le tableau de bord des contributions de l'écosystème Optimism est plein d'inspiration et de guides sur la façon de commencer à contribuer au collectif.
No activity yet