Quant à la raison pour laquelle Plasma a été enterré pendant longtemps et pourquoi Vitalik soutiendra fortement Rollup, les indices pointent principalement vers deux points : la mise en œuvre de DA sous la chaîne Ethereum est peu fiable, et la rétention des données est facile à se produire. Une fois la rétention de données se produit, la preuve de fraude est difficile à réaliser ; La conception du mécanisme de Plasma même est extrêmement hostile aux contrats intelligents, et il est particulièrement difficile de soutenir la migration de l'état du contrat vers la couche 1. Ces deux points font que Plasma utilise essentiellement uniquement les modèles UTXO ou similaires.

Afin de comprendre les deux points fondamentaux ci-dessus, commençons par les questions de l’AD et de la rétention de données. Le nom complet de DA est Disponibilité des données, qui se traduit littéralement par Disponibilité des données. Il est maintenant utilisé à mauvais escient par de nombreuses personnes. À tel point qu’il est sérieusement confondu avec « les données historiques peuvent être vérifiées ». Mais en fait, « les données historiques peuvent être vérifiées » et « preuve de stockage » sont des problèmes que Filecoin et Arweave ont déjà résolus. Selon la Fondation Ethereum et Celestia, la question de l’AD explore uniquement les scénarios de rétention de données.

Arbre de Merkle et Racine de Merkle et Preuve de Merkle

Pour expliquer ce que signifient réellement les attaques de rétention de données et les problèmes DA, nous devons d'abord parler brièvement de la racine de Merkle et de l'arbre de Merkle. Dans Ethereum ou la plupart des chaînes publiques, une structure de données en forme d'arbre appelée arbre de Merkle est utilisée pour servir de résumé/répertoire de l'état de tous les comptes, ou pour enregistrer les transactions regroupées dans chaque bloc.

Le nœud feuille en bas de l'arbre de Merkle est composé de hachages de données originales telles que des transactions ou l'état du compte. Ces hachages sont additionnés par paires et itérés de manière répétée, et finalement une racine de Merkle peut être calculée.

