Ce post détaille les dernières mises à jour de la décentralisation de base - y compris les propositions de sortie sans permission, les améliorations du bridge, et les mises à jour des rôles permissionnés - ce qui permet la progression de l'OP Stack vers un avenir plus décentralisé.

Les ingénieurs d'OP Labs et les développeurs principaux du Collectif Optimism poursuivent un processus sécurisé et pragmatique de décentralisation technologique. Au cours du sommet Keys in Mordor, l'équipe a identifié plusieurs mises à jour de protocole permettant de faire progresser l'OP Stack dans le spectre de la décentralisation. Ces améliorations sont appelées « baseline decentralization » et les équipes ont travaillé dans ce sens au cours de l'année écoulée. Des progrès significatifs ont été réalisés et nous sommes impatients de partager les mises à jour qui nous rapprochent d'un avenir plus décentralisé.

La décentralisation de base est un projet qui se compose principalement de deux éléments clés. Le premier est la mise en œuvre de propositions de sortie sans permission, permettant aux utilisateurs de se retirer sans dépendre du séquenceur ou de toute autre infrastructure centralisée. Le second implique des changements au niveau du bridge, en particulier des mises à jour de protocole qui décentralisent la gestion des clés de mise à jour du bridge et permettent des propositions de sortie sans permission.

Les propositions de sortie sans permission (PoP) permettent aux utilisateurs de retirer des actifs de L2 vers L1 sans dépendre du séquenceur ou de toute autre infrastructure centralisée, sans permission. Toutefois, le Conseil de Sécurité disposera toujours de capacités d'annulation afin de gérer les bugs, y compris la possibilité de revenir à des propositions de sortie avec permission dans le pire des cas.

Avant les PoP, les propositions de sortie étaient fournies par le contrat L2OutputOracle, qui était réservé aux entités autorisées et ne pouvait être publié que par une adresse dédiée. Avec les PoP, n'importe qui peut créer une proposition de sortie en interagissant avec le contrat DisputeGameFactory. Proposer un résultat signifie créer et participer à un jeu de litige. Une proposition de sortie fait une réclamation sur l'état de L2. Une fois finalisée, cette revendication peut être utilisée pour faciliter les retraits. Avec les PoP, il peut y avoir plusieurs propositions de sortie, chacune correspondant à des jeux de litige distincts, faits par n'importe qui. Le jeu de litige détermine la validité des propositions de sortie. Pour décourager les propositions de sortie non valides, une sortie doit être cautionnée de telle sorte que l'auteur de la proposition ne soit remboursé que si la proposition est jugée valide. N'importe qui peut contester la validité d'une proposition de sortie en participant au jeu de litige qui lui est associé, avec la caution de la proposition comme récompense en cas de succès.

Les PoP seront compatibles avec les futurs protocoles de résolution des litiges, y compris ceux basés sur des preuves à connaissance nulle. Le DisputeGameFactory peut fonctionner avec plusieurs types de jeux, en exigeant seulement que le jeu expose une interface simple (IDisputeGame) pour communiquer l'état du jeu, les métadonnées et le résultat. L'implémentation actuelle (FaultDisputeGame) utilise un mécanisme interactif de preuve de faute, mais à l'avenir, une implémentation ZK pourrait être utilisée.

L'architecture existante du bridge comprenait des retraits en deux étapes, la rejouabilité des messages, une correspondance 1:1 entre les domaines, une preuve de stockage unique, des chemins de code similaires sur L1 et L2, et la compatibilité avec les jetons ETH, ERC20, et ERC721.

Le contrat de bridge OptimismPortal est mis à jour pour utiliser les jeux de litige. Les utilisateurs devront toujours confirmer l'inclusion des retraits dans une racine de sortie via la fonction proveWithdrawalTransaction. Cependant, les utilisateurs devront désormais prouver leurs retraits par rapport aux propositions stockées dans DisputeGameFactory au lieu du contrat L2OutputOracle.

 function proveWithdrawalTransaction(
     Types.WithdrawalTransaction memory _tx,
-    uint256 _l2OutputIndex,
+    uint256 _disputeGameIndex,
     Types.OutputRootProof calldata _outputRootProof,
     bytes[] calldata _withdrawalProof
 )

Le processus de finalisation des retraits dans le portail OptimismPortal amélioré est similaire au processus de bridge actuel. Tout d'abord, un retrait est prouvé au contrat OptimismPortal en montrant qu'il est inclus dans une proposition sur l'état de la L2 (et donc en l'associant également à un jeu de litige). Un retrait est finalisé s'il a attendu un certain temps et que le jeu de litige associé se résout en faveur de la proposition de sortie.

