Interview avec les développeurs d'Optimism et de Redstone : Le mode Plasma redessine Layer 2

Dans cette édition spéciale de l'interview, nous avons invité le développeur principal du protocole Plasma Mode tdot( ainsi que le développeur de Redstone ), et le co-fondateur d'Optimism Ben Jones. Optimism est le principal moteur de l'OP Stack. Plasma Mode permet aux développeurs de construire sur l'OP Stack sans avoir à publier des données sur L1, mais plutôt de basculer de manière flexible vers des fournisseurs de données hors chaîne, ce qui permet d'économiser des coûts et d'améliorer l'évolutivité. Dans cette conversation, ils ont discuté des origines de la collaboration entre Redstone et Optimism, de l'importance de revitaliser Plasma, de la nécessité d'introduire des protocoles expérimentaux dans un environnement de production, de la feuille de route future de Plasma Mode et de l'OP Stack, ainsi que de leur enthousiasme pour le développement dans le domaine des jeux sur la chaîne.

01. Comment utiliser le mode Plasma pour améliorer OP Stack

Ben: Comment se déroule le processus d'amélioration de l'OP Stack?

tdot: J'ai rejoint Lattice il y a environ un an, responsable du mode Plasma. L'objectif est très clair : nous avons de nombreuses applications MUD qui consomment beaucoup de gas, et en même temps, nous essayons de mettre beaucoup de données sur la chaîne, donc nous avons besoin d'une solution qui supporte à la fois ces exigences et qui soit peu coûteuse. L'équipe de Lattice a déjà fait quelques expérimentations sur OP Stack, comme le prototypage de certains mondes en ligne et leur déploiement sur OP Stack. Nous avons constaté qu'OP Stack est déjà très utile.

Alors nous nous sommes demandé : "Comment pouvons-nous le rendre moins cher ?" L'hypothèse de base est : "Nous pensons que l'OP Stack est le cadre qui correspond le mieux à l'idéologie d'Ethereum et qui est entièrement compatible avec l'EVM." Ce qui fonctionne sur le réseau principal peut également fonctionner sur l'OP Stack, c'est la solution idéale. Mais nous voulons que ce soit moins cher.

À l'époque, calldata était encore la source de disponibilité des données de la chaîne OP Stack (DA), ce qui était très coûteux. Nous ne pouvions donc clairement pas démarrer un L2 avec calldata, car notre jeu complet sur chaîne et le monde MUD nécessitent un débit plus élevé. Par conséquent, nous avons décidé de commencer à explorer d'autres solutions de disponibilité des données (Alt DA). En fait, il a déjà été mentionné dans la documentation initiale d'OP Stack qu'il fallait explorer Alt DA.

Nous nous sommes donc demandé : "Que se passerait-il si nous commencions par un DA hors chaîne ?" Nous espérons que tout le modèle de sécurité et tout le reste peuvent dépendre de l'Ethereum L1. Par conséquent, nous avons évité d'autres solutions Alt DA et avons décidé de stocker les données dans un stockage DA centralisé, puis de trouver un modèle de sécurité efficace sur L1.

C'est pourquoi nous devons réutiliser certains anciens concepts de Plasma et les mettre au-dessus de rollup. Il y a quelques différences ici. La plus grande question est : comment implémenter la DA hors chaîne et le défi de données en chaîne sur la pile OP existante ? Notre objectif est de modifier le moins possible la pile OP, sans aucune influence sur le chemin de rollup, car nous ne voulons pas affecter la sécurité des autres chaînes de rollup utilisant la pile OP.

Lors de la conception des rollups, vous ne vous demandez pas : "Que se passerait-il si quelqu'un modifiait le processus de génération des données pour stocker les données ailleurs ?" Même avec ces modifications, l'OP Stack reste très puissant et fonctionne très bien dès sa sortie de la boîte. C'est le premier changement que nous avons apporté.

Ensuite, nous devons rédiger un contrat pour créer ces défis. Il y a des défis DA qui forcent les données à être mises en chaîne. C'est la deuxième étape, intégrer le contrat dans le processus. Nous devons construire tout le système d'intégration dans le processus de dérivation, afin que vous puissiez dériver des données à partir d'une source DA hors chaîne ainsi que d'un contrat de défi DA L1, au cas où des données seraient soumises sur la chaîne pendant le processus de résolution du défi.

Voici l'essentiel de la question. C'est complexe, car nous voulons garder les choses élégantes et robustes. En même temps, c'est un concept relativement simple. Nous n'avons pas essayé de réinventer la roue ou de changer complètement l'OP Stack, mais plutôt d'essayer de garder les choses simples dans un environnement complexe. Donc, dans l'ensemble, c'est un voyage d'ingénierie vraiment cool.

Ben: Je peux en parler du point de vue d'OP. Vous avez mentionné certains travaux préliminaires de Lattice. Juste à ce moment-là, nous chez Optimism avons presque réécrit l'ensemble de la pile OP de bout en bout, et nous appelons cette publication Bedrock.

