Corrigez les remarques vagues de Vitalik sur les problèmes de DA et les retraits résistants à la censure

Vitalik a raté le « défi de disponibilité des données » d’Arbitrum et Redstone, que l’on peut qualifier de tueur de Celestia.

Écrit par : Faust, geek web3

Le 16 janvier 2024, sous un tweet initié par Daniel Wang, fondateur du projet Ethereum Layer 2 Taiko, et en interaction avec Zeng Jiajun, fondateur du portefeuille AA Soul Wallet, Vitalik a déclaré : « La clé du Rollup est la sécurité inconditionnelle : même si vous êtes ciblé par tout le monde et que vous pouvez toujours retirer les actifs. Cela ne peut pas être fait si DA s’appuie sur un système externe (en dehors d’Ethereum). "

Escape Pod : “Retraits sécurisés sans conditions” selon les mots de Viatlik

Parce que Vitalik a parlé de son point de vue sur Validium dans la seconde moitié de ce tweet (Validium fait référence à la deuxième couche de ZK qui n’utilise pas Ethereum pour implémenter la publication des données DA), cela a attiré beaucoup d’attention (auparavant, il y avait des rumeurs selon lesquelles l’Ethereum Le fonds pensera Layer2 = Rollup).

(Il faut le souligner : **Le concept DA discuté dans la communauté Ethereum se réfère à la question de savoir si vous pouvez obtenir des données nouvellement générées à partir de la couche 2, et non si vous pouvez récupérer des données historiques il y a longtemps. ** S’il n’est pas publié sur Ethereum chaîne Nouvelles données, les nœuds Layer2 peuvent ne pas être en mesure d’analyser avec succès le dernier bloc L2)

Cependant, le “Débat sur la définition de la couche 2 d’Ethereum” et la “guerre DA” ont longtemps été entendus par d’innombrables personnes. Cet article n’a pas l’intention de discuter de tels sujets. ** Le but est de concentrer davantage d’énergie sur la première moitié de Le discours de Vitalik**, ce sont aussi les mots mentionnés au début de cet article.

Vitalik a déclaré ici que Rollup peut réaliser des retraits sans confiance et résistants à la censure. Même si tous les nœuds Layer2 ne coopèrent pas avec vous, vous pouvez toujours retirer vos actifs de Layer2 ; et, ** il a souligné que seul le rollup peut y parvenir " " Coffre-fort inconditionnel retrait", alors que la couche 2, qui s’appuie sur d’autres méthodes de libération des données DA, ne peut pas le faire. **

Mais en réalité, ce que dit Vitalik n’est pas rigoureux. **

Tout d’abord, seuls les actifs pontés de la couche 1 à la couche 2 peuvent être renvoyés vers la chaîne ETH. Les actifs natifs de la couche 2 pure ne peuvent pas être croisés vers la couche 1 (à moins que les actifs natifs de la couche 2 ne déploient un contrat d’actifs de transition sur la couche 1).

**Si, comme l’a dit Vitalik, “tout le monde vous cible”, **vous pouvez retirer les actifs de transition L1-L2 au maximum, **mais vous ne pouvez pas retirer votre “jeton natif de couche 2”, **pour le moment, ce n’est pas le cas. Peu importe que vous utilisiez un retrait normal, un retrait forcé ou une trappe de fuite.

Deuxièmement, « **Retrait sécurisé sans conditions » ne repose pas nécessairement sur le système DA. **La première solution Layer2 avant Rollup, Plasma qui implémente la libération des données DA sous la chaîne Ethereum, lorsque le système DA tombe en panne (c’est-à-dire que la rétention de données se produit, à l’exception du séquenceur/comité, personne d’autre ne peut recevoir de nouvelles données/état de transaction informations de transition), permet également aux utilisateurs de soumettre des certificats d’actifs via des données historiques et d’échapper à la couche 2 en toute sécurité.

En d’autres termes, **les retraits sécurisés de Plasma ne dépendent pas du système DA, et **les retraits anti-censure ne doivent pas nécessairement s’appuyer sur le système DA (mais des données historiques doivent être disponibles) ; de plus, **cette déclaration provient de Ethereum Dankrad de la Fondation (le créateur de Danksharding) l’a dit lui-même, ** est également universellement accepté.

