Rétention de données et protection contre la fraude : pourquoi Plasma ne prend pas en charge les contrats intelligents

Auteur : Faust, geek web3

Quant à savoir pourquoi 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 hors chaîne sur la chaîne Ethereum n’est pas fiable, et la rétention de données est facile à se produire, et une fois que la rétention de données se produit, la preuve de la fraude est difficile à développer ; **Ces deux points font que Plasma n’est fondamentalement qu’un modèle UTXO ou approximatif.

Pour comprendre ces deux points essentiels, commençons par l’AD et la conservation des données. DA est l’abréviation de Data Avalibility, qui se traduit littéralement par la disponibilité des données, et 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 réalité, les « données historiques » et la « preuve de stockage » sont des problèmes de longue date qui ont été résolus par des entreprises comme Filecoin et Arweave. Selon la Fondation Ethereum et Celestia, la question de l’AD concerne uniquement les scénarios de rétention de données. **

**** Arbre de Merkle & Racine de Merkle & Preuve de Merkle****

Pour illustrer ce que signifient les attaques de rétention de données et les problèmes de DA, nous devons d’abord parler brièvement de la racine de Merkle et de l’arbre de Merkle. **Dans Ethereum, ou dans la plupart des chaînes publiques, une structure de données arborescente appelée arbre de Merkle est utilisée pour servir de résumé/répertoire de l’état de l’ensemble du compte, 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 brutes telles que les transactions ou l’état du compte, **Ces hachages sont additionnés par paires et itérations, et une racine de Merkle peut enfin être calculée.