En gros, après deux ans de construction de rollup, nous prenons du recul et réfléchissons en disant : "Eh bien, si nous devions tirer le meilleur parti de toutes les expériences que nous avons acquises, à quoi cela ressemblerait-il ?" Cela a évolué en la bibliothèque de code qui a finalement été appelée Bedrock, qui est notre plus grande mise à niveau du réseau.

À ce moment-là, nous avons collaboré avec vous sur un projet appelé OPCraft, je pense que Biomes en est l'héritier spirituel, c'était notre expérience de jeu la plus agréable sur la chaîne. En même temps, nous avons aussi poussé un soupir de soulagement, car d'autres peuvent également utiliser OP Stack pour le développement. Je pense qu'un autre tournant important pour l'extension au cours des dernières années est que beaucoup de gens peuvent faire fonctionner la chaîne.

Ce n'est pas seulement ceux qui ont développé d'énormes et complexes bibliothèques de code qui peuvent le faire. Quand nous avons commencé à collaborer, voir d'autres prendre en charge cette bibliothèque de code et faire des choses vraiment incroyables est une grande affirmation. Ensuite, voir cette situation s'étendre à Plasma dans des applications réelles est vraiment génial. Je peux même parler un peu de cette histoire.

Avant qu'Optimism ne devienne Optimism, nous étudiions en fait une technologie appelée Plasma. À l'époque, la tâche qui nous incombait dépassait de loin la capacité de la communauté à évoluer. Le design que vous voyez dans les premières conceptions de Plasma peut ne pas avoir de correspondance directe avec le Plasma d'aujourd'hui.

Aujourd'hui, le Plasma est beaucoup plus simple. Nous distinguons la preuve et le défi de la validation d'état des défis de données. Finalement, nous avons réalisé il y a quelques années que les Rollups sont beaucoup plus simples que le Plasma. Je pense qu'à l'époque, la conclusion de la communauté était "le Plasma est mort". C'est un mème de l'histoire de l'évolutivité d'Ethereum à cette époque.

Mais nous avons toujours pensé que "Plasma n'est pas mort, c'est juste que nous pouvons d'abord essayer une tâche plus simple". Maintenant, nous utilisons des termes différents. Par exemple, à l'époque, il y avait des concepts comme (exits), maintenant vous pouvez revenir en arrière et dire "oh, c'était un défi de disponibilité des données avec quelques étapes supplémentaires". Donc, il est vraiment incroyable de voir non seulement l'OP Stack utilisé par d'autres, mais aussi évolué vers ce que nous avons essayé à l'origine mais d'une manière très confuse et immature. Nous avons déjà terminé un cycle complet, vous avez fait de superbes abstractions autour d'eux et les avez fait fonctionner d'une manière raisonnable et sensée. C'est vraiment cool.

02. Le plus important est d'entrer en production le plus rapidement possible

tdot : Le mode Plasma présente encore certains défis et problèmes non résolus, et nous travaillons encore à les résoudre. La clé est de savoir comment éviter de perdre jusqu'à dix ans ? Tu comprends ce que je veux dire ? Nous devons atteindre le stade où nous pouvons livrer des résultats le plus rapidement possible.

C'est notre idée. Nous avons déjà de nombreuses applications basées sur MUD prêtes à être lancées sur le mainnet. Nous avons besoin de préparer un mainnet pour ces jeux le plus rapidement possible. Les gens attendent déjà et sont prêts. Vous avez besoin d'une chaîne qui puisse être lancée rapidement et fonctionner pour exécuter toutes ces applications, afin que ces applications puissent se développer en parallèle et s'améliorer pendant que nous résolvons les problèmes. Passer de la recherche et développement à la réalisation d'une stabilité de production prend beaucoup de temps.

Pour lancer quelque chose sur le mainnet, de manière sans autorisation, robuste et sécurisée, il faut consacrer beaucoup de temps. Voir tout le processus que nous avons réalisé pour atteindre cet objectif est déjà impressionnant. C'est pourquoi nous devons rester très agiles, car il y a trop de choses. L'ensemble de l'écosystème se développe très rapidement. Je pense que tout le monde livre une grande quantité d'innovations. C'est pourquoi vous devez rester à jour, mais vous ne pouvez pas non plus faire de compromis sur la sécurité et la performance, sinon le système ne fonctionnera pas.

Ben: Ou plutôt un fardeau technique. Le principe du moindre changement que vous avez mentionné est l'un des concepts fondamentaux de notre réécriture de Bedrock. J'ai parlé de la réécriture complète de bout en bout, mais plus important encore, nous avons réduit d'environ 50 000 lignes de code, ce qui est en soi très puissant. Parce que vous avez raison, ces choses sont en effet très difficiles.

Chaque ligne de code ajoutée vous éloigne de l'environnement de production, rendant les choses plus difficiles à tester en conditions réelles et introduisant plus d'opportunités d'erreurs. Nous vous remercions donc pour tous vos efforts dans la promotion de ce processus, en particulier pour vos contributions au nouveau mode de fonctionnement de l'OP Stack.

