Un aperçu de Redstone : ce n'est pas Plasma, mais une variante d'Optimium
TechFlow SélectionTechFlow Sélection
Un aperçu de Redstone : ce n'est pas Plasma, mais une variante d'Optimium
Cet article présente le principe de Plasma, explique pourquoi il n'est pas adapté aux contrats intelligents et à la DeFi, et précise en quoi consiste Redstone.
Dédié à des analyses Web3 approfondiesAuteur : Faust, Geeker Web3
Récemment, un projet nommé Redstone est devenu un sujet brûlant. Cette infrastructure Layer2 spécialisée dans les jeux blockchain, lancée par l'équipe Lattice, a été officiellement publiée le 15 novembre et son réseau de test est désormais en ligne. Ce qui est intéressant, c'est que l'équipe Lattice affirme que « Redstone est une chaîne Alt-DA inspirée de Plasma ».
La veille du lancement de Redstone, Vitalik venait de publier un article intitulé « Exit games for EVM validiums: the return of Plasma », dans lequel il faisait un bref retour sur la solution technique « Plasma », jusque-là disparue de l'écosystème Ethereum, et suggérait d'introduire des preuves de validité (confondues avec les preuves ZK) pour résoudre les problèmes de Plasma.
Face à cela, plusieurs personnes pensent que Vitalik aurait publié cet article pour soutenir Redstone. Certains au sein de la communauté Geeker Web3 vont même jusqu'à spéculer qu'il pourrait avoir investi dans Redstone. Ajouté à la controverse antérieure sur la « définition du Layer2 Ethereum », beaucoup croient maintenant que nous allons assister à un « renouveau de Plasma », ce qui pourrait freiner des solutions DA extérieures à l'écosystème Ethereum comme Celestia, car Plasma n'impose pas de contraintes strictes sur la disponibilité des données (DA).
Cependant, selon les recherches menées par l'auteur de cet article, Redstone ne correspond pas au cadre général de Plasma, et son affirmation « inspiré par Plasma » semble davantage destinée à profiter de la popularité récente de l'article de Vitalik, plutôt que d'indiquer un véritable appui de sa part. En outre, le mécanisme de défi DA de Redstone ressemble fortement à celui introduit en avril 2022 par le projet Layer2 Metis, bien que les deux projets diffèrent par l'ordre des étapes de mise à jour du Stateroot et de publication des données DA.
En réalité, il semble y avoir eu une surinterprétation généralisée de Redstone. Dans les lignes suivantes, nous allons expliquer aux lecteurs, à travers un raisonnement simple, le fonctionnement de Plasma, pourquoi il est inadapté aux contrats intelligents et à la DeFi, ainsi que ce qu'est réellement Redstone.
Plasma : en cas d'attaque par rétention de données, retrait d'urgence obligatoire
L'histoire de Plasma remonte à 2017, durant la frénésie des ICO sur Ethereum, où la demande explosive des utilisateurs avait rapidement saturé le réseau à faible débit transactionnel. À ce moment critique, la première version théorique de Plasma fut publiée, proposant une solution de scaling en couche 2 capable de traiter « presque tous les scénarios financiers du monde ».
En résumé, Plasma est une solution de scaling qui ne publie sur la couche 1 (Layer1) que l'en-tête du bloc ou le Merkle Root, tandis que le reste des données (données DA) est publié hors chaîne. Si l'ordonnanceur (operator) de Plasma publie sur Layer1 un Merkle Root lié à une transaction invalide (signature numérique erronée, etc.), les utilisateurs concernés peuvent soumettre une preuve de fraude pour démontrer que le Root soumis est associé à une transaction invalide.
Le problème est que pour soumettre une preuve de fraude, il faut garantir que les données DA ne sont pas retenues. Or, Plasma n’impose aucune exigence stricte sur la couche DA, donc il ne peut pas garantir que les utilisateurs ou les nœuds L2 puissent recevoir ces données. Si l'ordonnanceur lance à un moment donné une attaque par rétention de données (aussi appelée problème de disponibilité des données), en ne publiant que les nouveaux en-têtes de bloc ou Merkle Root sans publier les corps de bloc correspondants, rendant impossible la vérification de la validité du Root, alors les utilisateurs doivent considérer l'ordonnanceur comme irrécupérable et recourir à un mécanisme d'urgence appelé « Exit Game » pour retirer leurs actifs de Layer2 vers Layer1.
Cette opération exige que l'utilisateur soumette une preuve Merkle prouvant qu’il possède effectivement un certain montant d'actifs sur L2. On peut appeler cela une « preuve d'actif ». Ce qui est intéressant, c’est que le mécanisme Exit Game de Plasma diffère du mode d’évacuation (escape hatch) des Rollups ZK. Un utilisateur ZK Rollup doit soumettre une preuve Merkle liée au dernier Stateroot valide, tandis qu’un utilisateur Plasma peut soumettre une preuve liée à un ancien Merkle Root, datant de longtemps.
Pourquoi une telle conception ? Simplement parce que le Stateroot soumis par un ZK Rollup est immédiatement vérifié par le contrat sur Layer1 (pour valider la preuve de validité). Si ce Stateroot récemment soumis est valide et légal, l’utilisateur doit alors fournir une preuve Merkle correspondant à ce Stateroot légitime afin de prouver la possession d’actifs.
Mais le Merkle Root soumis par l'ordonnanceur de Plasma ne peut pas être jugé valide directement par le contrat Layer1. Seuls les nœuds L2 peuvent lancer activement un défi pour rejeter un Root invalide. C’est pourquoi un mécanisme de défi existe, ce qui rend le fonctionnement de Plasma fondamentalement différent de celui des ZK Rollups.
Supposons que l'ordonnanceur vienne de publier un Merkle Root invalide numéro 101, tout en lançant une attaque par rétention de données empêchant les nœuds L2 de prouver que ce Root 101 est invalide. Dans ce cas, l'utilisateur peut soumettre une preuve Merkle correspondant au Root 100 ou à un Root antérieur, et retirer ses actifs.
Bien sûr, un problème subsiste : un utilisateur pourrait soumettre une preuve d’actif liée au Root 30 ou à un Root encore plus ancien, demandant à retirer ses actifs vers Layer1, alors que son solde a pu évoluer après la publication du Root 30. Autrement dit, il présente une preuve d’actif obsolète, ce qui constitue une attaque classique de double dépense.
Pour répondre à cela, Plasma permet à toute personne de soumettre une preuve de fraude contre un tel retrait, en signalant qu’un utilisateur a présenté une « preuve d’actif » périmée. En introduisant cette possibilité pour quiconque de contester les demandes de retrait, Plasma évite d’avoir à gérer les retraits d’urgence comme le font les ZK Rollups.
Mais un autre risque demeure : l'ordonnanceur pourrait transférer les actifs des autres vers son propre compte L2, puis lancer une attaque par rétention de données pour empêcher autrui de contester cette malversation. Ensuite, il initierait un retrait d’urgence depuis son propre compte en soumettant une « preuve d’actif » affirmant posséder légitimement ces actifs sur L2.
Clairement, dans ce cas, faute d’un historique complet, on ne peut pas facilement prouver que la source des actifs de l’ordonnanceur est illégitime. Que faire alors ? Les premières versions de Plasma, comme Plasma MVP, ont anticipé ce scénario et introduit la notion de « priorité de retrait ». Si une personne soumet une preuve d’actif liée à un Root plus ancien, sa demande de retrait sera traitée en priorité.
Si l’ordonnanceur tente cette malversation au moment du Root 101 et lance un retrait, les utilisateurs peuvent alors présenter une preuve d’actif liée au Root 99 ou antérieur pour effectuer un retrait d’urgence. Tant que l’ordonnanceur ne peut pas falsifier les enregistrements déjà publiés sur Layer1, les utilisateurs ont un moyen de s’échapper.
Mais Plasma comporte toujours un bug fatal : chaque fois que l’ordonnanceur retient les données, les utilisateurs doivent compter sur le retrait d’urgence (Exit Game) pour sécuriser leurs actifs. Si un grand nombre d’utilisateurs tentent de retirer simultanément leurs fonds, Layer1 risque de ne pas pouvoir gérer la charge.
Encore plus grave : qui devrait retirer les actifs détenus par des contrats DeFi ? Imaginons qu’un utilisateur ait déposé 100 ETH dans un pool de liquidité DEX. Puis, l’ordonnanceur de Plasma tombe en panne ou se comporte malicieusement, déclenchant un besoin de retrait d’urgence. À ce stade, les 100 ETH de l’utilisateur restent sous le contrôle du contrat DEX. Qui devrait alors les retirer vers Layer1 ?
La meilleure solution serait que l’utilisateur retire d’abord ses actifs du pool DEX, puis les transfère lui-même vers L1. Mais le problème est que l’ordonnanceur de Plasma est déjà en panne ou corrompu, donc l’utilisateur ne peut pas exécuter l’opération de retrait. Et si nous autorisons le propriétaire du contrat DEX à retirer les actifs contrôlés par le contrat, cela reviendrait à lui donner la propriété de ces actifs — il pourrait les retirer à tout moment et disparaître. N’est-ce pas terrifiant ?
Au final, la question de savoir comment gérer ces « biens publics » contrôlés par des contrats DeFi reste une bombe à retardement. Une solution possible serait de reconstruire sur Layer1 un contrat miroir reflétant le contrat DeFi de Layer2 via consensus social, mais cela introduirait d’énormes complications, augmenterait les coûts d’opportunité, et poserait la question cruciale de qui décidera du traitement du contrat miroir. Il s’agit en fait d’un problème de répartition du pouvoir, comme discuté précédemment par Xiangma dans son entretien « Les blockchains publiques hautes performances peinent à innover, les contrats intelligents impliquent une redistribution du pouvoir ».
Bien sûr, Vitalik a également souligné ce point dans son article récent « Exit games for EVM validiums: the return of Plasma », et insiste sur le fait que c’est l’une des raisons pour lesquelles Plasma est inadapté aux contrats intelligents. Les variantes connues de Plasma comme Plasma MVP ou Plasma Cash ont adopté un modèle UTXO ou similaire à la place du modèle de comptes Ethereum, et n’autorisent pas les contrats intelligents, évitant ainsi le problème de « répartition de la propriété des actifs ». Bien que la propriété de chaque UTXO appartienne clairement à l’utilisateur, ce modèle présente lui aussi de nombreux inconvénients et n’est pas adapté aux contrats intelligents. Ainsi, Plasma convient mieux aux paiements simples ou aux bourses de type carnet d’ordres.
Par la suite, avec la montée en popularité des ZK Rollups, Plasma a progressivement disparu de la scène, car les Rollups ne souffrent pas du problème de rétention de données. Si l’ordonnanceur d’un ZK Rollup tente une attaque par rétention de données — en ne publiant que le Stateroot sur Ethereum sans les données DA — ce Stateroot sera jugé invalide et automatiquement rejeté par le contrat de vérification (Verifier) sur Layer1. Ainsi, les données DA correspondant à un Stateroot valide d’un ZK Rollup sont nécessairement consultables sur Ethereum. Cela élimine complètement le scénario « publication d’en-têtes ou de Merkle Root sans publication des corps de blocs », résolvant ainsi le problème de disponibilité des données / attaque par rétention.
De plus, les anciennes données DA des Rollups sont accessibles sur Ethereum, permettant à quiconque de démarrer un nœud Layer2 à partir de l’historique de la chaîne ETH. Cela réduit considérablement la difficulté de mise en œuvre d’un système d’ordonnancement décentralisé voire sans permission. En comparaison, Plasma n’ayant aucune exigence stricte sur la DA, la mise en œuvre d’un ordonnanceur décentralisé est bien plus complexe (pour obtenir un ordonnanceur décentralisé remplaçable, il faut d’abord que tous les nœuds L2 reconnaissent le même bloc, ce qui impose des exigences spécifiques sur la mise en œuvre de la DA).
En outre, si l’ordonnanceur d’un ZK Rollup tente d’inclure une transaction invalide dans un bloc L2, cela échouera inévitablement, grâce aux garanties offertes par les preuves de validité.
En définitive, l’espace de malversation de l’ordonnanceur d’un ZK Rollup est bien plus restreint que celui de Plasma — au pire, il peut bloquer la mise à jour du Stateroot (équivalent à une panne du système du point de vue UX), ou refuser certaines transactions, autrement dit exercer une censure. En cas de panne de l’ordonnanceur, d’autres nœuds peuvent plus facilement le remplacer dans un système Rollup. Dans un Rollup idéal, la probabilité de déclenchement du mécanisme d’Exit Game (appelé escape hatch dans les ZK Rollups) peut être réduite à zéro.
(La colonne « Proposer Failure » sur L2BEAT montre comment chaque solution L2 gère la panne de l’ordonnanceur. « Self Propose » signifie généralement que d’autres nœuds peuvent remplacer l’ordonnanceur en panne.)
Aujourd’hui, presque aucune équipe dans l’écosystème Ethereum ne poursuit encore la voie de Plasma, et la plupart des projets Plasma sont mort-nés.
(Vitalik explique pourquoi les ZK Rollups sont supérieurs à Plasma, notamment en matière d’ordonnancement sans permission et de problème DA)
Qu'est-ce que Redstone ? Ce n'est pas Plasma, mais une variante d'Optimium
Dans la section précédente, nous avons brièvement exposé Plasma et les raisons pour lesquelles il a été remplacé par les Rollups. Quant à Redstone, vous avez probablement déjà remarqué ses différences avec Plasma : Redstone peut résoudre le problème d’attaque par rétention de données. Par exemple, il ne publie pas immédiatement un nouveau Stateroot, mais commence par publier les données DA brutes hors chaîne, puis envoie le hachage de ces données (datahash) comme preuve (commitment) sur la chaîne Ethereum, affirmant avoir publié hors chaîne les données complètes correspondant à ce datahash.
(Explication officielle de Redstone sur sa solution anti-rétention de données)
N’importe qui peut lancer un défi, affirmant que l’ordonnanceur de Redstone n’a pas publié hors chaîne les données brutes correspondant à ce datahash. À ce moment-là, l’ordonnanceur doit publier les données correspondant au datahash directement sur la chaîne pour répondre à l’accusation. S’il ne publie pas les données à temps sur Ethereum après avoir été mis en cause, alors son datahash / commitment précédent est considéré comme invalide.
Si l’ordonnanceur répond rapidement à la demande du challenger, ce dernier peut alors récupérer les données DA brutes correspondant au datahash. Finalement, pratiquement tous les nœuds L2 peuvent obtenir les données DA nécessaires, résolvant ainsi le problème de rétention de données. Bien sûr, le challenger doit d’abord payer des frais, environ équivalents au coût de publication des données brutes par l’ordonnanceur sur Ethereum — cette mesure vise à empêcher des challengers malveillants de lancer des défis gratuits, causant des pertes à l’ordonnanceur.
Enfin, après la période de défi sur le datahash, l’ordonnanceur publie le Stateroot correspondant, c’est-à-dire le root obtenu après exécution de la séquence de transactions contenue dans les données DA liées au datahash. À ce stade, les nœuds L2 peuvent utiliser le système de preuve de fraude pour contester les roots invalides. Si, après un défi, l’ordonnanceur n’a pas publié à temps les données brutes correspondant à un datahash, alors même s’il publie ultérieurement le Stateroot associé à ce datahash, celui-ci sera considéré comme invalide.
Puisque Redstone publie d’abord les données DA, puis seulement ensuite le Stateroot valide correspondant, il résout directement le problème d’attaque par rétention de données (cas où l’ordonnanceur publie uniquement le root sans les données DA).
Clairement, ce modèle diffère des Optimium standards (Rollups OP qui n’utilisent pas Ethereum pour la DA, comme Arbitrum Nova), dont la disponibilité des données repose généralement sur un comité DAC hors chaîne. Le DAC soumet périodiquement une transaction multisignature à la chaîne, et le contrat Rollup sur Layer1 suppose alors que l’ordonnanceur a publié hors chaîne le dernier lot de données DA.
(Source : L2beat)
Des projets comme Metis et Arbitrum Nova publient simultanément le Stateroot et le datahash. Si quelqu’un pense que les données DA sont retenues, il peut lancer un défi, et l’ordonnanceur publiera alors les données DA sur chaîne.
Ainsi, la différence clé entre Redstone et Metis réside ici : Redstone publie d’abord le datahash, attend la fin de la période de défi, puis publie le Stateroot ; Metis, en revanche, publie simultanément Stateroot et datahash, et ne publie les données DA sur chaîne qu’en cas de défi. Il est clair que l’approche de Redstone est plus sûre, car dans le cas de Metis, si l’ordonnanceur ignore constamment les demandes de données DA, le problème de rétention ne peut pas être résolu rapidement — on doit alors compter sur le retrait d’urgence, le consensus social, ou le remplacement de l’ordonnanceur par d’autres nœuds.
Mais dans Redstone, si l’ordonnanceur retient les données, le Stateroot qu’il publie est directement considéré comme invalide. Ainsi, Stateroot et données DA sont liés. Cela permet à Redstone d’offrir une garantie DA proche de celle des Rollups, en faisant de lui une variante d’Optimium fondamentalement supérieure à Arbitrum Nova et Metis.
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