(L’enregistrement au bas du diagramme est le jeu de données d’origine 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 des épreuves, connue sous le nom de Merkle Proof, tire parti de cette propriété de l’arbre de Merkle.

Par exemple, si Li Gang ne connaît que la valeur de la racine de Merkle dans la figure, il ne sait pas quelles données contient l’arbre de Merkle complet. Nous devons prouver à Li Gang que l’enregistrement 3 est bien lié à la racine de l’image, ou que le hachage de l’enregistrement 3 existe sur l’arbre de Merkle correspondant à la racine.

Nous n’avons qu’à soumettre Record3 et les 3 blocs de synthèse marqués en gris à Li Gang, au lieu de valider l’ensemble de l’arbre de Merkle ou tous ses nœuds feuilles, ce qui est la simplicité de la preuve de Merkle. Lorsque l’enregistrement sous-jacent de l’arbre de Merkle comporte un grand nombre de feuilles, par exemple 2 puissance 2 blocs de données (environ 1 million), la preuve de Merkle n’a besoin de contenir qu’au moins 21 blocs de données.

(Le bloc de données 30 et H2 dans la figure peut constituer une preuve de Merkle, prouvant que le bloc de données 30 existe sur l’arbre de Merkle correspondant à H0)**

Dans le Bitcoin, l’Ethereum ou les ponts inter-chaînes, cette « simplicité » de Merkle Proof est souvent utilisée. Le nœud de lumière que nous connaissons est en fait le Li Gang mentionné ci-dessus, qui ne reçoit que l’en-tête de bloc du nœud complet, et non du bloc complet. Il est important de souligner ici qu’Ethereum utilise un arbre de Merkle appelé State Trie, qui agit comme un résumé de l’ensemble du compte. La racine de Merkle de la Trie d’État, appelée StateRoot, change chaque fois que l’état de l’un des comptes associés à la Trie d’État change.

Dans l’en-tête de bloc d’Ethereum, StateRoot sera enregistré, et la racine de Merkle (appelée racine Txn) de l’arborescence des transactions sera également enregistrée. Si le bloc 100 contient 300 transactions, alors les feuilles de l’arbre commercial représentent ces 300 Txn.

Une autre différence est que la quantité globale de données dans State Trie est particulièrement importante, et que sa feuille sous-jacente correspond à toutes les adresses de la chaîne Ethereum (en fait, il existe de nombreux hachages d’état obsolètes), de sorte que le jeu de données d’origine correspondant à State Trie ne sera pas publié dans le bloc, seul le StateRoot sera enregistré dans l’en-tête du bloc. Le jeu de données d’origine de l’arborescence des transactions est constitué des données Txn de chaque bloc, et la racine Txn de l’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, ne connaît que StateRoot et TxnRoot, et ne peut pas déduire l’arbre de Merkle complet en fonction de la racine (ceci est déterminé par la nature de l’arbre de Merkle et de la fonction de hachage), le nœud léger ne peut pas connaître les données de transaction contenues dans le bloc, ni savoir quels changements ont été apportés au compte correspondant au trie d’état. **

Si Wang Qiang veut prouver à un nœud de lumière (Li Gang mentionné plus haut) que le bloc 100 contient une certaine transaction, et qu’il est connu que le nœud de lumière connaît l’en-tête de bloc du bloc 100 et connaît TxnRoot, alors le problème ci-dessus se traduit par : prouver que ce Txn existe sur l’arbre de Merkle correspondant à TxnRoot. À l’heure actuelle, Wang Qiang n’a qu’à soumettre l’épreuve de Merkle correspondante.

Dans de nombreux ponts inter-chaînes basés sur des solutions de clients légers, la légèreté et la simplicité des nœuds légers et de la preuve de Merkle mentionnées 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 des en-têtes de bloc d’autres chaînes (telles que Polygon). Lorsque Relayer soumet l’en-tête du 100e bloc de Polygon au contrat sur la chaîne ETH, le contrat vérifie la validité de l’en-tête (par exemple, s’il contient suffisamment de signatures provenant de 2/3 nœuds POS dans le réseau Polygon).

Si l’en-tête est valide et qu’un utilisateur déclare qu’il a initié un Txn cross-chain de Polygon à ETH, le Txn est compressé dans le 100e bloc de Polygon. Il lui suffit de prouver par la preuve de Merkle que le Txn cross-chain qu’il a initié peut correspondre au TxnRoot de l’en-tête du bloc 100 (en d’autres termes, il prouve que le Txn cross-chain qu’il a initié a un enregistrement dans le bloc 100 de Polygon). Cependant, le pont ZK utilisera des preuves à divulgation nulle de connaissance pour comprimer la quantité de calcul nécessaire à la vérification de la preuve de Merkle, ce qui réduira encore le coût de vérification des contrats de pont inter-chaînes.

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

Après avoir parlé de l’arbre de Merkle et de la racine de Merkle et de la preuve de Merkle, revenons au problème de DA et d’attaque par rétention de données mentionné au début de l’article, qui a été exploré avant 2017, et l’article original de Celestia a archéologisé l’origine du problème DA. Dans un document de 2017~18, Vitalik lui-même a parlé de la façon dont les bloqueurs peuvent délibérément dissimuler certains fragments de données du bloc et publier des blocs incomplets, de sorte que les nœuds complets ne peuvent pas confirmer l’exactitude de l’exécution des transactions/transitions d’état.

À ce stade, le producteur de blocs peut voler les actifs de l’utilisateur, par exemple en transférant toutes les pièces du compte A à une autre adresse, et le nœud complet ne peut pas déterminer si A lui-même l’a fait, car il ne connaît pas les données de transaction complètes contenues dans le dernier bloc.

Dans les chaînes publiques de couche 1 telles que Bitcoin ou Ethereum, les nœuds complets honnêtes rejetteront directement les blocs invalides ci-dessus. Mais les nœuds légers sont différents, ils ne reçoivent que l’en-tête de bloc du réseau, ils ne connaissent que StateRoot et TxnRoot, et ils ne savent pas si le bloc d’origine correspondant à l’en-tête et aux deux racines est valide.

Dans le livre blanc de Bitcoin, il y a en fait un trou de cerveau pour cette situation, Satoshi Nakamoto croyait autrefois que la plupart des utilisateurs auront tendance à exécuter des nœuds légers avec des exigences de configuration plus faibles, et que les nœuds légers ne peuvent pas juger si le bloc correspondant à l’en-tête du bloc est valide, et si un bloc est invalide, le nœud complet honnête enverra une alarme au nœud léger.

Mais Satoshi Nakamoto n’a pas fait d’analyse plus détaillée de cette solution, et plus tard, Vitalik et le fondateur de Celestia, Mustafa, se sont appuyés sur cette idée, combinée avec le travail d’autres prédécesseurs, pour introduire l’échantillonnage de données DA afin de s’assurer que des nœuds complets honnêtes peuvent restaurer les données complètes de chaque bloc et déclencher une alarme si nécessaire.

Note : DA Data Sampling (DAS) et Celestia ne sont pas au centre de cet article, les lecteurs intéressés peuvent lire l’article précédent de Geek Web3 : « Misconceptions about Data Availability : DA= Data Publishing ≠ Historical Data Retrieval »

L’anti-fraude de Plasma

Pour faire simple, Plasma est une solution de mise à l’échelle qui ne publie que les en-têtes de bloc de couche 2 sur la couche 1, et les données DA en dehors de l’en-tête de bloc (ensemble complet de données de transaction/changement d’état par compte) ne sont publiées que hors chaîne. En d’autres termes, Plasma est comme un pont inter-chaînes basé sur des clients légers, mettant en œuvre un client léger de couche 2 avec un contrat sur la chaîne ETH, et lorsqu’un utilisateur déclare qu’il souhaite croiser des actifs de L2 à L1, il doit soumettre une preuve de Merkle pour prouver qu’il possède réellement les actifs.

**La logique de vérification pour les actifs allant de L2 à L1 est similaire à celle du pont ZK mentionné ci-dessus, sauf que le modèle du pont Plasma est basé sur des preuves de fraude plutôt que sur des preuves ZK, ce qui est plus proche du pont dit « optimiste ». **Les demandes de retrait de L2 à L1 dans le réseau Plasma ne sont pas libérées immédiatement, mais ont une « période de défi », comme pour l’objectif de la période de défi, nous expliquerons ci-dessous.

Plasma n’a pas d’exigences strictes en matière de libération de données/DA, le séquenceur/opérateur se contente de diffuser chaque bloc L2 hors chaîne, et les nœuds qui sont prêts à obtenir le bloc L2 le font par eux-mêmes. Après cela, le séquenceur publiera l’en-tête du bloc L2 sur la couche 1. Par exemple, le séquenceur diffuse le bloc 100 hors chaîne, puis publie l’en-tête du bloc sur la chaîne. Si le bloc 100 contient des transactions non valides, n’importe quel nœud plasma peut soumettre une preuve de Merkle au contrat sur l’ETH avant la fin de la « période de défi » pour prouver que l’en-tête du bloc 100 peut être associé à une transaction invalide, ce qui est un scénario couvert par les preuves de fraude.

Les cas d’utilisation de Plasma à l’épreuve de la fraude sont également les suivants :

1. Supposons que la progression du réseau Plasma atteigne le bloc 200 et que l’utilisateur A initie une déclaration de retrait, indiquant qu’il a 10 ETH dans le bloc 100. Mais en fait, l’utilisateur A a dépensé l’ETH sur le compte après le bloc 100.

Ainsi, le comportement de A est en fait de dépenser 10 ETH, de déclarer qu’il avait 10 ETH dans le passé et d’essayer de retirer l’ETH. C’est le classique « double retrait », double dépense. À l’heure actuelle, n’importe qui peut soumettre une preuve de Merkle pour prouver le dernier statut d’actif de l’utilisateur A, et ne répond pas à sa déclaration de retrait, c’est-à-dire pour prouver que A n’avait pas de déclaration de retrait 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’un schéma Plasma basé sur le modèle UTXO (ce qui était principalement le cas dans le passé), il n’y a pas de StateRoot dans l’en-tête de bloc, seulement TxnRoot (UTXO ne prend pas en charge le modèle d’adresse de compte de style Ethereum, ni n’a de conception d’état globale comme State Trie). En d’autres termes, une chaîne qui adopte le modèle UTXO n’a que des enregistrements de transaction, pas des enregistrements d’état.

Dans ce cas, le séquenceur lui-même peut lancer une attaque à double dépense, par exemple en dépensant un UTXO qui a déjà été dépensé, ou en émettant des UTXO supplémentaires à un utilisateur à partir de rien. N’importe quel utilisateur peut soumettre une preuve Merkle pour prouver que l’historique d’utilisation de l’UTXO est apparu (a été dépensé) dans les blocs précédents, ou pour prouver que l’origine historique d’un UTXO est discutable. **

3. Pour les schémas Plasma compatibles EVM/State-Trie, il est possible que le séquenceur soumette un StateRoot invalide, par exemple, après avoir exécuté la transaction contenue dans le bloc 100, le StateRoot doit être converti en ST+, mais le séquenceur soumet ST- à la couche 1.

Dans ce cas, la preuve de fraude est plus complexe et nécessite que la transaction du bloc 100 soit rejouée sur la chaîne Ethereum, ce qui consomme beaucoup de gaz avec la quantité de paramètres de calcul et d’entrée requis. Il est difficile pour les premières équipes d’adoption de Plasma d’obtenir des preuves de fraude aussi complexes, donc la plupart d’entre elles utilisent le modèle UTXO, après tout, les preuves de fraude basées sur UTXO sont très simples et faciles à mettre en œuvre (Fuel, le premier programme Rollup à lancer des preuves de fraude, est basé sur UTXO)

Conservation des données et sortie du jeu****

Bien entendu, les scénarios mentionnés ci-dessus dans lesquels les preuves de fraude peuvent prendre effet ne sont établis que lorsque l’AD/la publication des données est valide. Si le séquenceur retient les données et ne publie pas le bloc complet hors chaîne, le nœud Plasma ne sera pas en mesure de confirmer si l’en-tête de bloc sur la couche 1 est valide, et bien sûr, il ne sera pas en mesure de publier la preuve de fraude en douceur.

À ce moment-là, le séquenceur peut voler les actifs de l’utilisateur, par exemple en transférant toutes les pièces du compte A au compte B, puis en transférant de l’argent du compte B au compte C, et enfin en initiant un retrait au nom de C. Les comptes B et C sont la propriété du séquenceur, et le transfert de B->C est inoffensif même s’il est rendu public.** Mais le séquenceur peut retenir les données du transfert invalide de 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 problématique, il est nécessaire de souligner que la signature numérique d’un « certain Txn transféré à B » est incorrecte).

