DEVS ON DEVS : Conversation avec tdot et Ben Jones

"Dans ce numéro spécial de Devs on Devs, nous avons invité tdot(, le développeur principal du protocole de Plasma Mode, ainsi que le développeur de Redstone ), et Ben Jones, le cofondateur d'Optimism. Optimism est le principal moteur de l'OP Stack. Plasma Mode permet aux développeurs de construire sur l'OP Stack sans avoir besoin de publier des données sur L1, mais peut plutôt passer de manière flexible à des fournisseurs de données hors chaîne, ce qui permet d'économiser des coûts et d'améliorer l'évolutivité. Au cours de la conversation, ils ont exploré l'origine de la collaboration entre Redstone et Optimism, l'importance de raviver Plasma, la nécessité d'introduire des protocoles expérimentaux dans l'environnement de production, la feuille de route future de Plasma Mode et de l'OP Stack, ainsi que leur enthousiasme pour le développement du domaine des jeux sur blockchain."

Comment améliorer OP Stack avec le mode Plasma

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, en étant spécifiquement responsable du Plasma Mode. L'objectif est très clair : nous avons de nombreuses applications MUD qui consomment beaucoup de gas, tout en essayant de mettre une grande quantité de données sur la chaîne, donc nous avons besoin d'une solution qui soutienne ces besoins tout en étant économique. L'équipe de Lattice a déjà réalisé quelques expérimentations sur l'OP Stack, comme le prototypage de certains mondes on-chain et leur déploiement sur l'OP Stack. Nous avons constaté que l'OP Stack est déjà très efficace.

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 le plus conforme à l'idéologie d'Ethereum et entièrement compatible avec l'EVM." Tout ce qui fonctionne sur le mainnet peut également fonctionner sur l'OP Stack, c'est la solution idéale. Mais nous souhaitons que ce soit moins cher.

À l'époque, les calldata étaient encore la source de disponibilité des données de la chaîne OP Stack (DA), ce qui était très coûteux. Donc, il était clairement impossible de lancer un L2 avec des calldata, car notre jeu de chaîne complète et notre monde MUD nécessitaient 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é d'explorer Alt DA dans la documentation initiale d'OP Stack.

Alors nous nous sommes 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 puisse s'appuyer sur Ethereum L1. C'est pourquoi nous avons évité d'autres solutions Alt DA et 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 placer au-dessus des rollups. Il y a quelques différences ici. La plus grande question est : comment réaliser un DA hors chaîne et des défis de données en chaîne sur la pile OP existante ? Notre objectif est de modifier le moins possible la pile OP, sans affecter le chemin des rollups, car nous ne voulons pas compromettre la sécurité des autres chaînes de rollup utilisant la pile OP.

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

Ensuite, nous devons rédiger des contrats pour créer ces défis. Il existe des défis DA qui forcent la mise en chaîne des données. C'est la deuxième étape, intégrer le contrat dans le processus. Nous devons construire l'ensemble du 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ù les données seraient soumises à la chaîne pendant la résolution du défi.

Voici le cœur du problème. C'est compliqué, 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 l'ensemble de la pile OP, mais nous avons essayé de garder les choses simples dans un environnement complexe. Donc, dans l'ensemble, c'est un très cool voyage d'ingénierie.

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

Fondamentalement, après deux ans de construction de rollup, nous avons fait un pas en arrière et réfléchi en disant : "Eh bien, si nous devions tirer parti de toutes les leçons apprises au maximum, à quoi cela ressemblerait-il ?" Cela a évolué en ce qui est finalement devenu le référentiel appelé Bedrock, qui représente notre plus grande mise à niveau du réseau.

À cette époque, nous avons collaboré avec vous sur un projet appelé OPCraft, je pense que Biomes en est l'héritier spirituel, c'est la fois où nous nous sommes le plus amusés sur la chaîne. En même temps, nous avons également poussé un soupir de soulagement, car d'autres peuvent également utiliser OP Stack pour le développement. Je pense qu'un autre tournant important de l'évolutivité 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é de vastes bibliothèques de code complexes qui peuvent le faire. Quand nous avons commencé à collaborer, voir d'autres prendre en charge cette bibliothèque de code et réaliser des choses vraiment incroyables est une grande validation. Puis voir cette situation s'étendre dans la pratique à Plasma, c'est vraiment génial. Je peux même parler un peu de cette histoire.

Avant qu'Optimism ne devienne Optimism, nous étudiions en réalité une technologie appelée Plasma. À l'époque, la tâche que nous avions à accomplir dépassait de loin la capacité de la communauté à évoluer. Ce que vous voyez dans les conceptions initiales de Plasma n'a peut-être pas de lien direct avec le Plasma d'aujourd'hui.

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

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 les sorties (exits), et 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, voir non seulement l'OP Stack utilisé par d'autres, mais aussi évolué en quelque chose que nous avons initialement essayé de faire d'une manière très désordonnée et immature, est vraiment incroyable. Nous avons accompli un cycle complet, et vous avez créé d'excellentes abstractions autour de cela, en les rendant fonctionnelles d'une manière raisonnable et sensée. C'est vraiment génial.

