DEVS ON DEVS: TDOT et BEN JONES en conversation

Ce numéro de dialogue spécial a invité le développeur du protocole central de Plasma Mode tdot(, également développeur de Redstone ) et co-fondateur d'Optimism, Ben Jones. Optimism est le principal promoteur de l'OP Stack. Plasma Mode permet aux développeurs de construire sur l'OP Stack, mais sans avoir besoin de publier des données sur L1, mais plutôt de 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é. Ils ont discuté de l'origine 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 leurs attentes concernant le développement du domaine des jeux 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 mode Plasma. L'objectif est clair : nous avons de nombreuses applications MUD qui consomment beaucoup de gas, et en même temps, nous essayons 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 peu coûteuse. L'équipe de Lattice a déjà effectué 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 facile à utiliser.

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." 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, 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, nous ne pouvions évidemment pas utiliser les 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 fait, il a déjà été mentionné dans la documentation initiale d'OP Stack de rechercher 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 contenu peuvent dépendre de l'Ethereum L1. Par conséquent, nous avons évité d'autres solutions de DA Alt, 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 de rollup. Il y a quelques différences ici. La plus grande question est : comment mettre en œuvre le DA hors chaîne et le défi de données sur chaîne sur la pile OP existante ? Notre objectif est de modifier le moins possible la pile OP, sans impact sur le chemin rollup, car nous ne voulons pas affecter la sécurité d'autres chaînes rollup qui utilisent la pile OP.

En concevant 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 la première modification que nous avons apportée.

Ensuite, nous devons rédiger un contrat pour créer ces défis. Il y a des défis DA pour forcer les données à être mises en 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 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 à la chaîne pendant la résolution du défi.

C'est là que se situe l'essentiel. 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 l'ensemble de l'OP Stack, mais plutôt d'essayer 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é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, et nous avons appelé cette version Bedrock.

En gros, après deux ans de construction du rollup, nous avons pris du recul et réfléchi en disant : "Eh bien, si nous devions tirer parti de toutes les expériences apprises au maximum, à quoi cela ressemblerait-il ?" Cela a évolué pour devenir la bibliothèque de code finalement 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 est son héritier spirituel, c'était notre moment le plus amusant en jouant 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 que l'un des tournants importants 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 et complexes bibliothèques de code qui peuvent le faire. Quand nous avons commencé à collaborer, voir d'autres 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 se déployer en pratique sur Plasma était 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 entreprise dépassait de loin les capacités de la communauté d'expansion à l'époque. Vous remarquerez peut-être que le design que vous voyez dans les premiers designs de Plasma n'a pas de correspondance directe avec le Plasma d'aujourd'hui.

Aujourd'hui, le Plasma est beaucoup plus simple. Nous distinguons la preuve et le défi de la validation d'état du défi des 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 "le Plasma est mort". C'est une blague 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 (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é en quelque chose que nous avons initialement essayé de faire mais de manière très confuse et immature, est vraiment étonnant. Nous avons bouclé la boucle, et vous avez fait des abstractions vraiment extraordinaires autour d'eux, les rendant fonctionnels d'une manière raisonnable et sensée. C'est vraiment cool.

Il est surtout important d'entrer dans l'environnement de production le plus rapidement possible.

tdot: Le mode Plasma présente encore certains défis et problèmes non résolus, auxquels nous travaillons toujours. 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.

Voici 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 exécuter toutes ces applications, afin que ces applications puissent se développer en parallèle tout en résolvant nos problèmes, et s'améliorer. Le passage de la recherche et développement à la stabilité de 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é, il faut consacrer beaucoup de temps. C'est déjà incroyable de voir tout le processus que nous avons mis en œuvre pour atteindre cet objectif. C'est pourquoi nous devons rester très agiles, 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 beaucoup 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 plutôt un fardeau technique. Le principe des modifications minimales 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 conditions réelles et introduisant plus d'opportunités d'erreurs. C'est pourquoi nous vous remercions pour tous vos efforts dans ce processus, en particulier pour votre contribution au nouveau mode opérationnel de l'OP Stack.

tdot: La pile OP a effectivement créé un moyen de faire avancer 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 milliers de choses, tout en livrant régulièrement tous ces produits. D'un point de vue coordination, cela 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, du point de vue de l'OP Stack, c'est l'une des choses les plus excitantes, sans même mentionner les incroyables jeux et mondes virtuels qui sont actuellement construits sur Redstone. Purement du point de vue de l'OP Stack, c'est un très bon exemple qui prouve que beaucoup de développeurs de cœur talentueux ont rejoint et amélioré cette pile, ce qui est remarquable.

C'est la première fois, vous pouvez modifier de manière significative les propriétés du système par une valeur booléenne clé. Être en mesure de le faire complètement, comme vous l'avez dit, il y a encore un long chemin à parcourir. Mais même pour y parvenir de manière efficace, un soutien modulaire est nécessaire, 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, ce qui permet d'ajuster et de modifier les attributs. Je suis donc très impatient de voir quelles nouvelles fonctionnalités seront intégrées. Je me souviens que nous étions inquiets à l'époque, car nous avions un fork contenant tous les changements apportés à l'OP Stack, et il fallait les fusionner dans la branche principale. Nous pensions alors : "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 très bien déroulé. L'atmosphère 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. 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 déroulé de manière é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 propos, je suis curieux de savoir comment, selon vous, ce travail va évoluer par la suite ? Qu'attendez-vous le plus de développer ensuite ?

tdot: Il existe de nombreuses orientations professionnelles différentes. Principalement intégrées aux mécanismes 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 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 être 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, comme ça il n'y a pas besoin de hard fork, et il n'y a pas de charge technique." Cependant, si vous souhaitez mettre rapidement en ligne le réseau principal, vous devez gérer ces mises à jour 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 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 reste encore une certaine marge d'optimisation en ce qui concerne la soumission en masse des engagements. Pour l'instant, nous faisons 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 la révision puisse être simple et rapide, et qu'il n'y ait pas de grande différence avec 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 l'adoption d'autres méthodes différentes. Donc, nous allons 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. Clarifier cela représentera un énorme progrès pour les utilisateurs.

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

Ben : À ce propos, ce sera une nouvelle épreuve pour la modularité de l'OP Stack. Les preuves de panne que vous avez mentionnées, (fault proofs), nous les attendons avec impatience dans Plasma.