La solution Plasma basée sur UTXO est ciblée par le fait que toute personne initiant un retrait doit soumettre l’historique complet de l’actif, bien qu’il y ait d’autres améliorations par la suite. Cependant, s’il s’agit d’une solution de plasma compatible EVM, elle sera faible dans ce domaine. Parce que si le Txn lié au contrat est impliqué, il y aura un coût énorme pour vérifier le processus de transition d’état sur la chaîne, il est donc difficile de mettre en œuvre un système de vérification de la validité des retraits en prenant en charge le modèle d’adresse de compte et le contrat intelligent Plasma.

De plus, en dehors du sujet ci-dessus, qu’il s’agisse d’un Plasma basé sur UTXO ou basé sur un modèle d’adresse de compte, la rétention de données peut provoquer la panique car vous ne savez pas quelles transactions le séquenceur effectue. **Les nœuds Plasma trouveront quelque chose d’anormal, mais ils ne seront pas en mesure de publier des preuves de fraude car le séquenceur Plasma n’enverra pas les données requises pour les preuves de fraude.

À l’heure actuelle, les gens ne peuvent voir que l’en-tête de bloc correspondant, mais ils ne savent pas ce qu’il y a dans le bloc, et ils ne savent pas ce que sont devenus les actifs de leur compte, ils vont donc collectivement initier une déclaration de retrait et essayer de retirer avec la preuve de Merkle correspondant au bloc historique, déclenchant un scénario extrême appelé « Exit Game », qui conduira à une « ruée », ce qui rendra la couche 1 sérieusement encombrée, et causera toujours des dommages aux actifs de certaines personnes (Les personnes qui ne reçoivent pas de notifications de nœud honnêtes ou qui ne glissent pas sur Twitter ne sauront pas que le séquenceur vole des pièces.)

