"Dans cette édition spéciale de Devs on Devs, nous invitons le mode Plasma[1][2]Le développeur principal du protocole est tdot[3](Redstone en même temps.)[4]développeurs) et Optimism[5]Co-fondateur Ben Jones。 L’optimisme est le principal catalyseur de la pile OP. Le mode Plasma permet aux développeurs de s’appuyer sur la pile OP, mais au lieu de publier des données sur L1, ils ont la possibilité de passer à des fournisseurs de données off-chain, ce qui permet de réduire les coûts et d’améliorer l’évolutivité. Dans cette conversation, ils explorent les origines du partenariat Redstone et Optimism, l’importance de la relance de Plasma, la nécessité de mettre en production des protocoles expérimentaux, la future feuille de route pour le mode Plasma et la pile OP, et leur enthousiasme pour la croissance de l’espace de jeu omnichain. ”
01. Comment utiliser le mode Plasma pour améliorer la pile OP
Ben: Quel est le processus d'amélioration de la pile OP ?
tdot: J'ai rejoint Lattice il y a environ un an, en charge spécifiquement du mode Plasma. L'objectif est très clair : nous avons beaucoup de MUD.[6]Les applications consomment beaucoup de gas et nous essayons de mettre beaucoup de données sur la chaîne, il est donc nécessaire de trouver une solution à la fois abordable et adaptée à ces besoins. L'équipe de Lattice a déjà effectué des expériences sur OP Stack, telles que la prototypage de certains mondes on-chain et leur déploiement sur OP Stack. Nous avons constaté que OP Stack est déjà très performant.
于是我们问自己,“怎么才能让它更便宜?” 基本的假设是,“我们认为 OP Stack 是最符合以太坊理念且完全兼容 EVM 的框架。” 在主网上运行的东西可以同样在 OP Stack 上运行,这是理想的解决方案。但我们希望它更便宜。
Quand calldata était encore une source de disponibilité des données (DA) sur la chaîne OP Stack, cela coûtait très cher. Par conséquent, il était évident que nous ne pouvions pas utiliser calldata pour lancer un L2, car nos jeux en chaîne complète et notre monde MUD nécessitaient un débit plus élevé. Nous avons donc décidé de commencer à explorer d'autres solutions de disponibilité des données (Alt DA). En fait, l'exploration d'Alt DA avait déjà été mentionnée dans le document initial sur OP Stack.
Alors nous nous sommes demandé : "Et si nous commencions par une approche hors chaîne pour les DAO ?" Nous voulions que tout le modèle de sécurité et tout le contenu puisse reposer sur Ethereum L1. Nous avons donc évité les autres solutions de DAO alternatives et avons décidé de stocker les données dans un système de stockage centralisé hors chaîne, puis de trouver un modèle de sécurité efficace sur L1.
C’est pourquoi nous réutilisons certains des anciens concepts de Plasma et les mettons au-dessus des rollups. Il y a quelques différences ici. La grande question est la suivante : comment mettre en œuvre off-chain DA et off-chain défis en matière de données en plus de la pile OP existante ? Notre objectif est d’apporter le moins de modifications possible à la pile OP sans aucun impact sur le chemin de cumul, car nous ne voulons pas affecter la sécurité des autres chaînes de cumul qui utilisent la pile OP.
Lors de la conception de rollup, vous ne pensez pas, "Que se passe-t-il si quelqu'un modifie le flux de génération de données pour stocker des données ailleurs ?" Même avec ces modifications, la pile OP reste très puissante et fonctionne bien dès le départ. C'est le premier changement que nous avons apporté.
Après cela, nous devons rédiger des contrats pour créer ces défis. Il existe des défis DA pour forcer les données off-chain. Il s’agit de la deuxième étape, l’intégration du contrat dans le processus. Nous devons construire l’ensemble du système intégré pendant le processus de dérivation afin que vous puissiez dériver des données d’une source DA off-chain ainsi que d’un contrat de défi DA L1 au cas où les données seraient soumises à la chaîne off-chain pendant le processus de résolution de défi.
C'est là l'essentiel de la question. C'est très complexe car nous voulons maintenir l'élégance et la stabilité de la situation. En même temps, c'est un concept relativement simple. Nous n'essayons pas de tout réinventer ou de changer l'ensemble de la pile OP, nous essayons plutôt de maintenir 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 d’un point de vue OP. Vous avez mentionné certains des premiers travaux de Lattice. Exactement au même moment, chez Optimism, nous avons réécrit de bout en bout la quasi-totalité de la pile OP, que nous appelons Bedrock.
Fondamentalement, après deux ans de construction de Rollup, nous avons fait un pas en arrière et réfléchi à la question : "Eh bien, à quoi ressemblerait-il si nous appliquions toutes les connaissances que nous avons acquises à l'extrême ?" Cela a évolué pour devenir la bibliothèque de code appelée Bedrock, qui est la mise à niveau la plus importante que nous ayons apportée au réseau.
在那个时候,我们与你们合作了一个叫OPCraft的项目。[7][8]的项目,我认为BiomesC'est son héritier spirituel, c'est la fois où nous avons le plus de plaisir à jouer hors-chaîne. En même temps, nous avons aussi soufflé un peu, car d'autres personnes 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 de nombreuses personnes peuvent exécuter des chaînes.
Karl d'Optimism observe le gameplay OPCraft.
并不是 seulement les personnes qui ont développé de vastes bibliothèques de code complexes peuvent le faire. Quand nous avons commencé à collaborer, voir d'autres personnes prendre en charge cette bibliothèque de code et accomplir des choses vraiment incroyables, c'était une grande affirmation. Et voir cette situation se déployer sur Plasma dans des applications concrètes, c'est vraiment génial. Je peux même vous parler un peu de cette histoire.
Avant qu’Optimism ne devienne Optimism, nous travaillions sur une technologie appelée Plasma. À ce moment-là, nous avions une tâche qui allait bien au-delà de ce que nous étions en mesure de faire évoluer la communauté à l’époque. Le design que vous avez vu dans les premiers jours de Plasma n’a peut-être pas d’équivalent direct au Plasma d’aujourd’hui.
Aujourd'hui, Plasma est beaucoup plus simple. Nous examinons séparément les preuves et les défis de vérification d'état par rapport aux défis de 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 "Plasma est mort". C'était un mème de l'époque de l'évolution de l'évolutivité d'Ethereum.
Mais nous avons toujours pensé que "Plasma n'est pas mort, mais nous pouvons simplement essayer une tâche plus simple". Maintenant, nous utilisons des termes différents. Par exemple, à l'époque, il y avait des concepts de sortie (exits), maintenant vous pouvez regarder 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 la pile OP utilisée par d'autres, mais aussi évoluer à partir de ce que nous avons initialement essayé de faire de manière très confuse et immature, c'est vraiment incroyable. Nous avons parcouru un cycle complet et vous avez créé de superbes abstractions autour d'eux et les avez fait fonctionner de manière logique et raisonnable. C'est vraiment cool.
La couverture de Coindesk depuis que Plasma est devenu Optimism
02. Le plus important est de passer rapidement en production.
**tdot:**Le mode Plasma présente encore des défis et des problèmes non résolus, et nous travaillons toujours à les résoudre. La clé est de trouver comment éviter de prendre une décennie entière ? Vous voyez ce que je veux dire, n'est-ce pas ? Nous devons atteindre rapidement une phase où nous pouvons livrer des résultats.
C’est ce que nous pensons. Nous avons déjà les applications MUD les plus longues qui souhaitent être mises en ligne sur le mainnet immédiatement. Nous devons préparer un mainnet pour ces jeux dès que possible. Les gens attendent déjà, et ils sont prêts. Vous avez besoin d’une chaîne rapide et opérationnelle pour exécuter toutes ces applications afin qu’elles puissent évoluer et s’améliorer en parallèle pendant que nous résolvons les problèmes. Il faut un temps long pour passer de la R&D à la stabilité de la production.
Il faut beaucoup de temps pour mettre quelque chose en ligne sur le mainnet et le rendre sans autorisation, robuste et sécurisé. C’est incroyable de voir tout le processus que nous avons suivi pour en arriver là. C’est pourquoi nous devons être très agiles parce que les choses sont si longues. L’ensemble de l’écosystème se développe très rapidement. Je pense que tout le monde innove beaucoup. C’est pourquoi vous devez suivre le rythme, mais vous ne pouvez pas non plus faire de compromis sur la sécurité et les performances, sinon le système ne fonctionnera pas.
Ben: Ou peut-être que c'est un fardeau technique. Le principe de modification minimale dont vous avez parlé est l'un des concepts clés lors de la réécriture de Bedrock. J'ai mentionné la réécriture de bout en bout, mais ce qui est encore plus important, c'est que nous avons réduit d'environ 50 000 lignes de code, ce qui est déjà très significatif. Parce que vous avez raison, ces choses sont vraiment difficiles.
Chaque ligne de code supplémentaire vous éloigne de l'environnement de production, rendant les choses plus difficiles à tester en situation réelle et introduisant davantage d'opportunités d'erreur. Nous vous sommes donc très reconnaissants pour tous vos efforts dans la promotion de ce processus, en particulier pour votre contribution au nouveau mode de fonctionnement de OP Stack.
**tdot:**OP Stack a vraiment créé une manière de faire avancer rapidement ce genre de choses. La coordination entre nous est très difficile car nous sommes clairement deux entreprises différentes. Chez Lattice, nous construisons un jeu, un moteur de jeu et une chaîne.
Et vous construisez des centaines de choses et livrez régulièrement tous ces produits. Du point de vue de la coordination, cela est vraiment très difficile.
Ben: Oui, il y a encore beaucoup de chemin à parcourir. Mais c'est précisément là que réside le charme central de la modularité. Pour moi, du point de vue de la pile OP, c'est l'une des choses les plus excitantes, sans même parler des jeux et mondes virtuels incroyables construits sur Redstone. Purement du point de vue de la pile OP, c'est un exemple très puissant qui témoigne de la participation de nombreux développeurs principaux talentueux qui ont rejoint et amélioré cette pile, c'est vraiment formidable.
C'est la première fois que vous pouvez changer significativement les propriétés du système avec une seule valeur booléenne clé. Il y a encore beaucoup de chemin à parcourir pour pouvoir le faire complètement, comme vous l'avez dit. Mais même pour s'en approcher efficacement, il faut un soutien modulaire, n'est-ce pas ? Pour nous, voir que vous avez réussi à le faire sans avoir à réécrire L2 Geth est vraiment rassurant. Cela prouve que la modularité fonctionne.
tdot: Les choses ont maintenant beaucoup progressé. À partir de cet exemple, vous avez transformé tout en petits modules indépendants qui peuvent être ajustés et dont les propriétés peuvent être modifiées. Je suis donc très impatient de voir quelles nouvelles fonctionnalités seront intégrées. Je me souviens que nous étions inquiets d'avoir une bifurcation contenant toutes les modifications apportées à OP Stack et qu'il fallait les fusionner dans la branche principale. Nous pensions alors : "Oh mon Dieu, il sera fou de passer en revue tout ce contenu."
Nous devons le décomposer en parties plus petites, mais tout le processus s'est déroulé très bien. La collaboration avec l'équipe a été très bonne, donc le processus de révision a également été agréable. Cela semble très naturel. De plus, je pense que le processus s'est déroulé très rapidement pour examiner et résoudre certains problèmes potentiels. Tout s'est déroulé étonnamment bien.
Ben : C’est génial. L’une de nos priorités cette année est de créer des chemins de contribution pour la pile OP. Merci beaucoup d’avoir participé aux tests et d’avoir piloté ces processus. Je suis heureux que les processus n’aient pas été écrasants et que nous ayons obtenu des résultats. En parlant de cela, je suis curieux, de votre point de vue, comment ce travail évolue-t-il ensuite ? Qu’est-ce que vous avez le plus hâte de développer ensuite ?
tdot: Il y a plusieurs orientations de travail différentes. L'intégration principale est basée sur le mécanisme de preuve de défaillance. Nous adoptons une approche progressive pour décentraliser l'ensemble de la pile technologique et ajouter ses caractéristiques sans permission, avec pour objectif final de réaliser des fonctionnalités sans permission et de sortie forcée.
Nous avons cet objectif ultime et nous l’atteignons progressivement tout en maintenant la sécurité. L’un des défis est qu’il est parfois plus facile de ne pas aller sur le mainnet car il n’y a pas besoin d’un fork dur. Vous pensez peut-être : « Oh, je vais juste attendre que tout soit complètement prêt avant de sortir pour qu’il n’y ait pas de fork dur et pas de fardeau technique. » « Mais si vous voulez passer rapidement en direct sur le mainnet, vous devez faire face à ces mises à niveau complexes et les publier fréquemment. Faire cela et maintenir une haute disponibilité est toujours un défi.
Je pense qu'il y aura de nombreuses améliorations 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 un certain espace d'optimisation pour la soumission groupée des engagements. Pour l'instant, nous faisons simplement un engagement par transaction. Et l'engagement n'est que le hachage des données d'entrée stockées hors chaîne.
Nous l’avons gardé aussi simple que possible pour le moment, afin que l’examen soit simple et rapide, et qu’il n’y ait pas de grandes différences pour la pile OP. Mais il existe certaines optimisations qui peuvent le rendre moins cher, comme le traitement par lots des engagements ou leur validation dans des objets blob, ou l’adoption d’une approche différente. Nous allons donc certainement nous pencher sur la question pour Goutte le coût de la L1.
C’est quelque chose qui nous enthousiasme beaucoup. Bien sûr, nous attendons également avec impatience tout ce qui concerne l’interopérabilité et la possibilité d’interagir entre toutes les chaînes. Le comprendre serait un énorme pas en avant pour les utilisateurs.
C’est long que vous aurez à faire le travail. Mais nous aimerions comprendre à quoi cela ressemble en mode Plasma, et avec différentes hypothèses de sécurité.
**Ben:**En parlant de cela, ce sera un autre test pour la modularité du module OP Stack. Vous avez mentionné les preuves de défaillance (fault proofs), nous avons hâte de les voir en ligne dans le mode Plasma. C'est également une fonctionnalité importante dans le roll-up qui sera déployée sur le Mainnet dans les prochains mois.
L’une des choses passionnantes à propos de la construction de cette base de code est que, bien qu’il y ait quelques mises en garde, relativement parlant, il est possible d’exécuter une preuve d’échec dans un nouvel environnement en cliquant simplement sur le bouton de recompilation. C’est donc très excitant de voir cela mis en œuvre dans la pratique, car ce sera un autre exemple de « fonctionnalité qui fonctionne tout simplement ». En tant que l’une des premières équipes à faire un changement à grande échelle, je suis sûr que ce ne sera pas complètement sans friction, mais c’est certainement un avantage très excitant pour la communauté de pouvoir essayer de publier une preuve d’échec sur une base de code fortement modifiée.
tdot: Sa conception est très bonne, vous pouvez insérer vos entrées comme avec un "oracle" et modifier ces sources de données dans le processus de preuve de défaillance. Cela ne devrait pas être trop difficile. Bien sûr, vous devez vous assurer qu'il fonctionne correctement tout au long du processus de bout en bout, mais je pense que le publier ne devrait pas être trop difficile. Cela pourrait également être un point clé de la feuille de route à venir.
Dans l’ensemble, nous sommes très intéressés par l’amélioration et l’optimisation des performances. Il n’y a pas de solution miracle, et chaque petit problème doit être résolu étape par étape. Si l’ensemble de la communauté se penche sur ces questions, comme une armée de développeurs qui travaillent sans relâche pour que nous puissions progressivement mettre en place une chaîne performante construite sur une stabilité incroyable.
Le logo MUD
03.MUD, Redstone et la collaboration avec Optimism
Ben: Je suis très impatient de voir les progrès que vous avez réalisés dans l'intégration de MUD et OP Stack. Je pense qu'il y a un immense potentiel ici. L'une des choses les plus excitantes sur lesquelles nous allons travailler au cours des prochaines années est de continuer à faire avancer les améliorations significatives de la performance et du débit discutées dans Ethereum L1.
La communauté de recherche sur Ethereum a fait de nombreux efforts dans ce domaine, mais c'est aussi un domaine à haut risque. Certaines modifications majeures nécessitent une plateforme de test. Un exemple auquel je pense est le problème d'expiration de l'état. Il ne fait aucun doute que votre travail est impressionnant car il repousse les limites de la quantité de contenu incroyable que la chaîne peut contenir. Je pense qu'un résultat que nous verrons est la véritable émergence du problème de "hausse de l'état". Cela signifie essentiellement que plus on joue, plus les nœuds doivent suivre de contenu et plus il est difficile d'exécuter des transactions.
La communauté Ethereum a travaillé sur ce problème pendant de nombreuses années et a proposé des solutions. Je pense que ces solutions sont délicates car elles modifient fondamentalement la structure de gestion des états. Fondamentalement, vous devez fournir ces preuves à un moment donné afin de pouvoir abandonner l'état, à moins que quelqu'un ne veuille le restaurer.
Je suis vraiment excité parce que je pense que le MUD est l’environnement idéal pour que vous puissiez réellement mettre en œuvre ces changements et les faire fonctionner. Vous avez fait un excellent travail de gestion de l’État et vous avez déjà un cadre et un modèle que tout le monde suit. J’ai aussi vraiment hâte d’y être, parce que je pense que le framework sur lequel vous vous concentrez sur la façon de construire des applications sur Redstone, sera en mesure d’expérimenter avec ce framework, d’essayer ces améliorations vraiment délicates qui vont apporter d’énormes gains de performance, mais qui doivent mettre à jour le paradigme. Je pense que vous avez le potentiel de faire une percée dans ce domaine, donc je suis très enthousiaste à ce sujet.
tdot : C’est un bon point. J’aime l’idée que les MUD empêchent les développeurs de travailler sur toutes sortes de fonctions de base. Fondamentalement, OP Stack est la couche de base, et vous avez juste affaire à des primitives de protocole et des choses comme ça. Développer avec des MUD, en revanche, consiste à simplifier ces processus. Lorsque nous entrons dans le monde de l’interopérabilité des chaînes les plus longues, nous réfléchissons à la façon de faire abstraction des chaînes les plus longues. C’est certainement une question importante qui vient à l’esprit lorsque l’on considère la combinaison de MUD et de Redstone.
Donc nous devons également comprendre à quoi ressemble une expérience de développement idéale. Il devient difficile de résoudre ces problèmes lorsque vous traitez avec toutes ces chaînes et vos utilisateurs se lassent de passer constamment de l'une à l'autre. Si vous avez beaucoup de L2, cela finira par être confus. J'ai récemment entendu quelqu'un dire: "Je ne me souviens pas sur quelle chaîne se trouve mon argent." Il est très compliqué de suivre les soldes sur chaque chaîne. Nous avons certainement besoin d'une certaine abstraction pour simplifier ce problème. Sinon, cela deviendra très complexe. MUD est sans aucun doute une très bonne opportunité pour résoudre ce problème.
Ben: J'attends ton aide. Il y a beaucoup de travail, mais c'est super cool.
tdot: Je pense que travailler avec vous est certainement d'une grande aide pour nous, car nous sommes une très petite équipe d'environ 15 personnes. Donc, il est évidemment difficile de faire face à toutes ces choses. Lorsque vous développez et collaborez sur Superchain, vous obtenez soudainement une grande entreprise avec tous les ressources d'ingénierie dont vous pourriez avoir besoin. Je suis essentiellement le seul ingénieur travaillant sur le mode Plasma de Lattice, mais en collaborant avec Optimism et en profitant de la puissance de tous les autres développeurs principaux, nous pouvons grandement améliorer notre productivité, ce qui nous permet de réaliser des travaux qui seraient normalement difficiles à réaliser indépendamment. Cet effet de volant est vraiment génial.
Quand j’en fais l’expérience, je me sens très puissant. Je me suis dit : « Wow, je n’arrive pas à croire qu’on vient de faire ça. » J’avais l’impression que tout était possible.
Ben : Mon cœur se réchauffe vraiment. Je vous remercie.
Sur la base de quelles philosophies sont conçus la sécurité de Plasma et le fonctionnement de Layer 2 ? Lorsque des événements étonnants se produisent, cela déclenche souvent des débats sur les modèles de sécurité au sein de la communauté, ce qui indique généralement une avancée des limites technologiques. Lorsque des événements subtils mais dignes de discussion et d'enseignement se produisent, cela signifie généralement des progrès passionnants.
J’ai l’impression que nous ne nous sommes pas vraiment penchés sur la structure de conception de Plasma en tant que modèle de sécurité Layer 2. Je suis curieux de savoir ce que vous en pensez. J’ai quelques réflexions sur les débuts de Plasma et j’aimerais entendre ce que vous en pensez également.
04. Définition du mode Plasma
tdot: Je voudrais vous présenter le mode Plasma et ce qu'il signifie. Il s'agit d'une nouvelle fonctionnalité du stack OP que nous développons actuellement, qui est encore à l'étape expérimentale et qui comprend un aspect de Plasma, à savoir la disponibilité des données hors-chaîne.
Nous l'appelons Plasma car il promeut l'idée de stocker les données d'entrée hors chaîne. Au lieu d'utiliser L1 DA, vous stockez les données sur n'importe quel service de stockage, comme AWS ou IPFS. Ensuite, vous devez surveiller la disponibilité de ces données. Il faut au moins une personne pour vérifier si les données soumises sont disponibles.
Si les données deviennent indisponibles pour une raison quelconque, le protocole permet aux utilisateurs de se retirer de force dans les sept jours. Il manque encore certaines parties en cours de développement, telles que les preuves de défaillance à venir et les soumissions sans permission. Les utilisateurs peuvent utiliser Sentinel.[9]Vérification automatique de la disponibilité des données. Si les données deviennent indisponibles, vous devez lancer un défi sur L1.
Si les données ne sont pas disponibles, vous devez relever le défi, essentiellement pour forcer la mise en ligne des données ou réorganiser les données afin de pouvoir retirer les fonds et sortir de la chaîne. Donc, à ce stade, ces composants ne sont pas encore entièrement déployés. Nous tenons donc à souligner qu'il y a encore une certaine distance à parcourir pour atteindre les objectifs de non-permission et d'accessibilité totale, mais nous avançons progressivement.
Concernant le coût d'extraction des fonds lié à la contestation des données des utilisateurs, il existe quelques hypothèses. Ces éléments sont encore en cours de définition et nous optimisons ces projets pour les rendre finalement moins chers et plus faciles d'accès. Nous élaborons une feuille de route pertinente. Cela diffère du plan de déploiement des preuves de fraude (fraud proofs) et du trieur décentralisé dans la feuille de route de OP Stack.
L’un des problèmes de ce protocole est le dilemme du pêcheur[10]Cela signifie que vous avez besoin d’un « pêcheur » honnête pour être en ligne à tout moment, car si personne n’est en ligne, vous ne savez pas si les données sont devenues indisponibles, et vous ne pouvez pas retirer de fonds pendant la fenêtre de retrait, et la chaîne peut être attaquée par les opérateurs.
Le dilemme du pêcheur
Vous avez plusieurs façons de résoudre ce problème. Vous pouvez motiver les gens à rester en ligne en utilisant un mécanisme de récompense, créer une communauté forte et veiller à ce que les parties prenantes qui ont investi davantage dans la chaîne, comme les utilisateurs qui exploitent des ponts ou fournissent de la liquidité, restent en ligne et garantissent l'honnêteté de la chaîne et des opérateurs. Ces utilisateurs devraient rester en ligne et relever les défis en cas de problème. Il est évident que ce sujet est très intéressant car il existe de nombreuses façons de résoudre ce dilemme et il reste encore beaucoup de travail à faire pour rendre ce système accessible à tous et garantir que les utilisateurs continuent de se préoccuper de la maintenance de la chaîne.
Ben : Qu’est-ce que Layer 2 ? C’est une Blockchain qui utilise la couche 1 plus efficacement. L’analogie classique est la suivante : « Vous n’allez pas au tribunal pour encaisser un chèque, vous allez au tribunal lorsque le chèque est sans provision. » « C’est la philosophie de conception de base derrière ces systèmes optimistes, et c’est notre réflexion sur le roll-up : utiliser la Blockchain plus efficacement. En utilisant L1 uniquement en cas de litige, le débit total de la Blockchain peut être augmenté. Je pense que c’est aussi une bonne analogie pour le modèle Plasma. Le modèle Plasma élargit essentiellement le concept de cumul, non seulement pour résoudre les litiges de retrait, mais aussi pour exiger la disponibilité des données de transaction elles-mêmes.
Je pense que cela sera un outil très puissant car en le mettant en œuvre, on peut utiliser Layer 1 de manière plus efficace et traiter beaucoup plus de données dans le système Layer 2, ce qui coûte beaucoup moins cher que de n'utiliser que roll-up. Donc c'est très excitant. Plus important encore, cela vous permet d'améliorer l'état existant, ce qui est impossible sans le mode Plasma.
Bien sûr, il n'est pas parfait. Il existe le dilemme du pêcheur (Fisherman's Dilemma), qui pose certaines exigences fondamentales pour tout le système. La chose la plus excitante à propos de Plasma par rapport à d'autres systèmes Alt DA est qu'il transforme les compromis de sécurité en compromis d'activité.
Dans d’autres systèmes, vous ne pouvez pas aller devant les tribunaux pour résoudre le problème des données. Les données existent par défaut. Cela signifie que si les données n’existent pas et que vous n’avez pas suffisamment de preuves pour prouver le statu quo devant les tribunaux, vous avez des problèmes. En revanche, le modèle Plasma constitue un bon compromis en ajoutant une nouvelle forme de défi, en évitant la perte de données et en faisant payer la communauté pour publier des données en L1.
Pendant la résolution des différends, vous pourriez ne pas connaître l'état de la chaîne, mais il est préférable de faire des compromis sur l'activité que sur la sécurité, car un compromis sur l'activité signifie que vous pourriez ne pas connaître l'état de la chaîne pendant un certain temps, tandis qu'un compromis sur la sécurité signifie que vous ne savez pas si les retraits de la chaîne sont valides, ce qui pourrait permettre à quelqu'un d'effectuer des retraits non valides. C'est ma vision du modèle Plasma.
Il étend le concept de "ne pas aller au tribunal pour encaisser un chèque, mais plutôt pour aller au tribunal lorsque le chèque est refusé" et l'applique pour améliorer les compromis lors de l'utilisation de Alt DA. Ainsi, même si les fonds peuvent être perdus, vous ne rencontrerez que des cas où l'état de la chaîne est temporairement inconnu et où les utilisateurs doivent payer des frais de publication de données. Je pense que c'est un compromis très excitant.
tdot: Lorsque nous utilisons le terme "Plasma", il y a effectivement certains risques car il est chargé d'histoire. Le problème réside dans la définition. Lorsque nous avons annoncé le mode Plasma et l'avons déployé sur le Mainnet, beaucoup de personnes ont pu penser qu'il était presque identique à celui décrit par Vitalik et d'autres.
En fait, il s’agit toujours de la pile OP. Lorsque nous avons introduit ces fonctionnalités de type plasma dans la pile OP, nous n’avons pas repensé la pile OP. Nous maintenons toujours les hypothèses de sécurité de la pile OP et ajoutons la disponibilité des données (DA) off-chain en plus de cela. Ce que nous avons emprunté à Plasma, c’est que les utilisateurs peuvent contester les données et vérifier leur utilisabilité, et si les données ne sont pas disponibles, ils peuvent forcer le fournisseur DA à les soumettre à l’off-chain, ou réorganiser les données pour la sortie. Notre hypothèse de sécurité est que, quoi qu’il arrive, les utilisateurs seront en mesure de forcer la sortie ou de retirer des fonds, même si l’opérateur de la chaîne ou le fournisseur DA est un nœud malveillant.
Afin ordre garantir cette situation, long mesures sont nécessaires. L’idée est de garantir d’abord les parties les plus élémentaires, et de développer progressivement certaines des garanties de la pile OP, de parvenir progressivement à la décentralisation et d’introduire progressivement ces garanties. Nous avons déjà les frameworks les plus longs pour évaluer la sécurité des rollups, construits par L2Beat et d’autres, qui sont très utiles à la communauté.
Mais Plasma lui-même ne convient pas parfaitement à ce modèle. Le problème est que si vous essayez d'adapter complètement le mode Plasma au framework rollup, il ne correspond pas parfaitement à toutes les étapes.
Nous avons encore besoin de mettre en œuvre certaines de ces fonctionnalités. Il est donc nécessaire d'avoir une feuille de route et une méthodologie claires. Je pense que ces éléments sont encore en cours de définition et d'amélioration. Il est très significatif que nous discutions ensemble de ces problèmes, trouvions leur signification et proposions une définition commune.
Ben : Oui, je suis tout à fait d’accord avec ça. Les progrès sur des éléments tels que la preuve d’échec sont importants, mais vous avez raison de dire que le modèle de sécurité de Plasma nécessite un nouveau cadre unique aux rollups. Si vous êtes suffisamment haussier sur la mise à l’échelle d’Ethereum, il n’y a pas d’autre option et vous aurez besoin d’une solution alternative de disponibilité des données (DA).
La réalité est que les rollups ont des compromis évidents. Ils sont plus faciles à construire, c’est pourquoi la communauté de mise à l’échelle a commencé à les construire en premier lieu. Mais si vous voulez un système Blockchain véritablement évolutif horizontalement, vous ne pouvez pas être limité par le débit de données L1. Et si vous n’utilisez que des rollups, vous êtes limité. Par conséquent, une fois que vous comprenez que l’objectif est d’amener la Blockchain à l’échelle mondiale, une solution alternative de disponibilité des données est nécessaire.
J’ai mentionné plus tôt que Plasma est le meilleur que nous puissions faire pour la Layer 2 d’Alt DA, mais il a aussi des compromis. Nous devons le communiquer clairement : si ce fournisseur de données tombe en panne, les fonds seront perdus. Mais ce que nous devons vraiment faire comprendre pour Plasma, c’est : « Si cette couche de disponibilité des données tombe en panne, les utilisateurs devront payer des frais de publication L1, et ces frais ne seront pas récupérés. » Pour comprendre le modèle de sécurité de Plasma, vous diriez : « C’est le fournisseur DA, et ce fournisseur peut tomber en panne et avoir besoin de $X par jour pour assurer la sécurité de la communauté. » ”
Ensuite, vous pourriez multiplier ce coût par le temps de la fenêtre de sortie et dire : "Si un fournisseur malveillant de DA se présente, le coût net sera de X dollars, ce qui est essentiellement le coût de ces défis jusqu'à ce que les gens puissent retirer leurs fonds." C'est une question très délicate qui suscitera certainement beaucoup de discussions sur les compromis. Vous pouvez évidemment avoir des sources de DA plus complexes, ce qui augmentera le coût des attaques et réduira la possibilité de brûler de l'argent.
Dans le même temps, cela augmente le coût du système. Donc, en fin de compte, en tant que gardiens de cette technologie, nous devons exposer ces compromis très clairement. Je pense que vous avez raison de dire que les fournisseurs de DA auront naturellement une incitation et ne nous mettront pas dans le dilemme du pêcheur parce qu’ils ne peuvent pas finir par retirer les fonds et ne peuvent que laisser les autres brûler l’argent. C’est probablement l’un de mes débats préférés Layer 2 la mise à l’échelle. C’était l’un des débats les plus originaux – avant que nous ne réalisions « nous devrons peut-être le faire un jour ou l’autre, mais nous pouvons contourner ce problème en publiant des données dans L1 ». C’est donc formidable de voir ce sujet revenir aux yeux du public.
Je pense que dans l'année à venir, nous verrons une compréhension accrue de cette question par la communauté.
La boucle est bouclée, de l’OPCraft aux biomes de Redstone
05.Standardisation de la chaîne et évolution vers l’avenir
tdot: Nous avons besoin d'outils plus performants pour vérifier les chaînes et garantir la disponibilité des données, assurer l'exactitude des sorties et effectuer des vérifications complètes, en veillant à ce qu'il y ait au moins une personne pour effectuer la vérification par défaut.
Plus les validateurs sont longs, plus la valeur de la chaîne est grande. Donc, si nous pouvons rendre moins cher et plus facile pour les gens d’exécuter ces validateurs, alors nous pouvons mettre en commun les ressources de la communauté et nous assurer qu’il y a toujours quelqu’un à contester et à vérifier. C’est l’une des étapes importantes pour améliorer la sécurité et la décentralisation.
C’est vraiment génial que nous puissions travailler ensemble sur ces choses. Cela donne au protocole plus d’attention longue, plus d’idées longues, plus de discussions longues et plus de tests plus longs. Je pense que le modèle Plasma sera géré par plus de longues personnes, et plus de personnes longues le découvriront et l’expérimenteront. De cette façon, l’exécution de votre protocole et le fait de savoir que plus de personnes longues l’exécutent également, ajoute plus de longs examens et de tests de combat au protocole. Finalement, nous trouverons des solutions très fiables. J’ai donc hâte d’y être. Si nous avions simplement développé ce protocole dans le coin nous-mêmes, l’expérience aurait été complètement différente.
Ben: C'est pourquoi cette méthode est très bonne pour nous aider à comprendre où se trouvent les problèmes. Nous avons réalisé que la normalisation est essentielle pour la pile OP. Nous devons fournir une manière uniforme et facile à comprendre pour permettre aux gens de faire fonctionner ces chaînes, tout en garantissant leurs caractéristiques de sécurité revendiquées. Car un défi réside dans le fait que des équipes externes pourraient apporter des modifications en apparence mineures, mais qui pourraient en réalité avoir un impact considérable sur la sécurité, les performances ou le comportement global du système. De notre point de vue, la normalisation est un outil puissant. Grâce aux discussions au sein de la communauté, nous pouvons non seulement obtenir un large éventail d'opinions, mais également établir un ensemble de normes qui permettent à chacun de faire fonctionner et de communiquer de manière responsable.
L2Beat propose un modèle de sécurité qui est une ressource publique très précieuse. Actuellement, il est encore très personnalisé et dispersé. Ce dont nous avons besoin, c'est de le mettre en mode Plasma lors de la compilation ou du déploiement de la version OP Stack, de manière à ce que le système puisse produire les hypothèses de sécurité que vous assumez. Par conséquent, la normalisation est essentielle. Vous avez raison, si tout le monde développe dans son propre petit environnement sans une mise en œuvre standard unifiée, ces problèmes seront amplifiés de manière exponentielle.
tdot: Il y a déjà des parties prenantes et des applications qui l'utilisent, ce qui est vraiment génial. Une fois en production, vous pourrez mieux comprendre les besoins des utilisateurs. Vous saurez qui utilise cette chaîne, qui la déploie, puis pourrez communiquer avec eux et leur demander : "Qu'attendez-vous ? De quoi avez-vous besoin ? Combien êtes-vous prêt à dépenser pour cela ? Est-ce un prix raisonnable ?" Ainsi, vous pourrez obtenir des commentaires réels au lieu de vous engager dans des discussions sans fin sans vraiment comprendre le problème.
L'importance de la théorie des jeux est qu'elle doit être testée dans le monde réel. Sinon, vous ne saurez jamais quel est le véritable effet. Bien que des spéculations puissent être faites, des imprévus surviendront toujours. Par conséquent, je pense qu'il est nécessaire d'itérer et de tester les expériences dans un environnement relativement sûr. C'est aussi très intéressant. C'est comme avoir différents niveaux de sécurité ; certaines chaînes ont des normes de sécurité élevées, tandis que d'autres sont à la pointe de la technologie et permettent des expérimentations audacieuses.
Ces chaînes sont peut-être moins chères et plus performantes, mais elles sont aussi plus risquées. Vous pouvez expérimenter et stimuler l’innovation. Par conséquent, il y a des risques et des avantages à être parmi les premiers utilisateurs de ces on-chains qui sont poussés à la limite. C’est ce à quoi nous avons pensé cette année.
Ben : Le collectif explore également des moyens d’apporter sa contribution. Je pense que vous le dites très bien. Vous devrez faire un compromis entre tester de nouvelles améliorations dans un environnement réel et gérer une chaîne qui a déjà fait ses preuves et qui est sécurisée. Nous considérons l’OP Stack comme un facilitateur Open Source de ce processus, où des technologies étonnantes sont développées à la pointe de la technologie, éprouvées pour fonctionner, puis retournées pour être incorporées dans des normes pour que tout le monde puisse en profiter.
Ceci est tout à fait conforme au concept de jeu à somme positive, open source et hausse. Vous avez tout à fait raison. Il y a des compromis qui doivent être faits pour faire progresser les technologies de pointe. Il est essentiel de créer des processus qui nous seront bénéfiques dans les moments importants, tels que la sortie de Redstone, tout en abordant des améliorations flexibles dans l’espace de mise à l’échelle d’Ethereum, qui peut encore avoir une décennie de marge de croissance plus courte. Nous devons intégrer ces expériences validées dans une norme clairement définie.
Nous sommes très heureux de commencer ce voyage avec vous.
tdot: Je pense que, malgré ces différences, il peut toujours faire partie de Superchain. C'est très intéressant en termes de partage des revenus, de motivation des gens à expérimenter et à déployer de nouvelles chaînes, tout en bénéficiant à l'ensemble de la communauté et à différentes implémentations.
Ce modèle est très bon, contrairement aux gens qui exécutent des forks dans leurs coins, il est difficile de les suivre et cela peut poser des problèmes de sécurité. Ici, vous avez un cadre pour vérifier et examiner les actions des gens. C'est sans aucun doute un énorme avantage. Je pense que c'est quelque chose qui s'est formé naturellement. C'est fascinant de voir son développement au cours de la dernière année.
Ben : Nous sommes dans le jeu, mec, nous devons continuer à repousser les limites. En fin de compte, ceux-ci devraient être considérés comme des extensions d’Ethereum à long terme. Au cours de la dernière année, le processus d’amélioration du cumul a été mis en ligne, ce qui est une chose vraiment cool qui relie essentiellement les développeurs principaux de Layer 1 et Layer 2.
À l’avenir, nous verrons Layer 2 adopter progressivement certains des EIP importants que tout le monde est si impatient de mettre en œuvre sur la couche 1. Layer 2 est une excellente plate-forme de test, et les améliorations commencent par quelques forks aléatoires, puis fusionnent dans la pile OP, et enfin publient.
Finalement, ces améliorations feront leur chemin jusqu’à la couche 1, et tout le monde applaudira. Ça va être plutôt cool. C’est un peu comme transformer Ethereum en un organisme, et la base de code Ethereum est son ADN.
tdot: Cela a aussi beaucoup de sens.
Ben: Oui, c'est génial. Revenons à la chaîne Redstone étonnante, tdot, êtes-vous excité par ce qui se passe sur Redstone en ce moment ?
tdot : Oui, nous avons la meilleure application. Pour être honnête, je suis toujours époustouflé. J’ai joué à This Cursed Machine[11], qui est actuellement l’application la plus folle fonctionnant sur Redstone. C’est vraiment génial, surtout quand les gens libèrent leur créativité et créent quelque chose qu’ils n’ont jamais fait auparavant.
Ben: Est-ce le premier jeu d'horreur off-chain ? Je ne suis pas sûr d'avoir déjà vu quelque chose comme This Cursed Machine auparavant.
tdot: Je ne sais pas. C'est une bonne question. Je pense que mettre ces expériences hors chaîne a vraiment dynamisé votre développement. J'apprécie vraiment que les gens créent ces nouveaux jeux au lieu de simplement porter des jeux existants hors chaîne.
Ben: Je ne veux pas vraiment comparer l'ère du début d'Internet avec le capital-risque classique, mais je pense vraiment que le monde autonome sur Redstone est en effet à la pointe de la tendance. Pour faire une comparaison, lorsque Internet est apparu, l'intuition des gens était de transposer ce qui existait déjà en ligne, comme transformer les journaux en version numérique.
Le véritable innovation réside dans la compréhension de la façon d'utiliser les fonctionnalités d'un nouveau système. En réalité, les journaux en ligne ne valent pas autant qu'un mini-journal de 240 caractères que chacun possède. Pour moi, cela ressemble beaucoup à l'espace d'innovation sur Redstone. La communauté actuelle est en train de repousser les limites des jeux et du monde en explorant comment les faire évoluer.
**tdot:**Oui, nous sommes très excités. Cet environnement attire vraiment une communauté très active où les gens peuvent pousser leurs idées à l'extrême. Cela représente une grande amélioration par rapport à une simple mentalité spéculative. Je pense que l'idée de jouer à des jeux avec des amis est également très chaleureuse et attire de très bonnes personnes.
C'est maintenant le moment de profiter du plaisir, mon pote. Je pense que nous ne sommes pas encore tout à fait prêts à accueillir tout ce qui est à venir, donc j'ai vraiment hâte.
Ben : Le plasma est de retour. Long live Plasma.
tdot: Nous sommes très excités, la construction vient de commencer.
Entretien avec les développeurs de Redstone : La renaissance des jeux sur chaîne complète et Plasma
DEVS ON DEVS: TDOT ET BEN JONES
原文链接:
"Dans cette édition spéciale de Devs on Devs, nous invitons le mode Plasma[1][2]Le développeur principal du protocole est tdot[3](Redstone en même temps.)[4]développeurs) et Optimism[5]Co-fondateur Ben Jones。 L’optimisme est le principal catalyseur de la pile OP. Le mode Plasma permet aux développeurs de s’appuyer sur la pile OP, mais au lieu de publier des données sur L1, ils ont la possibilité de passer à des fournisseurs de données off-chain, ce qui permet de réduire les coûts et d’améliorer l’évolutivité. Dans cette conversation, ils explorent les origines du partenariat Redstone et Optimism, l’importance de la relance de Plasma, la nécessité de mettre en production des protocoles expérimentaux, la future feuille de route pour le mode Plasma et la pile OP, et leur enthousiasme pour la croissance de l’espace de jeu omnichain. ”
01. Comment utiliser le mode Plasma pour améliorer la pile OP
Ben: Quel est le processus d'amélioration de la pile OP ?
tdot: J'ai rejoint Lattice il y a environ un an, en charge spécifiquement du mode Plasma. L'objectif est très clair : nous avons beaucoup de MUD.[6]Les applications consomment beaucoup de gas et nous essayons de mettre beaucoup de données sur la chaîne, il est donc nécessaire de trouver une solution à la fois abordable et adaptée à ces besoins. L'équipe de Lattice a déjà effectué des expériences sur OP Stack, telles que la prototypage de certains mondes on-chain et leur déploiement sur OP Stack. Nous avons constaté que OP Stack est déjà très performant.
于是我们问自己,“怎么才能让它更便宜?” 基本的假设是,“我们认为 OP Stack 是最符合以太坊理念且完全兼容 EVM 的框架。” 在主网上运行的东西可以同样在 OP Stack 上运行,这是理想的解决方案。但我们希望它更便宜。
Quand calldata était encore une source de disponibilité des données (DA) sur la chaîne OP Stack, cela coûtait très cher. Par conséquent, il était évident que nous ne pouvions pas utiliser calldata pour lancer un L2, car nos jeux en chaîne complète et notre monde MUD nécessitaient un débit plus élevé. Nous avons donc décidé de commencer à explorer d'autres solutions de disponibilité des données (Alt DA). En fait, l'exploration d'Alt DA avait déjà été mentionnée dans le document initial sur OP Stack.
Alors nous nous sommes demandé : "Et si nous commencions par une approche hors chaîne pour les DAO ?" Nous voulions que tout le modèle de sécurité et tout le contenu puisse reposer sur Ethereum L1. Nous avons donc évité les autres solutions de DAO alternatives et avons décidé de stocker les données dans un système de stockage centralisé hors chaîne, puis de trouver un modèle de sécurité efficace sur L1.
C’est pourquoi nous réutilisons certains des anciens concepts de Plasma et les mettons au-dessus des rollups. Il y a quelques différences ici. La grande question est la suivante : comment mettre en œuvre off-chain DA et off-chain défis en matière de données en plus de la pile OP existante ? Notre objectif est d’apporter le moins de modifications possible à la pile OP sans aucun impact sur le chemin de cumul, car nous ne voulons pas affecter la sécurité des autres chaînes de cumul qui utilisent la pile OP.
Lors de la conception de rollup, vous ne pensez pas, "Que se passe-t-il si quelqu'un modifie le flux de génération de données pour stocker des données ailleurs ?" Même avec ces modifications, la pile OP reste très puissante et fonctionne bien dès le départ. C'est le premier changement que nous avons apporté.
Après cela, nous devons rédiger des contrats pour créer ces défis. Il existe des défis DA pour forcer les données off-chain. Il s’agit de la deuxième étape, l’intégration du contrat dans le processus. Nous devons construire l’ensemble du système intégré pendant le processus de dérivation afin que vous puissiez dériver des données d’une source DA off-chain ainsi que d’un contrat de défi DA L1 au cas où les données seraient soumises à la chaîne off-chain pendant le processus de résolution de défi.
C'est là l'essentiel de la question. C'est très complexe car nous voulons maintenir l'élégance et la stabilité de la situation. En même temps, c'est un concept relativement simple. Nous n'essayons pas de tout réinventer ou de changer l'ensemble de la pile OP, nous essayons plutôt de maintenir 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 d’un point de vue OP. Vous avez mentionné certains des premiers travaux de Lattice. Exactement au même moment, chez Optimism, nous avons réécrit de bout en bout la quasi-totalité de la pile OP, que nous appelons Bedrock.
Fondamentalement, après deux ans de construction de Rollup, nous avons fait un pas en arrière et réfléchi à la question : "Eh bien, à quoi ressemblerait-il si nous appliquions toutes les connaissances que nous avons acquises à l'extrême ?" Cela a évolué pour devenir la bibliothèque de code appelée Bedrock, qui est la mise à niveau la plus importante que nous ayons apportée au réseau.
在那个时候,我们与你们合作了一个叫OPCraft的项目。[7][8]的项目,我认为BiomesC'est son héritier spirituel, c'est la fois où nous avons le plus de plaisir à jouer hors-chaîne. En même temps, nous avons aussi soufflé un peu, car d'autres personnes 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 de nombreuses personnes peuvent exécuter des chaînes.
Karl d'Optimism observe le gameplay OPCraft.
并不是 seulement les personnes qui ont développé de vastes bibliothèques de code complexes peuvent le faire. Quand nous avons commencé à collaborer, voir d'autres personnes prendre en charge cette bibliothèque de code et accomplir des choses vraiment incroyables, c'était une grande affirmation. Et voir cette situation se déployer sur Plasma dans des applications concrètes, c'est vraiment génial. Je peux même vous parler un peu de cette histoire.
Avant qu’Optimism ne devienne Optimism, nous travaillions sur une technologie appelée Plasma. À ce moment-là, nous avions une tâche qui allait bien au-delà de ce que nous étions en mesure de faire évoluer la communauté à l’époque. Le design que vous avez vu dans les premiers jours de Plasma n’a peut-être pas d’équivalent direct au Plasma d’aujourd’hui.
Aujourd'hui, Plasma est beaucoup plus simple. Nous examinons séparément les preuves et les défis de vérification d'état par rapport aux défis de 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 "Plasma est mort". C'était un mème de l'époque de l'évolution de l'évolutivité d'Ethereum.
Mais nous avons toujours pensé que "Plasma n'est pas mort, mais nous pouvons simplement essayer une tâche plus simple". Maintenant, nous utilisons des termes différents. Par exemple, à l'époque, il y avait des concepts de sortie (exits), maintenant vous pouvez regarder 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 la pile OP utilisée par d'autres, mais aussi évoluer à partir de ce que nous avons initialement essayé de faire de manière très confuse et immature, c'est vraiment incroyable. Nous avons parcouru un cycle complet et vous avez créé de superbes abstractions autour d'eux et les avez fait fonctionner de manière logique et raisonnable. C'est vraiment cool.
La couverture de Coindesk depuis que Plasma est devenu Optimism
02. Le plus important est de passer rapidement en production.
**tdot:**Le mode Plasma présente encore des défis et des problèmes non résolus, et nous travaillons toujours à les résoudre. La clé est de trouver comment éviter de prendre une décennie entière ? Vous voyez ce que je veux dire, n'est-ce pas ? Nous devons atteindre rapidement une phase où nous pouvons livrer des résultats.
C’est ce que nous pensons. Nous avons déjà les applications MUD les plus longues qui souhaitent être mises en ligne sur le mainnet immédiatement. Nous devons préparer un mainnet pour ces jeux dès que possible. Les gens attendent déjà, et ils sont prêts. Vous avez besoin d’une chaîne rapide et opérationnelle pour exécuter toutes ces applications afin qu’elles puissent évoluer et s’améliorer en parallèle pendant que nous résolvons les problèmes. Il faut un temps long pour passer de la R&D à la stabilité de la production.
Il faut beaucoup de temps pour mettre quelque chose en ligne sur le mainnet et le rendre sans autorisation, robuste et sécurisé. C’est incroyable de voir tout le processus que nous avons suivi pour en arriver là. C’est pourquoi nous devons être très agiles parce que les choses sont si longues. L’ensemble de l’écosystème se développe très rapidement. Je pense que tout le monde innove beaucoup. C’est pourquoi vous devez suivre le rythme, mais vous ne pouvez pas non plus faire de compromis sur la sécurité et les performances, sinon le système ne fonctionnera pas.
Ben: Ou peut-être que c'est un fardeau technique. Le principe de modification minimale dont vous avez parlé est l'un des concepts clés lors de la réécriture de Bedrock. J'ai mentionné la réécriture de bout en bout, mais ce qui est encore plus important, c'est que nous avons réduit d'environ 50 000 lignes de code, ce qui est déjà très significatif. Parce que vous avez raison, ces choses sont vraiment difficiles.
Chaque ligne de code supplémentaire vous éloigne de l'environnement de production, rendant les choses plus difficiles à tester en situation réelle et introduisant davantage d'opportunités d'erreur. Nous vous sommes donc très reconnaissants pour tous vos efforts dans la promotion de ce processus, en particulier pour votre contribution au nouveau mode de fonctionnement de OP Stack.
**tdot:**OP Stack a vraiment créé une manière de faire avancer rapidement ce genre de choses. La coordination entre nous est très difficile car nous sommes clairement deux entreprises différentes. Chez Lattice, nous construisons un jeu, un moteur de jeu et une chaîne.
Et vous construisez des centaines de choses et livrez régulièrement tous ces produits. Du point de vue de la coordination, cela est vraiment très difficile.
Ben: Oui, il y a encore beaucoup de chemin à parcourir. Mais c'est précisément là que réside le charme central de la modularité. Pour moi, du point de vue de la pile OP, c'est l'une des choses les plus excitantes, sans même parler des jeux et mondes virtuels incroyables construits sur Redstone. Purement du point de vue de la pile OP, c'est un exemple très puissant qui témoigne de la participation de nombreux développeurs principaux talentueux qui ont rejoint et amélioré cette pile, c'est vraiment formidable.
C'est la première fois que vous pouvez changer significativement les propriétés du système avec une seule valeur booléenne clé. Il y a encore beaucoup de chemin à parcourir pour pouvoir le faire complètement, comme vous l'avez dit. Mais même pour s'en approcher efficacement, il faut un soutien modulaire, n'est-ce pas ? Pour nous, voir que vous avez réussi à le faire sans avoir à réécrire L2 Geth est vraiment rassurant. Cela prouve que la modularité fonctionne.
tdot: Les choses ont maintenant beaucoup progressé. À partir de cet exemple, vous avez transformé tout en petits modules indépendants qui peuvent être ajustés et dont les propriétés peuvent être modifiées. Je suis donc très impatient de voir quelles nouvelles fonctionnalités seront intégrées. Je me souviens que nous étions inquiets d'avoir une bifurcation contenant toutes les modifications apportées à OP Stack et qu'il fallait les fusionner dans la branche principale. Nous pensions alors : "Oh mon Dieu, il sera fou de passer en revue tout ce contenu."
Nous devons le décomposer en parties plus petites, mais tout le processus s'est déroulé très bien. La collaboration avec l'équipe a été très bonne, donc le processus de révision a également été agréable. Cela semble très naturel. De plus, je pense que le processus s'est déroulé très rapidement pour examiner et résoudre certains problèmes potentiels. Tout s'est déroulé étonnamment bien.
Ben : C’est génial. L’une de nos priorités cette année est de créer des chemins de contribution pour la pile OP. Merci beaucoup d’avoir participé aux tests et d’avoir piloté ces processus. Je suis heureux que les processus n’aient pas été écrasants et que nous ayons obtenu des résultats. En parlant de cela, je suis curieux, de votre point de vue, comment ce travail évolue-t-il ensuite ? Qu’est-ce que vous avez le plus hâte de développer ensuite ?
tdot: Il y a plusieurs orientations de travail différentes. L'intégration principale est basée sur le mécanisme de preuve de défaillance. Nous adoptons une approche progressive pour décentraliser l'ensemble de la pile technologique et ajouter ses caractéristiques sans permission, avec pour objectif final de réaliser des fonctionnalités sans permission et de sortie forcée.
Nous avons cet objectif ultime et nous l’atteignons progressivement tout en maintenant la sécurité. L’un des défis est qu’il est parfois plus facile de ne pas aller sur le mainnet car il n’y a pas besoin d’un fork dur. Vous pensez peut-être : « Oh, je vais juste attendre que tout soit complètement prêt avant de sortir pour qu’il n’y ait pas de fork dur et pas de fardeau technique. » « Mais si vous voulez passer rapidement en direct sur le mainnet, vous devez faire face à ces mises à niveau complexes et les publier fréquemment. Faire cela et maintenir une haute disponibilité est toujours un défi.
Je pense qu'il y aura de nombreuses améliorations 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 un certain espace d'optimisation pour la soumission groupée des engagements. Pour l'instant, nous faisons simplement un engagement par transaction. Et l'engagement n'est que le hachage des données d'entrée stockées hors chaîne.
Nous l’avons gardé aussi simple que possible pour le moment, afin que l’examen soit simple et rapide, et qu’il n’y ait pas de grandes différences pour la pile OP. Mais il existe certaines optimisations qui peuvent le rendre moins cher, comme le traitement par lots des engagements ou leur validation dans des objets blob, ou l’adoption d’une approche différente. Nous allons donc certainement nous pencher sur la question pour Goutte le coût de la L1.
C’est quelque chose qui nous enthousiasme beaucoup. Bien sûr, nous attendons également avec impatience tout ce qui concerne l’interopérabilité et la possibilité d’interagir entre toutes les chaînes. Le comprendre serait un énorme pas en avant pour les utilisateurs.
C’est long que vous aurez à faire le travail. Mais nous aimerions comprendre à quoi cela ressemble en mode Plasma, et avec différentes hypothèses de sécurité.
**Ben:**En parlant de cela, ce sera un autre test pour la modularité du module OP Stack. Vous avez mentionné les preuves de défaillance (fault proofs), nous avons hâte de les voir en ligne dans le mode Plasma. C'est également une fonctionnalité importante dans le roll-up qui sera déployée sur le Mainnet dans les prochains mois.
L’une des choses passionnantes à propos de la construction de cette base de code est que, bien qu’il y ait quelques mises en garde, relativement parlant, il est possible d’exécuter une preuve d’échec dans un nouvel environnement en cliquant simplement sur le bouton de recompilation. C’est donc très excitant de voir cela mis en œuvre dans la pratique, car ce sera un autre exemple de « fonctionnalité qui fonctionne tout simplement ». En tant que l’une des premières équipes à faire un changement à grande échelle, je suis sûr que ce ne sera pas complètement sans friction, mais c’est certainement un avantage très excitant pour la communauté de pouvoir essayer de publier une preuve d’échec sur une base de code fortement modifiée.
tdot: Sa conception est très bonne, vous pouvez insérer vos entrées comme avec un "oracle" et modifier ces sources de données dans le processus de preuve de défaillance. Cela ne devrait pas être trop difficile. Bien sûr, vous devez vous assurer qu'il fonctionne correctement tout au long du processus de bout en bout, mais je pense que le publier ne devrait pas être trop difficile. Cela pourrait également être un point clé de la feuille de route à venir.
Dans l’ensemble, nous sommes très intéressés par l’amélioration et l’optimisation des performances. Il n’y a pas de solution miracle, et chaque petit problème doit être résolu étape par étape. Si l’ensemble de la communauté se penche sur ces questions, comme une armée de développeurs qui travaillent sans relâche pour que nous puissions progressivement mettre en place une chaîne performante construite sur une stabilité incroyable.
Le logo MUD
03.MUD, Redstone et la collaboration avec Optimism
Ben: Je suis très impatient de voir les progrès que vous avez réalisés dans l'intégration de MUD et OP Stack. Je pense qu'il y a un immense potentiel ici. L'une des choses les plus excitantes sur lesquelles nous allons travailler au cours des prochaines années est de continuer à faire avancer les améliorations significatives de la performance et du débit discutées dans Ethereum L1.
La communauté de recherche sur Ethereum a fait de nombreux efforts dans ce domaine, mais c'est aussi un domaine à haut risque. Certaines modifications majeures nécessitent une plateforme de test. Un exemple auquel je pense est le problème d'expiration de l'état. Il ne fait aucun doute que votre travail est impressionnant car il repousse les limites de la quantité de contenu incroyable que la chaîne peut contenir. Je pense qu'un résultat que nous verrons est la véritable émergence du problème de "hausse de l'état". Cela signifie essentiellement que plus on joue, plus les nœuds doivent suivre de contenu et plus il est difficile d'exécuter des transactions.
La communauté Ethereum a travaillé sur ce problème pendant de nombreuses années et a proposé des solutions. Je pense que ces solutions sont délicates car elles modifient fondamentalement la structure de gestion des états. Fondamentalement, vous devez fournir ces preuves à un moment donné afin de pouvoir abandonner l'état, à moins que quelqu'un ne veuille le restaurer.
Je suis vraiment excité parce que je pense que le MUD est l’environnement idéal pour que vous puissiez réellement mettre en œuvre ces changements et les faire fonctionner. Vous avez fait un excellent travail de gestion de l’État et vous avez déjà un cadre et un modèle que tout le monde suit. J’ai aussi vraiment hâte d’y être, parce que je pense que le framework sur lequel vous vous concentrez sur la façon de construire des applications sur Redstone, sera en mesure d’expérimenter avec ce framework, d’essayer ces améliorations vraiment délicates qui vont apporter d’énormes gains de performance, mais qui doivent mettre à jour le paradigme. Je pense que vous avez le potentiel de faire une percée dans ce domaine, donc je suis très enthousiaste à ce sujet.
tdot : C’est un bon point. J’aime l’idée que les MUD empêchent les développeurs de travailler sur toutes sortes de fonctions de base. Fondamentalement, OP Stack est la couche de base, et vous avez juste affaire à des primitives de protocole et des choses comme ça. Développer avec des MUD, en revanche, consiste à simplifier ces processus. Lorsque nous entrons dans le monde de l’interopérabilité des chaînes les plus longues, nous réfléchissons à la façon de faire abstraction des chaînes les plus longues. C’est certainement une question importante qui vient à l’esprit lorsque l’on considère la combinaison de MUD et de Redstone.
Donc nous devons également comprendre à quoi ressemble une expérience de développement idéale. Il devient difficile de résoudre ces problèmes lorsque vous traitez avec toutes ces chaînes et vos utilisateurs se lassent de passer constamment de l'une à l'autre. Si vous avez beaucoup de L2, cela finira par être confus. J'ai récemment entendu quelqu'un dire: "Je ne me souviens pas sur quelle chaîne se trouve mon argent." Il est très compliqué de suivre les soldes sur chaque chaîne. Nous avons certainement besoin d'une certaine abstraction pour simplifier ce problème. Sinon, cela deviendra très complexe. MUD est sans aucun doute une très bonne opportunité pour résoudre ce problème.
Ben: J'attends ton aide. Il y a beaucoup de travail, mais c'est super cool.
tdot: Je pense que travailler avec vous est certainement d'une grande aide pour nous, car nous sommes une très petite équipe d'environ 15 personnes. Donc, il est évidemment difficile de faire face à toutes ces choses. Lorsque vous développez et collaborez sur Superchain, vous obtenez soudainement une grande entreprise avec tous les ressources d'ingénierie dont vous pourriez avoir besoin. Je suis essentiellement le seul ingénieur travaillant sur le mode Plasma de Lattice, mais en collaborant avec Optimism et en profitant de la puissance de tous les autres développeurs principaux, nous pouvons grandement améliorer notre productivité, ce qui nous permet de réaliser des travaux qui seraient normalement difficiles à réaliser indépendamment. Cet effet de volant est vraiment génial.
Quand j’en fais l’expérience, je me sens très puissant. Je me suis dit : « Wow, je n’arrive pas à croire qu’on vient de faire ça. » J’avais l’impression que tout était possible.
Ben : Mon cœur se réchauffe vraiment. Je vous remercie.
Sur la base de quelles philosophies sont conçus la sécurité de Plasma et le fonctionnement de Layer 2 ? Lorsque des événements étonnants se produisent, cela déclenche souvent des débats sur les modèles de sécurité au sein de la communauté, ce qui indique généralement une avancée des limites technologiques. Lorsque des événements subtils mais dignes de discussion et d'enseignement se produisent, cela signifie généralement des progrès passionnants.
J’ai l’impression que nous ne nous sommes pas vraiment penchés sur la structure de conception de Plasma en tant que modèle de sécurité Layer 2. Je suis curieux de savoir ce que vous en pensez. J’ai quelques réflexions sur les débuts de Plasma et j’aimerais entendre ce que vous en pensez également.
04. Définition du mode Plasma
tdot: Je voudrais vous présenter le mode Plasma et ce qu'il signifie. Il s'agit d'une nouvelle fonctionnalité du stack OP que nous développons actuellement, qui est encore à l'étape expérimentale et qui comprend un aspect de Plasma, à savoir la disponibilité des données hors-chaîne.
Nous l'appelons Plasma car il promeut l'idée de stocker les données d'entrée hors chaîne. Au lieu d'utiliser L1 DA, vous stockez les données sur n'importe quel service de stockage, comme AWS ou IPFS. Ensuite, vous devez surveiller la disponibilité de ces données. Il faut au moins une personne pour vérifier si les données soumises sont disponibles.
Si les données deviennent indisponibles pour une raison quelconque, le protocole permet aux utilisateurs de se retirer de force dans les sept jours. Il manque encore certaines parties en cours de développement, telles que les preuves de défaillance à venir et les soumissions sans permission. Les utilisateurs peuvent utiliser Sentinel.[9]Vérification automatique de la disponibilité des données. Si les données deviennent indisponibles, vous devez lancer un défi sur L1.
Si les données ne sont pas disponibles, vous devez relever le défi, essentiellement pour forcer la mise en ligne des données ou réorganiser les données afin de pouvoir retirer les fonds et sortir de la chaîne. Donc, à ce stade, ces composants ne sont pas encore entièrement déployés. Nous tenons donc à souligner qu'il y a encore une certaine distance à parcourir pour atteindre les objectifs de non-permission et d'accessibilité totale, mais nous avançons progressivement.
Concernant le coût d'extraction des fonds lié à la contestation des données des utilisateurs, il existe quelques hypothèses. Ces éléments sont encore en cours de définition et nous optimisons ces projets pour les rendre finalement moins chers et plus faciles d'accès. Nous élaborons une feuille de route pertinente. Cela diffère du plan de déploiement des preuves de fraude (fraud proofs) et du trieur décentralisé dans la feuille de route de OP Stack.
L’un des problèmes de ce protocole est le dilemme du pêcheur[10]Cela signifie que vous avez besoin d’un « pêcheur » honnête pour être en ligne à tout moment, car si personne n’est en ligne, vous ne savez pas si les données sont devenues indisponibles, et vous ne pouvez pas retirer de fonds pendant la fenêtre de retrait, et la chaîne peut être attaquée par les opérateurs.
Le dilemme du pêcheur
Vous avez plusieurs façons de résoudre ce problème. Vous pouvez motiver les gens à rester en ligne en utilisant un mécanisme de récompense, créer une communauté forte et veiller à ce que les parties prenantes qui ont investi davantage dans la chaîne, comme les utilisateurs qui exploitent des ponts ou fournissent de la liquidité, restent en ligne et garantissent l'honnêteté de la chaîne et des opérateurs. Ces utilisateurs devraient rester en ligne et relever les défis en cas de problème. Il est évident que ce sujet est très intéressant car il existe de nombreuses façons de résoudre ce dilemme et il reste encore beaucoup de travail à faire pour rendre ce système accessible à tous et garantir que les utilisateurs continuent de se préoccuper de la maintenance de la chaîne.
Ben : Qu’est-ce que Layer 2 ? C’est une Blockchain qui utilise la couche 1 plus efficacement. L’analogie classique est la suivante : « Vous n’allez pas au tribunal pour encaisser un chèque, vous allez au tribunal lorsque le chèque est sans provision. » « C’est la philosophie de conception de base derrière ces systèmes optimistes, et c’est notre réflexion sur le roll-up : utiliser la Blockchain plus efficacement. En utilisant L1 uniquement en cas de litige, le débit total de la Blockchain peut être augmenté. Je pense que c’est aussi une bonne analogie pour le modèle Plasma. Le modèle Plasma élargit essentiellement le concept de cumul, non seulement pour résoudre les litiges de retrait, mais aussi pour exiger la disponibilité des données de transaction elles-mêmes.
Je pense que cela sera un outil très puissant car en le mettant en œuvre, on peut utiliser Layer 1 de manière plus efficace et traiter beaucoup plus de données dans le système Layer 2, ce qui coûte beaucoup moins cher que de n'utiliser que roll-up. Donc c'est très excitant. Plus important encore, cela vous permet d'améliorer l'état existant, ce qui est impossible sans le mode Plasma.
Bien sûr, il n'est pas parfait. Il existe le dilemme du pêcheur (Fisherman's Dilemma), qui pose certaines exigences fondamentales pour tout le système. La chose la plus excitante à propos de Plasma par rapport à d'autres systèmes Alt DA est qu'il transforme les compromis de sécurité en compromis d'activité.
Dans d’autres systèmes, vous ne pouvez pas aller devant les tribunaux pour résoudre le problème des données. Les données existent par défaut. Cela signifie que si les données n’existent pas et que vous n’avez pas suffisamment de preuves pour prouver le statu quo devant les tribunaux, vous avez des problèmes. En revanche, le modèle Plasma constitue un bon compromis en ajoutant une nouvelle forme de défi, en évitant la perte de données et en faisant payer la communauté pour publier des données en L1.
Pendant la résolution des différends, vous pourriez ne pas connaître l'état de la chaîne, mais il est préférable de faire des compromis sur l'activité que sur la sécurité, car un compromis sur l'activité signifie que vous pourriez ne pas connaître l'état de la chaîne pendant un certain temps, tandis qu'un compromis sur la sécurité signifie que vous ne savez pas si les retraits de la chaîne sont valides, ce qui pourrait permettre à quelqu'un d'effectuer des retraits non valides. C'est ma vision du modèle Plasma.
Il étend le concept de "ne pas aller au tribunal pour encaisser un chèque, mais plutôt pour aller au tribunal lorsque le chèque est refusé" et l'applique pour améliorer les compromis lors de l'utilisation de Alt DA. Ainsi, même si les fonds peuvent être perdus, vous ne rencontrerez que des cas où l'état de la chaîne est temporairement inconnu et où les utilisateurs doivent payer des frais de publication de données. Je pense que c'est un compromis très excitant.
tdot: Lorsque nous utilisons le terme "Plasma", il y a effectivement certains risques car il est chargé d'histoire. Le problème réside dans la définition. Lorsque nous avons annoncé le mode Plasma et l'avons déployé sur le Mainnet, beaucoup de personnes ont pu penser qu'il était presque identique à celui décrit par Vitalik et d'autres.
En fait, il s’agit toujours de la pile OP. Lorsque nous avons introduit ces fonctionnalités de type plasma dans la pile OP, nous n’avons pas repensé la pile OP. Nous maintenons toujours les hypothèses de sécurité de la pile OP et ajoutons la disponibilité des données (DA) off-chain en plus de cela. Ce que nous avons emprunté à Plasma, c’est que les utilisateurs peuvent contester les données et vérifier leur utilisabilité, et si les données ne sont pas disponibles, ils peuvent forcer le fournisseur DA à les soumettre à l’off-chain, ou réorganiser les données pour la sortie. Notre hypothèse de sécurité est que, quoi qu’il arrive, les utilisateurs seront en mesure de forcer la sortie ou de retirer des fonds, même si l’opérateur de la chaîne ou le fournisseur DA est un nœud malveillant.
Afin ordre garantir cette situation, long mesures sont nécessaires. L’idée est de garantir d’abord les parties les plus élémentaires, et de développer progressivement certaines des garanties de la pile OP, de parvenir progressivement à la décentralisation et d’introduire progressivement ces garanties. Nous avons déjà les frameworks les plus longs pour évaluer la sécurité des rollups, construits par L2Beat et d’autres, qui sont très utiles à la communauté.
Mais Plasma lui-même ne convient pas parfaitement à ce modèle. Le problème est que si vous essayez d'adapter complètement le mode Plasma au framework rollup, il ne correspond pas parfaitement à toutes les étapes.
Nous avons encore besoin de mettre en œuvre certaines de ces fonctionnalités. Il est donc nécessaire d'avoir une feuille de route et une méthodologie claires. Je pense que ces éléments sont encore en cours de définition et d'amélioration. Il est très significatif que nous discutions ensemble de ces problèmes, trouvions leur signification et proposions une définition commune.
Ben : Oui, je suis tout à fait d’accord avec ça. Les progrès sur des éléments tels que la preuve d’échec sont importants, mais vous avez raison de dire que le modèle de sécurité de Plasma nécessite un nouveau cadre unique aux rollups. Si vous êtes suffisamment haussier sur la mise à l’échelle d’Ethereum, il n’y a pas d’autre option et vous aurez besoin d’une solution alternative de disponibilité des données (DA).
La réalité est que les rollups ont des compromis évidents. Ils sont plus faciles à construire, c’est pourquoi la communauté de mise à l’échelle a commencé à les construire en premier lieu. Mais si vous voulez un système Blockchain véritablement évolutif horizontalement, vous ne pouvez pas être limité par le débit de données L1. Et si vous n’utilisez que des rollups, vous êtes limité. Par conséquent, une fois que vous comprenez que l’objectif est d’amener la Blockchain à l’échelle mondiale, une solution alternative de disponibilité des données est nécessaire.
J’ai mentionné plus tôt que Plasma est le meilleur que nous puissions faire pour la Layer 2 d’Alt DA, mais il a aussi des compromis. Nous devons le communiquer clairement : si ce fournisseur de données tombe en panne, les fonds seront perdus. Mais ce que nous devons vraiment faire comprendre pour Plasma, c’est : « Si cette couche de disponibilité des données tombe en panne, les utilisateurs devront payer des frais de publication L1, et ces frais ne seront pas récupérés. » Pour comprendre le modèle de sécurité de Plasma, vous diriez : « C’est le fournisseur DA, et ce fournisseur peut tomber en panne et avoir besoin de $X par jour pour assurer la sécurité de la communauté. » ”
Ensuite, vous pourriez multiplier ce coût par le temps de la fenêtre de sortie et dire : "Si un fournisseur malveillant de DA se présente, le coût net sera de X dollars, ce qui est essentiellement le coût de ces défis jusqu'à ce que les gens puissent retirer leurs fonds." C'est une question très délicate qui suscitera certainement beaucoup de discussions sur les compromis. Vous pouvez évidemment avoir des sources de DA plus complexes, ce qui augmentera le coût des attaques et réduira la possibilité de brûler de l'argent.
Dans le même temps, cela augmente le coût du système. Donc, en fin de compte, en tant que gardiens de cette technologie, nous devons exposer ces compromis très clairement. Je pense que vous avez raison de dire que les fournisseurs de DA auront naturellement une incitation et ne nous mettront pas dans le dilemme du pêcheur parce qu’ils ne peuvent pas finir par retirer les fonds et ne peuvent que laisser les autres brûler l’argent. C’est probablement l’un de mes débats préférés Layer 2 la mise à l’échelle. C’était l’un des débats les plus originaux – avant que nous ne réalisions « nous devrons peut-être le faire un jour ou l’autre, mais nous pouvons contourner ce problème en publiant des données dans L1 ». C’est donc formidable de voir ce sujet revenir aux yeux du public.
Je pense que dans l'année à venir, nous verrons une compréhension accrue de cette question par la communauté.
La boucle est bouclée, de l’OPCraft aux biomes de Redstone
05.Standardisation de la chaîne et évolution vers l’avenir
tdot: Nous avons besoin d'outils plus performants pour vérifier les chaînes et garantir la disponibilité des données, assurer l'exactitude des sorties et effectuer des vérifications complètes, en veillant à ce qu'il y ait au moins une personne pour effectuer la vérification par défaut.
Plus les validateurs sont longs, plus la valeur de la chaîne est grande. Donc, si nous pouvons rendre moins cher et plus facile pour les gens d’exécuter ces validateurs, alors nous pouvons mettre en commun les ressources de la communauté et nous assurer qu’il y a toujours quelqu’un à contester et à vérifier. C’est l’une des étapes importantes pour améliorer la sécurité et la décentralisation.
C’est vraiment génial que nous puissions travailler ensemble sur ces choses. Cela donne au protocole plus d’attention longue, plus d’idées longues, plus de discussions longues et plus de tests plus longs. Je pense que le modèle Plasma sera géré par plus de longues personnes, et plus de personnes longues le découvriront et l’expérimenteront. De cette façon, l’exécution de votre protocole et le fait de savoir que plus de personnes longues l’exécutent également, ajoute plus de longs examens et de tests de combat au protocole. Finalement, nous trouverons des solutions très fiables. J’ai donc hâte d’y être. Si nous avions simplement développé ce protocole dans le coin nous-mêmes, l’expérience aurait été complètement différente.
Ben: C'est pourquoi cette méthode est très bonne pour nous aider à comprendre où se trouvent les problèmes. Nous avons réalisé que la normalisation est essentielle pour la pile OP. Nous devons fournir une manière uniforme et facile à comprendre pour permettre aux gens de faire fonctionner ces chaînes, tout en garantissant leurs caractéristiques de sécurité revendiquées. Car un défi réside dans le fait que des équipes externes pourraient apporter des modifications en apparence mineures, mais qui pourraient en réalité avoir un impact considérable sur la sécurité, les performances ou le comportement global du système. De notre point de vue, la normalisation est un outil puissant. Grâce aux discussions au sein de la communauté, nous pouvons non seulement obtenir un large éventail d'opinions, mais également établir un ensemble de normes qui permettent à chacun de faire fonctionner et de communiquer de manière responsable.
L2Beat propose un modèle de sécurité qui est une ressource publique très précieuse. Actuellement, il est encore très personnalisé et dispersé. Ce dont nous avons besoin, c'est de le mettre en mode Plasma lors de la compilation ou du déploiement de la version OP Stack, de manière à ce que le système puisse produire les hypothèses de sécurité que vous assumez. Par conséquent, la normalisation est essentielle. Vous avez raison, si tout le monde développe dans son propre petit environnement sans une mise en œuvre standard unifiée, ces problèmes seront amplifiés de manière exponentielle.
tdot: Il y a déjà des parties prenantes et des applications qui l'utilisent, ce qui est vraiment génial. Une fois en production, vous pourrez mieux comprendre les besoins des utilisateurs. Vous saurez qui utilise cette chaîne, qui la déploie, puis pourrez communiquer avec eux et leur demander : "Qu'attendez-vous ? De quoi avez-vous besoin ? Combien êtes-vous prêt à dépenser pour cela ? Est-ce un prix raisonnable ?" Ainsi, vous pourrez obtenir des commentaires réels au lieu de vous engager dans des discussions sans fin sans vraiment comprendre le problème.
L'importance de la théorie des jeux est qu'elle doit être testée dans le monde réel. Sinon, vous ne saurez jamais quel est le véritable effet. Bien que des spéculations puissent être faites, des imprévus surviendront toujours. Par conséquent, je pense qu'il est nécessaire d'itérer et de tester les expériences dans un environnement relativement sûr. C'est aussi très intéressant. C'est comme avoir différents niveaux de sécurité ; certaines chaînes ont des normes de sécurité élevées, tandis que d'autres sont à la pointe de la technologie et permettent des expérimentations audacieuses.
Ces chaînes sont peut-être moins chères et plus performantes, mais elles sont aussi plus risquées. Vous pouvez expérimenter et stimuler l’innovation. Par conséquent, il y a des risques et des avantages à être parmi les premiers utilisateurs de ces on-chains qui sont poussés à la limite. C’est ce à quoi nous avons pensé cette année.
Ben : Le collectif explore également des moyens d’apporter sa contribution. Je pense que vous le dites très bien. Vous devrez faire un compromis entre tester de nouvelles améliorations dans un environnement réel et gérer une chaîne qui a déjà fait ses preuves et qui est sécurisée. Nous considérons l’OP Stack comme un facilitateur Open Source de ce processus, où des technologies étonnantes sont développées à la pointe de la technologie, éprouvées pour fonctionner, puis retournées pour être incorporées dans des normes pour que tout le monde puisse en profiter.
Ceci est tout à fait conforme au concept de jeu à somme positive, open source et hausse. Vous avez tout à fait raison. Il y a des compromis qui doivent être faits pour faire progresser les technologies de pointe. Il est essentiel de créer des processus qui nous seront bénéfiques dans les moments importants, tels que la sortie de Redstone, tout en abordant des améliorations flexibles dans l’espace de mise à l’échelle d’Ethereum, qui peut encore avoir une décennie de marge de croissance plus courte. Nous devons intégrer ces expériences validées dans une norme clairement définie.
Nous sommes très heureux de commencer ce voyage avec vous.
tdot: Je pense que, malgré ces différences, il peut toujours faire partie de Superchain. C'est très intéressant en termes de partage des revenus, de motivation des gens à expérimenter et à déployer de nouvelles chaînes, tout en bénéficiant à l'ensemble de la communauté et à différentes implémentations.
Ce modèle est très bon, contrairement aux gens qui exécutent des forks dans leurs coins, il est difficile de les suivre et cela peut poser des problèmes de sécurité. Ici, vous avez un cadre pour vérifier et examiner les actions des gens. C'est sans aucun doute un énorme avantage. Je pense que c'est quelque chose qui s'est formé naturellement. C'est fascinant de voir son développement au cours de la dernière année.
Ben : Nous sommes dans le jeu, mec, nous devons continuer à repousser les limites. En fin de compte, ceux-ci devraient être considérés comme des extensions d’Ethereum à long terme. Au cours de la dernière année, le processus d’amélioration du cumul a été mis en ligne, ce qui est une chose vraiment cool qui relie essentiellement les développeurs principaux de Layer 1 et Layer 2.
À l’avenir, nous verrons Layer 2 adopter progressivement certains des EIP importants que tout le monde est si impatient de mettre en œuvre sur la couche 1. Layer 2 est une excellente plate-forme de test, et les améliorations commencent par quelques forks aléatoires, puis fusionnent dans la pile OP, et enfin publient.
Finalement, ces améliorations feront leur chemin jusqu’à la couche 1, et tout le monde applaudira. Ça va être plutôt cool. C’est un peu comme transformer Ethereum en un organisme, et la base de code Ethereum est son ADN.
tdot: Cela a aussi beaucoup de sens.
Ben: Oui, c'est génial. Revenons à la chaîne Redstone étonnante, tdot, êtes-vous excité par ce qui se passe sur Redstone en ce moment ?
tdot : Oui, nous avons la meilleure application. Pour être honnête, je suis toujours époustouflé. J’ai joué à This Cursed Machine[11], qui est actuellement l’application la plus folle fonctionnant sur Redstone. C’est vraiment génial, surtout quand les gens libèrent leur créativité et créent quelque chose qu’ils n’ont jamais fait auparavant.
Ben: Est-ce le premier jeu d'horreur off-chain ? Je ne suis pas sûr d'avoir déjà vu quelque chose comme This Cursed Machine auparavant.
tdot: Je ne sais pas. C'est une bonne question. Je pense que mettre ces expériences hors chaîne a vraiment dynamisé votre développement. J'apprécie vraiment que les gens créent ces nouveaux jeux au lieu de simplement porter des jeux existants hors chaîne.
Ben: Je ne veux pas vraiment comparer l'ère du début d'Internet avec le capital-risque classique, mais je pense vraiment que le monde autonome sur Redstone est en effet à la pointe de la tendance. Pour faire une comparaison, lorsque Internet est apparu, l'intuition des gens était de transposer ce qui existait déjà en ligne, comme transformer les journaux en version numérique.
Le véritable innovation réside dans la compréhension de la façon d'utiliser les fonctionnalités d'un nouveau système. En réalité, les journaux en ligne ne valent pas autant qu'un mini-journal de 240 caractères que chacun possède. Pour moi, cela ressemble beaucoup à l'espace d'innovation sur Redstone. La communauté actuelle est en train de repousser les limites des jeux et du monde en explorant comment les faire évoluer.
**tdot:**Oui, nous sommes très excités. Cet environnement attire vraiment une communauté très active où les gens peuvent pousser leurs idées à l'extrême. Cela représente une grande amélioration par rapport à une simple mentalité spéculative. Je pense que l'idée de jouer à des jeux avec des amis est également très chaleureuse et attire de très bonnes personnes.
C'est maintenant le moment de profiter du plaisir, mon pote. Je pense que nous ne sommes pas encore tout à fait prêts à accueillir tout ce qui est à venir, donc j'ai vraiment hâte.
Ben : Le plasma est de retour. Long live Plasma.
tdot: Nous sommes très excités, la construction vient de commencer.
Références
Mode Plasma :[1]
tdot:[2]
Redstone:[3]
Optimisme:[4]
Ben Jones : _chain[5]
BOUE: [6]
OPCraft:[7]
Biomes: [8]
Sentinel: [9]
渔夫困境:[10]
Cette machine maudite : [11]