Corriger les déclarations imprécises de Vitalik sur la disponibilité des données (DA) et le retrait résistant à la censure
TechFlow SélectionTechFlow Sélection
Corriger les déclarations imprécises de Vitalik sur la disponibilité des données (DA) et le retrait résistant à la censure
Les retraits sécurisés de Plasma ne dépendent pas du système DA, et les retraits résistants à la censure n'ont pas non plus besoin de dépendre nécessairement du système DA.
Dédié à des analyses Web3 approfondiesAuteur : Faust, GeekWeb3
Le 16 janvier 2024, sous un tweet initié par Daniel Wang, fondateur du projet Layer2 Ethereum Taiko, et interagissant avec Jason Zeng, fondateur du portefeuille AA Soul Wallet, Vitalik a déclaré : « L’élément clé des rollups réside dans une sécurité inconditionnelle : même si tout le monde se retourne contre vous, vous pouvez toujours retirer vos actifs. Si la disponibilité des données (DA) dépend d’un système externe (hors Ethereum), cela devient impossible. »
Étant donné que Vitalik aborde ensuite son opinion sur les Validium (des solutions de type ZK Layer2 qui n’utilisent pas Ethereum pour publier leurs données DA), ce tweet a attiré beaucoup d’attention (la rumeur courait auparavant que la Fondation Ethereum considérait que Layer2 = Rollup).
(À noter : le concept de DA au sein de la communauté Ethereum concerne la capacité à accéder aux nouvelles données générées par le Layer2, et non à récupérer des données historiques anciennes. Si les nouvelles données ne sont pas publiées sur la chaîne Ethereum, les nœuds Layer2 peuvent ne pas réussir à interpréter correctement le dernier bloc L2.)
Toutefois, le débat autour de la « définition du Layer2 Ethereum » et la « guerre du DA » ont déjà été largement entendus. Cet article ne souhaite pas s’étendre sur ces sujets, mais souhaite concentrer l’attention sur la première partie de la déclaration de Vitalik, précisément celle citée en début d’article.
Vitalik affirme ici que les rollups permettent un retrait décentralisé résistant à la censure : même si tous les nœuds Layer2 refusent de coopérer, vous pouvez toujours retirer vos actifs du Layer2. Et il précise que seul un rollup peut offrir ce « retrait sécurisé inconditionnel », tandis que les Layer2 reposant sur d'autres méthodes de publication des données DA n’en sont pas capables.
En réalité, cette affirmation de Vitalik manque de rigueur.
Premièrement, seuls les actifs transférés du Layer1 vers le Layer2 peuvent être rapatriés sur la chaîne ETH ; les jetons natifs du Layer2 ne peuvent pas passer au Layer1 (sauf s’il existe un contrat de pont pour ces jetons natifs déployé sur le Layer1).
Dans le scénario décrit par Vitalik où « tout le monde est contre vous », vous ne pouvez retirer que les actifs transférés via le pont L1-L2, mais pas vos « jetons natifs Layer2 ». Dans ce cas, ni un retrait standard, ni un retrait forcé (forced withdraw), ni une trappe d’évacuation (escape hatch) ne fonctionneraient.
Deuxièmement, le « retrait sécurisé sans conditions » ne dépend pas nécessairement d’un système DA. Les premières solutions Layer2 antérieures aux rollups, comme Plasma — qui implémente la DA hors chaîne — permettent également aux utilisateurs, en cas de panne du système DA (c’est-à-dire lorsque les données sont retenues et que seuls le séquenceur ou le comité y ont accès), de soumettre une preuve d’actifs basée sur des données historiques pour quitter en toute sécurité le Layer2.
Autrement dit, le mécanisme de retrait sécurisé de Plasma ne dépend pas du système DA ; la capacité de retrait résistant à la censure n’exige pas non plus une dépendance au DA (à condition que les données historiques restent accessibles). D’ailleurs, c’est Dankrad lui-même, membre de la Fondation Ethereum et concepteur de Danksharding, qui a affirmé cela, ce qui en fait une vérité universellement admise.
Voir article précédent de GeekWeb3 :« Retenue de données et preuves de fraude : pourquoi Plasma ne prend pas en charge les contrats intelligents »
Troisièmement, sans parler de Celestia ou Blobstream, le problème de la retenue de données ou de panne du système DA peut être résolu même sans utiliser ETH comme couche DA. Par exemple, l’équipe d’Arbitrum et celle de Redstone mettent en œuvre un mécanisme appelé « défi de disponibilité des données » (data availability challenge), qui permet au séquenceur de publier uniquement un engagement DA (hash des données) sur la chaîne, attestant avoir publié les données hors chaîne. Si quelqu’un ne parvient pas à obtenir les données hors chaîne, il peut contester cet engagement et exiger que le séquenceur publie les données directement sur la chaîne.
Ce mécanisme est élégant, et n’exige pas l’utilisation de systèmes tiers tels que Celestia, Avail ou EigenDA. Il suffit que le projet Layer2 configure ses propres nœuds DAC hors chaîne, ce qui en fait un véritable concurrent de Celestia.
Dans cet article, l’auteur va analyser le « retrait sécurisé inconditionnel » évoqué par Vitalik ainsi que le « défi de disponibilité des données », encore peu connu, afin d’expliquer pourquoi Celestia, Avail, EigenDA et autres projets tiers de disponibilité des données ne sont pas obligatoires pour les Layer2 cherchant à assurer la sécurité tout en gardant la DA hors chaîne.
Par ailleurs, nous avons précédemment indiqué, dans un article traitant des « indicateurs d’évaluation des risques des Layer2 Bitcoin », que le retrait résistant à la censure est plus fondamental et crucial que le système DA. Cet article approfondira davantage cette idée.
La trappe d’évacuation : le « retrait sécurisé inconditionnel » selon Vitalik
En réalité, la déclaration de Vitalik n’est pas difficile à analyser : elle concerne la trappe d’évacuation (escape hatch) des ZK Rollups. Aussi appelée escape hatch, il s’agit d’un mode de retrait déclenché directement sur le Layer1. Dès son activation, le contrat du rollup entre en état de gel, refuse les nouvelles données soumises par le séquenceur, et permet à toute personne de présenter une preuve Merkle prouvant son solde sur le Layer2, puis de transférer ses actifs depuis l’adresse de dépôt officielle du pont Layer2.
Plus précisément, le mode escape hatch est un « mécanisme de retrait décentralisé » que l’utilisateur peut déclencher manuellement sur le Layer1 lorsqu’il subit un blocage prolongé de ses transactions par le séquenceur Layer2.
Avant d’activer la trappe d’évacuation, l’utilisateur dont les transactions ont été rejetées doit d’abord appeler la fonction de retrait forcé (forced withdrawal) dans le contrat Rollup sur le Layer1, soumettre une requête, et générer un événement pour informer les nœuds Layer2 qu’un retrait forcé a été demandé.
(Les nœuds Layer2 exécutent généralement un client Geth Ethereum, reçoivent les blocs Ethereum, et peuvent donc écouter l’événement de retrait forcé.)
Si la demande de retrait forcé est ignorée trop longtemps, l’utilisateur peut alors déclencher activement la trappe d’évacuation (Loopring fixe par défaut ce délai à 15 jours, StarkEx à 7 jours). Ensuite, comme mentionné au début, l’utilisateur soumet une preuve Merkle correspondant à ses actifs, prouve sa situation d’actifs sur le Layer2, et retire ses fonds via le contrat Rollup.
Mais pour construire une preuve Merkle, il faut d’abord connaître l’état complet du L2, ce qui nécessite d’obtenir les données auprès d’un nœud complet L2. Dans le cas extrême décrit par Vitalik, si aucun nœud Layer2 ne coopère, vous pouvez lancer vous-même un nœud complet Layer2, récupérer via le réseau Ethereum les données historiques publiées par le séquenceur L2 sur Ethereum, synchroniser chaque bloc depuis le bloc genesis jusqu’à l’état final, construire la preuve Merkle, et effectuer un retrait sécurisé via la trappe d’évacuation.
Il est clair que, dans ce cas, la « résistance à la censure » est équivalente à celle d’Ethereum/Layer1. Tant qu’un nœud complet Ethereum peut vous fournir des données historiques anciennes, le processus reste presque décentralisé.
Cependant, après EIP-4844, les nœuds complets Ethereum supprimeront automatiquement certaines données historiques, ce qui signifie que les données L2 datant de plus de 18 jours ne seront plus sauvegardées par l’ensemble du réseau ETH. À ce moment-là, la résistance à la censure du retrait via la trappe d’évacuation ne sera plus aussi proche du modèle sans confiance qu’aujourd’hui.
Après EIP-4844, nous devrons faire confiance au fait qu’un petit nombre de nœuds Ethereum, ayant conservé toutes les données historiques, accepteront de nous les fournir (les nœuds natifs Layer2 étant souvent très peu nombreux, ils ne sont pas pris en compte ici). Alors, l’hypothèse de confiance liée à la récupération des données historiques Layer1 / au retrait via la trappe d’évacuation passera d’un modèle aujourd’hui quasi sans confiance (0) à 1/N, c’est-à-dire supposer qu’au moins 1 parmi N nœuds vous fournira les données.
L’équipe EthStorage cherche à agrandir ce N, en incitant davantage de nœuds à stocker les données historiques. Si le dénominateur de 1/N est suffisamment grand, la fraction reste proche de zéro, presque équivalente à l’absence d’hypothèse de confiance. Cela pourrait partiellement résoudre le problème de récupération des données après EIP-4844.
Relation entre la trappe d’évacuation et la DA — l’attaque par rançon dans les Validium
Résumons à nouveau : la trappe d’évacuation permet de prouver via une preuve Merkle son solde sur Layer2, puis de retirer ses actifs de manière décentralisée sur le Layer1.
La raison pour laquelle Vitalik insiste sur le fait que la sécurité du retrait dépend de la DA concerne principalement les schémas Validium, qui peuvent être empêchés de retirer des fonds à cause d’une « attaque par retenue de données » (publication du stateroot sans les données transactionnelles associées).
Le principe est le suivant : le séquenceur pourrait retenir les données transactionnelles, ne publier sur Ethereum qu’une racine Merkle (stateroot), puis valider un nouveau stateroot via une preuve d’efficacité, faisant ainsi passer ce stateroot comme légitime.
Dans ce cas, personne ne connaît l’état complet correspondant au stateroot valide, et ne peut donc construire la preuve Merkle nécessaire pour activer la trappe d’évacuation. Vous ne pourrez retirer vos fonds que si le séquenceur accepte de libérer les données — ce que certains responsables techniques d’Arbitrum appellent métaphoriquement un « problème de rançon » (je préfère personnellement « attaque par chantage »).
Mais le fait que les Validium, dont la DA est hors chaîne, soient vulnérables à ce « chantage » s’explique par une conception mécanique imparfaite. En introduisant un mécanisme de défi lié aux retraits ou un « défi de disponibilité des données », on peut théoriquement résoudre ce problème.
Au passage, comme mentionné plus haut, Plasma, qui permet aux utilisateurs de retirer leurs fonds en utilisant des données historiques anciennes, n’est pas sujet à ce type d’« attaque par rançon », bien que Plasma place également la DA hors chaîne (DA hors chaîne + vérification des preuves de fraude sur chaîne).
Références :Retenue de données et preuves de fraude : pourquoi Plasma ne prend pas en charge les contrats intelligents
Ainsi, le retrait résistant à la censure / la trappe d’évacuation ne dépend pas nécessairement du système DA. Tout dépend de la conception du mécanisme de retrait. La raison pour laquelle Vitalik associe le retrait résistant à la censure au DA est qu’il raisonne à partir de schémas existants comme Validium ou les rollups à contrats intelligents, enfermé dans une forme de pensée préconçue.
Cela ne signifie pas que tous les Layer2 hors chaîne rencontrent le même problème que les Validium, ni que les rollups à contrats intelligents représentent la fin de l’innovation (comme le montre plus loin le défi de disponibilité des données).
Inversement, si votre solution Layer2 n’intègre dès le départ ni trappe d’évacuation ni mécanisme de retrait résistant à la censure, elle n’est intrinsèquement pas suffisamment décentralisée/sécurisée. Autrement dit, une bonne gestion de la DA et du système de preuves constitue une condition suffisante, mais non nécessaire, pour permettre des retraits résistants à la censure.
C’est pourquoi, dans nos articles précédents, nous avons expliqué que dans l’effet « tonneau » des Layer2, le retrait résistant à la censure représente une lacune plus fondamentale que la DA ou le système de preuves.
Le tueur de Celestia : le défi de disponibilité des données d’Arbitrum et Redstone
Après avoir examiné la relation entre la trappe d’évacuation et la DA, revenons à la DA elle-même : les Layer2 n’ont pas besoin de publier leurs données DA sur Ethereum pour éviter que le séquenceur pratique la « retenue de données ».
Redstone, Arbitrum, Metis et d’autres développent un mécanisme de « défi de disponibilité des données », permettant au séquenceur de publier sur chaîne uniquement un engagement DA (hash des données) + le stateroot, en attestant avoir publié hors chaîne les paramètres de transition d’état (données transactionnelles). Si quelqu’un ne parvient pas à récupérer les données hors chaîne, il peut contester l’engagement DA sur chaîne, forçant le séquenceur à divulguer les données sur chaîne.
Si, après un défi, le séquenceur ne publie pas rapidement les données sur la chaîne ETH, son hash/data commitment est considéré comme invalide, rendant aussi invalide le stateroot associé. Cela résout directement le problème de retenue de données (publication du stateroot sans les données transactionnelles associées).
Il est évident que, comparé aux Validium et Optimium (Layer2 avec DA hors chaîne), ce mécanisme ajoute un « défi de disponibilité des données ». Mais cette simple amélioration suffit à concurrencer sérieusement Celestia, Avail ou EigenDA. En configurant son propre DAC et en intégrant un défi de disponibilité des données, on n’a plus besoin de dépendre de Celestia.
En revanche, le défi de disponibilité des données soulève des problèmes économiques à résoudre. Le fondateur de ZkSync a souligné, lors d’un échange avec un responsable technique d’Arbitrum, que ce mécanisme est théoriquement vulnérable aux attaques DoS. Par exemple, le séquenceur pourrait publier rapidement des milliers d’engagements DA sur chaîne tout en retenant les données complètes. Il pourrait ainsi vider les fonds de tous les challengers, puis publier un bloc invalide et voler les actifs des utilisateurs.
Bien sûr, ce scénario est extrêmement hypothétique, il s’agit essentiellement d’un problème de théorie des jeux entre attaquant et défenseur. En réalité, le séquenceur est plus facilement exposé à des attaques DoS par des challengers malveillants, pouvant être forcé, après plusieurs défis, à fonctionner comme un rollup. La dynamique stratégique entre les deux parties autour du défi de disponibilité des données est fascinante, et testera pleinement la créativité des équipes d’Arbitrum, Redstone et Metis (un sujet qui mériterait un article entier).
Quoi qu’il en soit, le défi de disponibilité des données apportera davantage d’innovations dans la conception des solutions DA pour les Layer2, et marquera profondément l’écosystème des Layer2 Bitcoin.
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