Par conséquent, Plasma est une solution de mise à l’échelle de couche 2 peu fiable, et une fois qu’une attaque de rétention de données se produit, elle déclenche un « jeu de sortie », qui est facile pour les utilisateurs de subir des pertes, ce qui est une raison majeure de son abandon. **

Raisons pour lesquelles le plasma est difficile à prendre en charge les contrats intelligents****

Après avoir parlé des problèmes de sortie du jeu et de conservation des données, voyons pourquoi Plasma a du mal à prendre en charge les contrats intelligents, principalement pour deux raisons :

Tout d’abord, s’il s’agit d’un actif d’un contrat Defi, qui devrait le retirer vers la couche 1 ? Parce qu’il s’agit essentiellement de migrer l’état du contrat de la couche 2 à la couche 1, supposons que quelqu’un facture 100 ETH au pool LP du DEX, puis que le séquenceur Plasma fasse le mal, et que les gens veuillent 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 semble être de laisser l’utilisateur racheter d’abord les actifs du DEX, puis l’utilisateur retirera l’argent à L1 par lui-même, mais le problème est que le séquenceur Plasma a fait quelque chose de mal et peut rejeter la demande de l’utilisateur à tout moment.

Alors, que se passe-t-il si nous mettons en place un propriétaire pour le contrat DEX à l’avance, lui permettant de mettre les actifs du contrat sur L1 en cas d’urgence ? Évidemment, cela donnera au propriétaire du contrat la propriété des actifs publics, et il peut mettre ces actifs sur L1 à tout moment et s’enfuir, ne serait-ce pas terrible ?

Evidemment, que faire de ces « biens publics » dominés par les contrats Defi est un énorme coup de tonnerre. Il s’agit en fait du problème de la distribution de l’énergie publique, dont Xiangma a déjà parlé dans une interview avec « Il est difficile pour les chaînes publiques performantes de faire de nouvelles choses, et les contrats intelligents impliquent la distribution de l’énergie ».