Reportez-vous aux articles précédents de Geek Web3 : « Rétention de données et preuve de fraude : raisons pour lesquelles Plasma ne prend pas en charge les contrats intelligents »

Deuxièmement, en laissant de côté Celestia et Blobstream, le problème de rétention des données/échec de DA peut être résolu même sans utiliser ETH comme couche DA. Parlons simplement du « défi de disponibilité des données » que l’équipe Arbitrum et l’équipe Redstone mettent en œuvre, permettant au séquenceur de publier uniquement un engagement DA (en fait un datahash) sur la chaîne, indiquant que les données ont été publiées hors de la chaîne. Si quelqu’un ne peut pas obtenir les données nouvellement générées hors chaîne, il peut contester l’engagement DA sur la chaîne et exiger que le séquenceur divulgue les données à la chaîne.

Ce mécanisme est de conception très simple et ne nécessite pas de recours à des DA tiers tels que Celestia, Avail ou EigenDA. Il nécessite uniquement que la partie du projet Layer2 configure elle-même le nœud DAC hors chaîne. peut être qualifié de tueur de Celestia. **

Dans ce qui suit, l’auteur entend interpréter le « retrait sûr et sans conditions » mentionné par Vitalik et le « défi de disponibilité des données » qu’il n’a pas mentionné, et essayer de dire à tout le monde : **Pourquoi les projets DA tiers tels que Celestia, Avail , et EigenDA ne sont pas une option incontournable pour la couche 2 qui est DA hors chaîne et poursuit la sécurité ? **

De plus, dans notre précédent article expliquant « Indicateurs d’évaluation des risques Bitcoin Layer 2 », nous avons parlé du fait que les retraits résistants à la censure sont plus fondamentaux et critiques que le système DA. L’article d’aujourd’hui discutera également de ce point de vue. explication. **

En fait, il n’est pas difficile de déduire ce que Vitalik a dit : il parlait de la cabine de secours de ZK Rollup. Escape Hatch, également connu sous le nom d’Escape Hatch, est un mode de retrait déclenché directement sur Layer1. Une fois ce mode déclenché, le contrat Rollup entrera dans un état gelé, rejettera les nouvelles données soumises par le séquenceur et permettra à quiconque de montrer Merkle Proof pour prouver son solde d’actifs sur Layer2 et de transférer ses propres actifs depuis Transfert de l’adresse de dépôt officielle du pont Layer2. **

De plus, le mode ** escape trappe est un « mécanisme de retrait sans confiance » qui peut être déclenché manuellement par les parties sur la couche 1 après que la transaction de l’utilisateur a été rejetée par le séquenceur de couche 2 pendant une longue période. **

Cependant, avant d’activer le mode trappe de secours, les utilisateurs rejetés par le séquenceur doivent d’abord appeler la fonction de retrait forcé dans le contrat Rollup sur Layer1, lancer une demande de retrait forcé et lancer un événement pour informer le nœud Layer2 : quelqu’un a initié un retrait forcé.Demande de retrait.

Étant donné que tous les nœuds Layer2 exécuteront le client Ethereum geth et recevront des blocs Ethereum, ils peuvent surveiller le déclenchement de l’événement de retrait forcé

Si la demande de retrait forcé est ignorée pendant une longue période, l’utilisateur peut déclencher activement le mode trappe de secours (la période d’attente par défaut du protocole Loopring est de 15 jours et le plan StarkEx est de 7 jours). Ensuite, le processus opérationnel est celui décrit au début de cet article. L’utilisateur soumet la preuve Merkle correspondant à ses propres actifs pour prouver son statut d’actif dans la couche 2, puis retire les actifs du contrat associé au Rollup.

**Mais pour construire Merkle Proof, vous devez d’abord connaître le statut L2 complet, et **vous devez trouver un nœud complet L2 pour demander des données. Si la situation extrême mentionnée par Vitalik se produit et qu’il n’y a pas de nœud de couche 2 pour coopérer avec vous, ** vous pouvez démarrer vous-même un nœud complet de couche 2 et obtenir les données historiques publiées par le trieur L2 sur Ethereum via le réseau Ethereum, ** à partir de la couche 2 Les blocs de genèse commencent à être synchronisés un par un jusqu’à ce que l’état final soit calculé et que la preuve Merkle soit construite, puis les fonds peuvent être retirés en toute sécurité via la trappe de secours.