(Le record en bas de la figure est l'ensemble de données original correspondant au nœud feuille) La racine de Merkle a une propriété : si un nœud feuille au bas de l'arbre de Merkle change, la racine de Merkle calculée changera également. Par conséquent, les arbres de Merkle correspondant à différents ensembles de données originaux auront des racines de Merkle différentes, tout comme différentes personnes ont des empreintes digitales différentes. La technologie de vérification de preuve appelée Preuve de Merkle tire parti de cette propriété de l'arbre de Merkle. En prenant l'image ci-dessus comme exemple, si Li Gang connaît uniquement la valeur de la racine de Merkle sur l'image, il ne sait pas quelles données contient l'ensemble complet de l'arbre de Merkle. Nous voulons prouver à Li Gang que l'enregistrement 3 est effectivement lié à la racine sur l'image, ou en d'autres termes, prouver que le hachage de l'enregistrement 3 existe sur l'arbre de Merkle correspondant à la racine. Nous n'avons besoin de soumettre à Li Gang que l'enregistrement 3 et les trois blocs de données de hachage marqués en gris, sans avoir à soumettre l'ensemble de l'arbre de Merkle ou tous ses nœuds feuilles. Tel est le caractère simple de la Preuve de Merkle. Lorsque les enregistrements sous-jacents de l'arbre de Merkle contiennent un très grand nombre de feuilles, par exemple, il contient 2 à la puissance 20 blocs de données (environ 1 million), la Preuve de Merkle n'a besoin de contenir au moins 21 blocs de données.

(Le bloc de données 30 et H2 dans la figure peuvent constituer une preuve de Merkle, prouvant que le bloc de données 30 existe sur l’arbre de Merkle correspondant à H0)Cette « simplicité » de Merkle Proof est souvent utilisée dans le Bitcoin, l’Ethereum ou les ponts inter-chaînes. Le nœud de lumière que nous connaissons est en fait Li Gang mentionné ci-dessus. Il ne reçoit que l’en-tête de bloc du nœud complet, pas du bloc complet. Il convient de souligner ici qu’Ethereum utilise un arbre de Merkle appelé State Trie pour servir de résumé de tous les comptes. Tant que le statut d’un compte associé à la Trie d’État change, la racine de Merkle de la Trie d’État, appelée StateRoot, change. Dans l’en-tête de bloc d’Ethereum, le StateRoot sera enregistré et la racine de Merkle de l’arborescence des transactions (appelée racine Txn) sera également enregistrée., Une différence entre une arborescence de transactions et une arborescence d’état est que les données représentées par les feuilles sous-jacentes sont différentes. Si le bloc n° 100 contient 300 transactions, les feuilles de l’arborescence des transactions représentent ces 300 Txn. Une autre différence est que le volume global de données de State Trie est extrêmement important. Ses feuilles inférieures correspondent à toutes les adresses de la chaîne Ethereum (en fait, il existe de nombreux hachages d’état obsolètes), de sorte que l’ensemble de données d’origine correspondant à State Trie ne sera pas publié. Dans le bloc, seul le StateRoot est enregistré dans l’en-tête du bloc. L’ensemble de données d’origine de l’arborescence des transactions est constitué des données Txn de chaque bloc, et la racine Txn de cette arborescence sera enregistrée dans l’en-tête du bloc.

Étant donné que le nœud léger ne reçoit que l'en-tête de bloc et ne connaît que StateRoot et TxnRoot, il ne peut pas déduire l'arbre de Merkle complet basé sur la Racine (cela est déterminé par les propriétés de l'arbre de Merkle et la fonction de hachage), donc les nœuds légers ne peuvent pas connaître les données de transaction contenues dans le bloc, ni savoir quels changements se sont produits dans le compte correspondant à l'arbre d'état. Si Wang Qiang veut prouver à un nœud léger (mentionné précédemment par Li Gang) que le bloc n° 100 contient une certaine transaction, et qu'il est connu que le nœud léger connaît l'en-tête de bloc du bloc n° 100 et connaît TxnRoot, alors le problème ci-dessus est transformé en : Prouver que cette Txn existe sur l'arbre de Merkle correspondant à TxnRoot. À ce moment-là, Wang Qiang n'a besoin que de soumettre la preuve de Merkle correspondante.

Dans de nombreux ponts inter-chaînes basés sur des solutions de client léger, la légèreté et la simplicité des nœuds légers et de la Preuve de Merkle mentionnée ci-dessus sont souvent utilisées. Par exemple, les ponts ZK tels que Map Protocol mettront en place un contrat sur la chaîne ETH pour recevoir spécifiquement des en-têtes de blocs d'autres chaînes (comme Polygon). Lorsque le Relayer soumet l'en-tête du 100e bloc de Polygon au contrat sur la chaîne ETH, le contrat vérifiera la validité de l'en-tête (par exemple, s'il a recueilli les signatures de 2/3 des nœuds POS dans le réseau Polygon). Si l'en-tête est valide et qu'un utilisateur déclare avoir initié une Txn inter-chaîne de Polygon à ETH, la Txn sera emballée dans le 100e bloc de Polygon. Il lui suffit d'utiliser la Preuve de Merkle pour prouver que la Txn inter-chaîne initiée par lui peut correspondre au TxnRoot dans l'en-tête de bloc n° 100 (en d'autres termes, il s'agit de prouver que la Txn inter-chaîne initiée par vous est enregistrée dans le bloc 100 de Polygon). Cependant, ZK Bridge utilisera une preuve à divulgation nulle pour compresser la quantité de calcul nécessaire pour vérifier la Preuve de Merkle, réduisant ainsi davantage le coût de vérification des contrats de pont inter-chaînes.

Problèmes d'attaque DA et de rétention de données

Après avoir parlé de l'arbre de Merkle, de la racine de Merkle et de la preuve de Merkle, revenons à la question de l'attaque DA et de la rétention de données mentionnée au début de l'article. Cette question a été discutée dès 2017. Le document original de Celestia a la source du problème DA. Vitalik lui-même a mentionné dans un document de 2017 à 2018 que le producteur de blocs pourrait délibérément dissimuler certains fragments de données du bloc et publier des blocs incomplets à l'extérieur. En conséquence, le nœud complet ne peut pas confirmer la correction de l'exécution de la transaction/la transition de l'état.

À ce stade, le producteur de blocs peut voler les actifs des utilisateurs, tels que transférer toutes les pièces du compte d'A vers d'autres adresses, mais le nœud complet ne peut pas juger si A lui-même a fait cela car ils ne connaissent pas la transaction complète incluse dans le dernier bloc de données.

Dans les chaînes publiques de couche 1 telles que Bitcoin ou Ethereum, les nœuds complets honnêtes rejettent directement les blocs invalides ci-dessus. Mais les nœuds légers sont différents. Ils ne reçoivent que les en-têtes de bloc du réseau. Nous connaissons seulement StateRoot et TxnRoot, mais nous ne savons pas si l'en-tête et les blocs originaux correspondant aux deux racines sont valides.

Dans le livre blanc de Bitcoin, il y a en fait une réflexion sur cette situation. Satoshi Nakamoto croyait autrefois que la plupart des utilisateurs auraient tendance à exécuter des nœuds légers avec des exigences de configuration plus faibles, et les nœuds légers ne peuvent pas juger si le bloc correspondant à l'en-tête du bloc est valide. Si un bloc est invalide, les nœuds complets honnêtes enverront une alerte aux nœuds légers.

Cependant, Satoshi Nakamoto n'a pas mené une analyse plus détaillée de cette solution. Plus tard, Vitalik et le fondateur de Celestia Mustafa ont combiné cette idée avec les résultats d'autres prédécesseurs et ont introduit l'échantillonnage de données DA pour garantir que les nœuds complets honnêtes peuvent restaurer chaque bloc de données complet et générer des alertes lorsque cela est nécessaire.

Remarque : L'échantillonnage de données DA (DAS) et Celestia ne sont pas le centre d'intérêt de cet article. Les lecteurs intéressés peuvent lire les articles précédents de "Geek Web3":"Malentendu sur la disponibilité des données: DA = Publication des données ≠ Récupération des données historiques"

Preuve de fraude de Plasma

En termes simples, Plasma est une solution d’extension qui ne publie que l’en-tête de bloc de la couche 2 vers la couche 1, et les données DA en dehors de l’en-tête de bloc (ensemble complet de données de transaction/changements de statut de chaque compte). En d’autres termes, Plasma est comme un pont inter-chaînes basé sur des clients légers. Il utilise des contrats pour mettre en œuvre des clients légers de couche 2 sur la chaîne ETH. Lorsque les utilisateurs déclarent qu’ils souhaitent passer de L2 à L1, ils doivent soumettre une preuve de Merkle pour faire leurs preuves. est propriétaire de ces actifs. La logique de vérification des actifs passant de L2 à L1 est similaire à celle du pont ZK mentionné ci-dessus, sauf que le modèle de pontage de Plasma est basé sur la preuve de fraude, et non sur la preuve ZK, et est plus proche du pont dit « optimiste ». Les demandes de retrait de L2 à L1 dans le réseau Plasma ne seront pas publiées immédiatement, mais il y aura une « période de contestation ». En ce qui concerne l’objectif de la période de défi, nous l’expliquerons ci-dessous.

Plasma n'a pas d'exigences strictes en matière de publication de données/DA. Le séquenceur/l'opérateur ne diffuse que chaque bloc L2 hors chaîne, et les nœuds qui souhaitent obtenir des blocs L2 peuvent les obtenir eux-mêmes. Ensuite, le trieur publiera l'en-tête du bloc L2 sur la couche 1. Par exemple, le séquenceur diffuse d'abord le bloc n°100 hors chaîne, puis publie l'en-tête du bloc sur la chaîne. Si le bloc 100 contient des transactions invalides, tout nœud Plasma peut soumettre une preuve de Merkle au contrat sur ETH avant la fin de la "période de contestation". Prouver que l'en-tête de bloc n°100 peut être associé à une transaction invalide, c'est un scénario couvert par la preuve de fraude.

Les scénarios d’application de Plasma à l’épreuve de la fraude comprennent également les éléments suivants :1. Supposons que la progression du réseau Plasma atteigne le bloc n° 200. À ce moment-là, l’utilisateur A initie une déclaration de retrait, disant que lorsqu’il était dans le bloc n° 100, il avait 10 ETH. Mais en fait, l’utilisateur A a dépensé l’ETH sur son compte après le bloc 100. Par conséquent, le comportement de A est en fait le suivant : après avoir dépensé 10 ETH, il déclare qu’il a eu 10 ETH dans le passé, et essaie de retirer ces ETH. Il s’agit d’un « double retrait » et d’une double dépense typiques. À l’heure actuelle, n’importe qui peut soumettre une preuve de Merkle pour prouver que le dernier statut d’actif de l’utilisateur A ne satisfait pas à sa déclaration de retrait, c’est-à-dire pour prouver que A n’a pas retiré l’argent indiqué après le bloc 100. (Différents schémas Plasma ont des méthodes de preuve incohérentes pour cette situation, et le modèle d’adresse de compte est beaucoup plus gênant que la preuve de double dépense d’UTXO). 2. S’il s’agit d’une solution Plasma basée sur le modèle UTXO (c’était principalement le cas dans le passé), l’en-tête de bloc ne contient pas StateRoot, mais uniquement TxnRoot (UTXO ne prend pas en charge le modèle d’adresse de compte de style Ethereum, et il n’y a pas d’état global tel que State Trie). En d’autres termes, une chaîne utilisant le modèle UTXO n’a que des enregistrements de transaction et aucun enregistrement de statut. À ce stade, le séquenceur lui-même peut lancer une attaque à double dépense, par exemple en dépensant un UTXO qui a été dépensé à nouveau, ou en émettant des UTXO supplémentaires à un utilisateur à partir de rien. N’importe quel utilisateur peut soumettre une preuve de Merkle pour prouver que l’enregistrement d’utilisation de l’UTXO est apparu (a été dépensé) dans les blocs précédents, ou pour prouver qu’il y a un problème avec la source historique d’un certain UTXO.

1. Pour les solutions Plasma compatibles avec l'EVM/L'arbre d'état, le trieur peut soumettre une StateRoot invalide. Par exemple, après l'exécution de la transaction contenue dans le 100e bloc, la StateRoot devrait être convertie en ST+, mais le trieur passe à la Layer1 Ce qui a été soumis était ST-. La preuve de fraude dans ce cas est plus compliquée et nécessite de rejouer la transaction dans le bloc n°100 sur la chaîne Ethereum. Le montant de calcul et les paramètres d'entrée requis consommeront beaucoup de gaz. Les équipes qui ont adopté tôt Plasma ont eu du mal à réaliser de telles preuves de fraude complexes, donc la plupart d'entre elles ont adopté le modèle UTXO. Après tout, les preuves de fraude basées sur UTXO sont simples et faciles à mettre en œuvre. (Fuel, la première solution de rollup à fournir une preuve de fraude, est basée sur UTXO)

Rétention de données et jeu de sortie. Bien sûr, les scénarios ci-dessus où la preuve de fraude peut être efficace ne sont établis que lorsque la DA/la publication de données est efficace. Si le séquenceur se livre à une rétention de données et ne publie pas de blocs complets hors chaîne, le nœud Plasma ne pourra pas confirmer si l'en-tête de bloc sur la couche 1 est valide, et bien sûr il ne pourra pas émettre des preuves de fraude en douceur.

À ce stade, le séquenceur peut voler les actifs de l’utilisateur, par exemple, transférer en privé toutes les pièces du compte A vers le compte B, puis transférer de l’argent du compte B vers le compte C, et enfin initier un retrait au nom de C. Les comptes B et C appartiennent au séquenceur lui-même. Même si le transfert B->C est rendu public, il ne causera aucun préjudice ; Mais le trieur peut retenir les données du transfert invalide A->B, et les gens ne peuvent pas prouver qu’il y a un problème avec la source des actifs de B et C. (Pour prouver que la source des actifs de B est louche, il est nécessaire de souligner que la signature numérique d’un « certain Txn transféré à B » est incorrecte). La solution Plasma à base d’UTXO comporte des mesures ciblées. Par exemple, lorsqu’une personne initie un retrait, elle doit soumettre toutes les sources historiques des actifs. Bien sûr, il y aura d’autres mesures d’amélioration plus tard. Mais s’il s’agit d’une solution de plasma compatible EVM, elle apparaîtra faible dans cette zone. Parce que si Txn lié au contrat est impliqué, la vérification du processus de transition d’état sur la chaîne entraînera des coûts énormes,Par conséquent, Plasma, qui prend en charge les modèles d’adresse de compte et les contrats intelligents, ne peut pas facilement mettre en œuvre un système de vérification de la validité des retraits. De plus, en dehors du sujet ci-dessus, qu’il s’agisse de Plasma basé sur UTXO ou du modèle d’adresse de compte, une fois que la rétention de données se produit, cela provoquera essentiellement la panique des gens car vous ne savez pas quelles transactions le séquenceur a exécutées. Les nœuds Plasma trouveront que quelque chose ne va pas, mais ils ne seront pas en mesure d’émettre des preuves de fraude car le séquenceur Plasma n’a pas émis les données requises pour les preuves de fraude. À l’heure actuelle, les utilisateurs ne peuvent voir que l’en-tête de bloc correspondant, mais ils ne savent pas ce qu’il y a dans le bloc ni ce qu’il est advenu des actifs de leur compte. Tout le monde initiera collectivement une déclaration de retrait et utilisera l’en-tête de bloc correspondant. Merkle Proof tente de retirer de l’argent, déclenchant un scénario extrême appelé « Exit Game », cette situation conduira à une « bousculade », provoquant une grave congestion dans la couche 1, et causera toujours des dommages aux actifs de certaines personnes. (Les personnes qui n’ont pas reçu de notifications de nœud honnêtes ou qui ne vérifient pas Twitter ne sauront pas que le séquenceur vole des pièces).

ainsi, le plasma est une solution d’extension de couche 2 peu fiable. Une fois qu’une attaque de rétention de données se produit, le « jeu de sortie » sera déclenché, ce qui peut facilement entraîner des pertes pour les utilisateurs. C’est l’une des principales raisons de son abandon. Pourquoi Plasma a du mal à prendre en charge les contrats intelligentsAprès avoir parlé du jeu de sortie et des problèmes de conservation des données, voyons pourquoi Plasma a du mal à prendre en charge les contrats intelligents. Il y a deux raisons principales : Premièrement, s’il s’agit d’un actif d’un contrat Defi, qui doit le retirer au niveau 1 ? Parce qu’il s’agit essentiellement de migrer le statut du contrat de la couche 2 à la couche 1.Supposons que quelqu’un dépose 100 ETH dans le pool DEX LP, puis que le séquenceur Plasma fasse quelque chose de mal, et que les gens veuillent retirer de l’argent de toute urgence. À l’heure actuelle, les 100 ETH de l’utilisateur sont toujours contrôlés par le contrat DEX. Qui devrait être propriétaire de ces actifs à l’heure actuelle ? Mentionné sur la couche 1 ? Le meilleur moyen semble être de permettre aux utilisateurs de racheter d’abord des actifs à partir de DEX, puis de laisser les utilisateurs transférer eux-mêmes l’argent vers L1. Mais le problème est que le trieur de plasma a fait le mal et peut rejeter les demandes des utilisateurs à tout moment. Alors, que se passe-t-il si nous configurons le propriétaire du contrat DEX à l’avance et que nous lui permettons de porter les actifs du contrat à L1 en cas d’urgence ? De toute évidence, cela donnera au propriétaire du contrat la propriété des biens publics. Il peut porter ces actifs en L1 et s’enfuir à tout moment. N’est-ce pas terrible ? De toute évidence, la façon de traiter ces « propriétés publiques » contrôlées par des contrats Defi est une énorme surprise. 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 interviewIl est difficile de créer de nouvelles choses sur des chaînes publiques haute performance, les contrats intelligents impliquent la distribution de puissanceCela a été mentionné dans l'article.

Deuxièmement, si le contrat n’est pas autorisé à migrer, il subira d’énormes pertes ; Si le contrat est autorisé à migrer son état vers la couche 1, il y aura un double retrait difficile à résoudre dans Plasma fraud proof :Par exemple, nousSupposons que Plasma adopte le modèle d’adresse de compte d’Ethereum et prend en charge les contrats intelligents., il y a un mélangeur, actuellement déposé avec 100 ETH, et le propriétaire du mélangeur est contrôlé par Bob ; supposons que Bob retire 50 ETH de la table de mixage dans le 100e bloc. Ensuite, Bob initie une déclaration de retrait et transfère les 50 ETH à la couche 1 ; Ensuite, Bob utilise l’instantané de l’état du contrat passé (tel que le 70e bloc) pour migrer l’état passé de la table de mixage vers la couche 1, ce qui signifie que les 100 ETH que la table de mixage « possédait » ont également été transférés vers la couche 1 ; De toute évidence, il s’agit d’un « double retrait » typique, c’est-à-dire d’une double dépense.150 ETH ont été mentionnés par Bob à la couche 1, mais les utilisateurs du réseau de la couche 2 n’ont payé que 100 ETH à la table de mixage/Bob, et 50 ETH ont été retirés de nulle part. Cela pourrait facilement drainer les réserves de plasma à sec。 En théorie, on pourrait initier une preuve de fraude pour prouver que l’état du contrat de mixage a changé après le 70e bloc. Mais si, après le bloc n° 70, tous les Txn qui ont interagi avec le contrat de mixage n’ont pas changé le statut du contrat, à l’exception de la transaction dans laquelle Bob a emporté 50 ETH ; s’il y a un changement après le bloc n° 70, tous les Txn mentionnés ci-dessus doivent être exécutés sur la chaîne Ethereum, et enfin le contrat Plasma peut être confirmé. Le statut du contrat du mélangeur a en effet changé (la raison pour laquelle il est si compliqué est que déterminé par la structure du plasma lui-même). Si le nombre de Txn dans ce lot est extrêmement important, la preuve de fraude ne peut pas du tout être publiée sur Layer1. (Il dépassera la limite de gaz d’un seul bloc d’Ethereum).

https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598Theoretiquement, dans le scénario de double dépense ci-dessus, il semble que seul l’instantané de l’état actuel de la table de mixage soit soumis (en fait la preuve de Merkle correspondant à StateRoot), mais en fait, comme Plasma ne publie pas les données de transaction sur la chaîne, le contrat ne peut pas déterminer si vous Si l’instantané d’état soumis est valide. En effet, le séquenceur lui-même peut initier une rétention de données, soumettre des instantanés d’état non valides et incriminer de manière malveillante tout retrait. Par exemple, lorsque vous déclarez que vous avez 50 ETH sur votre compte et que vous lancez un retrait, le séquenceur peut effacer votre compte en privé à 0, puis initier une retenue de données, envoyer un StateRoot invalide à la chaîne et soumettre l’instantané d’état correspondant, vous accusant à tort de manquer d’argent sur votre compte. À l’heure actuelle, nous ne pouvons pas prouver que le StateRoot et l’instantané d’état envoyés par le séquenceur ne sont pas valides, car il a initié la rétention de données et vous ne pouvez pas obtenir suffisamment de données requises pour la preuve de la fraude. Afin d’éviter cela, lorsqu’un nœud Plasma présente un instantané d’état pour prouver que quelqu’un a doublé ses dépenses, il relit également les enregistrements de transaction au cours de cette période. Cela peut empêcher le séquenceur d’utiliser la rétention de données pour empêcher d’autres personnes de retirer de l’argent. Dans Rollup, si vous rencontrez le double retrait mentionné ci-dessus, il n’est théoriquement pas nécessaire de rejouer les transactions historiques, car Rollup n’a pas de problèmes de rétention de données et « forcera » le séquenceur à publier des données DA sur la chaîne. Si le séquenceur de cumul soumet un instantané d’état StateRoot non valide, il échouera à la vérification du contrat (ZK Rollup) ou sera bientôt contesté (OP Rollup). En fait, en plus de l’exemple du mélangeur de pièces mentionné ci-dessus, des scénarios tels que les contrats à signatures multiples peuvent également entraîner des doubles retraits sur le réseau Plasma. La preuve de la fraude est très inefficace pour gérer ce scénario. Cette situation est analysée dans ETH Research. En résumé, étant donné que la solution Plasma n’est pas propice aux contrats intelligents et ne prend fondamentalement pas en charge la migration du statut de contrat vers la couche 1, Plasma grand public doit utiliser UTXO ou des mécanismes similaires. Étant donné qu’UTXO n’a pas le problème des conflits de propriété d’actifs et qu’il peut très bien prendre en charge la protection contre la fraude (il est beaucoup plus petit), le prix à payer est qu’il n’a qu’un seul scénario d’application et ne peut fondamentalement prendre en charge que les transferts ou les échanges de carnets d’ordres. De plus, étant donné que la preuve contre la fraude elle-même dépend fortement des données de l’AD, si la couche de l’AD n’est pas fiable, il sera difficile de mettre en œuvre un système efficace de l’épreuve de la fraude. Cependant, la gestion du problème de l’AD par Plasma est trop grossière et ne peut pas résoudre le problème des attaques de rétention de données. Avec l’essor de Rollup, Plasma a lentement disparu de la scène de l’histoire.

Avertissement：

1. Cet article est repris de [ WeChat officiel : Geek Web3]. Tous les droits d'auteur appartiennent à l'auteur original [Faust]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendrel'équipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.