Le diagramme suivant résume le délai de finalisation d'un retrait.

Du point de vue de l'utilisateur, les changements lui permettent de soumettre une réclamation au L1 qu'il peut retirer, et un système de preuve modulaire peut contester ou valider cette réclamation. Une demande est valide s'il n'y a pas de contestation dans la fenêtre de preuve d'erreur ou, potentiellement à l'avenir, une validation instantanée lorsque l'OP Stack aura des preuves de validité. Le processus de soumission d'une réclamation nécessite une caution, ce qui signifie que les propositions sont mises en jeu. Les utilisateurs peuvent récupérer cette caution après la période de finalisation, à condition que la demande soit jugée valide. En d'autres termes, la revendication n'a pas été contestée ou a été attestée de manière probante.

Les changements introduits apportent certaines améliorations au bridge. Toutefois, la décentralisation n'est pas totale, car il existe certaines actions privilégiées que le Conseil de Sécurité est en mesure d'effectuer.

Le Conseil de Sécurité peut agir lorsqu'il y a un problème critique dans le système de litige, tel qu'un résultat de jeu invalide. Il a notamment la possibilité d'établir une liste noire des jeux de litige et d'inverser les propositions de sortie pour exiger un jeu de litige autorisé, où seul un ensemble d'acteurs autorisés aura la possibilité de participer à des jeux de litige.

Dans le cadre de la décentralisation du Conseil de Sécurité, un nouveau rôle Deputy Guardian a été introduit pour permettre à la Fondation de réagir rapidement en cas d'incident. Toutefois, le Gardien, détenu par le Conseil de Sécurité, peut retirer ce rôle en cas de besoin, de sorte que l'autorité ultime repose désormais sur le Conseil de Sécurité, plus décentralisé.

Les améliorations du bridge et les propositions de sortie sans permission sont déjà actives sur le testnet OP Sepolia et sont en attente de l'approbation de la gouvernance pour être déployées sur OP Mainnet, en même temps qu'une mise à jour des preuves de fautes. Les changements introduits dans ce flux de décentralisation de base reflètent notre approche stratégique et nos efforts continus pour atteindre notre feuille de route de décentralisation technologique à long terme.

Restez à l'écoute pour plus de mises à jour sur notre voyage vers un avenir plus décentralisé !

Ce post détaille les dernières mises à jour de la décentralisation de base - y compris les propositions de sortie sans permission, les améliorations du bridge, et les mises à jour des rôles permissionnés - ce qui permet la progression de l'OP Stack vers un avenir plus décentralisé.

Les ingénieurs d'OP Labs et les développeurs principaux du Collectif Optimism poursuivent un processus sécurisé et pragmatique de décentralisation technologique. Au cours du sommet Keys in Mordor, l'équipe a identifié plusieurs mises à jour de protocole permettant de faire progresser l'OP Stack dans le spectre de la décentralisation. Ces améliorations sont appelées « baseline decentralization » et les équipes ont travaillé dans ce sens au cours de l'année écoulée. Des progrès significatifs ont été réalisés et nous sommes impatients de partager les mises à jour qui nous rapprochent d'un avenir plus décentralisé.

La décentralisation de base est un projet qui se compose principalement de deux éléments clés. Le premier est la mise en œuvre de propositions de sortie sans permission, permettant aux utilisateurs de se retirer sans dépendre du séquenceur ou de toute autre infrastructure centralisée. Le second implique des changements au niveau du bridge, en particulier des mises à jour de protocole qui décentralisent la gestion des clés de mise à jour du bridge et permettent des propositions de sortie sans permission.

Les propositions de sortie sans permission (PoP) permettent aux utilisateurs de retirer des actifs de L2 vers L1 sans dépendre du séquenceur ou de toute autre infrastructure centralisée, sans permission. Toutefois, le Conseil de Sécurité disposera toujours de capacités d'annulation afin de gérer les bugs, y compris la possibilité de revenir à des propositions de sortie avec permission dans le pire des cas.

Avant les PoP, les propositions de sortie étaient fournies par le contrat L2OutputOracle, qui était réservé aux entités autorisées et ne pouvait être publié que par une adresse dédiée. Avec les PoP, n'importe qui peut créer une proposition de sortie en interagissant avec le contrat DisputeGameFactory. Proposer un résultat signifie créer et participer à un jeu de litige. Une proposition de sortie fait une réclamation sur l'état de L2. Une fois finalisée, cette revendication peut être utilisée pour faciliter les retraits. Avec les PoP, il peut y avoir plusieurs propositions de sortie, chacune correspondant à des jeux de litige distincts, faits par n'importe qui. Le jeu de litige détermine la validité des propositions de sortie. Pour décourager les propositions de sortie non valides, une sortie doit être cautionnée de telle sorte que l'auteur de la proposition ne soit remboursé que si la proposition est jugée valide. N'importe qui peut contester la validité d'une proposition de sortie en participant au jeu de litige qui lui est associé, avec la caution de la proposition comme récompense en cas de succès.

