DEVS ON DEVS : Conversation entre TDOT et BEN JONES

Dans cet épisode spécial de Devs on Devs, nous avons invité le développeur principal du protocole Plasma Mode, tdot(, également développeur de Redstone, ), ainsi que Ben Jones, co-fondateur 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 à publier de données sur L1, mais en pouvant 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é. 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 leurs attentes concernant le développement dans le domaine des jeux sur blockchain.

01. Comment améliorer OP Stack en utilisant le mode Plasma

Ben: Comment se déroule le processus d'amélioration de la pile OP ?

tdot: J'ai rejoint Lattice il y a environ un an, en étant spécifiquement responsable du Plasma Mode. L'objectif est 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 supporte à la fois ces besoins et qui soit bon marché. 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 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ée d'Ethereum et entièrement compatible avec l'EVM." Ce qui fonctionne sur la chaîne principale peut également fonctionner sur l'OP Stack, c'est la solution idéale. Mais nous espérons que ce sera moins cher.

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

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 pourra s'appuyer sur 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 voulons 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 implémenter le DA hors chaîne et les défis de données sur chaîne sur la pile OP existante ? Notre objectif est de modifier le moins possible la pile OP, sans aucun impact sur le chemin des rollups, car nous ne voulons pas affecter 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 des 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 sa sortie de la boîte. C'est notre première modification.

Ensuite, nous devons rédiger des contrats pour créer ces défis. Il existe des défis DA pour forcer les données à être mises sur la chaîne. C'est la deuxième étape, qui consiste à 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ù les données seraient soumises sur la chaîne pendant la résolution du défi.

C'est là que se situe l'essentiel. 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 plutôt 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 initiaux de Lattice. Juste à ce moment-là, nous avons presque réécrit l'ensemble de la pile OP de bout en bout chez Optimism, et cette version que nous avons publiée s'appelle Bedrock.

Fondamentalement, après deux ans de construction de rollup, nous avons pris du recul et réfléchi en disant : "Eh bien, si nous devions appliquer toutes les expériences acquises au maximum, à 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.

À cette époque, nous avons collaboré avec vous sur un projet appelé OPCraft, et je pense que Biomes est son 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 dans l'évolutivité au cours des dernières années est que beaucoup de personnes 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 personnes capables de reprendre cette bibliothèque de code et de faire des choses vraiment incroyables est une grande validation. Puis voir cette situation s'étendre à Plasma dans des applications réelles, c'est vraiment génial. Je peux même parler un peu de cette histoire.

Avant qu'Optimism ne devienne Optimism, nous avons en fait étudié une technologie appelée Plasma. À l'époque, la tâche que nous avions à accomplir dépassait de loin la capacité de la communauté d'extension à l'époque. Ce que vous voyez dans les conceptions initiales de Plasma peut ne pas avoir de correspondance directe avec le Plasma d'aujourd'hui.

Aujourd'hui, le Plasma est beaucoup plus simple. Nous séparons les preuves et les défis de la validation d'état des défis de données. Au final, 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 "Plasma est mort". C'est un mème de l'histoire de l'extension 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 les sorties(, 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 évoluer en quelque chose que nous avons essayé à l'origine mais d'une manière très confuse et immature, est vraiment incroyable. Nous avons complété un cycle complet, vous avez fait de superbes abstractions autour d'eux et les avez fait fonctionner d'une manière raisonnable et logique. C'est vraiment cool.

02. Le plus important est d'entrer rapidement dans l'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 passer jusqu'à dix ans ? Tu comprends ce que je veux dire ? Nous devons atteindre le stade où nous pouvons livrer des résultats dès que possible.

C'est notre idée. Nous avons déjà de nombreuses applications développées sur MUD prêtes à être lancées immédiatement 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 et s'améliorer pendant que nous résolvons les problèmes. Il faut beaucoup de temps pour passer de la recherche et développement à la réalisation d'une stabilité en production.

Pour mettre quelque chose en ligne sur le mainnet, de manière décentralisée, robuste et sécurisée, cela nécessite 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 évolue très rapidement. Je pense que tout le monde livre beaucoup d'innovations. C'est pourquoi vous devez suivre le rythme, mais vous ne pouvez pas 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 de changement minimum 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 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 tests en conditions réelles plus difficiles et introduisant plus d'opportunités d'erreurs. Nous vous remercions donc pour tous vos efforts dans ce processus, en particulier pour votre contribution au nouveau mode opératoire de l'OP Stack.

tdot: La pile OP a effectivement créé un moyen de vous permettre d'avancer 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, 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 vraiment très difficile.

Ben: Oui, il y a encore beaucoup de chemin à parcourir. Mais c'est justement là que réside le principal attrait 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 tous ces jeux et mondes virtuels incroyables 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 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é. Pour y parvenir complètement, comme vous l'avez dit, il reste effectivement beaucoup de chemin à parcourir. Mais même s'il s'agit de s'en approcher efficacement, cela nécessite un soutien modulaire, n'est-ce pas ? Pour nous, il est rassurant de voir que vous avez réalisé cela sans avoir besoin, par exemple, de réécrire L2 Geth. 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 modifiés. Je suis donc très impatient 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 un fork, contenant tous les changements apportés à l'OP Stack, qui devait être fusionné dans la branche principale. À l'époque, nous pensions : "Mon Dieu, passer en revue 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'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. 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 passé de manière étonnamment fluide.

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 beaucoup de participer aux tests et de faire avancer ces processus. Je suis content que ces processus ne soient pas devenus écrasants et que nous ayons obtenu certains résultats. À ce propos, je suis curieux de savoir, de votre point de vue, comment ce travail va évoluer ensuite ? Qu'attendez-vous le plus en termes de développement ?

tdot : Il existe de nombreuses directions de travail différentes. Principalement en 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 permission, l'objectif final étant de réaliser des fonctions telles que l'absence de permission et le retrait forcé.

Nous avons cet objectif ultime et nous l'atteignons progressivement tout en maintenant la sécurité. Un défi est que, parfois, ne pas aller sur le réseau principal est plus facile, car cela évite les hard forks. Vous pourriez penser : "Oh, je vais juste attendre que tout soit complètement prêt avant de lancer, ainsi il n'y a pas besoin de hard fork et pas de charge technique." Cependant, si vous souhaitez mettre rapidement en ligne le réseau principal, vous devez gérer 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 d'améliorations du côté 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 certaines optimisations en matière de soumission en masse des engagements. Actuellement, nous le faisons de manière 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 l'examen puisse être simple et rapide, et qu'il n'y ait pas de grandes différences avec l'OP Stack. Cependant, il existe maintenant certaines optimisations qui peuvent le rendre moins coûteux, comme le traitement par lots des engagements ou leur soumission dans un blob, ou l'adoption 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 beaucoup. Bien sûr, nous attendons également avec impatience tout le contenu lié à l'interopérabilité à venir et la possibilité d'interagir entre toutes les chaînes. Comprendre cela sera une avancée énorme pour les utilisateurs.

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

Ben: En parlant de cela, ce sera pour OP Stack