Une brève discussion sur Restone : Il ne s'agit pas de Plasma, mais d'une variante d'Optimium.

Ce dispositif spécial de couche 2 pour les jeux en chaîne, lancé par l'équipe de Lattice, a été officiellement publié le 15 novembre et est désormais en ligne sur le réseau de test. Il est intéressant de noter que l'équipe de Lattice a déclaré que "Redstone est une chaîne Alt-DA inspirée de Plasma"。.

La veille de la sortie de Redstone, Vitalik a publié l'article "Exit games for EVM validiums : the return of Plasma". L'article passe brièvement en revue la solution technique "Plasma" qui a disparu de l'écosystème Ethereum et souligne que la preuve de validité (confondue avec la preuve ZK) peut être introduite pour résoudre le problème de Plasma. À cet égard, de nombreux amis pensent que Vitalik a publié cet article pour soutenir Redstone. Certains ont même dit dans la communauté geek Web3 que Vitalik pourrait avoir investi dans Redstone. Couplé à la "dispute sur la définition de la couche 2 d'Ethereum" dans ce préquel, les gens ont généralement cru que cela déclencherait une "renaissance de Plasma" à l'avenir, et les solutions DA en dehors de l'écosystème Ethereum telles que Celestia pourraient être supprimées en conséquence.Parce que Plasma n'a pas d'exigences strictes pour DA.Cependant, selon les recherches de l'auteur de cet article, Redstone n'est pas conforme au cadre général de la solution Plasma. Le fait qu'elle se dise "inspirée par Plasma" pourrait en fait suivre les sujets brûlants de l'article de Vitalik. Ce n'est pas que Vitalik veuille vraiment prendre la défense de Redstone. En outre, le plan de défi DA de Redstone est assez similaire au plan lancé par le projet Metis de la couche 2 en avril 2022, à l'exception de l'ordre des deux étapes de mise à jour de Stateroot et de publication des données DA qui est différent. La situation réelle est donc la suivante : tout le monde a peut-être "surinterprété" Redstone. Ce qui suit expliquera aux lecteurs, par le biais d'un raisonnement simple, le principe de Plasma et pourquoi il n'est pas favorable aux contrats intelligents et à Defi, et ce qu'est exactement Redstone.

Plasma : Des retraits urgents sont nécessaires en cas d'attaque par rétention de données.

L'histoire de Plasma remonte au boom de l'ICO Ethereum en 2017. À cette époque, la demande de transactions des utilisateurs d'Ethereum a explosé, et l'ETH, qui avait un faible TPS, a été submergé. À ce stade, la première version théorique de Plasma a été publiée, qui proposait un plan d'expansion de la deuxième couche capable de gérer "presque tous les scénarios financiers dans le monde". En d'autres termes, Plasma est une solution d'expansion qui ne publie que l'en-tête de bloc/la racine deerkle de la couche 2 vers la couche 1. Si la racine Merkle émise par le trieur/opérateur de Plasma sur L1 est associée à une transaction non valide (erreur de signature numérique, etc.), l'utilisateur concerné peut soumettre un certificat de fraude pour prouver que la racine soumise par le trieur est associée à une transaction non valide. Mais le problème est que pour délivrer un certificat de fraude, il faut s'assurer que les données DA ne sont pas retenues, mais Plasma n'a pas d'exigences strictes concernant la couche DA et ne peut pas garantir que les utilisateurs ou les nœuds L2 peuvent recevoir des données. Si le séquenceur est lancé à un moment donnéLes attaques par rétention de données (également connues sous le nom de problèmes de disponibilité des données) ne publient que les nouveaux en-têtes de blocs/racineserkle mais pas les corps de blocs correspondants.Sans la possibilité de vérifier si l'en-tête de bloc/la racine est valide, les utilisateurs ne peuvent que passer au séquenceur "sans espoir" et retirer les actifs de la couche 2 à la couche 1 par le biais d'un mécanisme de sortie d'urgence appelé "Exit Game".