**De toute évidence, la « résistance à la censure » à l’heure actuelle est équivalente à Ethereum/Layer1 lui-même. **Tant que le nœud complet d’Ethereum vous fournit des données historiques d’il y a longtemps, il est proche du manque de confiance.

**Cependant, après EIP-4844, tous les nœuds Ethereum perdront automatiquement certaines données historiques, de sorte que les données historiques de la couche 2 pendant plus de 18 jours ne seront plus sauvegardées par l’ensemble du nœud ETH. À ce moment-là, la résistance à la censure des retraits des trappes de secours ne sera plus aussi bon qu’aujourd’hui est si proche du Trustless. **

Après 4844, nous devons être sûrs qu’un nombre relativement limité de nœuds Ethereum qui stockent toutes les données historiques sont prêts à vous fournir des données (les nœuds natifs de couche 2 sont souvent très peu nombreux, nous ne les considérerons donc pas pour le moment). D’ici là, l’hypothèse de confiance des **données historiques de la couche 1 peut être récupérée/le retrait des trappes de secours de la couche 2 passera de Trustless ou 0 d’aujourd’hui à 1/N, c’est-à-dire qu’il est supposé qu’un nœud sur N peut vous fournir des données. **

L’équipe EthStorage semble s’être engagée à étendre ce N pour encourager davantage de nœuds à stocker des données historiques d’il y a longtemps. Si le dénominateur de 1/N est suffisamment grand, le score est toujours proche de 0, ce qui est proche de l’absence d’hypothèse de confiance. Cela peut être une solution appropriée au problème de la récupération des données historiques après 4844.

La relation entre les pods d’évasion et DA – L’attaque du ransomware Validium

Ici, nous allons le résumer à nouveau : **La trappe de secours vous permet de prouver votre statut d’actif de couche 2 via Merkle Proof et d’effectuer des retraits fiables sur la couche 1. **

La raison pour laquelle Vitalik a mentionné que la sécurité des actifs impliqués dans les retraits nécessite DA comme condition préalable est que la solution Validium peut empêcher les retraits dus à des « attaques de rétention de données ». (Seul stateroot est publié et les données de transaction correspondantes ne sont pas publiées).

Le principe spécifique est le suivant : le séquenceur peut conserver les données de transaction et publier uniquement une racine Merkle (Stateroot) sur la chaîne Ethereum, puis, grâce à une preuve de validité, essayer de faire en sorte que la nouvelle Stateroot réussisse la vérification et devienne la Stateroot légale actuelle.

À l’heure actuelle, tout le monde ne connaît pas le statut complet correspondant à la Stateroot légale et ne peut pas construire la preuve Merkle correspondante pour lancer le retrait de la trappe de secours. **Vous ne pouvez pas retirer d’argent à moins que le trieur soit disposé à vous communiquer les données. C’est ce que le directeur technique d’Arbitrum appelle clairement un « problème de rançon » (je préfère personnellement l’appeler une attaque de rançon). **

**Mais la raison pour laquelle DA est sujet aux « attaques de rançon » dans Validium hors chaîne est que la conception de son propre mécanisme n’est pas assez parfaite. **Si un mécanisme de contestation lié au comportement de retrait est introduit, ou si un défi de disponibilité des données est introduit , théoriquement Peut résoudre le problème des attaques de ransomware.

À propos, comme mentionné précédemment, Plasma, qui permet aux utilisateurs de retirer de l’argent à l’aide de données historiques d’il y a longtemps, n’aura pas d’“attaques de rançon” comme Validium, et Plasma est également DA hors chaîne (vérification en chaîne DA+ hors chaîne preuve de fraude).

*Référence : *Rétention de données et preuve de fraude : pourquoi Plasma ne prend pas en charge les contrats intelligents

**Ainsi, les retraits/issues de secours résistants à la censure ne dépendent pas nécessairement du DA, tout dépend de la conception du mécanisme du processus de retrait. **La raison pour laquelle Vitalik pense que les retraits résistants à la censure sont liés à DA est qu’il est parti de solutions existantes telles que Validium et Smart Contract Rollup, et qu’il avait déjà un état d’esprit fixe en tête.