Les PoP seront compatibles avec les futurs protocoles de résolution des litiges, y compris ceux basés sur des preuves à connaissance nulle. Le DisputeGameFactory peut fonctionner avec plusieurs types de jeux, en exigeant seulement que le jeu expose une interface simple (IDisputeGame) pour communiquer l'état du jeu, les métadonnées et le résultat. L'implémentation actuelle (FaultDisputeGame) utilise un mécanisme interactif de preuve de faute, mais à l'avenir, une implémentation ZK pourrait être utilisée.

L'architecture existante du bridge comprenait des retraits en deux étapes, la rejouabilité des messages, une correspondance 1:1 entre les domaines, une preuve de stockage unique, des chemins de code similaires sur L1 et L2, et la compatibilité avec les jetons ETH, ERC20, et ERC721.

Le contrat de bridge OptimismPortal est mis à jour pour utiliser les jeux de litige. Les utilisateurs devront toujours confirmer l'inclusion des retraits dans une racine de sortie via la fonction proveWithdrawalTransaction. Cependant, les utilisateurs devront désormais prouver leurs retraits par rapport aux propositions stockées dans DisputeGameFactory au lieu du contrat L2OutputOracle.

 function proveWithdrawalTransaction(
     Types.WithdrawalTransaction memory _tx,
-    uint256 _l2OutputIndex,
+    uint256 _disputeGameIndex,
     Types.OutputRootProof calldata _outputRootProof,
     bytes[] calldata _withdrawalProof
 )

Le processus de finalisation des retraits dans le portail OptimismPortal amélioré est similaire au processus de bridge actuel. Tout d'abord, un retrait est prouvé au contrat OptimismPortal en montrant qu'il est inclus dans une proposition sur l'état de la L2 (et donc en l'associant également à un jeu de litige). Un retrait est finalisé s'il a attendu un certain temps et que le jeu de litige associé se résout en faveur de la proposition de sortie.

Le diagramme suivant résume le délai de finalisation d'un retrait.

Du point de vue de l'utilisateur, les changements lui permettent de soumettre une réclamation au L1 qu'il peut retirer, et un système de preuve modulaire peut contester ou valider cette réclamation. Une demande est valide s'il n'y a pas de contestation dans la fenêtre de preuve d'erreur ou, potentiellement à l'avenir, une validation instantanée lorsque l'OP Stack aura des preuves de validité. Le processus de soumission d'une réclamation nécessite une caution, ce qui signifie que les propositions sont mises en jeu. Les utilisateurs peuvent récupérer cette caution après la période de finalisation, à condition que la demande soit jugée valide. En d'autres termes, la revendication n'a pas été contestée ou a été attestée de manière probante.

Les changements introduits apportent certaines améliorations au bridge. Toutefois, la décentralisation n'est pas totale, car il existe certaines actions privilégiées que le Conseil de Sécurité est en mesure d'effectuer.

Le Conseil de Sécurité peut agir lorsqu'il y a un problème critique dans le système de litige, tel qu'un résultat de jeu invalide. Il a notamment la possibilité d'établir une liste noire des jeux de litige et d'inverser les propositions de sortie pour exiger un jeu de litige autorisé, où seul un ensemble d'acteurs autorisés aura la possibilité de participer à des jeux de litige.

Dans le cadre de la décentralisation du Conseil de Sécurité, un nouveau rôle Deputy Guardian a été introduit pour permettre à la Fondation de réagir rapidement en cas d'incident. Toutefois, le Gardien, détenu par le Conseil de Sécurité, peut retirer ce rôle en cas de besoin, de sorte que l'autorité ultime repose désormais sur le Conseil de Sécurité, plus décentralisé.

Les améliorations du bridge et les propositions de sortie sans permission sont déjà actives sur le testnet OP Sepolia et sont en attente de l'approbation de la gouvernance pour être déployées sur OP Mainnet, en même temps qu'une mise à jour des preuves de fautes. Les changements introduits dans ce flux de décentralisation de base reflètent notre approche stratégique et nos efforts continus pour atteindre notre feuille de route de décentralisation technologique à long terme.

Restez à l'écoute pour plus de mises à jour sur notre voyage vers un avenir plus décentralisé !