Il est surtout important d'entrer rapidement en production

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

C'est notre idée. Nous avons déjà de nombreuses applications basées sur MUD prêtes à être lancées sur la blockchain principale. Nous avons besoin de préparer une blockchain principale 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 mise en ligne rapidement et qui fonctionne, pour exécuter toutes ces applications, afin qu'elles puissent se développer parallèlement tout en résolvant nos problèmes et devenir meilleures. Il faut beaucoup de temps pour passer de la recherche et du développement à la stabilité en production.

Pour mettre quelque chose en ligne sur le réseau principal, de manière à ce qu'il soit sans autorisation, robuste et sécurisé, 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 quantité considérable d'innovations. C'est pourquoi vous devez suivre le rythme, mais vous ne pouvez pas non plus faire de compromis sur la sécurité et la performance, sinon le système ne pourra pas fonctionner.

Ben : Ou plutôt, c'est un fardeau technique. Le principe de la moindre intervention que vous mentionnez est l'un des concepts clés lors de la 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 supplémentaire vous éloigne de l'environnement de production, rendant les choses plus difficiles à tester en conditions réelles et introduisant davantage d'opportunités d'erreurs. C'est pourquoi nous vous remercions sincèrement pour tous vos efforts dans ce processus, en particulier pour vos contributions au nouveau mode d'opération d'OP Stack.

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

Et vous construisez des centaines de choses, en livrant régulièrement tous ces produits. En termes de coordination, cela n'est vraiment pas facile.

Ben: Oui, il reste effectivement encore beaucoup de 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 passionnantes, sans même mentionner les incroyables jeux et mondes virtuels qui sont en cours de construction sur Redstone. Purement du point de vue de l'OP Stack, c'est un exemple très puissant qui prouve que de nombreux excellents développeurs principaux 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 grâce à une valeur booléenne clé. Pouvoir le faire complètement, comme vous l'avez dit, il y a encore beaucoup de chemin à parcourir. Mais même s'il s'agit de s'en approcher efficacement, cela nécessite un support 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 un véritable 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, pouvant être ajustés et modifier leurs propriétés. J'attends donc avec impatience de voir quelles nouvelles fonctionnalités seront intégrées. Je me souviens que nous étions préoccupés par le fait que nous avions une branche contenant tous les changements apportés à l'OP Stack, qui devait être fusionnée dans la branche principale. À l'époque, nous nous disions : "Mon dieu, il serait fou de devoir examiner tout ça."

Nous avons dû le décomposer en parties plus petites, mais tout le processus s'est déroulé très bien. L'atmosphère de collaboration avec l'équipe est très bonne, donc le processus de révision a également été agréable. Cela semblait très naturel. Et 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 passé de manière surprenante.

Ben: C'est vraiment génial. Cette année, l'un de nos objectifs est de créer des voies de contribution pour OP Stack. Je vous remercie donc d'avoir participé aux tests et d'avoir fait avancer ces processus. Je suis heureux que ces processus ne soient pas insupportables et que nous ayons obtenu certains résultats. À ce sujet, je suis curieux de savoir, de votre point de vue, comment ce travail va évoluer ensuite ? Qu'attendez-vous avec le plus d'impatience dans le développement à venir ?

tdot : Il existe de nombreuses directions de travail différentes. Principalement liées à l'intégration des mécanismes de preuve de panne. 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 sans autorisation et la sortie forcée.

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 passer en mainnet peut être plus facile, car cela évite d'avoir à faire un hard fork. Vous pourriez penser : "Oh, je peux simplement attendre que tout soit complètement prêt avant de lancer, ainsi je n'aurai pas besoin de faire un hard fork, ni d'avoir un fardeau technique." Cependant, si vous souhaitez mettre rapidement en ligne le mainnet, vous devez gérer ces mises à niveau complexes et publier fréquemment. Réaliser cela tout en maintenant une haute disponibilité est toujours un défi.

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

Nous restons temporairement aussi simples que possible, afin que l'examen puisse être simple et rapide, et qu'il n'y ait pas de grande différence avec l'OP Stack. Cependant, il existe maintenant quelques optimisations qui peuvent le rendre moins coûteux, comme le traitement par lots des engagements ou leur soumission dans un blob, ou en utilisant d'autres méthodes différentes. Nous allons donc certainement étudier cela pour réduire les coûts de L1.

C'est une 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 une avancée énorme pour les utilisateurs.

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

Ben: À ce propos, ce sera une autre épreuve pour la modularité du module OP Stack. Vous avez mentionné