**Mais cela ne signifie pas que toutes les couches 2 de DA offchain dans le monde sont confrontées aux mêmes problèmes que Validium. **Cela ne signifie pas que le rollup de type contrat intelligent est la fin de tout. L’innovation peut survenir à tout moment (comme les défis de disponibilité des données mentionnés plus loin) .

D’un autre côté, si votre solution de couche 2 ne prend pas en compte dès le début des conceptions telles que des trappes de secours et des retraits anti-censure, votre couche 2 ne sera certainement pas suffisamment fiable/sûre. **En d’autres termes, un bon DA et un bon système de preuves sont des conditions suffisantes pour obtenir des retraits résistants à la censure, mais ils ne constituent pas une condition nécessaire.

Par conséquent, dans notre article précédent, nous avons mentionné que dans l’effet baril de couche 2, le retrait résistant à la censure est une lacune plus fondamentale que les systèmes DA et de preuve, et il y a une raison.

*Matériel de référence : *“Utilisation de la théorie du baril pour démanteler le modèle de sécurité Bitcoin/Ethereum Layer 2 et les indicateurs de risque”

Celestia Killer : défis en matière de disponibilité des données pour Arbitrum et Redstone

Après avoir parlé de la relation entre la trappe de secours et DA, revenons sur DA lui-même : la couche 2 n’a pas besoin de publier les données DA sur Ethereum pour éviter la « rétention de données » par le séquenceur.

Redstone, Arbitrum, Metis, etc. développent tous un mécanisme de « défi de disponibilité des données », qui permet au séquenceur de publier uniquement DA Commitment (datahash) + Stateroot sur la chaîne, en précisant que les paramètres de transition d’état (données de transaction) ont été publiés. hors chaîne. **Si quelqu’un ne peut pas obtenir les données nouvellement générées hors chaîne, il peut contester l’engagement DA sur la chaîne et exiger que le séquenceur divulgue les données à la chaîne. **

Si le séquenceur ne parvient pas à publier les données sur la chaîne ETH à temps après avoir été contesté, le datahash/l’engagement qu’il a publié précédemment sera considéré comme invalide, et la racine d’état associée sera également invalide. **De toute évidence, cela résout directement le problème de rétention de données (seul le stateroot est publié et les données de transaction correspondantes ne sont pas publiées). **

De toute évidence, cela présente un « défi de disponibilité des données » supplémentaire par rapport à la couche 2 des offchains DA telles que Validium et Optimium. **Mais une conception aussi simple suffit à créer une forte concurrence contre Celestia, Avail, EigenDA, etc. **Configurez vous-même un DAC et introduisez les défis de disponibilité des données, afin que vous n’ayez plus besoin de compter sur Celestia.

Mais en revanche, les **défis en matière de disponibilité des données posent également des problèmes économiques qui doivent être résolus. **Le fondateur de ZkSync a souligné lors d’une bataille avec le directeur technique d’Arbitrum que **les problèmes de disponibilité des données sont théoriquement sensibles aux attaques DoS. **Par exemple, le séquenceur libère rapidement des milliers d’engagements DA sur la chaîne, puis retient les données complètes correspondantes sans les publier. Il peut ainsi drainer tous les fonds des challengers, puis émettre un blocage invalide, volant les actifs des utilisateurs.

Bien sûr, cette hypothèse est trop extrême. Il s’agit essentiellement d’un problème de théorie du jeu entre l’attaquant et le défenseur. En fait, le séquenceur est plus susceptible d’être attaqué par des challengers malveillants et de dégénérer en Rollup après avoir été continuellement défié. La situation de jeu entre les équipes offensives et défensives autour du défi de la disponibilité des données est en fait très intéressante, et la conception du mécanisme correspondant testera également pleinement la sagesse d’Arbitrum, Redstone et de l’équipe du projet Metis (ce sujet peut être écrit séparément).

Mais dans tous les cas, le défi de la disponibilité des données apportera plus d’innovation dans la conception de la solution DA de Layer 2, qui apportera également une contribution significative à l’écosystème Bitcoin Layer 2.