DEVS ON DEVS : Conversation entre TDOT et BEN JONES

Dans cet épisode spécial de la rubrique "Développeur à Développeur", nous avons invité tdot, développeur du protocole central de Plasma Mode (également développeur de Redstone), ainsi que Ben Jones, cofondateur d'Optimism. Optimism est le principal promoteur 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 se connecter de manière flexible à des fournisseurs de données off-chain, 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 raviver Plasma, de la nécessité d'introduire des protocoles expérimentaux dans l'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 du domaine des jeux sur blockchain.

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

Ben: Quel est le processus pour commencer à améliorer la pile OP ?

tdot: J'ai rejoint Lattice il y a environ un an, en charge 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à effectué quelques expérimentations sur l'OP Stack, comme le prototypage de certains mondes en ligne et leur déploiement sur l'OP Stack. Nous avons constaté que l'OP Stack est déjà très fonctionnel.

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ée 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, le calldata était toujours la source de disponibilité des données (DA) de la chaîne OP Stack, ce qui était très coûteux. Il était donc évident que nous ne pouvions pas utiliser le calldata pour lancer un L2, car notre jeu en chaîne complet 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 réalité, l'exploration d'Alt DA avait déjà été mentionnée dans la documentation initiale d'OP Stack.

Alors, nous nous sommes demandé : "Que se passerait-il si nous commencions avec un DA hors chaîne ?" Nous espérons que tout le modèle de sécurité et tout le reste pourra s'appuyer sur l'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 l'OP Stack existant ? Notre objectif est de modifier le moins possible l'OP Stack, sans impact sur le chemin des rollups, car nous ne voulons pas affecter la sécurité des autres chaînes de rollup utilisant l'OP Stack.

En concevant un rollup, vous ne vous demandez 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 un défi DA pour forcer 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ù des données seraient soumises sur la chaîne pendant la résolution du défi.

C'est là que se situe le cœur du problème. 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 nous essayons 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 parler du point de vue d'OP. Vous avez mentionné certains des travaux antérieurs de Lattice. Juste à ce moment-là, nous avons presque réécrit l'ensemble de l'OP Stack de manière de bout en bout, cette publication que nous appelons Bedrock.

En gros, après deux ans de construction de rollup, nous avons pris du recul et réfléchi : "Eh bien, si nous devions mettre à profit toutes les expériences que nous avons acquises, à quoi cela ressemblerait-il ?" Cela a évolué en ce qui est finalement devenu la bibliothèque de code 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 moment le plus amusant sur la chaîne. En même temps, nous avons aussi poussé un soupir de soulagement, car d'autres pouvaient également utiliser OP Stack pour le développement. Je pense qu'un autre tournant important pour 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 et complexes bibliothèques de code qui peuvent le faire. Quand nous avons commencé à collaborer, voir d'autres capables de prendre en main cette bibliothèque de code et de réaliser des choses vraiment impressionnantes est un grand encouragement. Puis 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 étions en fait en train d'étudier une technologie appelée Plasma. À l'époque, la tâche que nous avions à accomplir dépassait de loin la capacité de la communauté d'évolutivité de l'époque. Le design que vous voyez dans les premiers designs de Plasma n'a peut-être pas de relation directe avec le Plasma d'aujourd'hui.

Aujourd'hui, Plasma est beaucoup plus simple. Nous séparons les preuves et les défis de validation d'état des défis de données. En fin de compte, 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'évolutivité d'Ethereum à cette époque.

Mais nous avons toujours pensé que "Plasma n'est pas mort, il suffit que nous puissions 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, c'est incroyable de voir que non seulement OP Stack est utilisé par d'autres, mais qu'il a aussi évolué en quelque chose que nous avons initialement essayé de faire, mais de manière très confuse et immature. Nous avons déjà fait un tour complet, et vous avez fait d'excellentes abstractions autour d'eux, et les avez rendues fonctionnelles d'une manière raisonnable et sensée. C'est vraiment génial.

02. Le plus important est d'entrer rapidement en environnement de 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 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 développées sur MUD prêtes à être mises en ligne 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 mise en ligne rapidement et fonctionner pour exécuter toutes ces applications, afin que ces applications puissent se développer parallèlement tout en résolvant nos problèmes et en s'améliorant. Il faut beaucoup de temps, de la recherche et développement à la réalisation de la stabilité de production.

Pour mettre quelque chose en ligne sur la chaîne principale, afin qu'il soit sans autorisation, robuste et sécurisé, il faut passer beaucoup de temps. Le processus que nous avons suivi 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 évolue très rapidement. Je pense que tout le monde livre beaucoup d'innovations. C'est pourquoi vous devez suivre, mais vous ne pouvez pas faire de compromis sur la sécurité et la performance, sinon le système ne pourra pas fonctionner.

Ben : Ou plutôt un fardeau technique. Le principe du minimum de modifications que vous avez mentionné est l'un des concepts clés 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 déjà très puissant. Parce que vous avez raison, ces choses sont en effet très difficiles.

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

tdot : La pile OP a effectivement créé un moyen de progresser rapidement sur 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 et une chaîne.

Et vous construisez des centaines et des centaines de choses, en livrant régulièrement tous ces produits. Sur le plan de la coordination, ce n'est vraiment pas facile.

Ben: Oui, il y a encore un long chemin à parcourir. Mais c'est justement là que réside le véritable attrait de la modularité. Pour moi, d'un point de vue de l'OP Stack, c'est l'une des choses les plus excitantes, sans mentionner les jeux et les mondes virtuels incroyables qui sont déjà en cours de construction sur Redstone. Purement d'un 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 remarquable.

C'est la première fois que vous pouvez modifier de manière significative les propriétés du système grâce à une valeur booléenne clé. Pour y parvenir complètement, comme vous l'avez dit, il y a encore un long chemin à parcourir. Mais même approcher de manière efficace cela 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, pouvant être ajustés et modifié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 à l'idée d'avoir un fork contenant toutes les modifications apportées à l'OP Stack, qui devait être intégré dans la branche principale. À l'époque, nous pensions : "Mon dieu, il serait fou de devoir examiner tout ça."

Nous avons dû le décomposer en plus petites parties, mais l'ensemble du processus s'est déroulé très bien. L'ambiance de collaboration avec l'équipe était très bonne, 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 a été étonnamment fluide.

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 ne soient pas trop difficiles à gérer 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 ? Qu'attendez-vous le plus en termes de développement ?

tdot: Il existe de nombreuses directions de travail différentes. Principalement l'intégration avec le mécanisme 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 qu'il est parfois plus facile de ne pas aller sur le réseau principal, car cela évite d'avoir à effectuer un hard fork. Vous pourriez penser : "Oh, je peux juste attendre que tout soit complètement prêt avant de lancer, ainsi je n'aurai pas besoin de faire un hard fork et je n'aurai pas de charge technique." Cependant, si vous voulez mettre rapidement en ligne le réseau principal, vous devez traiter ces mises à niveau 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 de mises à niveau côté Plasma une fois que le mécanisme de preuve de panne et toutes ces parties seront prêtes. Je pense qu'il reste encore de la place pour optimiser la soumission en masse des engagements. Pour l'instant, nous faisons les choses de manière très simple, un engagement par transaction. Et l'engagement n'est que la valeur de hachage des données d'entrée stockées hors chaîne.

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

C'est quelque chose qui nous excite énormément. Bien sûr, nous attendons également avec impatience tout le contenu lié à l'interopérabilité à venir et la capacité 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, et