Devs on Devs : conversation entre tdot et Ben Jones

Dans cet épisode spécial de Devs on Devs, nous avons invité tdot(, le développeur principal du protocole de Plasma Mode, qui est également développeur de Redstone ), ainsi que Ben Jones, co-fondateur d'un projet Layer 2 bien connu, pour discuter. Ce projet Layer 2 bien connu est un acteur clé 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 leur permet de basculer de manière flexible vers 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 ce projet Layer 2, l'importance de faire revivre Plasma, la nécessité d'introduire des protocoles expérimentaux dans un environnement de production, la feuille de route future de Plasma Mode et de l'OP Stack, ainsi que leur enthousiasme pour le développement dans le domaine des jeux sur chaîne.

Comment utiliser le mode Plasma pour améliorer OP Stack

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

tdot: J'ai rejoint Lattice il y a environ un an, en me concentrant sur le mode Plasma. L'objectif est très clair : nous avons de nombreuses applications MUD qui consomment beaucoup de gaz, 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à 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 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 le plus conforme à l'idée 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 données de l'interface d'appel (calldata) étaient toujours 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 calldata pour lancer un L2, car notre jeu blockchain complet 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é dans la documentation initiale de l'OP Stack qu'il fallait explorer Alt DA.

Alors, 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 puisse dépendre de l'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 devons réutiliser certains anciens concepts de Plasma et les placer sur un rollup. Il y a quelques différences ici. La plus grande question est : comment mettre en œuvre DA hors chaîne et contestations 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 vous demandez 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, OP Stack reste très puissant et fonctionne très bien dès la sortie de la boîte. C'est notre première modification.

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 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 à la chaîne pendant le processus de résolution du défi.

Voici l'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 tout réinventer ou de changer l'ensemble de la pile OP, 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 en parler du point de vue d'OP. Vous avez mentionné certains travaux précoces de Lattice. Juste à ce moment-là, nous avons presque réécrit l'ensemble de la pile OP de bout en bout, cette version que nous appelons Bedrock.

En gros, après deux ans de construction de rollup, nous avons pris du recul et réfléchi en disant : "Eh bien, si nous devions tirer le meilleur parti de toutes les expériences 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.

À cette époque, nous avons collaboré avec vous sur un projet appelé OPCraft, je pense que Biomes en est l'héritier spirituel, c'est la fois où nous nous sommes le plus amusés à jouer sur la chaîne. En même temps, nous avons aussi poussé un soupir de soulagement, car d'autres peuvent également développer avec OP Stack. Je pense qu'un autre tournant important 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. Lorsque nous avons commencé à collaborer, voir d'autres prendre en charge cette bibliothèque de code et accomplir des choses vraiment étonnantes était une grande validation. Puis voir cette situation s'étendre à Plasma dans des applications réelles, c'était vraiment génial. Je peux même parler un peu de cette histoire.

Avant la création d'un projet Layer 2 bien connu, nous étions en réalité en train d'étudier une technologie appelée Plasma. À l'époque, la tâche qui nous incombait dépassait de loin les capacités de la communauté d'extension à ce moment-là. Ce que vous voyez dans les conceptions initiales de Plasma peut ne pas avoir de lien direct avec le Plasma d'aujourd'hui.

Aujourd'hui, le Plasma est beaucoup plus simple. Nous distinguons les preuves et les défis de 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 que la conclusion de la communauté à l'époque était "Plasma est mort". C'est une blague de l'histoire de l'évolutivité 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 (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 OP Stack utilisé par d'autres, mais aussi évolué en quelque chose que nous avons initialement essayé de faire mais d'une manière très confuse et immature, est vraiment incroyable. Nous avons fait un cycle complet, vous avez fait de formidables abstractions autour d'eux et les avez fait fonctionner d'une manière raisonnable et sensée. C'est vraiment génial.

Il est surtout important 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 prendre 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 basé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 celles-ci 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 de la stabilité en production.

Pour mettre quelque chose en ligne sur le réseau principal, le rendre sans autorisation, robuste et sécurisé, cela demande beaucoup de temps. Voir tout le processus de réalisation de cet objectif est déjà assez impressionnant. C'est pourquoi nous devons rester très agiles, car il y a trop de choses en cours. L'écosystème se développe très rapidement. Je pense que tout le monde livre une quantité énorme 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 technique. Le principe des modifications minimales que vous avez mentionné est l'un des concepts 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 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 pratique 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érationnel de l'OP Stack.

tdot: La pile OP a effectivement créé un moyen de faire avancer rapidement ce genre 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, tout en livrant régulièrement tous ces produits. D'un point de vue coordination, ce n'est vraiment pas facile.

Ben: Oui, il y a en effet encore beaucoup de chemin à parcourir. Mais c'est justement là tout l'attrait du modularisme. Pour moi, du point de vue de l'OP Stack, c'est l'une des choses les plus excitantes, sans même mentionner les jeux et 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 le projet et ont amélioré cette pile, ce qui est vraiment impressionnant.

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 encore un long chemin à parcourir. Mais même s'il s'agit de s'en approcher efficacement, un soutien modulable 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, 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 inquiets à l'époque, car nous avions une branche contenant tous les changements apportés à l'OP Stack, que nous devions fusionner dans le tronc principal. Nous pensions alors : "Mon dieu, examiner tout cela va être fou."

Nous avons dû décomposer cela en parties plus petites, mais tout le processus s'est très bien déroulé. L'atmosphère de coopération avec l'équipe est très bonne, donc le processus d'examen 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 l'examen et la résolution de certains problèmes potentiels. Tout s'est passé 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. Donc, je vous remercie beaucoup de participer aux tests et de faire avancer ces processus. Je suis heureux que ces processus ne soient pas trop accablants et que nous ayons obtenu des résultats. En parlant de cela, je suis curieux de savoir, de votre point de vue, comment ce travail va évoluer ensuite ? Qu'est-ce que vous attendez le plus de développer ensuite ?

tdot: Il existe de nombreuses directions de travail différentes. L'accent est principalement mis sur l'intégration des 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'implémenter 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 lancer sur le réseau principal est plus facile, car cela évite d'avoir à effectuer un 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 et il n'y aura pas de charge technique." Cependant, si vous voulez mettre rapidement en ligne 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 beaucoup de mises à niveau dans le mode 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 l'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 n'est que la valeur de hachage des données d'entrée stockées hors chaîne.

Nous restons temporairement aussi simples que possible, afin que l'examen puisse être simple et rapide, et qu'il n'y ait pas de grandes différences pour OP Stack. Mais maintenant, il y a quelques optimisations qui peuvent le rendre moins cher, comme le traitement par lots des engagements ou leur soumission.