Récemment, un projet appelé Redstone est devenu un sujet brûlant. **Cette fonctionnalité de couche 2 lancée par l’équipe Lattice a été officiellement lancée le 15 novembre et a maintenant été lancée sur le réseau de test. Il est intéressant de noter que l’équipe de Lattice affirme que « Redstone est une chaîne Alt-DA inspirée du plasma ».
Juste un jour avant la sortie de Redstone, Vitalik a publié l’article « Exit games for EVM validiums : the return of Plasma », dans lequel il a brièvement passé en revue la solution technique « Plasma » qui avait disparu de l’écosystème Ethereum, et a souligné que des preuves de validité (confondues avec ZK Proof) pourraient être introduites pour résoudre le problème de Plasma.
À cet égard, de nombreux amis pensent que Vitalik a publié cet article afin de donner une plate-forme à Redstone, et même dans la communauté geek Web3, certaines personnes disent que Vitalik n’a pas investi dans Redstone. Couplé avec le « différend sur la définition de la couche 2 d’Ethereum » dans la rumeur précédente, il était largement admis que la prochaine « renaissance de Plasma » serait déclenchée, et que les solutions DA en dehors de l’écosystème Ethereum telles que Celestia pourraient être supprimées, car Plasma n’a pas d’exigences strictes pour DA. **
Cependant, selon les recherches de l’auteur de cet article, Redstone ne correspond pas au cadre général de la solution Plasma, et sa prétention à être « inspiré par Plasma » a la possibilité de frotter la chaleur de l’article de Vitalik, plutôt que de dire que Vitalik veut vraiment représenter Redstone. De plus, le défi DA de Redstone est similaire au projet de couche 2 que Metis a lancé en avril 2022, sauf que l’ordre de mise à jour de la Stateroot et de publication des données DA est différent.
Donc, la situation réelle est que vous avez peut-être « sur-interprété » Redstone. Ce qui suit est un raisonnement simple pour expliquer comment fonctionne Plasma, pourquoi il n’est pas convivial pour les contrats intelligents et Defi, et ce qu’est exactement Redstone. **
Plasma : Retrait urgent en cas d’attaque par rétention de données
L’histoire du plasma remonte au boom de l’Ethereum IC0 en 2017, lorsque la demande de transactions des utilisateurs d’Ethereum a explosé et que l’ETH à faible TPS a été submergé. À ce stade, la première version théorique de Plasma a été publiée, qui proposait un schéma de mise à l’échelle de couche 2 capable de gérer « presque tous les scénarios financiers du monde ».
Pour faire simple, Plasma est une solution de mise à l’échelle qui ne publie que l’en-tête de bloc de couche 2/racine de Merkle vers la couche 1, et la partie des données en dehors de l’en-tête de bloc/racine de Merkle (données DA) n’est publiée que hors chaîne. **Si la racine de Merkle publiée par le séquenceur/opérateur plasma sur L1 est associée à une transaction non valide (par exemple, une erreur de signature numérique), l’utilisateur peut soumettre un certificat de fraude pour prouver que la racine soumise par le séquenceur est associée à une transaction non valide.
Le problème est que pour émettre des preuves de fraude, il est nécessaire de s’assurer que les données DA ne sont pas retenues, mais Plasma n’a pas d’exigences strictes pour 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 lance une attaque par retenue de données (également connue sous le nom de problème de disponibilité des données) à un moment donné, et ne publie qu’un nouvel en-tête de bloc/racine de Merkle, mais ne publie pas le corps de bloc correspondant, ce qui rend impossible la vérification de la validité de l’en-tête/racine de bloc, l’utilisateur ne peut que considérer par défaut le séquenceur comme « désespéré » et retirer les ressources de la couche 2 à la couche 1 via un mécanisme de sortie d’urgence appelé « Exit Game ».
Cette étape nécessite que l’utilisateur soumette une preuve de Merkle pour prouver qu’il dispose d’un montant correspondant d’actifs sur L2, que nous pouvons appeler « Proof of Assets ». Il est intéressant de noter que le jeu de sortie de Plasma n’est pas le même que le mode Escape Pod de ZK Rollup, où les utilisateurs de ZK Rollup doivent soumettre une preuve de Merkle correspondant à la racine d’état valide la plus récente, tandis que les utilisateurs de Plasma peuvent soumettre une preuve correspondant à une racine de Merkle d’il y a longtemps.
Pourquoi est-il conçu de cette façon ? C’est juste que le Stateroot soumis par le ZK Rollup sera immédiatement mis en jugement par le contrat sur la couche 1 (pour déterminer si la preuve de validité est valide). Si la Stateroot nouvellement soumise est valide et légitime, alors l’utilisateur doit soumettre la preuve de Merkle correspondant à la Stateroot valide comme preuve d’actifs.
Cependant, la racine de Merkle soumise par le séquenceur Plasma, le contrat de couche 1 ne peut pas juger si elle est valide ou non, et ne peut que laisser le nœud L2 prendre l’initiative de contester pour exclure la racine invalide, il y aura donc un mécanisme de défi, ce qui rend le fonctionnement de Plasma et Zk Rollup très différent. **
Supposons que le séquenceur vient de publier une racine de Merkle 101 invalide et de lancer une attaque de rétention de données, de sorte que le nœud L2 ne puisse pas prouver que la racine 101 est invalide, alors l’utilisateur peut soumettre la preuve de merkle correspondant à la racine 100 ou à la racine antérieure et retirer ses actifs.
Bien sûr, il y a un problème qui doit être résolu ici, c’est-à-dire qu’un utilisateur peut soumettre un certificat d’actif correspondant à la racine 30 ou antérieure, et demander à retirer l’actif vers la couche 1, mais le statut de l’actif de cette personne peut changer après la publication de la racine 30. En d’autres termes, il soumet une preuve d’actifs obsolète, ce qui est une attaque typique à double dépense/double dépense. **
En réponse, Plasma permet à quiconque de soumettre un certificat de fraude pour les cas ci-dessus, indiquant que la « preuve d’équité » soumise par un utilisateur qui a initié une demande de retrait est obsolète. En introduisant cette « n’importe qui peut contester la déclaration de retrait de quelqu’un d’autre », Plasma n’a pas besoin de gérer les demandes de retrait d’urgence comme ZK Rollup.
Mais il est toujours possible que le trieur transfère les actifs de quelqu’un d’autre sur son propre compte L2 avant de lancer une attaque de rétention de données qui rend impossible pour les étrangers de contester sa tricherie. Après cela, le propre compte du séquenceur initie un retrait d’urgence, en soumettant une « preuve d’actifs » affirmant qu’il possède bien les actifs sur L2.
Évidemment, en raison de l’absence d’un morceau d’historique, il n’y a aucun moyen de prouver directement que la source d’actifs du séquenceur est problématique. Les versions antérieures de Plasma, telles que Plasma MVP, en ont tenu compte et ont proposé une « priorité de retrait ». Si une personne soumet une preuve d’actif correspondant à root plus tôt, sa demande de retrait sera prioritaire.
Si le séquenceur triche et initie un retrait lors de la soumission du numéro racine 101, l’utilisateur peut soumettre une preuve d’actifs correspondant au numéro racine 99 ou antérieur pour effectuer un retrait d’urgence. Évidemment, tant que le séquenceur ne peut pas altérer l’historique qui a été posté sur la couche 1, l’utilisateur a un moyen de s’échapper.
Mais Plasma a encore un bug fatal : tant que le séquenceur initie la rétention de données, les gens doivent compter sur des retraits d’urgence (également connus sous le nom de Exit Game) pour assurer la sécurité des actifs, et si un grand nombre d’utilisateurs se retirent collectivement dans un court laps de temps, la couche 1 est facile à gérer ;
Supposons que quelqu’un recharge 100 ETH dans le pool LP du DEX, puis que le séquenceur du Plasma tombe en panne ou fasse le mal, et que les gens doivent se retirer de toute urgence, à ce moment-là, les 100 ETH de l’utilisateur sont toujours contrôlés par le contrat DEX, qui devrait mentionner ces actifs à la couche 1 à ce moment-là ?
La meilleure façon de le faire est de permettre aux utilisateurs de racheter d’abord leurs actifs du pool DEX, puis de laisser les utilisateurs retirer eux-mêmes leur argent vers L1, mais le problème est que le séquenceur Plasma fonctionne mal/est corruptible, et les utilisateurs ne peuvent pas racheter leurs actifs. Mais ne serait-ce pas terrible si nous permettions au propriétaire du contrat DEX d’amener les actifs contrôlés par le contrat à L1, ce qui donnerait évidemment au propriétaire du contrat la propriété des actifs, et qu’il pourrait augmenter ces actifs à L1 à tout moment et s’enfuir ?
Donc, en fin de compte, comment traiter ces « biens publics » soutenus par des contrats Defi est un énorme coup de tonnerre. **Si vous suivez le consensus social, il semble qu’il soit acceptable de reconstruire un contrat miroir sur la couche 1 qui reflète le contrat defi sur la couche 2, mais cela introduira un problème assez énorme, augmentera le coût d’opportunité, et qui votera sur l’élimination du contrat miroir sera également un gros problème. Il s’agit en fait du problème de la distribution de l’énergie publique, dont Xiangma a déjà parlé dans une interview "Il est difficile pour les chaînes publiques performantes de faire de nouvelles choses, et les contrats intelligents impliquent la distribution d’énergie.
Bien sûr, Vitalik le souligne également dans son récent article « Exit games for EVM validiums : the return of Plasma », et souligne que c’est l’un des facteurs qui rendent Plasma hostile aux contrats intelligents. **Dans le passé, des variantes bien connues de Plasma 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 « distribution de la propriété des actifs » mentionné ci-dessus, bien que la propriété de chaque UTXO appartienne à l’utilisateur, mais UTXO lui-même présente de nombreux défauts et n’est pas convivial pour les contrats intelligents. Par conséquent, la solution Plasma est la mieux adaptée pour les paiements simples ou les échanges de carnets d’ordres.
Plus tard, avec la popularité de ZK Rollup, Plasma lui-même s’est également retiré de la scène de l’histoire, car Rollup n’avait pas le problème de la rétention des données de Plasma. Si le séquenceur du ZK Rollup lance une attaque par retenue de données et ne soumet que la Stateroot à la chaîne ETH sans données DA, cette racine sera jugée invalide et rejetée par le contrat Verifier sur L1. Par conséquent, les données DA correspondant à la Stateroot légale de ZK Rollup doivent être disponibles sur la chaîne ETH. De cette façon, il n’y a pas de « publier uniquement l’en-tête de bloc ou la racine de merkle, mais pas le corps de bloc correspondant », c’est-à-dire que le problème de disponibilité des données/l’attaque de rétention de données peut être résolu. **
Dans le même temps, les données DA passées des Rollups sont disponibles sur Ethereum, et n’importe qui peut démarrer des nœuds de couche 2 à travers l’histoire de la chaîne ETH, ce qui réduit considérablement la difficulté des schémas de séquenceur décentralisés ou même sans autorisation. En revanche, Plasma n’a pas d’exigences strictes pour DA, et il est plus difficile d’implémenter un séquenceur décentralisé (pour implémenter un séquenceur décentralisé remplaçable, vous devez d’abord vous assurer que tous les nœuds L2 reconnaissent le même bloc, ce qui met en avant des exigences pour l’implémentation DA).
De plus, si le séquenceur du ZK Rollup tente d’inclure des transactions invalides dans le bloc de couche 2, il n’y parviendra pas, ce qui est garanti par le principe de preuve de validité.
En fin de compte, le séquenceur ZK Rollup a une marge d’action beaucoup plus petite que Plasma - il peut au mieux bloquer les mises à jour Stateroot, être l’équivalent d’un temps d’arrêt au niveau de l’expérience utilisateur ou refuser certaines demandes des utilisateurs, familièrement connu sous le nom de censure des transactions. Dans le même temps, si le séquenceur échoue dans le schéma de cumul, il sera plus facile pour les autres nœuds de le remplacer. **Idéalement, la probabilité de déclencher le mode de jeu Exit dans Plasma peut être réduite à 0 (appelée capsule d’évasion dans ZK Rollup).
(La colonne Échec du proposant sur L2BEAT montre comment chaque solution L2 peut gérer les défaillances du séquenceur, Self Pose fait souvent référence à d’autres nœuds qui peuvent remplacer le séquenceur qui est actuellement en panne)**
Aujourd’hui, il n’y a presque plus d’équipes dans l’écosystème Ethereum qui s’en tiennent encore à la voie Plasma, et presque tous les projets Plasma sont mort-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 : Ce n’est pas du Plasma, c’est une variante de l’Optimium****
Ci-dessus, nous avons brièvement expliqué Plasma et les raisons pour lesquelles il est remplacé par Rollup, et en ce qui concerne Redstone, vous avez également dû voir la différence entre lui et Plasma : Redstone peut résoudre le problème des attaques de rétention de données,** Par exemple, il ne publiera pas immédiatement une nouvelle racine d’état, mais publiera d’abord les données DA d’origine hors chaîne, puis publiera le datahash des données DA sur la chaîne ETH en tant qu’engagement d’informations d’identification associées, en indiquant qu’il a publié les données complètes correspondant à ce datahash hors chaîne.
(L’explication officielle de Redstone sur son propre plan pour empêcher les attaques de rétention de données)**
N’importe qui peut défier le séquenceur de Redstone de dire qu’il ne publie pas les données brutes pour ce datahash hors chaîne. À ce stade, le séquenceur doit publier les données correspondant au datahash on-chain pour répondre au défi du questionneur. **Si le séquenceur ne publie pas les données sur la chaîne ETH en temps opportun après avoir été contesté, son datahash/engagement précédemment publié sera considéré comme invalide.
Si le séquenceur répond à la demande du challenger en temps opportun, le challenger peut obtenir les données DA d’origine correspondant au datahash à temps. À terme, tous les nœuds L2 peuvent obtenir les données DA requises pour résoudre le problème des attaques de rétention de données. Bien entendu, le challenger lui-même doit payer une redevance qui est approximativement égale au coût de la publication par le séquenceur des données DA brutes sur la chaîne ETH, afin d’éviter que des challengers malveillants ne contestent gratuitement le séquenceur et ne lui fassent subir des pertes.
Enfin, lorsque la période de challenge pour le datahash est terminée, le séquenceur publiera la stateroot correspondante, qui est la racine obtenue après l’exécution de la séquence de transaction contenue dans les données DA correspondant au datahash. À ce stade, le nœud L2 peut utiliser le système de protection contre la fraude pour contester ces racines non valides. Si le séquenceur ne publie pas les données DA d’origine correspondantes à temps après l’activation d’un datahash, le séquenceur sera invalide par défaut, même si la racine d’état correspondant au datahash est publiée ultérieurement.
Étant donné que Redstone publie d’abord les données DA, puis publie l’Stateroot valide correspondant, il résout directement le problème des attaques par rétention de données (le séquenceur ne publie que les données root mais pas les données DA).
De toute évidence, ce modèle est différent de l’Optimium ordinaire (OP Rollup of DA without Ethereum, tel qu’Arbitrum Nova), Optimium s’appuie généralement sur des comités DAC hors chaîne pour assurer la disponibilité des données, DAC soumet un txn multi-Sig à la chaîne de temps en temps, et le contrat de Rollup sur la couche 1 sera par défaut au séquenceur qui a publié le dernier lot de données DA hors chaîne après avoir reçu le txn multi-Sig.
(图源 :L2beat)
Alors que Metis et Arbitrum Nova soumettent Stateroot et datahash en même temps, si quelqu’un pense que le séquenceur retient les données DA, il essaiera de lancer une contestation, et le séquenceur enverra les données DA correspondant au datahash à la chaîne.
Par conséquent, la principale différence entre Redstone et Metis est la suivante : le premier publie d’abord le datahash et attend la fin de la période de contestation de l’AD avant de publier l’étatroot, tandis que Métis publie à la fois l’étatracine et le datahachage, et si quelqu’un lance une contestation, les données de l’AD sont téléchargées dans la chaîne. De toute évidence, la solution de Redstone est plus sûre, car dans le schéma de Metis, si le séquenceur ne répond pas à la demande du challenger pour les données DA, le problème de l’attaque par rétention de données ne peut pas être résolu rapidement, et la seule façon de s’appuyer sur des retraits d’urgence et un consensus social est de laisser d’autres nœuds prendre le contrôle du séquenceur actuel ;
Cependant, dans le cas de Redstone, si le séquenceur s’engage dans la rétention de données, la stateroot libérée par lui est directement considérée comme invalide, de sorte que les données stateroot et DA sont liées, ce qui permet à Redstone d’obtenir des garanties DA plus proches de Rollup, qui est essentiellement une variante Optimium supérieure à Arbitrum Nova et Metis.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Restone : Ce n’est pas du Plasma mais la variante de l’Optimium
Auteur : Faust, geek web3***
Récemment, un projet appelé Redstone est devenu un sujet brûlant. **Cette fonctionnalité de couche 2 lancée par l’équipe Lattice a été officiellement lancée le 15 novembre et a maintenant été lancée sur le réseau de test. Il est intéressant de noter que l’équipe de Lattice affirme que « Redstone est une chaîne Alt-DA inspirée du plasma ».
Juste un jour avant la sortie de Redstone, Vitalik a publié l’article « Exit games for EVM validiums : the return of Plasma », dans lequel il a brièvement passé en revue la solution technique « Plasma » qui avait disparu de l’écosystème Ethereum, et a souligné que des preuves de validité (confondues avec ZK Proof) pourraient être introduites pour résoudre le problème de Plasma.
À cet égard, de nombreux amis pensent que Vitalik a publié cet article afin de donner une plate-forme à Redstone, et même dans la communauté geek Web3, certaines personnes disent que Vitalik n’a pas investi dans Redstone. Couplé avec le « différend sur la définition de la couche 2 d’Ethereum » dans la rumeur précédente, il était largement admis que la prochaine « renaissance de Plasma » serait déclenchée, et que les solutions DA en dehors de l’écosystème Ethereum telles que Celestia pourraient être supprimées, car Plasma n’a pas d’exigences strictes pour DA. **
Cependant, selon les recherches de l’auteur de cet article, Redstone ne correspond pas au cadre général de la solution Plasma, et sa prétention à être « inspiré par Plasma » a la possibilité de frotter la chaleur de l’article de Vitalik, plutôt que de dire que Vitalik veut vraiment représenter Redstone. De plus, le défi DA de Redstone est similaire au projet de couche 2 que Metis a lancé en avril 2022, sauf que l’ordre de mise à jour de la Stateroot et de publication des données DA est différent.
Donc, la situation réelle est que vous avez peut-être « sur-interprété » Redstone. Ce qui suit est un raisonnement simple pour expliquer comment fonctionne Plasma, pourquoi il n’est pas convivial pour les contrats intelligents et Defi, et ce qu’est exactement Redstone. **
Plasma : Retrait urgent en cas d’attaque par rétention de données
L’histoire du plasma remonte au boom de l’Ethereum IC0 en 2017, lorsque la demande de transactions des utilisateurs d’Ethereum a explosé et que l’ETH à faible TPS a été submergé. À ce stade, la première version théorique de Plasma a été publiée, qui proposait un schéma de mise à l’échelle de couche 2 capable de gérer « presque tous les scénarios financiers du monde ».
Pour faire simple, Plasma est une solution de mise à l’échelle qui ne publie que l’en-tête de bloc de couche 2/racine de Merkle vers la couche 1, et la partie des données en dehors de l’en-tête de bloc/racine de Merkle (données DA) n’est publiée que hors chaîne. **Si la racine de Merkle publiée par le séquenceur/opérateur plasma sur L1 est associée à une transaction non valide (par exemple, une erreur de signature numérique), l’utilisateur peut soumettre un certificat de fraude pour prouver que la racine soumise par le séquenceur est associée à une transaction non valide.
Le problème est que pour émettre des preuves de fraude, il est nécessaire de s’assurer que les données DA ne sont pas retenues, mais Plasma n’a pas d’exigences strictes pour 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 lance une attaque par retenue de données (également connue sous le nom de problème de disponibilité des données) à un moment donné, et ne publie qu’un nouvel en-tête de bloc/racine de Merkle, mais ne publie pas le corps de bloc correspondant, ce qui rend impossible la vérification de la validité de l’en-tête/racine de bloc, l’utilisateur ne peut que considérer par défaut le séquenceur comme « désespéré » et retirer les ressources de la couche 2 à la couche 1 via un mécanisme de sortie d’urgence appelé « Exit Game ».
Cette étape nécessite que l’utilisateur soumette une preuve de Merkle pour prouver qu’il dispose d’un montant correspondant d’actifs sur L2, que nous pouvons appeler « Proof of Assets ». Il est intéressant de noter que le jeu de sortie de Plasma n’est pas le même que le mode Escape Pod de ZK Rollup, où les utilisateurs de ZK Rollup doivent soumettre une preuve de Merkle correspondant à la racine d’état valide la plus récente, tandis que les utilisateurs de Plasma peuvent soumettre une preuve correspondant à une racine de Merkle d’il y a longtemps.
Pourquoi est-il conçu de cette façon ? C’est juste que le Stateroot soumis par le ZK Rollup sera immédiatement mis en jugement par le contrat sur la couche 1 (pour déterminer si la preuve de validité est valide). Si la Stateroot nouvellement soumise est valide et légitime, alors l’utilisateur doit soumettre la preuve de Merkle correspondant à la Stateroot valide comme preuve d’actifs.
Cependant, la racine de Merkle soumise par le séquenceur Plasma, le contrat de couche 1 ne peut pas juger si elle est valide ou non, et ne peut que laisser le nœud L2 prendre l’initiative de contester pour exclure la racine invalide, il y aura donc un mécanisme de défi, ce qui rend le fonctionnement de Plasma et Zk Rollup très différent. **
Supposons que le séquenceur vient de publier une racine de Merkle 101 invalide et de lancer une attaque de rétention de données, de sorte que le nœud L2 ne puisse pas prouver que la racine 101 est invalide, alors l’utilisateur peut soumettre la preuve de merkle correspondant à la racine 100 ou à la racine antérieure et retirer ses actifs.
Bien sûr, il y a un problème qui doit être résolu ici, c’est-à-dire qu’un utilisateur peut soumettre un certificat d’actif correspondant à la racine 30 ou antérieure, et demander à retirer l’actif vers la couche 1, mais le statut de l’actif de cette personne peut changer après la publication de la racine 30. En d’autres termes, il soumet une preuve d’actifs obsolète, ce qui est une attaque typique à double dépense/double dépense. **
En réponse, Plasma permet à quiconque de soumettre un certificat de fraude pour les cas ci-dessus, indiquant que la « preuve d’équité » soumise par un utilisateur qui a initié une demande de retrait est obsolète. En introduisant cette « n’importe qui peut contester la déclaration de retrait de quelqu’un d’autre », Plasma n’a pas besoin de gérer les demandes de retrait d’urgence comme ZK Rollup.
Mais il est toujours possible que le trieur transfère les actifs de quelqu’un d’autre sur son propre compte L2 avant de lancer une attaque de rétention de données qui rend impossible pour les étrangers de contester sa tricherie. Après cela, le propre compte du séquenceur initie un retrait d’urgence, en soumettant une « preuve d’actifs » affirmant qu’il possède bien les actifs sur L2.
Évidemment, en raison de l’absence d’un morceau d’historique, il n’y a aucun moyen de prouver directement que la source d’actifs du séquenceur est problématique. Les versions antérieures de Plasma, telles que Plasma MVP, en ont tenu compte et ont proposé une « priorité de retrait ». Si une personne soumet une preuve d’actif correspondant à root plus tôt, sa demande de retrait sera prioritaire.
Si le séquenceur triche et initie un retrait lors de la soumission du numéro racine 101, l’utilisateur peut soumettre une preuve d’actifs correspondant au numéro racine 99 ou antérieur pour effectuer un retrait d’urgence. Évidemment, tant que le séquenceur ne peut pas altérer l’historique qui a été posté sur la couche 1, l’utilisateur a un moyen de s’échapper.
Mais Plasma a encore un bug fatal : tant que le séquenceur initie la rétention de données, les gens doivent compter sur des retraits d’urgence (également connus sous le nom de Exit Game) pour assurer la sécurité des actifs, et si un grand nombre d’utilisateurs se retirent collectivement dans un court laps de temps, la couche 1 est facile à gérer ;
Supposons que quelqu’un recharge 100 ETH dans le pool LP du DEX, puis que le séquenceur du Plasma tombe en panne ou fasse le mal, et que les gens doivent se retirer de toute urgence, à ce moment-là, les 100 ETH de l’utilisateur sont toujours contrôlés par le contrat DEX, qui devrait mentionner ces actifs à la couche 1 à ce moment-là ?
La meilleure façon de le faire est de permettre aux utilisateurs de racheter d’abord leurs actifs du pool DEX, puis de laisser les utilisateurs retirer eux-mêmes leur argent vers L1, mais le problème est que le séquenceur Plasma fonctionne mal/est corruptible, et les utilisateurs ne peuvent pas racheter leurs actifs. Mais ne serait-ce pas terrible si nous permettions au propriétaire du contrat DEX d’amener les actifs contrôlés par le contrat à L1, ce qui donnerait évidemment au propriétaire du contrat la propriété des actifs, et qu’il pourrait augmenter ces actifs à L1 à tout moment et s’enfuir ?
Donc, en fin de compte, comment traiter ces « biens publics » soutenus par des contrats Defi est un énorme coup de tonnerre. **Si vous suivez le consensus social, il semble qu’il soit acceptable de reconstruire un contrat miroir sur la couche 1 qui reflète le contrat defi sur la couche 2, mais cela introduira un problème assez énorme, augmentera le coût d’opportunité, et qui votera sur l’élimination du contrat miroir sera également un gros problème. Il s’agit en fait du problème de la distribution de l’énergie publique, dont Xiangma a déjà parlé dans une interview "Il est difficile pour les chaînes publiques performantes de faire de nouvelles choses, et les contrats intelligents impliquent la distribution d’énergie.
Bien sûr, Vitalik le souligne également dans son récent article « Exit games for EVM validiums : the return of Plasma », et souligne que c’est l’un des facteurs qui rendent Plasma hostile aux contrats intelligents. **Dans le passé, des variantes bien connues de Plasma 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 « distribution de la propriété des actifs » mentionné ci-dessus, bien que la propriété de chaque UTXO appartienne à l’utilisateur, mais UTXO lui-même présente de nombreux défauts et n’est pas convivial pour les contrats intelligents. Par conséquent, la solution Plasma est la mieux adaptée pour les paiements simples ou les échanges de carnets d’ordres.
Plus tard, avec la popularité de ZK Rollup, Plasma lui-même s’est également retiré de la scène de l’histoire, car Rollup n’avait pas le problème de la rétention des données de Plasma. Si le séquenceur du ZK Rollup lance une attaque par retenue de données et ne soumet que la Stateroot à la chaîne ETH sans données DA, cette racine sera jugée invalide et rejetée par le contrat Verifier sur L1. Par conséquent, les données DA correspondant à la Stateroot légale de ZK Rollup doivent être disponibles sur la chaîne ETH. De cette façon, il n’y a pas de « publier uniquement l’en-tête de bloc ou la racine de merkle, mais pas le corps de bloc correspondant », c’est-à-dire que le problème de disponibilité des données/l’attaque de rétention de données peut être résolu. **
Dans le même temps, les données DA passées des Rollups sont disponibles sur Ethereum, et n’importe qui peut démarrer des nœuds de couche 2 à travers l’histoire de la chaîne ETH, ce qui réduit considérablement la difficulté des schémas de séquenceur décentralisés ou même sans autorisation. En revanche, Plasma n’a pas d’exigences strictes pour DA, et il est plus difficile d’implémenter un séquenceur décentralisé (pour implémenter un séquenceur décentralisé remplaçable, vous devez d’abord vous assurer que tous les nœuds L2 reconnaissent le même bloc, ce qui met en avant des exigences pour l’implémentation DA).
De plus, si le séquenceur du ZK Rollup tente d’inclure des transactions invalides dans le bloc de couche 2, il n’y parviendra pas, ce qui est garanti par le principe de preuve de validité.
En fin de compte, le séquenceur ZK Rollup a une marge d’action beaucoup plus petite que Plasma - il peut au mieux bloquer les mises à jour Stateroot, être l’équivalent d’un temps d’arrêt au niveau de l’expérience utilisateur ou refuser certaines demandes des utilisateurs, familièrement connu sous le nom de censure des transactions. Dans le même temps, si le séquenceur échoue dans le schéma de cumul, il sera plus facile pour les autres nœuds de le remplacer. **Idéalement, la probabilité de déclencher le mode de jeu Exit dans Plasma peut être réduite à 0 (appelée capsule d’évasion dans ZK Rollup).
(La colonne Échec du proposant sur L2BEAT montre comment chaque solution L2 peut gérer les défaillances du séquenceur, Self Pose fait souvent référence à d’autres nœuds qui peuvent remplacer le séquenceur qui est actuellement en panne)**
Aujourd’hui, il n’y a presque plus d’équipes dans l’écosystème Ethereum qui s’en tiennent encore à la voie Plasma, et presque tous les projets Plasma sont mort-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 : Ce n’est pas du Plasma, c’est une variante de l’Optimium****
Ci-dessus, nous avons brièvement expliqué Plasma et les raisons pour lesquelles il est remplacé par Rollup, et en ce qui concerne Redstone, vous avez également dû voir la différence entre lui et Plasma : Redstone peut résoudre le problème des attaques de rétention de données,** Par exemple, il ne publiera pas immédiatement une nouvelle racine d’état, mais publiera d’abord les données DA d’origine hors chaîne, puis publiera le datahash des données DA sur la chaîne ETH en tant qu’engagement d’informations d’identification associées, en indiquant qu’il a publié les données complètes correspondant à ce datahash hors chaîne.
(L’explication officielle de Redstone sur son propre plan pour empêcher les attaques de rétention de données)**
N’importe qui peut défier le séquenceur de Redstone de dire qu’il ne publie pas les données brutes pour ce datahash hors chaîne. À ce stade, le séquenceur doit publier les données correspondant au datahash on-chain pour répondre au défi du questionneur. **Si le séquenceur ne publie pas les données sur la chaîne ETH en temps opportun après avoir été contesté, son datahash/engagement précédemment publié sera considéré comme invalide.
Si le séquenceur répond à la demande du challenger en temps opportun, le challenger peut obtenir les données DA d’origine correspondant au datahash à temps. À terme, tous les nœuds L2 peuvent obtenir les données DA requises pour résoudre le problème des attaques de rétention de données. Bien entendu, le challenger lui-même doit payer une redevance qui est approximativement égale au coût de la publication par le séquenceur des données DA brutes sur la chaîne ETH, afin d’éviter que des challengers malveillants ne contestent gratuitement le séquenceur et ne lui fassent subir des pertes.
Enfin, lorsque la période de challenge pour le datahash est terminée, le séquenceur publiera la stateroot correspondante, qui est la racine obtenue après l’exécution de la séquence de transaction contenue dans les données DA correspondant au datahash. À ce stade, le nœud L2 peut utiliser le système de protection contre la fraude pour contester ces racines non valides. Si le séquenceur ne publie pas les données DA d’origine correspondantes à temps après l’activation d’un datahash, le séquenceur sera invalide par défaut, même si la racine d’état correspondant au datahash est publiée ultérieurement.
Étant donné que Redstone publie d’abord les données DA, puis publie l’Stateroot valide correspondant, il résout directement le problème des attaques par rétention de données (le séquenceur ne publie que les données root mais pas les données DA).
De toute évidence, ce modèle est différent de l’Optimium ordinaire (OP Rollup of DA without Ethereum, tel qu’Arbitrum Nova), Optimium s’appuie généralement sur des comités DAC hors chaîne pour assurer la disponibilité des données, DAC soumet un txn multi-Sig à la chaîne de temps en temps, et le contrat de Rollup sur la couche 1 sera par défaut au séquenceur qui a publié le dernier lot de données DA hors chaîne après avoir reçu le txn multi-Sig.
(图源 :L2beat)
Alors que Metis et Arbitrum Nova soumettent Stateroot et datahash en même temps, si quelqu’un pense que le séquenceur retient les données DA, il essaiera de lancer une contestation, et le séquenceur enverra les données DA correspondant au datahash à la chaîne.
Par conséquent, la principale différence entre Redstone et Metis est la suivante : le premier publie d’abord le datahash et attend la fin de la période de contestation de l’AD avant de publier l’étatroot, tandis que Métis publie à la fois l’étatracine et le datahachage, et si quelqu’un lance une contestation, les données de l’AD sont téléchargées dans la chaîne. De toute évidence, la solution de Redstone est plus sûre, car dans le schéma de Metis, si le séquenceur ne répond pas à la demande du challenger pour les données DA, le problème de l’attaque par rétention de données ne peut pas être résolu rapidement, et la seule façon de s’appuyer sur des retraits d’urgence et un consensus social est de laisser d’autres nœuds prendre le contrôle du séquenceur actuel ;
Cependant, dans le cas de Redstone, si le séquenceur s’engage dans la rétention de données, la stateroot libérée par lui est directement considérée comme invalide, de sorte que les données stateroot et DA sont liées, ce qui permet à Redstone d’obtenir des garanties DA plus proches de Rollup, qui est essentiellement une variante Optimium supérieure à Arbitrum Nova et Metis.