Long article de Vitalik : Le jeu de sortie des EVM Validiums et le retour de Plasma

Plasma nous permet de contourner complètement le problème de la disponibilité des données, réduisant considérablement les frais de transaction.

Auteur : Vitalik Buterin

Traduction : jk, Odaily

 

Plasma est une catégorie de solutions de scalabilité pour la blockchain qui permet à toutes les données et calculs (à l’exception des dépôts, retraits et racines Merkle) de rester hors chaîne. Cela ouvre la porte à une scalabilité massive non limitée par la disponibilité des données on-chain. Plasma a été proposé pour la première fois en 2017 et a connu de nombreuses itérations en 2018, notamment Minimal Viable Plasma, Plasma Cash, Plasma Cashflow et Plasma Prime. Malheureusement, en raison de (i) coûts importants de stockage de données côté client et (ii) des limitations fondamentales de Plasma qui rendent difficile son extension au-delà des paiements, Plasma a largement été remplacé par les rollups.

 

L’émergence des preuves de validité (aussi appelées ZK-SNARKs) nous donne une raison de reconsidérer cette décision. Le plus grand défi pour faire fonctionner Plasma dans le domaine des paiements, à savoir le stockage de données côté client, peut être efficacement résolu grâce aux preuves de validité. De plus, les preuves de validité offrent une gamme d’outils qui nous permettent de créer des chaînes de type Plasma exécutant l’EVM. Les garanties de sécurité de Plasma ne couvrent pas tous les utilisateurs, car la raison fondamentale qui empêche d’étendre le mécanisme de sortie de style Plasma à de nombreuses applications complexes subsiste. Cependant, il est en pratique possible de protéger une très grande proportion des actifs.

 

Dans ce qui suit, je vais détailler comment Plasma y parvient.

 

Vue d’ensemble : Comment fonctionne Plasma

La version la plus simple de Plasma à comprendre est Plasma Cash. Plasma Cash fonctionne en traitant chaque jeton individuel comme un NFT distinct et en suivant un historique séparé pour chaque jeton. La chaîne Plasma a un opérateur, responsable de la création et de la publication régulière des blocs. Chaque transaction dans un bloc est stockée sous forme d’arbre Merkle clairsemé : si une transaction transfère la propriété du jeton k, elle apparaît à la position k de l’arbre. Lorsque l’opérateur de la chaîne Plasma crée un nouveau bloc, il publie la racine de l’arbre Merkle sur la chaîne et envoie directement à chaque utilisateur la branche Merkle correspondant aux jetons qu’il possède.

 

 

Supposons que ce sont les trois derniers arbres de transactions dans la chaîne Plasma Cash. Alors, en supposant que tous les arbres précédents sont valides, nous savons qu’Eve possède actuellement le jeton 1, David possède le jeton 4, et George possède le jeton 6.

 

Le principal risque dans tout système Plasma est le comportement malveillant de l’opérateur. Cela peut se produire de deux manières :

 

1. Publication d’un bloc invalide (par exemple, l’opérateur inclut une transaction transférant le jeton 1 de Fred à Hermione, alors que Fred ne possède pas ce jeton à ce moment-là) ;

 

2. Publication d’un bloc indisponible (par exemple, l’opérateur n’envoie pas l’une de ses branches Merkle à Bob, l’empêchant ainsi de prouver à d’autres que son jeton est toujours valide et non dépensé).

 

Si le comportement de l’opérateur concerne les actifs d’un utilisateur, il incombe à l’utilisateur de sortir immédiatement (plus précisément, dans les 7 jours). Lorsqu’un utilisateur (« sortant ») effectue une sortie, il fournit une branche Merkle prouvant l’inclusion de la transaction transférant le jeton du propriétaire précédent à lui-même. Cela déclenche une période de contestation de 7 jours, durant laquelle d’autres peuvent contester la sortie en fournissant l’une des trois preuves Merkle suivantes :

 

1. Propriétaire non à jour : une transaction ultérieure signée par le sortant, transférant son jeton à quelqu’un d’autre ;

 

