DEVS ON DEVS : Conversation entre TDOT et BEN JONES

Dans cet épisode spécial de Devs on Devs, nous avons invité tdot(, développeur principal du protocole Plasma Mode et également développeur de Redstone ), ainsi que Ben Jones, 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 à 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 exploré l'origine de la collaboration entre Redstone et Optimism, l'importance de raviver Plasma, la nécessité d'introduire des protocoles expérimentaux en 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.

01. Comment améliorer OP Stack avec le mode Plasma

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

tdot: J'ai rejoint Lattice il y a environ un an, 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 supporte ces exigences tout en étant peu coûteuse. L'équipe de Lattice a déjà effectué quelques expérimentations sur l'OP Stack, comme la 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 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 mainnet 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 encore la source de disponibilité des données de la chaîne OP Stack (DA), ce qui était très coûteux. Donc, nous ne pouvions clairement pas utiliser le calldata pour lancer un L2, car notre jeu full chain et notre monde MUD nécessitent 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.

Alors nous nous sommes demandé : "Que se passerait-il si nous commencions par 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 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 mettre en œuvre la 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 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.

Lors de la conception du 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 un contrat pour créer ces défis. Il y a des défis DA utilisés pour forcer l'enregistrement des données sur la 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 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 à la chaîne pendant la résolution du défi.

C'est le point 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 nous avons essayé de garder les choses simples dans un environnement complexe. Donc, dans l'ensemble, c'est un voyage d'ingénierie très 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 avons presque réécrit l'ensemble de l'OP Stack de manière end-to-end chez Optimism, et cette publication est ce 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 tirer le meilleur parti de toutes les expériences apprises, à quoi cela ressemblerait-il ?" Cela a évolué vers ce qui est finalement devenu le dépôt de code appelé Bedrock, qui est notre plus grande mise à niveau du réseau.

À ce moment-là, nous avons collaboré avec vous sur un projet appelé OPCraft, et je pense que Biomes en est l'héritier spirituel. C'était notre expérience la plus amusante 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 développer. 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é des bibliothèques de code énormes et complexes qui peuvent faire cela. Lorsque nous avons commencé à collaborer, voir d'autres prendre en charge cette bibliothèque de code et faire des choses vraiment incroyables était une grande validation. Puis voir cette situation se développer dans des applications pratiques sur Plasma était vraiment génial. Je peux même parler un peu de cette histoire.

Avant qu'Optimism ne devienne Optimism, nous étudions en réalité une technologie appelée Plasma. À l'époque, la tâche que nous avons assumée 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 relation directe avec le Plasma d'aujourd'hui.

Aujourd'hui, le Plasma est beaucoup plus simple. Nous séparons la preuve et le défi 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 le Plasma. Je pense que la conclusion de la communauté à l'époque é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), 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é vers ce que nous avons essayé à l'origine mais d'une manière très confuse et immature, est vraiment incroyable. Nous avons fait un cycle complet, et vous avez fait d'excellentes abstractions autour d'eux, les rendant fonctionnels 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 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 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 mise en ligne rapidement et qui fonctionne, pour faire fonctionner toutes ces applications, afin que celles-ci puissent se développer en parallèle tout en résolvant nos problèmes, et devenir meilleures. Le passage de la recherche et développement à la réalisation de la stabilité en production prend beaucoup de temps.

Pour mettre quelque chose en ligne sur le mainnet, de manière à ce qu'il soit sans autorisation, robuste et sécurisé, cela nécessite beaucoup de temps. Voir l'ensemble du processus que nous avons réalisé pour atteindre cet objectif est vraiment impressionnant. C'est pourquoi nous devons maintenir une grande agilité, car il y a trop de choses à gérer. L'ensemble de l'écosystème se développe très rapidement. Je pense que tout le monde livre une quantité massive 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 un fardeau technologique. 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 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 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 la promotion de ce processus, en particulier pour votre contribution au nouveau mode opératoire de l'OP Stack.

tdot: OP Stack a effectivement créé un moyen de faire progresser 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, et une chaîne.

Et vous construisez des centaines et des centaines de choses, tout en livrant régulièrement tous ces produits. Du point de vue de la coordination, cela n'est vraiment pas facile.

Ben: Oui, il reste effectivement beaucoup de chemin à parcourir. Mais c'est précisément là que réside le véritable attrait de la modularité. Pour moi, du point de vue de l'OP Stack, c'est l'une des choses les plus excitantes, sans parler des jeux et des mondes virtuels incroyables qui sont actuellement construits 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 de base ont rejoint et amélioré cette pile, ce qui est vraiment remarquable.

C'est la première fois, vous pouvez modifier considérablement les propriétés du système grâce à une valeur booléenne clé. Être capable de le faire complètement, comme vous l'avez dit, il y a en effet encore beaucoup de chemin à parcourir. Mais même s'il est presque efficace de le faire, cela nécessite un soutien modularisé, n'est-ce pas ? Pour nous, voir que vous avez réalisé cela sans avoir à réécrire par exemple L2 Geth, c'est un vrai 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. 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 une fourche, contenant tous les changements apportés à l'OP Stack, qui devait être fusionnée dans la branche principale. À l'époque, nous pensions : "Mon Dieu, examiner 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'atmosphère de collaboration avec l'équipe est excellente, donc le processus de révision a également été agréable. Cela semblait très naturel. De plus, 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 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 heureux que ces processus n'aient pas été trop difficiles à gérer et que nous ayons obtenu certains résultats. À ce propos, je suis curieux de savoir comment, selon vous, 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 intégrées au mécanisme de preuve de défaillance. Nous adoptons une approche progressive pour décentraliser l'ensemble de la pile technologique et accroître 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 passer sur le mainnet peut être plus facile, car cela évite d'avoir à procéder à des hard forks. Vous pourriez penser : "Oh, je vais juste attendre que tout soit complètement prêt avant de publier, ainsi je n'aurai pas besoin de faire de hard forks et il n'y aura pas de charge technique." Cependant, si vous souhaitez mettre rapidement en ligne le mainnet, 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 défaillance et toutes ces parties seront prêtes. Je pense qu'il y a encore de la place pour optimiser la soumission en masse des engagements. Pour l'instant, nous faisons très simplement, 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 grande différence avec l'OP Stack. Cependant, il existe maintenant certaines optimisations qui peuvent le rendre moins cher, 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 un énorme progrès 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, tout en ayant des hypothèses de sécurité différentes.

Ben :