Dans cet épisode spécial de Devs on Devs, nous avons invité tdot(, le développeur principal du protocole Plasma Mode, ainsi que le développeur de Redstone ) et le 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 sans avoir à publier des données sur L1, mais en pouvant passer de manière flexible aux fournisseurs de données hors chaîne, ce qui permet d'économiser des coûts et d'améliorer l'évolutivité. Dans la 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 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 du domaine des jeux sur la chaîne.
Comment améliorer OP Stack en utilisant le mode Plasma
Ben: Quel est le processus de début de l'amélioration de la pile OP ?
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, tout en essayant de mettre beaucoup de données sur la chaîne, donc nous avons besoin d'une solution qui supporte à la fois ces exigences et qui soit économique. L'équipe de Lattice a déjà effectué quelques expériences sur l'OP Stack, comme le prototypage de certains mondes sur la chaîne et leur déploiement sur l'OP Stack. Nous avons constaté que l'OP Stack est déjà très utilisable.
Alors, nous nous sommes demandé : "Comment pouvons-nous le rendre moins cher ?" L'hypothèse de base est : "Nous pensons que le 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 le OP Stack, c'est la solution idéale. Mais nous voulons qu'il 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. Nous ne pouvions donc clairement pas utiliser le calldata pour lancer un L2, car notre jeu en chaîne complet et notre monde MUD nécessitent 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 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 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 DA alternatives 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 au-dessus du rollup. Il y a quelques différences ici. La plus grande question est de savoir comment mettre en œuvre la DA hors chaîne et les défis de données sur chaîne sur le Stack OP existant ? Notre objectif est de modifier le Stack OP le moins possible, sans impact sur le chemin du rollup, car nous ne voulons pas affecter la sécurité des autres chaînes de rollup utilisant le Stack OP.
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 les 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 boîte. C'est le premier changement que nous avons effectué.
Ensuite, nous devons rédiger un contrat pour créer ces défis. Il existe des défis DA qui forcent les données à être mises sur la chaîne. 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 de dérivation, 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 la résolution du défi.
C'est le cœur du problème. 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 voyage d'ingénierie très cool.
Ben: Je peux en parler du point de vue d'OP. Vous avez mentionné certains travaux précoces de Lattice. Il se trouve qu'au même moment, nous avons presque réécrit l'ensemble de l'OP Stack de manière end-to-end, et nous avons appelé cette publication 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 que nous avons apprises, à quoi cela ressemblerait-il ?" Cela a évolué vers ce qui est finalement devenu la bibliothèque de code 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'est la fois où nous avons le plus joué 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 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 capables de prendre en charge cette bibliothèque de code et de réaliser quelque chose de vraiment incroyable est une grande validation. Puis voir cela s'étendre dans des applications réelles sur Plasma est vraiment génial. Je peux même parler un peu de cette histoire.
Avant qu'Optimism ne devienne Optimism, nous faisions en réalité des recherches sur une technologie appelée Plasma. À l'époque, la tâche que nous avons entreprise dépassait de loin la capacité de la communauté d'extension de l'époque. Le design que vous voyez dans les premiers designs de Plasma n'a peut-être pas de correspondance 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 la 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 qu'à l'époque, la conclusion de la communauté était "Le Plasma est mort". C'est une blague de l'histoire de l'extension d'Ethereum de 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 (exits), et 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, c'est vraiment incroyable de voir que non seulement OP Stack est utilisé par d'autres, mais aussi qu'il a évolué en quelque chose que nous avons initialement essayé de faire mais d'une manière très chaotique et immaturée. Nous avons complété un cycle entier, et vous avez fait de superbes abstractions autour d'eux et les avez fait fonctionner d'une manière raisonnable et sensée. C'est vraiment cool.
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 dix ans ? Tu vois ce que je veux dire ? Nous devons atteindre rapidement une étape où nous pouvons livrer des résultats.
Voici notre idée. Nous avons déjà de nombreuses applications basé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 qui puisse faire fonctionner toutes ces applications, afin que ces applications puissent se développer en parallèle 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 mise en production avec stabilité.
Pour mettre quelque chose en ligne sur la blockchain principale, de manière sans autorisation, robuste et sécurisée, il faut investir beaucoup de temps. Voir tout le processus que nous avons réalisé pour atteindre cet objectif est déjà incroyable. C'est pourquoi nous devons rester très agiles, car il y a tellement de choses à faire. 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 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 du moindre changement que vous mentionnez est l'une des idées centrales 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 difficiles.
Chaque ligne de code ajoutée vous éloigne davantage de l'environnement de production, rendant les choses plus difficiles à tester en situation réelle et introduisant plus d'opportunités d'erreurs. Ainsi, nous vous remercions sincèrement pour tous vos efforts dans ce processus, en particulier pour votre contribution au nouveau mode de fonctionnement d'OP Stack.
tdot : La pile OP a effectivement créé un moyen de faire avancer rapidement ce type 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, 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 effectivement encore beaucoup de chemin à parcourir. Mais c'est justement là que réside le charme central 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 jeux et mondes virtuels incroyables qui sont déjà 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 incroyable.
C'est la première fois que 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 modulable, n'est-ce pas ? Pour nous, voir que vous avez réalisé cela sans avoir besoin, par exemple, de réécrire L2 Geth, est un véritable soulagement. Pour moi, cela prouve que la modularité fonctionne.
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 une bifurcation, contenant tous les changements apportés à 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 tout le processus s'est déroulé très bien. L'ambiance de collaboration avec l'équipe est très agréable, donc le processus de révision a également été plaisant. Cela semble 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 principaux est de créer un parcours 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 trop difficiles à gérer et que nous ayons obtenu certains résultats. À ce sujet, je suis très curieux de savoir comment vous voyez l'évolution de ce travail dans les mois à venir ? Qu'est-ce que vous attendez le plus de développer ensuite ?
tdot: Il existe de nombreuses directions de travail différentes. Principalement liées à 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 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 déployer sur le réseau principal peut être plus facile, car cela évite les forks. Vous pourriez penser : "Oh, je peux simplement attendre que tout soit complètement prêt avant de lancer, de cette façon il n'y aura pas besoin de fork et pas de charge technique." Cependant, si vous voulez lancer rapidement sur 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 de mises à jour 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 des optimisations en ce qui concerne la soumission en masse des engagements. Pour l'instant, 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 temporairement 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. Cependant, il existe maintenant des optimisations qui peuvent le rendre moins coûteux, comme le traitement par lots des engagements ou leur soumission dans un blob, ou l'utilisation d'autres.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Les cofondateurs d'Optimism discutent avec les développeurs de Plasma Mode des améliorations et de l'avenir de l'OP Stack.
Devs on Devs : tdot et Ben Jones en conversation
Dans cet épisode spécial de Devs on Devs, nous avons invité tdot(, le développeur principal du protocole Plasma Mode, ainsi que le développeur de Redstone ) et le 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 sans avoir à publier des données sur L1, mais en pouvant passer de manière flexible aux fournisseurs de données hors chaîne, ce qui permet d'économiser des coûts et d'améliorer l'évolutivité. Dans la 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 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 du domaine des jeux sur la chaîne.
Comment améliorer OP Stack en utilisant le mode Plasma
Ben: Quel est le processus de début de l'amélioration de la pile OP ?
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, tout en essayant de mettre beaucoup de données sur la chaîne, donc nous avons besoin d'une solution qui supporte à la fois ces exigences et qui soit économique. L'équipe de Lattice a déjà effectué quelques expériences sur l'OP Stack, comme le prototypage de certains mondes sur la chaîne et leur déploiement sur l'OP Stack. Nous avons constaté que l'OP Stack est déjà très utilisable.
Alors, nous nous sommes demandé : "Comment pouvons-nous le rendre moins cher ?" L'hypothèse de base est : "Nous pensons que le 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 le OP Stack, c'est la solution idéale. Mais nous voulons qu'il 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. Nous ne pouvions donc clairement pas utiliser le calldata pour lancer un L2, car notre jeu en chaîne complet et notre monde MUD nécessitent 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 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 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 DA alternatives 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 au-dessus du rollup. Il y a quelques différences ici. La plus grande question est de savoir comment mettre en œuvre la DA hors chaîne et les défis de données sur chaîne sur le Stack OP existant ? Notre objectif est de modifier le Stack OP le moins possible, sans impact sur le chemin du rollup, car nous ne voulons pas affecter la sécurité des autres chaînes de rollup utilisant le Stack OP.
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 les 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 boîte. C'est le premier changement que nous avons effectué.
Ensuite, nous devons rédiger un contrat pour créer ces défis. Il existe des défis DA qui forcent les données à être mises sur la chaîne. 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 de dérivation, 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 la résolution du défi.
C'est le cœur du problème. 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 voyage d'ingénierie très cool.
Ben: Je peux en parler du point de vue d'OP. Vous avez mentionné certains travaux précoces de Lattice. Il se trouve qu'au même moment, nous avons presque réécrit l'ensemble de l'OP Stack de manière end-to-end, et nous avons appelé cette publication 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 que nous avons apprises, à quoi cela ressemblerait-il ?" Cela a évolué vers ce qui est finalement devenu la bibliothèque de code 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'est la fois où nous avons le plus joué 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 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 capables de prendre en charge cette bibliothèque de code et de réaliser quelque chose de vraiment incroyable est une grande validation. Puis voir cela s'étendre dans des applications réelles sur Plasma est vraiment génial. Je peux même parler un peu de cette histoire.
Avant qu'Optimism ne devienne Optimism, nous faisions en réalité des recherches sur une technologie appelée Plasma. À l'époque, la tâche que nous avons entreprise dépassait de loin la capacité de la communauté d'extension de l'époque. Le design que vous voyez dans les premiers designs de Plasma n'a peut-être pas de correspondance 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 la 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 qu'à l'époque, la conclusion de la communauté était "Le Plasma est mort". C'est une blague de l'histoire de l'extension d'Ethereum de 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 (exits), et 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, c'est vraiment incroyable de voir que non seulement OP Stack est utilisé par d'autres, mais aussi qu'il a évolué en quelque chose que nous avons initialement essayé de faire mais d'une manière très chaotique et immaturée. Nous avons complété un cycle entier, et vous avez fait de superbes abstractions autour d'eux et les avez fait fonctionner d'une manière raisonnable et sensée. C'est vraiment cool.
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 dix ans ? Tu vois ce que je veux dire ? Nous devons atteindre rapidement une étape où nous pouvons livrer des résultats.
Voici notre idée. Nous avons déjà de nombreuses applications basé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 qui puisse faire fonctionner toutes ces applications, afin que ces applications puissent se développer en parallèle 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 mise en production avec stabilité.
Pour mettre quelque chose en ligne sur la blockchain principale, de manière sans autorisation, robuste et sécurisée, il faut investir beaucoup de temps. Voir tout le processus que nous avons réalisé pour atteindre cet objectif est déjà incroyable. C'est pourquoi nous devons rester très agiles, car il y a tellement de choses à faire. 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 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 du moindre changement que vous mentionnez est l'une des idées centrales 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 difficiles.
Chaque ligne de code ajoutée vous éloigne davantage de l'environnement de production, rendant les choses plus difficiles à tester en situation réelle et introduisant plus d'opportunités d'erreurs. Ainsi, nous vous remercions sincèrement pour tous vos efforts dans ce processus, en particulier pour votre contribution au nouveau mode de fonctionnement d'OP Stack.
tdot : La pile OP a effectivement créé un moyen de faire avancer rapidement ce type 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, 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 effectivement encore beaucoup de chemin à parcourir. Mais c'est justement là que réside le charme central 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 jeux et mondes virtuels incroyables qui sont déjà 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 incroyable.
C'est la première fois que 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 modulable, n'est-ce pas ? Pour nous, voir que vous avez réalisé cela sans avoir besoin, par exemple, de réécrire L2 Geth, est un véritable soulagement. Pour moi, cela prouve que la modularité fonctionne.
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 une bifurcation, contenant tous les changements apportés à 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 tout le processus s'est déroulé très bien. L'ambiance de collaboration avec l'équipe est très agréable, donc le processus de révision a également été plaisant. Cela semble 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 principaux est de créer un parcours 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 trop difficiles à gérer et que nous ayons obtenu certains résultats. À ce sujet, je suis très curieux de savoir comment vous voyez l'évolution de ce travail dans les mois à venir ? Qu'est-ce que vous attendez le plus de développer ensuite ?
tdot: Il existe de nombreuses directions de travail différentes. Principalement liées à 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 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 déployer sur le réseau principal peut être plus facile, car cela évite les forks. Vous pourriez penser : "Oh, je peux simplement attendre que tout soit complètement prêt avant de lancer, de cette façon il n'y aura pas besoin de fork et pas de charge technique." Cependant, si vous voulez lancer rapidement sur 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 de mises à jour 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 des optimisations en ce qui concerne la soumission en masse des engagements. Pour l'instant, 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 temporairement 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. Cependant, il existe maintenant des optimisations qui peuvent le rendre moins coûteux, comme le traitement par lots des engagements ou leur soumission dans un blob, ou l'utilisation d'autres.