2. Double dépense : une transaction transférant le jeton du propriétaire précédent à quelqu’un d’autre, incluse avant la transaction transférant le jeton au sortant ;

 

3. Historique invalide : une transaction transférant le jeton au cours des 7 derniers jours sans dépense correspondante. Le sortant peut répondre en fournissant la dépense correspondante ; s’il ne le fait pas, la sortie échoue.

 

 

Selon ces règles, toute personne possédant le jeton k doit voir toutes les branches Merkle à la position k dans tous les arbres historiques de la semaine passée, afin de s’assurer qu’elle possède effectivement le jeton k et peut le sortir. Elle doit stocker toutes les branches contenant des transferts d’actifs afin de pouvoir répondre aux contestations et sortir ses jetons en toute sécurité.

 

Extension aux jetons fongibles

Le design ci-dessus fonctionne pour les jetons non fongibles (NFT). Cependant, les jetons fongibles comme ETH et USDC sont plus courants que les NFT. Une façon d’appliquer Plasma Cash aux jetons fongibles est de traiter chaque petite dénomination de jeton (par exemple 0,01 ETH) comme un NFT distinct. Malheureusement, si nous procédons ainsi, les frais de gas pour sortir seraient trop élevés.

 

Une solution consiste à optimiser le traitement en regroupant de nombreux jetons adjacents en une seule unité, pouvant être transférée ou sortie en une seule fois. Il existe deux façons de le faire :

 

1. Utiliser Plasma Cash presque tel quel, mais calculer très rapidement l’arbre Merkle de nombreux objets si beaucoup d’objets adjacents sont identiques, grâce à des algorithmes complexes. Ce n’est étonnamment pas si difficile ; vous pouvez voir une implémentation Python ici.

 

2. Utiliser Plasma Cashflow, qui représente simplement de nombreux jetons adjacents comme un seul objet.

 

Cependant, ces deux méthodes rencontrent un problème de fragmentation : si vous recevez 0,001 ETH de centaines de personnes lors de l’achat de café, vous aurez 0,001 ETH à de nombreux endroits dans l’arbre, donc sortir effectivement ces ETH nécessitera toujours de nombreuses sorties individuelles, rendant les frais de gas trop élevés. Des protocoles de défragmentation ont été développés, mais leur mise en œuvre est assez complexe.

 

Une autre approche consiste à repenser le système en adoptant un modèle plus traditionnel d’« output de transaction non dépensé » (UTXO). Lorsque vous sortez un jeton, vous devez fournir l’historique de ce jeton pour la semaine écoulée, et quiconque peut contester votre sortie en prouvant que ces jetons ont déjà été sortis dans l’historique.

 

 

Le retrait de l’UTXO de 0,2 ETH en bas à droite peut être annulé en montrant le retrait de n’importe quel UTXO de son historique, comme indiqué en vert sur le schéma. À noter en particulier que les UTXO du milieu gauche et du bas gauche sont des ancêtres, mais pas celui du haut gauche. Cette méthode est similaire à l’idée de coloration basée sur l’ordre dans les protocoles de jetons colorés autour de 2013.

 

Il existe plusieurs techniques pour y parvenir. Dans tous les cas, l’objectif est de suivre une notion de « même jeton » à différents points de l’historique afin d’empêcher qu’un « même jeton » soit extrait deux fois.

 

Défis de l’extension à l’EVM

Malheureusement, étendre cela à l’EVM au-delà des paiements est beaucoup plus difficile. Un défi clé est que de nombreux objets d’état dans l’EVM n’ont pas de « propriétaire » explicite. La sécurité de Plasma dépend du fait que chaque objet ait un propriétaire, responsable de surveiller et d’assurer la disponibilité des données on-chain, et de sortir l’objet en cas de problème. Or, de nombreuses applications Ethereum ne fonctionnent pas ainsi. Par exemple, un pool de liquidité Uniswap n’a pas de propriétaire unique.

 