Cette étape exige que l'utilisateur soumette une preuve Merkle pour prouver qu'il possède effectivement un montant correspondant d'actifs sur L2. C'est ce que nous appelons la "preuve d'actifs". Ce qui est intéressant, c'est que l'Exit Game de Plasma et le mode d'évasion de ZK Rollup sont différents. Les utilisateurs de ZK Rollup doivent soumettre la preuve de Merkle correspondant à la dernière Stateroot valide, tandis que les utilisateurs de Plasma peuvent soumettre la preuve correspondant à la racine de Merkle d'il y a longtemps. Pourquoi est-il conçu de la sorte ? Tout simplement parce que le Stateroot soumis par ZK Rollup sera immédiatement jugé par le contrat sur la couche 1 (pour déterminer si le certificat de validité est valide). Si le Stateroot nouvellement soumis est valide et légal, l'utilisateur doit alors soumettre la preuve Merkle correspondant au Stateroot légal pour servir de certificat d'actif. Cependant, le contrat Layer1 ne peut pas déterminer si la racine Merkle soumise par le séquenceur de Plasma est valide. Il ne peut autoriser le nœud L2 qu'à lancer activement une contestation pour éliminer les racines non valides, de sorte qu'il y aura un mécanisme de contestation. Supposons que le séquenceur vienne d'émettre une racine Merkle 101 non valide et qu'il ait lancé une attaque de rétention de données de sorte que le nœud L2 ne puisse pas prouver que la racine n° 101 n'est pas valide. À ce stade, l'utilisateur peut soumettre une épreuve de merkle correspondant à la racine n° 100 ou à une racine antérieure. Retirez vos propres avoirs.

Bien entendu, un problème doit être résolu : un utilisateur peut présenter un certificat d'actifs correspondant à la racine n° 30 ou à une racine antérieure et demander à retirer des actifs à la couche 1. Toutefois, la situation patrimoniale de cette personne peut changer après la publication de la racine n° 30. En d'autres termes, il a présenté une preuve d'actif périmée, ce qui constitue une attaque typique de double dépense.

À cet égard, Plasma permet à toute personne de soumettre une preuve de fraude dans la situation susmentionnée, en soulignant que la "preuve d'actifs" soumise par un utilisateur qui a initié une déclaration de retrait est périmée. En introduisant ce principe de "n'importe qui peut contester la demande de retrait de quelqu'un d'autre", Plasma n'a pas besoin de gérer les demandes de retrait d'urgence comme le ZK Rollup, mais il reste une possibilité, à savoir que le séquenceur transfère d'abord les actifs d'autres personnes vers son propre compte L2, puis lance une attaque de rétention de données afin que les personnes extérieures ne puissent pas contester son comportement de tricheur. Par la suite, le séquenceur a effectué un retrait d'urgence de son propre compte et a soumis une "preuve d'actifs" affirmant qu'il possédait effectivement ces actifs sur L2. Il est évident qu'à l'heure actuelle, en raison de l'absence d'historique, on ne peut pas prouver directement qu'il y a un problème avec la source des actifs de la trieuse. Que faire dans cette situation ? Les premières versions de Plasma, telles que Plasma MVP, tenaient compte de cet aspect et proposaient la "priorité de retrait". Si le certificat de patrimoine présenté par une personne correspond à une racine antérieure, sa demande de retrait sera traitée en premier.

