Titre original : « Corriger les remarques laxistes de Vitalik Buterin sur les questions de DA et les retraits résistants à la censure »
Auteur original : Faust
Source originale : Geek Web3
Le 16 janvier 2024, dans un tweet initié par DanielWang, fondateur du projet Ethereum Layer 2 Taiko, et interagissant avec Zeng Jiajun, fondateur d’AA Wallet Soul Wallet, Vitalik a déclaré : « La clé de Rollup est la sécurité inconditionnelle : même si vous êtes ciblé par tout le monde, vous pouvez toujours retirer vos actifs. Cela ne peut pas être fait si DA s’appuie sur des systèmes externes (en dehors d’Ethereum). 」**
Capsule d’évasion : le « sevrage sûr et sans conditions » de Viatlik
Depuis que Vitalik a parlé de son point de vue sur Validium dans la seconde moitié de ce tweet (Validium fait référence à ZK Layer 2 qui n’utilise pas Ethereum pour mettre en œuvre la publication de données DA), il a reçu beaucoup d’attention (la rumeur selon laquelle la Fondation Ethereum pense que Layer 2 = Rollup).
(Il convient de souligner que le concept DA dont parle la communauté Ethereum fait référence à la question de savoir si vous pouvez accéder aux données nouvellement générées de la couche 2, et non si vous pouvez récupérer des données historiques d’il y a longtemps.) **Si de nouvelles données ne sont pas publiées sur la chaîne Ethereum, le nœud de couche 2 peut ne pas être en mesure de résoudre le dernier bloc L2 en douceur)
Cependant, la « controverse sur la définition de la couche 2 d’Ethereum » et la « guerre DA » ont longtemps été entendues par d’innombrables personnes, et cet article ne va pas entrer dans une discussion sur de tels sujets, mais pour concentrer plus d’énergie sur la première moitié du discours de Vitalik, qui est celle couverte au début de cet article.
Vitalik montre ici que les cumuls peuvent permettre des retraits résistants à la censure sans Trust, vous permettant de retirer vos actifs même si tous les nœuds de couche 2 ne coopèrent pas avec votre couche 2 et, souligne-t-il, seuls les cumuls peuvent réaliser de tels « retraits inconditionnels et sécurisés », ce qui ne peut pas être fait par la couche 2 qui s’appuie sur d’autres méthodes de publication de données DA. **
Mais en réalité, les propos de Vitalik ne sont pas rigoureux. **
Tout d’abord, seules les ressources qui sont pontées vers la couche 2 peuvent revenir à la chaîne de ETH, et les ressources natives de couche 2 pures ne peuvent pas passer à la couche 1 (sauf si la ressource native de couche 2 déploie un contrat de ressource de pont sur la couche 1).
Si, comme l’a dit Vitalik, « tout le monde vous cible », vous pouvez retirer les actifs du pont L1-L2 au maximum, mais vous ne pouvez pas retirer votre propre « jeton natif de couche 2 », pour le moment, que vous preniez un retrait ordinaire, un retrait forcé ou une trappe d’évasion, cela ne sert à rien.
Deuxièmement, les « retraits sécurisés sans conditions » ne doivent pas nécessairement s’appuyer sur le système DA. ** Les premières solutions de couche 2 avant le cumul, Plasma qui implémente la publication de données DA sous la chaîne Ethereum, et les défaillances du système DA (c’est-à-dire que la rétention de données se produit et que personne d’autre que le séquenceur/comité ne peut recevoir de nouvelles données de transaction/informations de transition d’état), il permet également aux utilisateurs de soumettre une preuve d’actifs grâce à des données historiques et de s’échapper en toute sécurité de la couche 2.
En d’autres termes, les retraits sécurisés de Plasma n’ont aucune dépendance vis-à-vis du système DA, et les retraits résistants à la censure n’ont pas besoin de s’appuyer sur le système DA (mais de s’assurer que les données historiques sont disponibles) ; de plus, cette déclaration a été faite par Dankrad (le proposant de Danksharding) de la Fondation Ethereum, et elle est également axiomatique partout.
Reportez-vous aux articles précédents de Geek Web3 : « Rétention de données et preuve de fraude : pourquoi Plasma ne prend pas en charge les contrats intelligents »
Deuxièmement, Celestia et Blobstream mis à part, le problème de rétention des données/défaillance DA peut être résolu même si ETH n’est pas utilisé comme couche DA. Parlons simplement du « défi de disponibilité des données » sur lequel travaillent l’équipe d’Arbitrum et l’équipe de Redstone, permettant au séquenceur de ne publier qu’un seul engagement DA (en fait datahash) sur la chaîne, indiquant que les données ont été publiées 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 demander au séquenceur de divulguer les données sur la chaîne.
La conception de ce mécanisme est très simple, et il n’a pas besoin de s’appuyer sur des DA tiers tels que Celestia, Avail ou EigenDA, mais n’a besoin que de la partie du projet de couche 2 pour mettre en place son propre nœud DAC hors chaîne, que l’on peut appeler le tueur de Celestia. **
Dans ce qui suit, l’auteur a l’intention d’interpréter les « retraits sécurisés inconditionnels » de Vitalik et les « défis de disponibilité des données » qu’il n’a pas mentionnés, en essayant de vous dire : Pourquoi les projets DA tiers tels que Celestia et Avail et EigenDA ne sont-ils pas nécessaires pour la couche 2 de DA offchain et de recherche de sécurité ?
De plus, dans notre article précédent sur les « Indicateurs d’évaluation des risques de la couche 2 de Bitcoin », nous avons parlé du fait que les retraits résistants à la censure sont plus basiques et critiques que les systèmes DA, et l’article d’aujourd’hui expliquera plus en détail ce point. **
En fait, les mots de Vitalik ne sont pas difficiles à déduire, ** parle de la capsule de sauvetage du ZK Rollup. **L’Escape Pod alias Escape Hatch est un mode de retrait qui se déclenche directement sur la couche 1. Une fois ce mode déclenché, le contrat de cumul entrera dans un état gelé, rejettera les nouvelles données soumises par Sequencer et permettra à quiconque de présenter une preuve Merkle pour prouver son solde d’actifs sur la couche 2 et transférer ses actifs à partir de l’adresse officielle de dépôt relais de la couche 2. **
De plus, le mode capsule d’échappement est un « mécanisme de retrait sans confiance » qui peut être déclenché manuellement par les parties de la couche 1 après que la transaction de l’utilisateur ait été rejetée par le séquenceur de couche 2 pendant une longue période. **
Toutefois, avant d’activer le mode capsule d’échappement, les utilisateurs qui sont rejetés par le séquenceur doivent appeler la fonction de retrait forcé dans le contrat de cumul sur la couche 1 pour lancer une demande de retrait forcé et lever un événement pour informer le nœud de couche 2 que quelqu’un a initié une demande de retrait forcé.
Étant donné que le nœud de couche 2 exécutera le client geth Ethereum et recevra EthereumBlock, il sera en mesure d’écouter le déclenchement des événements 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 capsule d’échappement (le délai d’attente par défaut est de 15 jours pour le protocole Loopring et de 7 jours pour la solution StarkEx). Ensuite, comme indiqué au début de cet article, les utilisateurs soumettent la preuve Merkle correspondant à leurs ressources, prouvent leur statut d’actif dans la couche 2, puis retirent les ressources du contrat lié au cumul.
Mais pour construire la preuve de Merkle, vous devez d’abord connaître l’état L2 complet, et vous devez trouver un nœud complet L2 pour demander des données. Si le genre de situation extrême dont parle 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 un nœud complet de couche 2 par vous-même, obtenir les données historiques publiées par le séquenceur L2 sur Ethereum via le réseau Ethereum, et synchroniser une par une à partir du bloc Genesis de couche 2 jusqu’à ce que l’état final soit calculé, et que la preuve de Merkle soit construite, et que vous puissiez retirer de l’argent en toute sécurité via la capsule de sauvetage.
**De toute évidence, la « résistance à la censure » à l’heure actuelle est équivalente à Ethereum/Layer 1 lui-même. **Tant qu’il y a un nœud EthereumFull pour vous fournir des données historiques d’il y a longtemps, il est proche de Trustless.
**Cependant, après EIP-4844, le nœud EthereumFull perdra automatiquement une partie des données historiques, de sorte que les données historiques de la couche 2 de plus de 18 jours ne seront plus sauvegardées par le réseau ETH Node, et la résistance à la censure des retraits des cabines d’évasion ne sera plus aussi proche de Trustless qu’elle l’est aujourd’hui. **
Après 4844, nous devons faire confiance à un nombre relativement limité d’EthereumNode qui stockent toutes les données historiques, prêts à vous fournir des données (les nœuds natifs de couche 2 sont souvent très petits, alors ne les considérez pas pour le moment). À ce moment-là, l’hypothèse de confiance selon laquelle les données historiques de la couche 1 sont récupérables / les retraits de pod de sauvetage de la couche 2 passera de sans confiance ou 0 aujourd’hui à 1/N, c’est-à-dire en supposant que 1 nœud sur N peut vous fournir des données. **
L’équipe d’EthStorage semble s’être engagée à faire évoluer ce N, en incitant davantage de nœuds à stocker des données historiques d’il y a longtemps. Si le dénominateur de 1/N est suffisamment grand, la fraction est toujours proche de 0, ce qui est proche de ne pas introduire l’hypothèse de confiance. Il s’agit peut-être d’une solution appropriée au problème de la récupération des données historiques postérieures à 4844.
Relation entre la capsule d’évasion et DA – L’attaque par rançon de Validium
Ici, nous résumons à nouveau : **La capsule d’échappement est un retrait qui vous permet de prouver votre statut d’actif de couche 2 grâce à Merkle Proof et aux retraits sans confiance sur la couche 1. **
La raison pour laquelle Vitalik a mentionné que la sécurité des actifs impliqués dans les retraits doit avoir DA comme prémisse, signifie principalement que le système de validium ne peut pas être retiré en raison d’attaques de rétention de données. (Seule stateroot est publiée, pas les données de transaction correspondantes).
Le principe spécifique est que le séquenceur peut retenir les données de transaction, ne libérer qu’une racine de Merkle (Stateroot) à la chaîne Ethereum, puis réussir à faire passer la vérification de la nouvelle Stateroot et à devenir la Stateroot légitime actuelle grâce à la preuve de validité.
À l’heure actuelle, vous ne connaissez pas l’état complet correspondant à la racine d’état légitime, et vous ne pouvez pas construire la preuve de Merkle correspondante pour initier le retrait de la capsule de sauvetage. Vous ne pouvez pas vous retirer tant que le séquenceur n’est pas prêt à vous fournir les données, ce que l’un des responsables techniques d’Arbitrum appelle un « problème de rançon » (je préfère personnellement l’appeler une attaque avec rançon). **
Cependant, la raison pour laquelle le validium hors chaîne de DA est sujet aux « attaques de ransomware » est que sa propre conception de mécanisme n’est pas parfaite, et si un mécanisme de défi lié au comportement de retrait est introduit, ou si un défi de disponibilité des données est introduit, le problème d’attaque de ransomware peut théoriquement être résolu.
Soit dit en passant, comme mentionné précédemment, Plasma, qui permet aux utilisateurs de retirer des données historiques d’il y a longtemps, n’aura pas d’"attaque de ransomware » telle que les validiums, et Plasma est également DA off-chain (off-chain DA+ on-chain verification fraud proof).
Référence : Rétention de données et protection contre la fraude : pourquoi Plasma ne prend pas en charge les contrats intelligents
Par conséquent, les retraits/capsules d’évasion résistants à la censure n’ont pas besoin de s’appuyer sur 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 a un état d’esprit préconçu basé sur des solutions existantes telles que Validium et Smart Contract Rollup.
Mais cela ne signifie pas que tous les DA offchain Layer 2 dans le monde sont confrontés aux mêmes problèmes que les validiums, et cela ne signifie pas que les Smart Contract Rollups sont la fin de tout, et que l’innovation peut survenir à tout moment (comme les défis de disponibilité des données mentionnés plus tard).
**À l’inverse, si votre solution de couche 2 ne prend pas en compte dès le départ la conception de capsules de sauvetage et de retraits résistants à la censure, votre couche 2 ne sera certainement pas assez fiable/sécurisée. En d’autres termes, un bon système d’AD et d’attestation est une condition suffisante pour un retrait résistant à la censure, mais pas nécessaire.
Ainsi, dans notre article précédent, nous avons mentionné que dans l’effet de baril de couche 2, les retraits résistants à la censure sont une lacune plus fondamentale que les systèmes DA et de preuve, et il y a une raison.
Référence : « Démantèlement des modèles de sécurité et des indicateurs de risque de la couche 2 Bitcoin / Ethereum avec la théorie du baril »
Celestia Killer : les défis de la disponibilité des données pour Arbitrum et Redstone
Après avoir parlé de la relation entre la capsule d’échappement et le DA, revenons sur le DA lui-même : la couche 2 n’a pas besoin de publier les données du DA sur Ethereum afin d’éviter que le séquenceur ne s’engage dans la « rétention des données ».
Redstone, Arbitrum, Metis et d’autres travaillent tous sur un mécanisme de « défi de disponibilité des données » qui permet aux séquenceurs de ne publier que DA Commitment(datahash)+Stateroot on-chain, déclarant que les paramètres de transition d’état (données de transaction) ont été publiés hors chaîne. Si quelqu’un n’est pas en mesure d’obtenir les données nouvellement générées hors chaîne, il peut contester l’engagement DA on-chain et demander au séquenceur de divulguer les données on-chain. **
Si le séquenceur est contesté et ne publie pas de données sur la chaîne de ETH en temps opportun, son datahash/engagement précédemment publié sera considéré comme invalide, et le stateroot associé sera également invalide. Évidemment, cela résout directement le problème de conservation des données (seule la stateroot est publiée, pas les données de transaction correspondantes). **
De toute évidence, il s’agit d’un « défi de disponibilité des données » de plus que la couche 2 des offchains DA telles que Validium et Optimium. Mais une conception aussi simple est suffisante pour créer une forte concurrence avec Celestia et Avail, EigenDA, etc. Configurez votre propre DAC pour présenter des problèmes de disponibilité des données et ne plus dépendre de Celestia.
À l’inverse, cependant, les problèmes de disponibilité des données comportent également des problèmes économiques qui doivent être résolus. Lors d’une bataille avec le responsable technique d’Arbitrum, le fondateur de ZkSync a souligné que les problèmes de disponibilité des données sont théoriquement sensibles aux attaques par déni de service. Par exemple, le séquenceur publie rapidement des milliers d’engagements DA sur la chaîne, puis retient les données complètes correspondantes et ne les publie pas. De cette façon, il peut drainer tous les fonds des challengers, puis publier un bloc invalide pour voler 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 des jeux pour les côtés offensifs et défensifs, et en fait, le séquenceur est plus susceptible d’être attaqué par des adversaires malveillants, et il régresse en rollup après avoir été contesté continuellement. Le jeu entre l’attaquant et le défenseur autour du défi de la disponibilité des données est en fait très intéressant, et la conception de la mécanique correspondante mettra pleinement à l’épreuve la sagesse d’Arbitrum et de Redstone, ainsi que de l’équipe du projet Metis (ce sujet peut être écrit séparément).
Quoi qu’il en soit, le défi de la disponibilité des données apportera plus d’innovation à la conception DA de la couche 2, ce qui fera également une grande différence pour l’écosystème de la couche 2 de Bitcoin.
Lien vers l’article original
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Pourquoi la déclaration de Vitalik Buterin sur les « problèmes de DA et les retraits résistants à la censure » n’est-elle pas rigoureuse ?
Titre original : « Corriger les remarques laxistes de Vitalik Buterin sur les questions de DA et les retraits résistants à la censure »
Auteur original : Faust
Source originale : Geek Web3
Le 16 janvier 2024, dans un tweet initié par DanielWang, fondateur du projet Ethereum Layer 2 Taiko, et interagissant avec Zeng Jiajun, fondateur d’AA Wallet Soul Wallet, Vitalik a déclaré : « La clé de Rollup est la sécurité inconditionnelle : même si vous êtes ciblé par tout le monde, vous pouvez toujours retirer vos actifs. Cela ne peut pas être fait si DA s’appuie sur des systèmes externes (en dehors d’Ethereum). 」**
Capsule d’évasion : le « sevrage sûr et sans conditions » de Viatlik
Depuis que Vitalik a parlé de son point de vue sur Validium dans la seconde moitié de ce tweet (Validium fait référence à ZK Layer 2 qui n’utilise pas Ethereum pour mettre en œuvre la publication de données DA), il a reçu beaucoup d’attention (la rumeur selon laquelle la Fondation Ethereum pense que Layer 2 = Rollup).
(Il convient de souligner que le concept DA dont parle la communauté Ethereum fait référence à la question de savoir si vous pouvez accéder aux données nouvellement générées de la couche 2, et non si vous pouvez récupérer des données historiques d’il y a longtemps.) **Si de nouvelles données ne sont pas publiées sur la chaîne Ethereum, le nœud de couche 2 peut ne pas être en mesure de résoudre le dernier bloc L2 en douceur)
Cependant, la « controverse sur la définition de la couche 2 d’Ethereum » et la « guerre DA » ont longtemps été entendues par d’innombrables personnes, et cet article ne va pas entrer dans une discussion sur de tels sujets, mais pour concentrer plus d’énergie sur la première moitié du discours de Vitalik, qui est celle couverte au début de cet article.
Vitalik montre ici que les cumuls peuvent permettre des retraits résistants à la censure sans Trust, vous permettant de retirer vos actifs même si tous les nœuds de couche 2 ne coopèrent pas avec votre couche 2 et, souligne-t-il, seuls les cumuls peuvent réaliser de tels « retraits inconditionnels et sécurisés », ce qui ne peut pas être fait par la couche 2 qui s’appuie sur d’autres méthodes de publication de données DA. **
Mais en réalité, les propos de Vitalik ne sont pas rigoureux. **
Tout d’abord, seules les ressources qui sont pontées vers la couche 2 peuvent revenir à la chaîne de ETH, et les ressources natives de couche 2 pures ne peuvent pas passer à la couche 1 (sauf si la ressource native de couche 2 déploie un contrat de ressource de pont sur la couche 1).
Si, comme l’a dit Vitalik, « tout le monde vous cible », vous pouvez retirer les actifs du pont L1-L2 au maximum, mais vous ne pouvez pas retirer votre propre « jeton natif de couche 2 », pour le moment, que vous preniez un retrait ordinaire, un retrait forcé ou une trappe d’évasion, cela ne sert à rien.
Deuxièmement, les « retraits sécurisés sans conditions » ne doivent pas nécessairement s’appuyer sur le système DA. ** Les premières solutions de couche 2 avant le cumul, Plasma qui implémente la publication de données DA sous la chaîne Ethereum, et les défaillances du système DA (c’est-à-dire que la rétention de données se produit et que personne d’autre que le séquenceur/comité ne peut recevoir de nouvelles données de transaction/informations de transition d’état), il permet également aux utilisateurs de soumettre une preuve d’actifs grâce à des données historiques et de s’échapper en toute sécurité de la couche 2.
En d’autres termes, les retraits sécurisés de Plasma n’ont aucune dépendance vis-à-vis du système DA, et les retraits résistants à la censure n’ont pas besoin de s’appuyer sur le système DA (mais de s’assurer que les données historiques sont disponibles) ; de plus, cette déclaration a été faite par Dankrad (le proposant de Danksharding) de la Fondation Ethereum, et elle est également axiomatique partout.
Reportez-vous aux articles précédents de Geek Web3 : « Rétention de données et preuve de fraude : pourquoi Plasma ne prend pas en charge les contrats intelligents »
Deuxièmement, Celestia et Blobstream mis à part, le problème de rétention des données/défaillance DA peut être résolu même si ETH n’est pas utilisé comme couche DA. Parlons simplement du « défi de disponibilité des données » sur lequel travaillent l’équipe d’Arbitrum et l’équipe de Redstone, permettant au séquenceur de ne publier qu’un seul engagement DA (en fait datahash) sur la chaîne, indiquant que les données ont été publiées 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 demander au séquenceur de divulguer les données sur la chaîne.
La conception de ce mécanisme est très simple, et il n’a pas besoin de s’appuyer sur des DA tiers tels que Celestia, Avail ou EigenDA, mais n’a besoin que de la partie du projet de couche 2 pour mettre en place son propre nœud DAC hors chaîne, que l’on peut appeler le tueur de Celestia. **
Dans ce qui suit, l’auteur a l’intention d’interpréter les « retraits sécurisés inconditionnels » de Vitalik et les « défis de disponibilité des données » qu’il n’a pas mentionnés, en essayant de vous dire : Pourquoi les projets DA tiers tels que Celestia et Avail et EigenDA ne sont-ils pas nécessaires pour la couche 2 de DA offchain et de recherche de sécurité ?
De plus, dans notre article précédent sur les « Indicateurs d’évaluation des risques de la couche 2 de Bitcoin », nous avons parlé du fait que les retraits résistants à la censure sont plus basiques et critiques que les systèmes DA, et l’article d’aujourd’hui expliquera plus en détail ce point. **
En fait, les mots de Vitalik ne sont pas difficiles à déduire, ** parle de la capsule de sauvetage du ZK Rollup. **L’Escape Pod alias Escape Hatch est un mode de retrait qui se déclenche directement sur la couche 1. Une fois ce mode déclenché, le contrat de cumul entrera dans un état gelé, rejettera les nouvelles données soumises par Sequencer et permettra à quiconque de présenter une preuve Merkle pour prouver son solde d’actifs sur la couche 2 et transférer ses actifs à partir de l’adresse officielle de dépôt relais de la couche 2. **
De plus, le mode capsule d’échappement est un « mécanisme de retrait sans confiance » qui peut être déclenché manuellement par les parties de la couche 1 après que la transaction de l’utilisateur ait été rejetée par le séquenceur de couche 2 pendant une longue période. **
Toutefois, avant d’activer le mode capsule d’échappement, les utilisateurs qui sont rejetés par le séquenceur doivent appeler la fonction de retrait forcé dans le contrat de cumul sur la couche 1 pour lancer une demande de retrait forcé et lever un événement pour informer le nœud de couche 2 que quelqu’un a initié une demande de retrait forcé.
Étant donné que le nœud de couche 2 exécutera le client geth Ethereum et recevra EthereumBlock, il sera en mesure d’écouter le déclenchement des événements 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 capsule d’échappement (le délai d’attente par défaut est de 15 jours pour le protocole Loopring et de 7 jours pour la solution StarkEx). Ensuite, comme indiqué au début de cet article, les utilisateurs soumettent la preuve Merkle correspondant à leurs ressources, prouvent leur statut d’actif dans la couche 2, puis retirent les ressources du contrat lié au cumul.
Mais pour construire la preuve de Merkle, vous devez d’abord connaître l’état L2 complet, et vous devez trouver un nœud complet L2 pour demander des données. Si le genre de situation extrême dont parle 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 un nœud complet de couche 2 par vous-même, obtenir les données historiques publiées par le séquenceur L2 sur Ethereum via le réseau Ethereum, et synchroniser une par une à partir du bloc Genesis de couche 2 jusqu’à ce que l’état final soit calculé, et que la preuve de Merkle soit construite, et que vous puissiez retirer de l’argent en toute sécurité via la capsule de sauvetage.
**De toute évidence, la « résistance à la censure » à l’heure actuelle est équivalente à Ethereum/Layer 1 lui-même. **Tant qu’il y a un nœud EthereumFull pour vous fournir des données historiques d’il y a longtemps, il est proche de Trustless.
**Cependant, après EIP-4844, le nœud EthereumFull perdra automatiquement une partie des données historiques, de sorte que les données historiques de la couche 2 de plus de 18 jours ne seront plus sauvegardées par le réseau ETH Node, et la résistance à la censure des retraits des cabines d’évasion ne sera plus aussi proche de Trustless qu’elle l’est aujourd’hui. **
Après 4844, nous devons faire confiance à un nombre relativement limité d’EthereumNode qui stockent toutes les données historiques, prêts à vous fournir des données (les nœuds natifs de couche 2 sont souvent très petits, alors ne les considérez pas pour le moment). À ce moment-là, l’hypothèse de confiance selon laquelle les données historiques de la couche 1 sont récupérables / les retraits de pod de sauvetage de la couche 2 passera de sans confiance ou 0 aujourd’hui à 1/N, c’est-à-dire en supposant que 1 nœud sur N peut vous fournir des données. **
L’équipe d’EthStorage semble s’être engagée à faire évoluer ce N, en incitant davantage de nœuds à stocker des données historiques d’il y a longtemps. Si le dénominateur de 1/N est suffisamment grand, la fraction est toujours proche de 0, ce qui est proche de ne pas introduire l’hypothèse de confiance. Il s’agit peut-être d’une solution appropriée au problème de la récupération des données historiques postérieures à 4844.
Relation entre la capsule d’évasion et DA – L’attaque par rançon de Validium
Ici, nous résumons à nouveau : **La capsule d’échappement est un retrait qui vous permet de prouver votre statut d’actif de couche 2 grâce à Merkle Proof et aux retraits sans confiance sur la couche 1. **
La raison pour laquelle Vitalik a mentionné que la sécurité des actifs impliqués dans les retraits doit avoir DA comme prémisse, signifie principalement que le système de validium ne peut pas être retiré en raison d’attaques de rétention de données. (Seule stateroot est publiée, pas les données de transaction correspondantes).
Le principe spécifique est que le séquenceur peut retenir les données de transaction, ne libérer qu’une racine de Merkle (Stateroot) à la chaîne Ethereum, puis réussir à faire passer la vérification de la nouvelle Stateroot et à devenir la Stateroot légitime actuelle grâce à la preuve de validité.
À l’heure actuelle, vous ne connaissez pas l’état complet correspondant à la racine d’état légitime, et vous ne pouvez pas construire la preuve de Merkle correspondante pour initier le retrait de la capsule de sauvetage. Vous ne pouvez pas vous retirer tant que le séquenceur n’est pas prêt à vous fournir les données, ce que l’un des responsables techniques d’Arbitrum appelle un « problème de rançon » (je préfère personnellement l’appeler une attaque avec rançon). **
Cependant, la raison pour laquelle le validium hors chaîne de DA est sujet aux « attaques de ransomware » est que sa propre conception de mécanisme n’est pas parfaite, et si un mécanisme de défi lié au comportement de retrait est introduit, ou si un défi de disponibilité des données est introduit, le problème d’attaque de ransomware peut théoriquement être résolu.
Soit dit en passant, comme mentionné précédemment, Plasma, qui permet aux utilisateurs de retirer des données historiques d’il y a longtemps, n’aura pas d’"attaque de ransomware » telle que les validiums, et Plasma est également DA off-chain (off-chain DA+ on-chain verification fraud proof).
Référence : Rétention de données et protection contre la fraude : pourquoi Plasma ne prend pas en charge les contrats intelligents
Par conséquent, les retraits/capsules d’évasion résistants à la censure n’ont pas besoin de s’appuyer sur 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 a un état d’esprit préconçu basé sur des solutions existantes telles que Validium et Smart Contract Rollup.
Mais cela ne signifie pas que tous les DA offchain Layer 2 dans le monde sont confrontés aux mêmes problèmes que les validiums, et cela ne signifie pas que les Smart Contract Rollups sont la fin de tout, et que l’innovation peut survenir à tout moment (comme les défis de disponibilité des données mentionnés plus tard).
**À l’inverse, si votre solution de couche 2 ne prend pas en compte dès le départ la conception de capsules de sauvetage et de retraits résistants à la censure, votre couche 2 ne sera certainement pas assez fiable/sécurisée. En d’autres termes, un bon système d’AD et d’attestation est une condition suffisante pour un retrait résistant à la censure, mais pas nécessaire.
Ainsi, dans notre article précédent, nous avons mentionné que dans l’effet de baril de couche 2, les retraits résistants à la censure sont une lacune plus fondamentale que les systèmes DA et de preuve, et il y a une raison.
Référence : « Démantèlement des modèles de sécurité et des indicateurs de risque de la couche 2 Bitcoin / Ethereum avec la théorie du baril »
Celestia Killer : les défis de la disponibilité des données pour Arbitrum et Redstone
Après avoir parlé de la relation entre la capsule d’échappement et le DA, revenons sur le DA lui-même : la couche 2 n’a pas besoin de publier les données du DA sur Ethereum afin d’éviter que le séquenceur ne s’engage dans la « rétention des données ».
Redstone, Arbitrum, Metis et d’autres travaillent tous sur un mécanisme de « défi de disponibilité des données » qui permet aux séquenceurs de ne publier que DA Commitment(datahash)+Stateroot on-chain, déclarant que les paramètres de transition d’état (données de transaction) ont été publiés hors chaîne. Si quelqu’un n’est pas en mesure d’obtenir les données nouvellement générées hors chaîne, il peut contester l’engagement DA on-chain et demander au séquenceur de divulguer les données on-chain. **
Si le séquenceur est contesté et ne publie pas de données sur la chaîne de ETH en temps opportun, son datahash/engagement précédemment publié sera considéré comme invalide, et le stateroot associé sera également invalide. Évidemment, cela résout directement le problème de conservation des données (seule la stateroot est publiée, pas les données de transaction correspondantes). **
De toute évidence, il s’agit d’un « défi de disponibilité des données » de plus que la couche 2 des offchains DA telles que Validium et Optimium. Mais une conception aussi simple est suffisante pour créer une forte concurrence avec Celestia et Avail, EigenDA, etc. Configurez votre propre DAC pour présenter des problèmes de disponibilité des données et ne plus dépendre de Celestia.
À l’inverse, cependant, les problèmes de disponibilité des données comportent également des problèmes économiques qui doivent être résolus. Lors d’une bataille avec le responsable technique d’Arbitrum, le fondateur de ZkSync a souligné que les problèmes de disponibilité des données sont théoriquement sensibles aux attaques par déni de service. Par exemple, le séquenceur publie rapidement des milliers d’engagements DA sur la chaîne, puis retient les données complètes correspondantes et ne les publie pas. De cette façon, il peut drainer tous les fonds des challengers, puis publier un bloc invalide pour voler 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 des jeux pour les côtés offensifs et défensifs, et en fait, le séquenceur est plus susceptible d’être attaqué par des adversaires malveillants, et il régresse en rollup après avoir été contesté continuellement. Le jeu entre l’attaquant et le défenseur autour du défi de la disponibilité des données est en fait très intéressant, et la conception de la mécanique correspondante mettra pleinement à l’épreuve la sagesse d’Arbitrum et de Redstone, ainsi que de l’équipe du projet Metis (ce sujet peut être écrit séparément).
Quoi qu’il en soit, le défi de la disponibilité des données apportera plus d’innovation à la conception DA de la couche 2, ce qui fera également une grande différence pour l’écosystème de la couche 2 de Bitcoin.
Lien vers l’article original