Un autre défi est que l’EVM ne tente pas de limiter les dépendances. Dans le bloc N, l’ETH détenu dans le compte A peut provenir de n’importe où dans le bloc N-1. Pour sortir un état cohérent, une chaîne Plasma EVM aurait besoin d’un mécanisme de sortie où, dans le pire des cas, une personne souhaitant sortir avec les informations du bloc N devrait payer le coût de publication de l’état complet du bloc N sur la chaîne : un coût pouvant atteindre plusieurs millions de dollars. Les schémas Plasma basés sur UTXO n’ont pas ce problème : chaque utilisateur peut sortir ses actifs du dernier bloc pour lequel il possède les données.

 

Un troisième défi est que la dépendance infinie dans l’EVM rend difficile la mise en place d’incitations cohérentes pour prouver la validité. La validité de tout état dépend de tout le reste, donc prouver quoi que ce soit nécessite de tout prouver. Dans ce cas, en raison du problème de disponibilité des données, il est généralement impossible de rendre la résolution des échecs compatible avec les incitations. Un problème particulièrement gênant est que nous perdons la garantie présente dans les systèmes basés sur UTXO, à savoir que l’état d’un objet ne peut pas être modifié sans l’accord de son propriétaire. Cette garantie est très utile car elle signifie que le propriétaire connaît toujours l’état prouvable le plus récent de ses actifs, ce qui simplifie le mécanisme de sortie. Sans elle, créer un mécanisme de sortie devient beaucoup plus difficile.

 

Comment les preuves de validité atténuent ces problèmes

La fonction la plus basique des preuves de validité est de prouver on-chain la validité de chaque bloc Plasma. Cela simplifie grandement l’espace de conception : cela signifie que nous n’avons à nous soucier que des attaques de bloc indisponible de l’opérateur, et non des blocs invalides. Par exemple, dans Plasma Cash, cela élimine la nécessité de se préoccuper des contestations historiques. Cela réduit la quantité d’état que l’utilisateur doit télécharger, passant d’une branche par bloc de la semaine passée à une branche par actif.

 

De plus, les extractions à partir de l’état le plus récent (dans le cas courant où l’opérateur est honnête, toutes les extractions se feront à partir de l’état le plus récent) ne sont pas sujettes à des contestations de propriétaire non à jour, donc dans une chaîne Plasma à preuve de validité, ce type d’extraction ne sera pas contesté du tout. Cela signifie qu’en situation normale, les retraits peuvent être effectués immédiatement.

 

Extension à l’EVM : graphe UTXO parallèle

Dans le cas de l’EVM, les preuves de validité nous permettent également de faire des choses intelligentes : elles peuvent être utilisées pour implémenter un graphe UTXO parallèle pour ETH et les jetons ERC 20, et prouver par SNARK l’équivalence entre le graphe UTXO et l’état EVM. Une fois cela en place, vous pouvez implémenter un système Plasma « classique » sur le graphe UTXO.

 

 

Cela nous permet de contourner de nombreuses complexités de l’EVM. Par exemple, dans un système basé sur les comptes, quelqu’un peut modifier votre compte sans votre consentement (en vous envoyant des jetons, augmentant ainsi son solde), ce qui n’a pas d’importance car la construction Plasma ne se fait pas sur l’état EVM lui-même, mais sur un état UTXO parallèle à l’EVM, où tout jeton reçu sera un objet indépendant.

 

Extension à l’EVM : sortie d’état complet

Des schémas plus simples ont déjà été proposés pour créer un « Plasma EVM », comme Plasma Free, ainsi que cet article de 2019. Dans ces schémas, n’importe qui peut envoyer un message sur L1 pour forcer l’opérateur à inclure une transaction ou à rendre disponible une branche d’état spécifique. Si l’opérateur échoue, la chaîne commence à revenir en arrière sur les blocs. Une fois qu’une copie complète de l’état, ou au moins toutes les données signalées comme potentiellement manquantes par les utilisateurs, a été publiée, la chaîne cesse de revenir en arrière. Pour effectuer un retrait, il peut être nécessaire de publier une récompense, qui paiera la part de gas de l’utilisateur pour la publication d’un si grand volume de données.

 

De tels schémas ont une faiblesse : ils n’autorisent pas les retraits instantanés en situation normale, car il est toujours possible qu’il faille revenir en arrière sur l’état le plus récent.

 

