Licencier Validium ? Comprendre à nouveau la couche 2 du point de vue du proposant de Danksharding
TechFlow SélectionTechFlow Sélection
Licencier Validium ? Comprendre à nouveau la couche 2 du point de vue du proposant de Danksharding
Cet article entend explorer en profondeur la raison pour laquelle un Validium n'est pas, à proprement parler, une « couche 2 », en analysant plus finement les détails de la couche 2 selon la perspective de Dankrad.
Dédié à des analyses Web3 approfondiesAuteur : Faust, Geek web3
Introduction
Récemment, Dankrad Feist, chercheur à la Fondation Ethereum et initiateur de Danksharding, a publié sur Twitter des déclarations controversées. Il affirme clairement que les blockchains modulaires qui n’utilisent pas ETH comme couche de disponibilité des données (Data Availability Layer, DA) ne sont ni des Rollups, ni des couches 2 d’Ethereum (Layer 2). Selon Dankrad, Arbitrum Nova, Immutable X et Mantle devraient être rayés de la liste des « Layer 2 », car ils publient leurs données transactionnelles en dehors d’Ethereum (via un réseau DAC hors chaîne dédié à la disponibilité des données).
Par ailleurs, Dankrad précise que des solutions telles que Plasmas et les canaux d’état, qui n’exigent pas de disponibilité des données sur chaîne pour assurer la sécurité, restent qualifiées de Layer 2, mais que Validium (ZKRollup n’utilisant pas ETH comme couche DA) ne constitue pas un véritable Layer 2.
Ces propos ont suscité l’interrogation de nombreux fondateurs ou chercheurs spécialisés dans les Rollups. De nombreux projets qualifiés de « Layer 2 » évitent en effet d’utiliser Ethereum comme couche DA afin de réduire les coûts ; exclure ces projets remettrait en cause un grand nombre de solutions de mise à l’échelle. En outre, si Validium n’est pas considéré comme un Layer 2, alors Plasma ne devrait pas non plus y prétendre.
À cela, Dankrad répond que lorsque la disponibilité des données (DA) est compromise — par exemple si le réseau hors chaîne DA retient les données sans les rendre publiques — les utilisateurs de Plasma peuvent toujours retirer leurs actifs en toute sécurité vers la couche 1 (L1). En revanche, dans le même scénario, les utilisateurs de Validium (dont la majorité des projets reposent sur StarkEx) ne peuvent pas retirer leurs fonds vers L1, et voient leur argent gelé sur L2.
Il est clair que Dankrad entend définir un projet de mise à l’échelle comme Layer 2 selon son niveau de sécurité. D’un point de vue sécuritaire, il est exact que dans un cas extrême combinant une panne du séquenceur et une attaque de retenue de données par la couche DA (occultation des nouvelles données), Validium peut effectivement bloquer les actifs des utilisateurs sur L2, empêchant tout retrait vers L1. Bien que Plasma soit généralement moins sûr que Validium, sa conception différente lui permet, dans les mêmes conditions critiques, de garantir aux utilisateurs le retrait sécurisé de leurs actifs vers L1. La position de Dankrad n’est donc pas infondée.
Cet article adopte le point de vue de Dankrad afin d’analyser en détail ce qu’est un Layer 2, et de mieux comprendre pourquoi Validium ne constitue pas un « Layer 2 » au sens strict.
Comment définir précisément un Layer 2 ?
Selon la définition donnée sur ethereum.org et partagée par la plupart des membres de la communauté Ethereum, un Layer 2 est une « blockchain indépendante qui étend l’évolutivité d’Ethereum tout en héritant de sa sécurité ». D’abord, « étendre l’évolutivité d’Ethereum » signifie décharger le trafic que la blockchain principale ne peut supporter, allégeant ainsi la pression en termes de TPS. Quant à « hériter de la sécurité d’Ethereum », cela peut se traduire par « s’appuyer sur Ethereum pour assurer sa propre sécurité ».
Par exemple, toutes les transactions (Tx) sur un Layer 2 doivent être définitivement confirmées (finalisées) sur Ethereum, et aucune transaction erronée ne sera validée. Pour annuler un bloc sur L2, il faut d’abord annuler le bloc correspondant sur Ethereum ; tant qu’Ethereum n’est pas victime d’une attaque à 51 % entraînant un réexécution de blocs, aucun bloc L2 ne sera révoqué.
Si nous approfondissons davantage la notion de sécurité d’un Layer 2, il convient d’examiner aussi des situations extrêmes. Par exemple, si l’équipe du projet L2 disparaît, si le séquenceur tombe en panne ou si la couche DA hors chaîne cesse de fonctionner, dans ces cas-là, les utilisateurs peuvent-ils retirer en toute sécurité leurs fonds depuis L2 vers L1 ?
Le mécanisme de « retrait forcé » sur les Layer 2
Sans tenir compte des risques liés à la mise à jour des contrats L2 ou aux signatures multiples, des projets comme Arbitrum ou StarkEx prévoient tous deux un mécanisme de retrait forcé pour les utilisateurs. Si le séquenceur L2 lance une attaque par censure en refusant délibérément certaines transactions ou demandes de retrait, ou s’il tombe définitivement en panne, un utilisateur d’Arbitrum peut invoquer la fonction forceInclusion du contrat Sequencer Inbox sur L1, soumettant directement ses données de transaction à Ethereum. Si, dans les 24 heures, le séquenceur n’a pas traité cette transaction marquée comme « devant être incluse », celle-ci est automatiquement intégrée à la séquence des transactions du Rollup. Ce dispositif offre ainsi aux utilisateurs L2 une « sortie de secours » leur permettant de forcer un retrait.
En comparaison, la solution StarkEx dotée d’un sas d’évacuation (Escape Hatch) va encore plus loin. Si une demande de retrait forcé soumise par un utilisateur L1 n’est pas prise en compte par le séquenceur au terme d’une période de 7 jours, cet utilisateur peut activer la fonction freezeRequest, plaçant alors L2 en mode gel. À ce moment-là, le séquenceur L2 ne peut plus mettre à jour l’état de L2 sur L1, et l’état gelé ne pourra être débloqué qu’après une année complète.
Une fois l’état L2 gelé, l’utilisateur peut construire une preuve de Merkle liée à l’état actuel, attestant qu’il possède un montant donné sur L2, puis utiliser le contrat Escape Hatch sur L1 pour retirer ses fonds. C’est ce que propose StarkEx sous le nom de service de « retrait total ». Même si le projet L2 disparaît ou si le séquenceur tombe en panne définitive, les utilisateurs conservent un moyen de récupérer leurs fonds.
Toutefois, un problème subsiste : les projets L2 basés sur StarkEx sont majoritairement des Validium (comme Immutable X ou ApeX), qui ne publient pas leurs données DA sur Ethereum. Toutes les informations nécessaires à la construction de l’arbre d’état L2 restent hors chaîne. Si l’utilisateur ne peut pas obtenir hors chaîne les données nécessaires à la construction de la preuve de Merkle (par exemple en cas d’attaque par retenue de données de la couche DA), il sera incapable d’activer le retrait via le sas d’évacuation.
Ainsi, la raison invoquée par Dankrad au début de l’article devient limpide : puisque Validium ne publie pas les données DA sur chaîne comme un Rollup classique, l’utilisateur pourrait ne pas pouvoir générer la preuve de Merkle requise pour un « retrait forcé ».
Différence entre Validium et Plasma lors d’une attaque par retenue de données
En réalité, le séquenceur de Validium ne publie sur L1 que la dernière racine d’état (Stateroot) de L2, accompagnée d’une preuve de validité (Validity Proof, ou ZK Proof), attestant que toutes les transitions d’état impliquées dans la génération de ce nouveau Stateroot (changements de solde des utilisateurs) sont correctes.
Or, la seule connaissance du Stateroot ne permet pas de reconstruire l’arbre d’état courant (world state trie), ni donc de connaître l’état précis de chaque compte L2 (y compris les soldes). Les utilisateurs L2 ne peuvent donc pas construire une preuve de Merkle correspondant au Stateroot légitime actuel. Voilà précisément le point faible de Validium.
(Une preuve de Merkle correspond aux données utilisées dans la génération de la racine, parties foncées sur l’image. Pour construire une preuve de Merkle valide, il faut connaître la structure de l’arbre d’état, donc disposer des données DA.)
Il convient ici de préciser le rôle du DAC. Les données DA de Validium — notamment le lot de transactions récemment traité par le séquenceur — sont synchronisées avec un réseau dédié appelé Comité de disponibilité des données (DAC), constitué de plusieurs serveurs. Ce comité est généralement géré par l’équipe du projet L2, des membres de la communauté ou d’autres entités (bien que, en pratique, la composition exacte du DAC soit souvent opaque).
Ce qui est intéressant, c’est que les membres du DAC doivent fréquemment signer une validation sur L1, attestant que le nouveau Stateroot et la preuve de validité soumis par le séquenceur L2 correspondent bien aux données DA reçues par le DAC. Seule cette signature collective rend légitimes le nouveau Stateroot et la preuve de validité.
Actuellement, le DAC d’Immutable X utilise une signature multisignature 5/7, tandis que dYdX, bien qu’étant un ZKRollup, dispose également d’un DAC utilisant une signature 1/2. (dYdX publie uniquement sur L1 les différences d’état — State diff — et non les données complètes des transactions. Toutefois, en disposant des State diff historiques, on peut reconstituer les soldes de tous les comptes L2, permettant ainsi de construire une preuve de Merkle pour un retrait total.)
La position de Dankrad est justifiée. Si les membres du DAC de Validium s’entendent pour lancer une attaque par retenue de données, en empêchant les autres nœuds L2 d’accéder aux dernières données et en mettant à jour le Stateroot légitime de L2, les utilisateurs ne pourront pas construire la preuve de Merkle associée au Stateroot actuel pour retirer leurs fonds (car les données DA postérieures à cet instant ne seront plus accessibles ; seules les anciennes données le seront).
Mais Dankrad envisage uniquement des cas théoriques extrêmes. Dans la réalité, la plupart des séquenceurs Validium diffusent en temps réel les nouvelles données transactionnelles à d’autres nœuds L2, dont certains sont honnêtes. Dès qu’un seul nœud honnête accède aux données DA, l’utilisateur peut quitter L2 en toute sécurité.
Mais pourquoi ce problème théorique existe-t-il chez Validium et pas chez Plasma ? Parce que Plasma détermine la légitimité du Stateroot différemment de Validium, grâce à une fenêtre de preuve de fraude. Plasma était une solution de mise à l’échelle antérieure aux OPRollups, et comme ceux-ci, il repose sur des preuves de fraude pour assurer la sécurité de L2.
Comme OPR, Plasma intègre une période de contestation : le nouveau Stateroot publié par le séquenceur n’est pas immédiatement validé ; il faut attendre la fin de la fenêtre sans qu’aucun nœud L2 n’ait soumis de preuve de fraude. Ainsi, le Stateroot légitime actuel de Plasma (comme d’OPR) date de plusieurs jours (comme la lumière des étoiles que nous voyons aujourd’hui, émise il y a longtemps), et les utilisateurs peuvent généralement accéder aux données DA passées.
De plus, le mécanisme de preuve de fraude ne fonctionne que si les données DA sont disponibles à l’instant présent, c’est-à-dire si les nœuds vérificateurs (Verifier) de Plasma peuvent accéder aux données DA actuelles, afin de produire une preuve de fraude si nécessaire.
La question devient simple : le bon fonctionnement de Plasma suppose que les données DA soient disponibles à tout moment. Si, à partir d’un certain moment, les données DA deviennent indisponibles, les utilisateurs peuvent-ils encore retirer leurs fonds en sécurité ?
Analysons cela : supposons que la fenêtre de contestation de Plasma soit de 7 jours. À partir d’un instant T0, les nouvelles données DA deviennent indisponibles (le DAC lance une attaque par retenue, empêchant les nœuds honnêtes d’accéder aux données post-T0). Or, le Stateroot légitime à T0 et durant une période suivante a été soumis avant T0, et les données historiques antérieures à T0 sont traçables. Les utilisateurs peuvent donc construire une preuve de Merkle pour forcer leur retrait.
Même si beaucoup d’utilisateurs ne détectent pas immédiatement l’anomalie, la présence de la fenêtre de contestation (7 jours pour OP) garantit que tant que le Stateroot soumis à T0 n’est pas encore validé, et que les données DA antérieures à T0 restent accessibles, les utilisateurs peuvent retirer leurs fonds en toute sécurité vers L1.
Conclusion
Nous pouvons désormais clarifier la différence de sécurité entre Validium et Plasma :
Dans Validium, une fois que le séquenceur publie un Stateroot accompagné d’une preuve de validité et d’une validation du DAC, celui-ci devient immédiatement légitime. Si les utilisateurs et les nœuds L2 honnêtes subissent une attaque par retenue de données et ne peuvent pas construire la preuve de Merkle correspondant au Stateroot actuel, ils ne peuvent pas retirer leurs fonds vers L1.
Dans Plasma, après la soumission d’un nouveau Stateroot, il faut attendre la fin de la fenêtre de contestation pour qu’il devienne légitime. Le Stateroot actuel est donc celui soumis quelques jours auparavant. Grâce à cette fenêtre (3 jours pour ARB, 7 jours pour OP), même si les données DA du nouveau Stateroot deviennent indisponibles, les utilisateurs disposent encore des données DA du Stateroot légitime (soumis précédemment) et ont donc assez de temps pour forcer un retrait vers L1.
Ainsi, les propos de Dankrad sont fondés : en cas d’attaque par retenue de données, Validium peut piéger les actifs des utilisateurs sur L2, contrairement à Plasma.
(Sur l’image ci-dessous, Dankrad fait une erreur : Plasma ne devrait pas autoriser le retrait via une preuve de Merkle obsolète, car cela entraînerait un risque de double dépense.)
Les attaques par retenue de données sur les couches DA hors chaîne posent bien des risques, que Celestia tente précisément de résoudre. Toutefois, la plupart des projets Layer 2 offrent des ports permettant aux nœuds L2 de rester synchronisés hors chaîne avec le séquenceur. Ainsi, les inquiétudes de Dankrad relèvent souvent davantage de la théorie que de la réalité.
Si l’on pousse à l’extrême, imaginons que tous les nœuds hors chaîne de Plasma tombent simultanément en panne : dans ce cas, les utilisateurs ordinaires n’ayant pas exécuté de nœud L2 ne pourraient pas forcer de retrait vers L1. Mais la probabilité d’un tel événement équivaut à celle où tous les nœuds d’une blockchain publique s’effondreraient définitivement — un scénario quasi impossible.
En somme, bien des discussions portent sur des situations qui ne se produiront probablement jamais. Comme le dit si bien le vice-directeur du KGB dans la série américaine *Tchernobyl* : « Pourquoi s’inquiéter de choses qui n’arriveront jamais ? »
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
