Analyse des raisons pour lesquelles Plasma ne prend pas en charge les contrats intelligents : rétention de données et preuves de fraude
TechFlow SélectionTechFlow Sélection
Analyse des raisons pour lesquelles Plasma ne prend pas en charge les contrats intelligents : rétention de données et preuves de fraude
Plasma ne peut pas résoudre le problème de la rétention de données et n'est pas favorable au transfert de l'état des contrats vers la couche 1 ; il sera donc inévitablement abandonné.
Dédié à des analyses Web3 approfondiesRédaction : Faust, geek web3
Les raisons pour lesquelles Plasma a été longtemps oublié, et pourquoi Vitalik soutient fermement Rollup, se résument principalement à deux points : implémenter la DA (disponibilité des données) hors chaîne Ethereum est peu fiable, car elle entraîne facilement une rétention de données ; or, en cas de rétention, il devient difficile d’émettre des preuves de fraude. La conception même du mécanisme Plasma est extrêmement défavorable aux contrats intelligents, notamment en ce qu’elle ne permet guère le transfert d’état des contrats vers la couche 1. Ces deux facteurs limitent Plasma à l’adoption de modèles UTXO ou similaires.
Pour comprendre ces deux idées fondamentales, commençons par aborder la question de la DA et celle de la rétention de données. DA signifie Data Availability (disponibilité des données), souvent traduit littéralement par « disponibilité des données ». Ce terme est aujourd’hui fréquemment mal utilisé, au point d’être confondu avec la notion de « vérifiabilité historique des données ». Pourtant, la vérifiabilité historique des données ainsi que la preuve de stockage sont des problèmes déjà résolus par des projets comme Filecoin ou Arweave. Selon la Fondation Ethereum et Celestia, le problème de la DA concerne exclusivement les scénarios de rétention de données.
Arbre de Merkle, racine de Merkle et preuve de Merkle
Afin d’expliquer précisément ce qu’est une attaque par rétention de données et à quoi correspond le problème de la DA, nous devons d’abord brièvement présenter la racine de Merkle, l’arbre de Merkle et la preuve de Merkle. Dans Ethereum ou la plupart des blockchains publiques, une structure de données arborescente appelée « arbre de Merkle » sert de résumé ou d’index à l’ensemble des états des comptes, ou bien enregistre les transactions incluses dans chaque bloc.
Les feuilles situées au bas de l’arbre de Merkle sont constituées du hachage des données brutes telles que les transactions ou les états des comptes. Ces hachages sont regroupés par paires, puis combinés itérativement jusqu’à produire une valeur unique appelée racine de Merkle (Merkle Root).
(Les « records » tout en bas de l’image représentent les données brutes associées aux nœuds feuilles)
La racine de Merkle possède une propriété importante : si un nœud feuille de l’arbre de Merkle change, alors la racine de Merkle calculée change également. Ainsi, différents ensembles de données brutes produisent différentes racines de Merkle, un peu comme chaque individu possède une empreinte digitale unique. C’est cette propriété que met à profit la technique de vérification appelée « preuve de Merkle ».
Reprenons l’exemple illustré ci-dessus : supposons que Li Gang connaisse uniquement la valeur de la racine de Merkle figurant sur l’image, mais ignore complètement les données complètes de l’arbre. Nous souhaitons prouver à Li Gang que « Record 3 » est effectivement lié à cette racine, c’est-à-dire démontrer que le hachage de « Record 3 » existe bien dans l’arbre de Merkle associé à cette racine.
Il nous suffit alors de fournir à Li Gang le « Record 3 » lui-même, ainsi que les trois blocs de données digest grisés sur l’image, sans avoir besoin de transmettre l’intégralité de l’arbre de Merkle ni tous ses nœuds feuilles. C’est là toute la concision de la preuve de Merkle. Lorsque l’arbre contient un très grand nombre de feuilles — par exemple 2²⁰ blocs de données (environ un million) —, la preuve de Merkle nécessite au minimum seulement 21 blocs de données.
(Les blocs de données 30 et H2 sur l’image forment ensemble une preuve de Merkle, attestant que le bloc 30 appartient bien à l’arbre de Merkle associé à H0)
Dans Bitcoin, Ethereum ou les ponts inter-chaînes, on utilise fréquemment cette « concision » offerte par la preuve de Merkle. Les nœuds légers dont nous parlons correspondent exactement à Li Gang dans notre exemple : ils reçoivent uniquement l’en-tête (header) des blocs depuis les nœuds complets, et non les blocs entiers. Soulignons ici qu’Ethereum utilise une structure appelée « State Trie », un arbre de Merkle, comme résumé de l’ensemble des comptes. Dès lors qu’un état de compte lié au State Trie change, sa racine de Merkle — appelée StateRoot — change aussi.
L’en-tête d’un bloc Ethereum inclut le StateRoot, ainsi que la racine de Merkle de l’arbre des transactions (abrégée Txn Root). La différence entre l’arbre des transactions et l’arbre d’état réside dans la nature des données représentées par leurs feuilles. Par exemple, si le bloc numéro 100 contient 300 transactions, les feuilles de l’arbre des transactions représentent précisément ces 300 transactions.
Une autre différence tient au volume global des données : le State Trie est extrêmement volumineux, car ses feuilles représentent tous les adresses sur Ethereum (et même de nombreux hachages d’états obsolètes). L’ensemble des données brutes du State Trie n’est donc pas publié dans les blocs ; seul le StateRoot est enregistré dans l’en-tête. En revanche, les données brutes de l’arbre des transactions correspondent directement aux transactions contenues dans chaque bloc, et leur TxnRoot est inscrit dans l’en-tête du bloc.
Étant donné que les nœuds légers ne reçoivent que les en-têtes des blocs, ils connaissent uniquement le StateRoot et le TxnRoot, mais ne peuvent pas reconstruire l’arbre de Merkle complet à partir de la racine (en raison des propriétés mêmes de l’arbre de Merkle et des fonctions de hachage). Ainsi, les nœuds légers ne peuvent pas connaître les données des transactions incluses dans les blocs, ni savoir quels comptes ont vu leur état modifié.
Si Wang Qiang souhaite prouver à un nœud léger (Li Gang, mentionné plus haut) qu’une transaction donnée est incluse dans le bloc numéro 100, sachant que ce nœud connaît l’en-tête du bloc 100 et son TxnRoot, alors le problème se reformule ainsi : démontrer que cette transaction existe bien dans l’arbre de Merkle associé au TxnRoot. Dans ce cas, Wang Qiang n’a qu’à fournir la preuve de Merkle correspondante.
De nombreux ponts inter-chaînes basés sur des solutions de type « client léger » exploitent cette légèreté et cette concision du nœud léger et de la preuve de Merkle. Par exemple, Map Protocol et d’autres ponts ZK déploient sur Ethereum un contrat conçu pour recevoir les en-têtes de blocs provenant d’autres chaînes (comme Polygon). Lorsqu’un relais (relayer) soumet l’en-tête du 100ᵉ bloc de Polygon au contrat sur Ethereum, celui-ci vérifie la validité de cet en-tête (par exemple, s’il dispose bien des signatures de 2/3 des nœuds POS du réseau Polygon).
Si l’en-tête est valide et qu’un utilisateur affirme avoir initié une transaction inter-chaînes de Polygon vers ETH, incluse dans le 100ᵉ bloc de Polygon, il peut simplement fournir une preuve de Merkle pour montrer que sa transaction correspond bien au TxnRoot du 100ᵉ bloc (autrement dit, il prouve que sa transaction figure bien dans le 100ᵉ bloc de Polygon). Toutefois, les ponts ZK utilisent la preuve à divulgation nulle de connaissance (ZK) pour compresser les calculs nécessaires à la vérification de la preuve de Merkle, réduisant ainsi davantage le coût de vérification pour le contrat du pont.
DA et attaques par rétention de données
Après avoir expliqué l’arbre de Merkle, la racine de Merkle et la preuve de Merkle, revenons maintenant au problème de la DA et des attaques par rétention de données évoqué au début de cet article. Ce sujet a été discuté dès avant 2017, et le document original de Celestia retrace l’origine du problème DA. Vitalik lui-même, dans un document datant de 2017-2018, a mentionné que les producteurs de blocs pourraient intentionnellement dissimuler certaines parties des données d’un bloc, publiant ainsi un bloc incomplet. Dans ce cas, les nœuds complets ne peuvent plus vérifier la validité de l’exécution des transactions ou des transitions d’état.
À ce moment-là, le producteur de blocs pourrait voler les actifs des utilisateurs, par exemple en transférant tous les jetons du compte A vers une autre adresse, sans que les nœuds complets puissent juger si A a effectué cette action, faute d’avoir accès aux données complètes des transactions du dernier bloc.
Sur des blockchains de niveau 1 comme Bitcoin ou Ethereum, les nœuds complets honnêtes rejettent directement ces blocs invalides. Mais les nœuds légers sont différents : ils ne reçoivent que les en-têtes (headers) du réseau, connaissent donc le StateRoot et le TxnRoot, mais ignorent si les données brutes associées à ces en-têtes et racines sont valides.
Dans le livre blanc de Bitcoin, Satoshi Nakamoto avait envisagé ce cas de figure : la majorité des utilisateurs opteraient probablement pour des nœuds légers nécessitant moins de ressources, or ces derniers ne peuvent pas vérifier si un bloc est valide. Si un bloc est invalide, les nœuds complets honnêtes devraient alerter les nœuds légers.
Cependant, Satoshi Nakamoto n’a pas approfondi cette proposition. Plus tard, Vitalik et Mustafa, fondateur de Celestia, ont développé cette idée en y intégrant d’autres travaux antérieurs, introduisant notamment l’échantillonnage des données (data sampling) pour garantir que les nœuds complets honnêtes puissent reconstituer les données complètes de chaque bloc et émettre une alerte si nécessaire.
Preuves de fraude dans Plasma
En résumé, Plasma est une solution de mise à l’échelle qui publie uniquement les en-têtes des blocs de la couche 2 sur la couche 1, tandis que les données DA (données complètes des transactions / modifications d’état des comptes) sont publiées hors chaîne. Autrement dit, Plasma fonctionne comme un pont inter-chaînes basé sur un client léger : un contrat sur Ethereum implémente un client léger de la couche 2. Lorsqu’un utilisateur souhaite retirer des actifs de la couche 2 vers la couche 1, il doit fournir une preuve de Merkle pour démontrer qu’il possède bien ces actifs.
La logique de vérification du retrait d’actifs de la couche 2 vers la couche 1 est similaire à celle des ponts ZK décrite précédemment, à la différence que le modèle de pont de Plasma repose sur des preuves de fraude plutôt que sur des preuves ZK, se rapprochant ainsi du concept de « pont optimiste ». Les demandes de retrait de la couche 2 vers la couche 1 dans le réseau Plasma ne sont pas immédiatement approuvées, mais font l’objet d’une « période de contestation ». À quoi sert cette période ? Nous allons l’expliquer ci-dessous.
Plasma n’impose aucune exigence stricte concernant la publication des données (DA) : l’ordonnanceur (operator) diffuse simplement chaque bloc L2 hors chaîne, et seuls les nœuds intéressés iront les récupérer. Ensuite, l’ordonnanceur publie l’en-tête du bloc L2 sur la couche 1. Par exemple, il diffuse d’abord hors chaîne le bloc numéro 100, puis publie son en-tête sur la chaîne. Si ce bloc 100 contient une transaction invalide, tout nœud Plasma peut, avant la fin de la période de contestation, soumettre au contrat Ethereum une preuve de Merkle prouvant que l’en-tête du bloc 100 est lié à une transaction invalide. Tel est l’un des cas d’usage de la preuve de fraude.
Les autres cas d’usage des preuves de fraude dans Plasma sont les suivants :
1. Supposons que le réseau Plasma ait atteint le bloc 200. L’utilisateur A déclare alors qu’il possédait 10 ETH au bloc 100. En réalité, après le bloc 100, A a dépensé tous ses ETH.
Son comportement revient donc à : après avoir dépensé ses 10 ETH, prétendre qu’il en possédait encore 10 auparavant, et tenter de les retirer. Il s’agit typiquement d’un « double retrait », ou double dépense. Dans ce cas, toute personne peut soumettre une preuve de Merkle prouvant que l’état actuel des actifs d’A ne correspond pas à sa demande de retrait — autrement dit, prouver qu’après le bloc 100, A ne possédait plus les fonds qu’il réclame. (Les différentes variantes de Plasma n’utilisent pas toutes la même méthode pour ce type de preuve ; la preuve de double dépense est nettement plus complexe dans un modèle d’adresses de comptes que dans un modèle UTXO.)
2. Dans un schéma Plasma basé sur le modèle UTXO (la majorité des anciennes versions), l’en-tête de bloc ne contient pas de StateRoot, seulement un TxnRoot (le modèle UTXO ne supporte pas le système d’adresses de comptes d’Ethereum, ni une conception globale d’état comme le State Trie). Autrement dit, les chaînes basées sur UTXO conservent uniquement l’historique des transactions, pas l’état.
Dans ce cas, l’ordonnanceur peut lui-même lancer une attaque par double dépense : par exemple, dépenser deux fois un UTXO déjà utilisé, ou créer artificiellement un nouvel UTXO. Tout utilisateur peut alors soumettre une preuve de Merkle prouvant que cet UTXO a déjà été utilisé dans un bloc antérieur (dépensé), ou que son origine historique est invalide.
3. Pour les schémas Plasma compatibles EVM et supportant le State Trie, l’ordonnanceur pourrait soumettre un StateRoot invalide. Par exemple, après exécution des transactions du bloc 100, le StateRoot devrait être ST+, mais l’ordonnanceur soumet ST- à la couche 1.
Dans ce cas, la preuve de fraude est plus complexe : elle nécessite de rejouer les transactions du bloc 100 sur Ethereum, ce qui consomme beaucoup de gaz en raison du volume des calculs et des paramètres d’entrée requis. Les premières équipes utilisant Plasma ont eu du mal à implémenter de telles preuves complexes, ce qui les a poussées à adopter majoritairement le modèle UTXO, dont les preuves de fraude sont simples et faciles à mettre en œuvre (Fuel, le premier projet Rollup à implémenter une preuve de fraude, était basé sur UTXO).
Rétention de données et « jeu de sortie » (Exit Game)
Bien entendu, les preuves de fraude décrites ci-dessus ne fonctionnent que si la publication des données (DA) est effective. Si l’ordonnanceur retient les données et ne publie pas les blocs complets hors chaîne, les nœuds Plasma ne peuvent pas vérifier si les en-têtes sur la couche 1 sont valides, ni émettre efficacement des preuves de fraude.
Dans ce cas, l’ordonnanceur peut voler les actifs des utilisateurs, par exemple en transférant tous les jetons du compte A vers le compte B, puis en envoyant de B vers C, et enfin en lançant un retrait au nom de C. Les comptes B et C appartiennent à l’ordonnanceur ; le transfert B→C, même rendu public, n’a pas d’importance ; mais l’ordonnanceur peut retenir les données du transfert invalide A→B, empêchant ainsi quiconque de prouver que les actifs de B et C proviennent d’une source illégitime (pour prouver que les actifs de B viennent d’une source suspecte, il faudrait montrer que la signature numérique de « la transaction ayant transféré à B » est erronée).
Les schémas Plasma basés sur UTXO ont mis en place des mesures spécifiques, comme exiger que tout demandeur de retrait fournisse l’historique complet de provenance de ses actifs, bien que des améliorations ultérieures aient été apportées. Mais pour les schémas Plasma compatibles EVM, ces mesures s’avèrent inefficaces. Car si des transactions liées à des contrats sont concernées, la vérification du changement d’état sur chaîne engendrerait des coûts prohibitifs, rendant difficile l’implémentation d’un mécanisme de vérification de la validité des retraits dans un Plasma supportant les adresses de comptes et les contrats intelligents.
Par ailleurs, indépendamment de ce qui précède, quelle que soit la base (UTXO ou adresses de comptes), une rétention de données déclenche généralement une panique collective, car on ignore quelles transactions ont été exécutées. Les nœuds Plasma détectent une anomalie, mais ne peuvent pas publier de preuve de fraude ciblée, car les données nécessaires à cette preuve n’ont pas été diffusées par l’ordonnanceur.
Dans cette situation, les gens ne voient que les en-têtes des blocs, sans savoir ce qu’ils contiennent ni comment leurs actifs ont évolué. Ils lancent donc collectivement des demandes de retrait, utilisant des preuves de Merkle correspondant à des blocs historiques, ce qui déclenche un scénario extrême appelé « Exit Game », conduisant à un emballement (« stampede ») qui congestionne gravement la couche 1 et cause toujours des pertes pour certains utilisateurs (ceux qui n’ont pas reçu l’alerte des nœuds honnêtes ou ne suivent pas Twitter ignorent que l’ordonnanceur est en train de voler des jetons).
Ainsi, Plasma est une solution de mise à l’échelle de couche 2 peu fiable : en cas d’attaque par rétention de données, elle déclenche un « Exit Game », exposant facilement les utilisateurs à des pertes. C’est l’une des principales raisons de son abandon.
Pourquoi Plasma peine à supporter les contrats intelligents
Après avoir expliqué le « Exit Game » et le problème de rétention de données, examinons pourquoi Plasma a tant de difficultés à prendre en charge les contrats intelligents. Deux raisons principales :
Premièrement, dans le cas d’actifs liés à un contrat DeFi, qui devrait les retirer vers la couche 1 ? Car cela revient essentiellement à transférer l’état du contrat de la couche 2 vers la couche 1. Imaginons qu’un utilisateur ait déposé 100 ETH dans un pool de liquidité d’un DEX. Ensuite, l’ordonnanceur Plasma devient malveillant, et les utilisateurs doivent effectuer un retrait d’urgence. À ce moment-là, les 100 ETH sont encore sous le contrôle du contrat DEX. Qui devrait alors retirer ces fonds vers la couche 1 ?
La meilleure solution semble être de demander d’abord aux utilisateurs de retirer leurs actifs du DEX, puis de les transférer eux-mêmes vers la couche 1. Mais le problème est que l’ordonnanceur Plasma est déjà malveillant et pourrait refuser toute requête.
Alors, que se passerait-il si nous attribuions au contrat DEX un propriétaire (owner) autorisé à retirer les actifs du contrat vers la couche 1 en cas d’urgence ? Cela donnerait clairement au propriétaire du contrat un contrôle sur des actifs publics, qu’il pourrait retirer vers la couche 1 et disparaître — ce qui serait terrifiant !
Manifestement, la gestion de ces « biens publics » contrôlés par des contrats DeFi représente une véritable bombe à retardement. Cela touche à la difficile question de la répartition du pouvoir, comme l’a souligné Xiang Ma dans son interview intitulée « Les blockchains hautes performances peinent à innover : les contrats intelligents impliquent une distribution du pouvoir ».
Deuxièmement, interdire aux contrats de migrer leur état entraînerait des pertes massives ; autoriser les contrats à migrer leur état vers la couche 1 créerait un cas de double retrait que les preuves de fraude de Plasma ne peuvent pas résoudre :
Prenons l’hypothèse que Plasma adopte le modèle d’adresses de comptes d’Ethereum et supporte les contrats intelligents. Un mixer contient actuellement 100 ETH, et son propriétaire est contrôlé par Bob.
Supposons que Bob retire 50 ETH du mixer au bloc 100. Ensuite, Bob lance une demande de retrait, transférant ces 50 ETH vers la couche 1.
Puis, Bob utilise un instantané ancien de l’état du contrat (par exemple au bloc 70) pour transférer l’état passé du mixer vers la couche 1, ce qui permet de transférer aussi les 100 ETH que le mixer « possédait auparavant » vers la couche 1.
Clairement, c’est un cas classique de « double retrait », ou double dépense. Bob a retiré 150 ETH vers la couche 1, alors que les utilisateurs du réseau L2 n’ont versé au mixer / à Bob que 100 ETH. 50 ETH ont donc été créés ex nihilo. Cela peut facilement vider les réserves de Plasma. Théoriquement, on pourrait lancer une preuve de fraude pour montrer que l’état du contrat mixer a changé après le bloc 70.
Mais si, après le bloc 70, toutes les transactions ayant interagi avec le contrat mixer n’ont pas modifié son état, sauf celle où Bob a retiré 50 ETH, alors pour prouver que l’état du contrat a changé après le bloc 70, il faudrait rejouer toutes ces transactions sur Ethereum afin que le contrat Plasma confirme que l’état a effectivement changé (cette complexité découle de la structure même de Plasma). Si le nombre de ces transactions est très élevé, la preuve de fraude ne peut tout simplement pas être publiée sur la couche 1 (cela dépasserait la limite de gaz d’un bloc Ethereum).
Théoriquement, dans ce scénario de double dépense, il suffirait de soumettre l’instantané actuel de l’état du mixer (essentiellement la preuve de Merkle correspondant au StateRoot). Mais en pratique, comme Plasma ne publie pas les données de transaction sur chaîne, le contrat ne peut pas vérifier si l’instantané soumis est valide. Car l’ordonnanceur pourrait lui-même lancer une rétention de données et soumettre un instantané d’état invalide, accusant malicieusement tout demandeur de retrait.
Par exemple, lorsque vous déclarez posséder 50 ETH et demandez un retrait, l’ordonnanceur pourrait effacer votre solde à zéro, lancer une rétention de données, soumettre un StateRoot invalide sur chaîne et fournir un instantané d’état falsifié pour vous accuser de ne rien posséder. Dans ce cas, personne ne peut prouver que le StateRoot et l’instantané soumis par l’ordonnanceur sont invalides, car il a lancé une rétention de données, privant tout le monde des données nécessaires à la preuve de fraude.
Pour éviter cela, lorsqu’un nœud Plasma présente un instantané d’état pour prouver une double dépense, il doit rejouer l’historique des transactions de la période concernée, empêchant ainsi l’ordonnanceur d’utiliser la rétention de données pour bloquer les retraits. Dans un Rollup, en revanche, en cas de double retrait, il n’est théoriquement pas nécessaire de rejouer les transactions historiques, car le Rollup n’a pas de problème de rétention de données : il oblige l’ordonnanceur à publier les données DA sur chaîne. Si l’ordonnanceur d’un Rollup soumet un StateRoot ou un instantané d’état invalide, soit la vérification échoue (Rollup ZK), soit il sera rapidement contesté (Rollup OP).
Outre l’exemple du mixer, d’autres cas comme les contrats multisignatures peuvent également provoquer des doubles retraits dans Plasma. Et les preuves de fraude sont très inefficaces face à ces scénarios. ETH Research analyse ce phénomène.
En conclusion, comme Plasma n’est pas adapté aux contrats intelligents et ne supporte pratiquement pas le transfert d’état des contrats vers la couche 1, les versions mainstream de Plasma ont dû se limiter à des mécanismes UTXO ou similaires, car UTXO évite les conflits de propriété et prend bien en charge les preuves de fraude (nettement plus compactes), au prix d’une portée d’application restreinte, limitée essentiellement aux transferts ou aux bourses de type order book.
En outre, comme les preuves de fraude dépendent fortement des données DA, un niveau DA peu fiable rend difficile la mise en place d’un système efficace de preuves de fraude. Or, Plasma traite le problème DA de manière trop rudimentaire et ne parvient pas à contrer les attaques par rétention de données. Avec l’émergence des Rollups, Plasma a progressivement disparu de la scène.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