Deuxièmement, si le contrat n’est pas autorisé à migrer son état, il subira une perte énorme, et si le contrat est autorisé à migrer son état vers la couche 1, il y aura des doubles retraits difficiles à résoudre avec la preuve de la fraude Plasma :

Par exemple, supposons que Plasma adopte le modèle d’adresse de compte d’Ethereum, prenne en charge les contrats intelligents, dispose d’un mélangeur de pièces, dépose actuellement 100 ETH et que le propriétaire du mélangeur de pièces est contrôlé par Bob ;

Supposons que Bob retire 50 ETH de la table de mixage au bloc 100. Après cela, Bob a initié une déclaration de retrait et a franchi les 50 ETH à la couche 1 ;

Après cela, Bob utilise un instantané de l’état passé du contrat (par exemple, le bloc 70) pour migrer l’état passé de la table de mixage vers la couche 1, qui traversera également les 100 ETH que la table de mixage « avait autrefois » vers la couche 1.

De toute évidence, il s’agit d’un « double drawdown » 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 au mélangeur/Bob, et 50 ETH ont été retirés de nulle part. Cela peut facilement épuiser les réserves de plasma. Théoriquement, on pourrait initier une preuve de fraude pour prouver que l’état du contrat de mélangeur a changé après le bloc 70.

Mais si vous voulez montrer la preuve que le contrat Mixer a changé après le bloc 70, vous devez exécuter tous les Txn mentionnés ci-dessus sur la chaîne Ethereum pour finalement laisser le contrat Plasma déterminer que l’état du contrat Mixer a effectivement changé (la raison pour laquelle il est si complexe est déterminée par la structure de Plasma lui-même). Si la quantité de Txn est si importante, la preuve de fraude ne sera pas du tout publiée sur la couche 1 (elle dépassera la limite de gaz pour un seul bloc d’Ethereum).

Théoriquement, dans le scénario de double dépense ci-dessus, il semble que vous n’ayez besoin de soumettre qu’un instantané de l’état actuel de la table de mixage (qui est 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 l’instantané de l’état que vous soumettez est valide. **En effet, le séquenceur lui-même peut initier la conservation des données, soumettre des instantanés d’état non valides et signaler 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 un instantané d’état correspondant pour vous accuser à tort de manquer d’argent sur votre compte. À ce stade, vous ne pouvez 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 conservation des données, et vous n’obtenez pas suffisamment de données nécessaires pour prouver la fraude. **

Pour éviter cela, le nœud Plasma relit également l’historique des transactions pendant cette période lorsqu’il présente un instantané de l’état pour prouver que quelqu’un a une double dépense, ce qui empêche le séquenceur de retenir des données pour empêcher les autres de se retirer. Dans Rollup, si vous rencontrez le double retrait mentionné ci-dessus, vous n’avez pas besoin de rejouer la transaction historique en théorie, car Rollup n’a pas le problème de la rétention de données et « forcera » le séquenceur à publier des données DA sur la chaîne. **Les séquenceurs de cumul qui soumettent un instantané d’état StateRoot non valide échoueront soit à la validation du contrat (ZK Rollup), soit seront bientôt contestés (OP Rollup).

En effet, en plus de l’exemple du mélangeur de pièces mentionné ci-dessus, des scénarios tels que les contrats multi-signatures peuvent également entraîner des doubles retraits sur le réseau Plasma. Les preuves de fraude sont inefficaces pour gérer de tels scénarios. **Cette situation est analysée dans ETH Research.

Pour résumer, parce que le schéma Plasma n’est pas propice aux contrats intelligents et ne prend fondamentalement pas en charge la migration de l’état du contrat vers la couche 1, le Plasma grand public doit choisir UTXO ou des mécanismes similaires, car UTXO n’a pas le problème du conflit de propriété des actifs et peut bien prendre en charge la preuve de la fraude (beaucoup plus petite en taille), mais au prix d’un scénario d’application unique, il ne peut fondamentalement prendre en charge que les échanges de transfert ou de carnet d’ordres.

De plus, étant donné que la preuve de fraude elle-même dépend fortement des données de l’AD, il sera difficile d’obtenir un système efficace de l’épreuve de la fraude si la couche de l’AD n’est pas fiable. Cependant, la gestion des problèmes de DA par Plasma est trop rudimentaire pour résoudre le problème des attaques de rétention de données, et avec l’essor du Rollup, Plasma a lentement disparu de l’histoire. **