Limites des schémas Plasma EVM

De tels schémas sont puissants, mais ne peuvent pas offrir des garanties de sécurité complètes à tous les utilisateurs. Leur cas d’échec le plus évident concerne les objets d’état spécifiques qui n’ont pas de « propriétaire » économique explicite.

 

Considérons le cas d’un CDP (position de dette collatéralisée), un smart contract dans lequel un utilisateur verrouille des jetons, qui ne peuvent être libérés que lorsque l’utilisateur rembourse la dette. Supposons qu’un utilisateur verrouille 1 ETH dans un CDP (environ 2000 dollars au moment de la rédaction), avec une dette de 1000 DAI. Maintenant, la chaîne Plasma cesse de publier des blocs, et l’utilisateur refuse de sortir. L’utilisateur a alors une option gratuite : si le prix de l’ETH tombe sous 1000 dollars, il abandonne le CDP ; si le prix de l’ETH reste au-dessus de 1000 dollars, il finit par le réclamer. En moyenne, un utilisateur malveillant gagnera ainsi de l’argent.

 

Un autre exemple est celui des systèmes de confidentialité, tels que Tornado Cash ou Privacy Pools. Considérons un système de confidentialité avec cinq déposants :

 

 

Les ZK-SNARKs dans les systèmes de confidentialité cachent la correspondance entre le propriétaire du jeton entrant et celui du jeton sortant.

 

Supposons que seul l’orange ait déjà retiré, et que l’opérateur Plasma cesse alors de publier des données. Supposons que nous utilisions une méthode de graphe UTXO avec règle FIFO, chaque jeton étant apparié à celui en dessous. Alors, l’orange peut retirer ses jetons prémix et postmix, le système les considérant comme deux jetons distincts. Si le bleu tente de retirer son jeton prémix, l’état mis à jour de l’orange le remplacera ; en même temps, le bleu n’aura pas l’information pour retirer son jeton postmix.

 

Si vous permettez aux quatre autres déposants de retirer le smart contract de confidentialité lui-même (ce qui remplacera les dépôts), puis de retirer les jetons sur L1, ce problème peut être résolu. Cependant, la mise en œuvre effective d’un tel mécanisme nécessite un effort supplémentaire de la part des développeurs du système de confidentialité.

 

Il existe d’autres méthodes pour résoudre les problèmes de confidentialité, comme la méthode Intmax, qui consiste à placer quelques octets on-chain à la manière d’un rollup, et à faire circuler l’information entre les utilisateurs via un opérateur de type Plasma.

 

Les positions LP Uniswap présentent des problèmes similaires : si vous avez échangé de l’ETH contre de l’USDC dans une position Uniswap, vous pouvez essayer de retirer votre USDC d’avant l’échange et votre ETH d’après l’échange. Si vous collaborez avec l’opérateur de la chaîne Plasma, les fournisseurs de liquidité et les autres utilisateurs n’auront pas accès à l’état post-transaction, et ne pourront donc pas retirer leur USDC post-transaction. Une logique spéciale est nécessaire pour empêcher cela.

 

Conclusion

Même en 2023, Plasma reste un design sous-estimé. Les rollups restent la référence et offrent des propriétés de sécurité inégalées. C’est particulièrement vrai du point de vue de l’expérience développeur : rien n’égale la simplicité pour les développeurs d’applications de ne même pas avoir à se soucier du graphe de propriété et des flux d’incitations dans leur application.

 

Cependant, Plasma nous permet de contourner complètement le problème de la disponibilité des données, réduisant considérablement les frais de transaction. Pour les chaînes qui seraient autrement des validiums, Plasma peut représenter une amélioration majeure de la sécurité. Les ZK-EVMs ont enfin été réalisés cette année, ce qui nous offre une excellente occasion de réexplorer cet espace de conception et de proposer des constructions plus efficaces, afin de simplifier l’expérience développeur et de protéger les fonds des utilisateurs.

Remerciements particuliers à Karl Floersch, Georgios Konstantopoulos et Martin Koppelmann pour leurs contributions en matière de retours, de relecture et de discussions.