Si le séquenceur effectue la tricherie susmentionnée et initie un retrait lors de la soumission de la racine n° 101, l'utilisateur peut soumettre un certificat d'actif correspondant à la racine n° 99 ou à une racine antérieure afin d'effectuer un retrait d'urgence. De toute évidence, tant que le trieur ne peut pas altérer les enregistrements historiques qui ont été publiés sur Layer1, l'utilisateur dispose d'un moyen de s'échapper : Tant que le séquenceur initie la rétention des données, les gens doivent compter sur les retraits d'urgence (également connus sous le nom d'Exit Game) pour assurer la sécurité des actifs. Si un grand nombre d'utilisateurs retirent collectivement de l'argent dans un court laps de temps, Layer1 sera facilement incapable de le gérer;Le plus grave est de savoir qui doit retirer les actifs enregistrés sur le contrat Defi à Layer 1?Supposons que quelqu'un charge 100 ETH dans le pool LP de DEX, puis que le séquenceur de Plasma tombe en panne ou fait quelque chose de mal, et que les gens ont besoin de retirer des fonds de toute urgence. À ce stade, les 100 ETH de l'utilisateur sont toujours contrôlés par le contrat DEX. À l'heure actuelle, quels devraient être ces actifs ? Qui a parlé de Layer1 ? La meilleure solution consiste à laisser les utilisateurs racheter leurs actifs auprès du pool DEX, puis à les laisser transférer eux-mêmes l'argent à L1. Cependant, le problème est que le séquenceur Plasma a mal fonctionné ou a fait le mal, et les utilisateurs ne peuvent pas racheter les actifs. opération. Mais si nous autorisons le propriétaire du contrat DEX à transférer les actifs contrôlés par le contrat en L1, il est évident que le propriétaire du contrat deviendra propriétaire des actifs. Il peut lever ces actifs pour L1 et s'enfuir à tout moment. N'est-ce pas terrible ? Si nous suivons le consensus social, il semble possible de reconstruire un contrat miroir sur la couche 1 qui met en correspondance le contrat Defi sur la couche 2, mais cela introduira des problèmes considérables et augmentera les coûts d'opportunité. Qui votera pour décider de la manière de disposer du contrat miroir ? Ce sera un gros problème. Il s'agit en fait du problème de la répartition de la puissance publique. Les voleurs avaient précédemment déclaré dans une interview: "Il est difficile de créer de nouvelles choses dans les chaînes publiques à haute performance, les contrats intelligents impliquent la distribution d'énergie".

Bien sûr, Vitalik l'a également souligné dans son récent article "Exit games for EVM validiums : the return of Plasma",Et a souligné que c'est l'un des facteurs qui rend Plasma peu favorable aux contrats intelligents.Les variantes de Plasma bien connues dans le passé, telles que Plasma MVP et Plasma Cash, utilisaient UTXO ou des modèles similaires pour remplacer le modèle d'adresse de compte d'Ethereum, et ne prenaient pas en charge les contrats intelligents, ce qui peut éviter le problème de la "distribution de la propriété des actifs" mentionné plus haut. Bien que la propriété de chaque UTXO appartienne à l'utilisateur lui-même, l'UTXO lui-même présente de nombreux défauts et n'est pas adapté aux contrats intelligents. Par conséquent, la solution Plasma est plus adaptée aux échanges simples de paiements ou de carnets d'ordres. Après cela, avec la popularité de ZK Rollup, Plasma lui-même s'est retiré de la scène de l'histoire, parce que Rollup n'a pas le problème de rétention des données de Plasma. Si le séquenceur de ZK Rollup lance une attaque de rétention de données et ne soumet à la chaîne ETH que des données Stateroot mais pas de données DA, une telle racine sera jugée invalide et directement rejetée par le contrat Verifier sur L1. Par conséquent, les données DA correspondant au Stateroot légal du ZK Rollup doivent être disponibles sur la chaîne ETH. En même temps, les données DA passées de Rollup peuvent être vérifiées sur Ethereum, et n'importe qui peut démarrer des nœuds de couche 2 grâce aux enregistrements historiques sur la chaîne ETH, ce qui réduira considérablement la difficulté des solutions de séquenceur décentralisées et même sans permission. En revanche, Plasma n'a pas d'exigences strictes en matière d'AD, et il est plus difficile de mettre en œuvre un trieur décentralisé (pour mettre en œuvre un trieur décentralisé remplaçable, nous devons d'abord nous assurer que tous les nœuds L2 reconnaissent le même bloc, ce qui pose des exigences pour la mise en œuvre de l'AD). En outre, si le séquenceur de ZK Rollup tente d'inclure des transactions non valides dans les blocs de la couche 2, il n'y parviendra pas. Ceci est garanti par le principe de la preuve de validité. En fin de compte, l'espace maléfique de la trieuse ZK Rollup est beaucoup plus petit que celui de Plasma. Tout au plus, elle peut bloquer les mises à jour de Stateroot, ce qui équivaut à un arrêt au niveau de l'interface utilisateur, ou refuser les demandes de certains utilisateurs, ce qui est communément appelé l'examen des transactions. Un Rollup idéal peut réduire à 0 la probabilité de déclencher le mode Exit dans Plasma (appelé escape hatch dans ZK Rollup).

(La colonne Échec du proposant sur L2BEAT montre comment chaque solution L2 réagit à l'échec du séquenceur. L'auto-proposition fait souvent référence à d'autres nœuds qui peuvent remplacer le séquenceur actuellement en panne.)

Aujourd'hui, presque aucune équipe de l'écosystème Ethereum n'adhère encore à la voie Plasma, et presque tous les projets Plasma sont morts-nés.

(Vitalik explique pourquoi ZK Rollup est supérieur à Plasma, en mentionnant le fonctionnement du séquenceur sans permission et les problèmes de DA)

Qu'est-ce que Redstone ? Il ne s'agit pas de plasma, mais d'une variante de l'Optimium.

Ci-dessus, nous avons brièvement expliqué Plasma et les raisons pour lesquelles il a été remplacé par Rollup. Quant à Redstone, vous avez dû voir la différence avec Plasma : Redstone peut résoudre le problème des attaques par rétention de données, par exemple en ne publiant pas immédiatement un nouveau stateroot. Au lieu de cela, il publiera d'abord les données DA originales sous la chaîne ETH, puis utilisera le datahash des données DA comme engagement de crédibilité associé et le publiera sur la chaîne ETH, en disant qu'il l'a publié sous la chaîne. Les données complètes correspondant au segment datahash.

(Explication officielle de Redstone concernant son plan de prévention des attaques par rétention de données)

N'importe qui peut lancer un défi, en disant que la trieuse de Redstone n'a pas publié les données originales correspondant à ce datahash hors chaîne. Si le séquenceur ne publie pas les données sur la chaîne ETH à temps après avoir été mis au défi, le datahash/engagement qu'il a publié précédemment sera considéré comme invalide. Si le trieur répond à temps à la demande du challenger, ce dernier peut obtenir à temps les données DA originales correspondant au datahash.En fin de compte, tous les nœuds L2 peuvent en principe obtenir les données DA requises pour résoudre le problème des attaques par rétention de données.Bien entendu, le challenger lui-même doit d'abord payer une redevance, qui est approximativement égale au coût de la publication par le séquenceur des données DA originales sur la chaîne ETH. Cette mesure vise à empêcher les challengers malveillants de défier gratuitement le séquenceur, ce qui entraînerait des pertes pour ce dernier. . enfin, lorsque la période de contestation du datahash se termine, la trieuse libère le stateroot correspondant, c'est-à-dire la racine obtenue après l'exécution de la séquence de transactions contenue dans les données DA correspondant au datahash. À ce stade, les nœuds L2 peuvent utiliser le système de preuve de fraude pour contester ces racines non valides. Si la trieuse ne libère pas à temps les données originales correspondantes de l'AD après qu'un datahash précédent a été contesté, même si la trieuse libère ultérieurement le stateroot correspondant à ce datahash, celui-ci sera invalide par défaut. parce que Redstone publie d'abord les données DA, puis les Stateroot effectifs correspondants, ce qui résout directement le problème des attaques par dissimulation de données. sorter ne publie que les données racine et non les données DA). Évidemment, ce mode est différent de l'Optimium ordinaire (OP Rollup qui n'utilise pas Ethereum pour implémenter DA, comme Arbitrum Nova).Optimium s'appuie généralement sur le comité DAC hors chaîne pour assurer la disponibilité des données.DAC soumet un txn multi-signé à la chaîne à intervalles réguliers. Une fois que le contrat de reconduction de la couche 1 a reçu la note de transmission multi-signée, le séquenceur publie par défaut le dernier lot de données DA en dehors de la chaîne.

(Source : L2beat)

Par exemple, Metis et Arbitrum Nova soumettent Stateroot et datahash en même temps. Si quelqu'un pense que le trieur a retenu des données DA, il essaiera de le contester et le trieur enverra à la chaîne les données DA correspondant au datahash. La différence essentielle entre Redstone et Metis réside dans cette étape : le premier publie d'abord le datahash, puis le stateroot à la fin de la période de challenge DA ; Metis publie le stateroot et le datahash en même temps. Il est évident que la solution de Redstone est plus sûre, car avec la solution de Metis, si le trieur ne répond jamais à la demande de données DA du challenger, le problème de l'attaque par rétention de données ne peut pas être résolu rapidement. Nous ne pouvons compter que sur les retraits d'urgence et le consensus social, ou laisser d'autres nœuds prendre en charge la trieuse actuelle. ;

Cela permet à Redstone d'obtenir une garantie de DA plus proche de celle de Rollup, qui est essentiellement une variante d'Optimium supérieure à Arbitrum Nova et Metis.

Clause de non-responsabilité：

1. Cet article est repris de[极客web3]. Tous les droits d'auteur appartiennent à l'auteur original[Faust]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.