DEVS ON DEVS : Conversation entre TDOT et BEN JONES

Dans ce numéro spécial de Devs on Devs, nous avons invité le développeur principal du protocole Plasma Mode, tdot(, qui est également le développeur de Redstone ), et Ben Jones, co-fondateur 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 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 revigorer Plasma, de la nécessité d'introduire des protocoles expérimentaux en 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 de chaîne complète.

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

Ben: Quel est le processus de début d'amélioration de l'OP Stack ?

tdot: J'ai rejoint Lattice il y a environ un an, en me concentrant sur le Plasma Mode. L'objectif est très clair : nous avons beaucoup d'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 abordable. L'équipe de Lattice a déjà fait quelques expériences 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 bien utilisé.

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 à la philosophie d'Ethereum et 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. Il était donc évident que nous ne pouvions pas lancer un L2 avec calldata, car notre jeu full-chain et notre 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é d'explorer Alt DA dans la documentation initiale d'OP Stack.

Ainsi, nous nous sommes demandé : "Que se passerait-il si nous commencions par un DA hors chaîne ?" Nous espérons que l'ensemble du modèle de sécurité et tout le reste peuvent dépendre de L1 Ethereum. 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 du rollup. Il y a quelques différences ici. La plus grande question est : comment implémenter le DA hors chaîne et le défi de données sur chaîne sur l'OP Stack existant ? Notre objectif est de modifier le moins possible l'OP Stack, sans affecter le chemin du rollup, car nous ne voulons pas compromettre la sécurité des autres chaînes de rollup utilisant l'OP Stack.

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 bien dès la sortie de la boîte. C'est le premier changement que nous avons fait.

Ensuite, nous devons rédiger un contrat pour créer ces défis. Il existe des défis 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 dérivé, afin que vous puissiez dériver des données à partir d'une source DA hors chaîne et d'un contrat de défi DA L1, au cas où les données seraient soumises sur la chaîne pendant le processus de résolution du défi.

Voici le point essentiel. C'est complexe, car nous voulons que les choses restent é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 parler du point de vue d'OP. Vous avez mentionné certains des travaux précoces de Lattice. Juste à ce moment-là, nous avons presque réécrit l'ensemble de l'OP Stack de manière end-to-end chez Optimism, que nous appelons Bedrock.

Fondamentalement, après avoir construit le rollup pendant deux ans, nous avons fait un pas en arrière et réfléchi en disant : "Eh bien, si nous devions pousser toutes les expériences que nous avons apprises à leur limite, à quoi cela ressemblerait-il ?" Cela a évolué pour devenir la base de code finalement connue sous le nom de 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 est son héritier spirituel, c'est la fois où nous avons le plus apprécié de jouer 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 développer. Je pense que dans les dernières années, un autre tournant important pour l'évolutivité 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 être capables de prendre en charge cette bibliothèque de code et de faire des choses vraiment incroyables était une grande validation. Ensuite, voir cette situation s'étendre à Plasma dans des applications réelles était vraiment génial. Je peux même parler un peu de cette histoire.

Avant qu'Optimism ne devienne Optimism, nous avons en réalité étudié une technologie appelée Plasma. À l'époque, la tâche que nous avons entreprise dépassait de loin la capacité de la communauté à évoluer. Le design que vous voyez dans les premiers designs 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 de l'é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 que la conclusion de la communauté à l'époque était que "Plasma est mort". C'est un mème de cette période de l'histoire de l'évolutivité d'Ethereum.

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), 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 que l'OP Stack est utilisé par d'autres, mais qu'il a aussi évolué vers ce que nous avons initialement essayé de faire, mais de manière très confuse et immature. Nous avons bouclé la boucle, et vous avez fait de superbes abstractions autour d'elles, les rendant 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, que nous continuons à travailler. La clé est de savoir comment éviter de passer des années à le faire. Tu comprends ce que je veux dire ? Nous devons atteindre rapidement une phase 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 le mainnet immédiatement. 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 qui fonctionne pour exécuter toutes ces applications, afin que ces applications puissent se développer en parallèle pendant que nous résolvons les problèmes et deviennent meilleures. Il faut beaucoup de temps pour passer de la recherche et du développement à la mise en production et à la stabilité.

Pour mettre quelque chose en ligne sur une blockchain principale, de manière sans permission, robuste et sécurisée, il faut consacrer beaucoup de temps. Voir l'ensemble du processus par lequel nous avons atteint 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 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 fonctionnera pas.

Ben: Ou on peut dire que c'est un fardeau technique. Le principe de moindre modification que vous avez mentionné est l'un des principes 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 vraiment difficiles.

Chaque ligne de code supplémentaire vous éloigne davantage 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 ce processus, en particulier pour votre contribution au nouveau modèle opérationnel d'OP Stack.

tdot: OP Stack a effectivement créé un moyen de vous permettre de progresser rapidement sur ce type 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 et des milliers de choses, en livrant régulièrement tous ces produits. En termes de coordination, ce n'est vraiment pas facile.

Ben : Oui, il y a effectivement encore beaucoup de chemin à parcourir. Mais c'est justement là toute l'attrait du modularisme. Pour moi, du point de vue de l'OP Stack, c'est l'une des choses les plus passionnantes, sans même mentionner les jeux et les mondes virtuels incroyables qui sont déjà construits sur Redstone. Purement du point de vue de l'OP Stack, c'est un très bon exemple qui prouve que de nombreux excellents développeurs principaux ont rejoint et amélioré cette pile, ce qui est vraiment impressionnant.

C'est la première fois, vous pouvez modifier de manière significative les attributs du système grâce à une valeur booléenne clé. Pouvoir le faire complètement, comme vous l'avez dit, il y a encore un long chemin à parcourir. Mais même s'il est presque possible de le faire efficacement, cela nécessite un support modulaire, n'est-ce pas ? Pour nous, voir que vous avez réalisé cela sans avoir à réécrire par exemple L2 Geth, c'est un véritable soulagement. Pour moi, cela prouve que la modularité est en train de fonctionner.

tdot: La situation s'est améliorée. D'après cet exemple, vous avez transformé tout en petits modules indépendants, pouvant ê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 l'ensemble du processus s'est déroulé très bien. L'ambiance de collaboration avec l'équipe était excellente, donc le processus de révision a également été agréable. Cela semblait très naturel. Et je pense que le processus a été très rapide en ce qui concerne la révision et la résolution de certains problèmes potentiels. Tout s'est déroulé de manière étonnamment fluide.

Ben: C'est vraiment super. Cette année, l'un de nos points forts est de créer un chemin de contribution pour OP Stack. Donc, je vous remercie beaucoup de participer aux tests et de faire avancer ces processus. Je suis heureux que ces processus ne soient pas accablants 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. Il s'agit principalement de l'intégration du 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 d'atteindre des fonctionnalités telles que l'absence d'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 aller sur le réseau principal est plus facile, car cela évite d'avoir à effectuer une hard fork. Vous pourriez penser : "Oh, je vais juste attendre que tout soit complètement prêt avant de lancer, ainsi je n'aurai pas besoin de faire de hard fork ni d'avoir de charge technique." Cependant, si vous souhaitez lancer rapidement le réseau principal, 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 de nombreuses améliorations dans le 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 des optimisations dans la soumission groupée des engagements. Pour l'instant, nous faisons 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 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 rendre cela 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 nous serons en mesure d'interagir entre toutes les chaînes. Comprendre cela sera un énorme progrès pour les utilisateurs.

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

Ben: En parlant de cela,