tdot: La pile OP a effectivement créé un moyen de faire avancer rapidement ce genre de choses. Coordonner tout le monde est très difficile, car nous sommes manifestement deux entreprises différentes. Chez Lattice, nous construisons un jeu, un moteur de jeu, ainsi qu'une chaîne.

Et vous construisez des centaines et des milliers de choses, tout en livrant régulièrement tous ces produits. En termes de coordination, c'est en effet très difficile.

Ben: Oui, il y a encore un long chemin à parcourir. Mais c'est justement là que réside le charme essentiel de la modularité. Pour moi, du point de vue de l'OP Stack, c'est l'une des choses les plus excitantes, sans même mentionner les incroyables jeux et mondes virtuels en cours de construction sur Redstone. Purement du point de vue de l'OP Stack, c'est un exemple très puissant, prouvant que de nombreux excellents développeurs de base ont rejoint et amélioré cette pile, ce qui est vraiment remarquable.

C'est la première fois, vous pouvez changer de manière significative les propriétés du système avec une valeur booléenne clé. Être capable de le faire complètement, comme vous l'avez dit, il y a encore beaucoup de chemin à parcourir. Mais même se rapprocher de le faire efficacement nécessite un soutien modulaire, n'est-ce pas ? Pour nous, voir que vous avez réalisé cela sans avoir besoin par exemple de réécrire L2 Geth est vraiment un soulagement. Pour moi, cela prouve que la modularité fonctionne.

tdot: La situation s'est maintenant améliorée. D'après cet exemple, vous avez transformé tout en petits modules indépendants, qui peuvent être ajustés et modifier des attributs. J'attends donc avec impatience de voir quelles nouvelles fonctionnalités seront intégrées. Je me souviens que nous étions inquiets à l'époque, car nous avions un fork contenant tous les changements apportés à l'OP Stack, qu'il fallait fusionner dans la branche principale. Nous pensions alors : "Mon dieu, réviser tout cela serait fou."

Nous avons dû le décomposer en parties plus petites, mais tout le processus s'est déroulé très bien. L'ambiance de collaboration avec l'équipe était très agréable, donc le processus de révision a également été agréable. Cela semblait très naturel. De plus, je pense que le processus s'est déroulé très rapidement en ce qui concerne la révision et la résolution de certains problèmes potentiels. Tout s'est déroulé de manière inattendue sans accroc.

Ben: C'est vraiment super. Cette année, l'un de nos objectifs est de créer un chemin de contribution pour OP Stack. Je vous remercie donc beaucoup de participer aux tests et de faire avancer ces processus. Je suis heureux que ces processus n'aient pas été trop difficiles à gérer et que nous ayons réalisé certains résultats. À ce propos, je suis très curieux de savoir comment, de votre point de vue, ce travail va évoluer par la suite ? Qu'attendez-vous le plus en termes de développement ?

tdot: Il existe de nombreuses directions de travail différentes. Principalement, il s'agit de l'intégration des mécanismes de preuve de défaillance. Nous adoptons une approche progressive pour décentraliser l'ensemble de la pile technologique et augmenter ses caractéristiques sans autorisation, l'objectif final étant de réaliser des fonctionnalités telles que l'absence de permission et le retrait forcé.

Nous avons cet objectif ultime et nous le réalisons progressivement tout en maintenant la sécurité. Un défi est que, parfois, ne pas se connecter au réseau principal est plus facile, car cela évite d'avoir à effectuer des forks. Vous pourriez penser : "Oh, je peux juste attendre que tout soit complètement prêt avant de publier, cela évitera d'avoir à effectuer des forks et il n'y aura pas de charge technique." Cependant, si vous voulez mettre rapidement le réseau principal en ligne, vous devez gérer ces mises à jour complexes et publier fréquemment. Faire cela tout en maintenant une haute disponibilité est toujours un défi.

Je pense qu'il y aura beaucoup d'améliorations du côté du modèle Plasma une fois que le mécanisme de preuve de défaillance et toutes ces parties seront prêtes. Je pense qu'il y a encore de la place pour optimiser l'engagement de soumission en masse. Pour l'instant, nous faisons très simple, un engagement par transaction. Et l'engagement est simplement la valeur de hachage des données d'entrée stockées hors chaîne.

Nous restons pour l'instant aussi simples que possible, afin que la révision puisse être simple et rapide, et qu'il n'y ait pas de grande différence avec OP Stack. Mais maintenant, il y a certaines optimisations qui peuvent rendre cela moins cher, comme le traitement par lots des engagements ou les soumettre dans un blob, ou d'autres méthodes différentes. Donc, nous allons certainement étudier cela pour réduire les coûts de L1.

C'est quelque chose qui nous excite beaucoup. Bien sûr, nous attendons également avec impatience tout le contenu lié à l'interopérabilité à venir, et d'être en mesure d'interagir entre toutes les chaînes. Comprendre cela sera un énorme progrès pour les utilisateurs.

Beaucoup de ces travaux devront certainement être réalisés par vous. Mais nous espérons comprendre à quoi cela ressemble dans le mode Plasma, avec différentes hypothèses de sécurité.

Ben: En parlant de cela, ceci