• Titre original transmis : Incompréhension de la disponibilité des données : DA = publication des données ≠ extraction des données historiques

Introduction :

Qu'est-ce que la disponibilité des données exactement ? Pour la plupart des gens, la première impression peut être « d'accéder aux données historiques d'un moment donné », mais il s'agit en fait d'un malentendu majeur à propos du concept DA. Récemment, les cofondateurs de L2BEAT et les partisans de Danksharding, ainsi que le fondateur de Celestia, ont clarifié cette idée fausse. Ils ont fait remarquer que la disponibilité des données (DA) devrait en fait faire référence à la « publication de données », mais la plupart des gens ont interprété la DA comme une « récupérabilité des données historiques », ce qui implique en fait des problèmes de stockage des données.

Par exemple, il y a quelque temps, Dankrad a évoqué le mécanisme de retrait et d'évacuation obligatoires de la couche 2, en faisant remarquer que le retrait obligatoire de Validium nécessite l'obtention du dernier état L2 pour créer un Merkle Proof, alors que Plasma n'a besoin que des données datant de 7 jours auparavant (cela concerne ses méthodes pour déterminer une racine d'État légitime).

Dankrad a clairement fait remarquer que Validium exigeait que DA garantisse la sécurité des fonds des utilisateurs, mais pas Plasma. Ici, le cas d'utilisation de The Dankrad montre la différence entre la DA et la récupération de données historiques, à savoir que la DA n'implique souvent que des données récemment publiées.

À L2BEAT, la distinction entre la disponibilité des données (DA) et le stockage des données (DS) a été encore soulignée. Bartek de L2BEAT a souligné à plusieurs reprises que la DA et le stockage des données et la récupération des données historiques sont deux choses différentes, et que les utilisateurs peuvent accéder aux données L2 dont ils ont besoin uniquement parce que les nœuds qui fournissent des données sont « assez gentils avec vous ». En outre, L2BEAT prévoit d'utiliser « la disponibilité de nœuds de stockage de données autorisés » comme nouvel indicateur pour évaluer les cumuls, au-delà de DA.

Les déclarations des membres de la communauté Ethereum/de l'Ethereum Foundation montrent leur intention de clarifier et d'affiner les concepts liés à la couche 2 à l'avenir, ainsi que de fournir une définition plus détaillée de la couche 2 elle-même. Cela est dû au fait que de nombreux termes liés au Rollup et à la L2 n'ont pas été clairement expliqués, comme la mesure dans laquelle les données sont considérées comme « historiques ». Certains pensent que les contrats intelligents ne peuvent appeler que les données des 256 derniers blocs, les données datant d'avant 256 blocs (50 minutes) sont considérées comme « historiques ».

Cependant, le « Rollup » mentionné par Celestia et la Fondation Ethereum fait uniquement référence à deux choses différentes. Cet article vise à clarifier la différence entre le concept DA et le stockage des données, qu'il s'agisse de la source de la DA, de l'échantillonnage de la disponibilité des données, ou des méthodes de mise en œuvre de la DA dans les rollups, en expliquant ce que signifie réellement la disponibilité des données : la publication de données.

L'origine du concept DA

Le concept de DA trouve son origine dans la question de la « disponibilité des données », que Mustafa, fondateur de Celestia, explique comme suit : la DA consiste à s'assurer que toutes les données d'un bloc sont publiées sur le réseau lorsqu'un producteur de blocs propose un nouveau bloc. Si le producteur du bloc ne publie pas toutes les données du bloc, il est impossible de vérifier si le bloc contient des transactions erronées.

Mustafa souligne également qu'Ethereum Rollups publie simplement les données des blocs L2 sur la chaîne Ethereum et s'appuie sur l'ETH pour garantir la disponibilité des données. Sur le site officiel d'Ethereum, le problème de disponibilité des données se résume à la question suivante : « Comment vérifier si les données d'un nouveau bloc sont disponibles ? » Pour les clients légers, la question de la disponibilité des données fait référence à la vérification de la disponibilité d'un bloc sans avoir à télécharger la totalité du bloc.

Le site officiel d'Ethereum fait également une distinction claire entre la disponibilité et la récupérabilité des données : la disponibilité des données fait référence à la capacité des nœuds à télécharger des blocs de données lorsqu'ils sont proposés, en d'autres termes, elle est liée au délai avant qu'un bloc ne parvienne à un consensus. La récupérabilité des données fait référence à la capacité des nœuds à récupérer des informations historiques depuis la blockchain. Bien que l'archivage puisse nécessiter des données historiques sur la blockchain, les nœuds n'ont pas besoin d'utiliser ces données pour vérifier les blocs et traiter les transactions.

Selon le contributeur chinois de Celestia et partenaire de W3Hitchhiker, Ren Hongyi, Layer 2 suppose au préalable qu'Ethereum est suffisamment sécurisé et décentralisé. Les trieurs peuvent envoyer des données DA à Ethereum en toute confiance, et ces données seront propagées sans entrave à tous les nœuds complets d'Ethereum. Comme les nœuds complets de L2 gèrent eux-mêmes le client Geth, ils sont considérés comme un sous-ensemble des nœuds complets d'Ethereum et peuvent donc recevoir les données DA de la couche 2.

Aux yeux du Dr Qi Zhou, fondateur d'ETHStorage, la définition de la disponibilité des données (DA) est que personne ne peut refuser de communiquer les données de transaction soumises par les utilisateurs au réseau. Le modèle de confiance correspondant est que nous n'avons qu'à faire confiance au protocole de la couche 1 (L1) lui-même, sans avoir à introduire d'autres hypothèses de confiance.

Qi Zhou souligne que l'implémentation actuelle de DA dans Ethereum est essentiellement la diffusion P2P (en utilisant le protocole Gossip), où chaque nœud complet télécharge, propage de nouveaux blocs et stocke les données Rollup. Cependant, les nœuds complets d'Ethereum ne stockeront pas les blocs historiques pour toujours. Après la mise en œuvre de l'EIP-4844, il se peut qu'ils suppriment automatiquement les données datant d'il y a un certain temps (18 jours apparemment). Il n'existe pas beaucoup de nœuds d'archives qui stockent toutes les données historiques dans le monde. ETHStorage prévoit de combler cette lacune de l'écosystème Ethereum et d'aider Layer 2 à établir ses nœuds dédiés à la permanence des données.

Les premières discussions sur la disponibilité des données par la Fondation Ethereum sont visibles dans les tweets de Vitalik Buterin et les documents GitHub de 2017. À l'époque, il pensait que pour garantir l'évolutivité et l'efficacité de la blockchain, il était nécessaire d'améliorer la configuration matérielle des nœuds complets (les nœuds complets sont ceux qui téléchargent le bloc complet et vérifient sa validité, et les validateurs, qui participent au consensus, sont un sous-ensemble des nœuds complets). Cependant, l'augmentation de la configuration matérielle requise pour les nœuds complets augmenterait également les coûts opérationnels, ce qui conduirait à la centralisation de la blockchain.

À ce sujet, Vitalik a suggéré de concevoir un système pour faire face aux risques de sécurité liés à la tendance à la centralisation des nœuds complets à hautes performances. Il avait prévu d'introduire des codes d'effacement et un échantillonnage aléatoire des données afin de concevoir un protocole qui permettrait aux nœuds légers dotés de capacités matérielles réduites de vérifier qu'un bloc fonctionne sans problème sans connaître le bloc complet.

Son idée initiale était en fait liée à une idée mentionnée dans le livre blanc sur le Bitcoin, selon laquelle les nœuds lumineux n'ont pas besoin de recevoir le bloc complet mais qu'ils seront alertés par des nœuds complets honnêtes en cas de problème avec le bloc. Ce concept pourrait être étendu à des preuves de fraude ultérieures, mais cela ne garantit pas que les nœuds complets honnêtes puissent toujours obtenir suffisamment de données, pas plus qu'il ne permet de juger a posteriori si le proposant du bloc a refusé de publier certaines données.

Par exemple, un nœud A peut publier une preuve de fraude affirmant avoir reçu un bloc incomplet du nœud B. Cependant, il est impossible de déterminer si le bloc incomplet a été fabriqué par A ou envoyé par B. Vitalik a fait remarquer que ce problème pouvait être résolu par le biais du Data Availability Sampling (DAS), qui implique évidemment des problèmes de publication des données.

Vitalik a brièvement abordé ces problèmes et leurs solutions dans son article « A note on data availability and erasure coding ». Il a fait remarquer que les preuves DA (disponibilité des données) sont essentiellement un « complément » aux preuves de fraude.

Échantillonnage de la disponibilité des données

Cependant, le concept de DA n'est pas si facile à expliquer, comme en témoigne le document GitHub de Vitalik qui a fait l'objet de 18 corrections, la dernière datant du 25 septembre 2018. Juste la veille, le 24 septembre 2018, Mustafa, fondateur de Celestia, et Vitalik avaient co-écrit le célèbre article « Fraud and Data Availability Proofs : Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities ».

Il est intéressant de noter que Mustafa est répertorié comme le premier auteur de l'article, et non Vitalik (un autre auteur est aujourd'hui chercheur à la blockchain publique Sui). L'article évoque le concept des preuves de fraude et explique le principe de l'échantillonnage de la disponibilité des données (DAS), qui consiste à concevoir un protocole mixte de DAS, de codage d'effacement bidimensionnel et de preuves de fraude. Le journal indique spécifiquement que le système DA Proof est un complément nécessaire aux preuves de fraude.

Du point de vue de Vitalik, le protocole fonctionne comme suit :

Supposons qu'une blockchain publique possède N nœuds de consensus (validateurs) dotés d'un matériel de grande capacité, ce qui permet un débit de données et une efficacité élevés. Bien qu'une telle blockchain puisse avoir un TPS (transactions par seconde) élevé, le nombre de nœuds de consensus, N, est relativement faible, ce qui la rend plus centralisée avec une probabilité de collusion plus élevée entre les nœuds.

Cependant, on suppose qu'au moins l'un des N nœuds de consensus est honnête. Tant qu'au moins 1/N des validateurs sont honnêtes, capables de détecter et de diffuser des preuves de fraude lorsqu'un bloc n'est pas valide, les clients légers ou les validateurs honnêtes peuvent prendre conscience des problèmes de sécurité du réseau et utiliser des mécanismes tels que la suppression des nœuds malveillants et des forks de consensus social pour rétablir le fonctionnement normal du réseau.

Comme Vitalik l'a déjà mentionné, si un nœud complet et honnête reçoit un bloc et constate qu'il manque certaines parties, et publie une preuve de fraude, il est difficile de déterminer si le proposant du bloc n'a pas publié cette partie, si elle a été bloquée par d'autres nœuds pendant la transmission, ou s'il s'agit d'un faux drapeau de la part du nœud qui publie la preuve de fraude. De plus, si la majorité des nœuds conspirent, le validateur honnête 1/N risque d'être isolé, incapable de recevoir de nouveaux blocs, ce qui est un scénario d'attaque par rétention de données. Dans de tels cas, le nœud honnête ne peut pas déterminer si cela est dû à de mauvaises conditions du réseau ou à un complot délibéré de dissimulation commis par d'autres. Il ne peut pas non plus savoir si d'autres nœuds sont également isolés, ce qui rend difficile de déterminer si la majorité a conspiré en faveur de la rétention de données.

Il doit donc y avoir un moyen de s'assurer, avec une très forte probabilité, que les validateurs honnêtes puissent obtenir les données nécessaires pour valider les blocs ; et d'identifier qui est à l'origine d'une attaque de rétention de données, que ce soit le proposant du blocage qui n'a pas publié suffisamment de données, celles-ci n'ont pas été divulguées par d'autres nœuds ou s'il s'agit d'un complot majoritaire. De toute évidence, ce modèle de sécurité offre bien plus de protection que l' « hypothèse de majorité honnête » courante dans les chaînes PoS classiques, et l'échantillonnage de disponibilité des données (DAS) est la méthode de mise en œuvre spécifique.

En supposant qu'il y ait de nombreux nœuds lumineux sur le réseau, peut-être 10 fois N, chacun étant connecté à plusieurs validateurs (pour simplifier, supposons que chaque nœud d'éclairage est connecté aux N validateurs). Ces nœuds lumineux effectuaient de multiples échantillonnages de données à partir de validateurs, demandant à chaque fois une petite partie des données au hasard (supposons que cela ne représente que 1 % d'un bloc). Ensuite, ils transmettaient les fragments acquis aux validateurs dépourvus de ces données. Tant qu'il y a suffisamment de nœuds lumineux et que la fréquence d'échantillonnage des données est suffisamment élevée, même si certaines demandes sont refusées, tant que la plupart reçoivent une réponse, on peut garantir que tous les validateurs pourront éventuellement acquérir la quantité de données nécessaire pour valider un bloc. Cela peut annuler l'impact de la rétention de données par des nœuds autres que celui qui propose le bloc.

(Source de l'image : W3 Hitchhiker)

Si la majorité des validateurs conspirent et refusent de répondre à la plupart des demandes émanant de light nodes, les utilisateurs se rendront facilement compte qu'il y a un problème avec la chaîne (parce que même si certaines personnes ont une connexion Internet de mauvaise qualité, la plupart des demandes émanant de light nodes ne seront pas rejetées). Le stratagème susmentionné peut donc très probablement déterminer le comportement de la majorité en matière de complot, même si de telles situations sont rares en elles-mêmes. Grâce à cette approche, les incertitudes provenant de sources autres que le proposant du bloc peuvent être résolues. Si le proposant du bloc refuse de communiquer des données, par exemple s'il ne publie pas suffisamment de données dans le bloc pour le valider (après avoir introduit le codage d'effacement bidimensionnel), un bloc contient 2 000 fragments, et si la restauration des données d'origine du bloc nécessite au moins environ kk fragments, soit 1/4. Pour empêcher d'autres personnes de restaurer les données d'origine, le proposant devra ne pas divulguer au moins k+1*k+1 fragments). Ils seront finalement détectés par des validateurs honnêtes, qui diffuseront ensuite des preuves de fraude pour avertir les autres.

Selon Vitalik et Mustafa, ils ont essentiellement combiné des idées qui avaient déjà été proposées par d'autres et y ont ajouté leurs propres innovations. Si l'on considère le concept et la méthode de mise en œuvre dans leur ensemble, il est clair que la « disponibilité des données » fait référence à la question de savoir si les données nécessaires pour vérifier le dernier bloc ont été publiées par le proposant du bloc et si elles peuvent être reçues par les vérificateurs. Il s'agit de savoir si les données sont « entièrement publiées » plutôt que si « les données historiques peuvent être récupérées ».

Comment la disponibilité des données (DA) d'Ethereum Rollup est mise en œuvre

Sur la base de l'assertion ci-dessus, voyons comment la disponibilité des données (DA) est implémentée dans les rollups d'Ethereum, ce qui devient très clair : le proposant de blocs dans un rollup est connu sous le nom de Sequencer, qui publie les données nécessaires pour vérifier les transitions d'état de la couche 2 sur Ethereum à intervalles réguliers. Plus précisément, il initie une transaction dans le cadre d'un contrat spécifique, en insérant les données relatives à la DA dans les paramètres de saisie personnalisés, qui sont ensuite enregistrées dans un bloc Ethereum. Compte tenu du haut degré de décentralisation d'Ethereum, on peut être sûre que les données soumises par le séquenceur seront correctement reçues par les « vérificateurs ». Cependant, les entités jouant le rôle de « vérificateurs » diffèrent selon les réseaux Rollup.

Par exemple, dans le cas d'Arbitrum, le séquenceur publie des lots de transactions dans le cadre d'un certain contrat sur Ethereum. Le contrat lui-même ne vérifie pas ces données mais émet un événement que les nœuds complets de L2 peuvent écouter, leur indiquant que le séquenceur a publié un lot de transactions. Plus précisément, ZK Rollups utilise un contrat Verifier sur Ethereum comme « vérificateur ». Un ZK Rollup n'a besoin que de publier un State Diff + Validity Proof, c'est-à-dire des informations sur les changements d'état et une preuve de validité. Le contrat Verifier vérifie la preuve de validité pour voir s'il correspond au State Diff. Si la validation est réussie, le bloc/lot L2 publié par le séquenceur est considéré comme valide.

(Source : ancien livre blanc de Polygon Hermez)

Les rollups optimistes nécessitent de publier davantage de données sur Ethereum, car ils s'appuient uniquement sur des nœuds complets de niveau 2 pour télécharger les données et vérifier la validité des blocs. Cela signifie qu'au minimum, les signatures numériques de chaque transaction L2 (qui utilisent désormais couramment des signatures agrégées) doivent être divulguées. Si des appels contractuels sont passés, les paramètres de saisie doivent également être divulgués, en plus des adresses de transfert des transactions, des valeurs de nonce pour empêcher les attaques par rediffusion, etc. Cependant, par rapport aux données complètes des transactions, il y a encore quelques ajustements.

Par rapport aux ZK Rollups, le coût DA (disponibilité des données) des cumuls optimistes est plus élevé car les cumuls ZK ne doivent divulguer les changements d'état final qu'après l'exécution d'un lot de transactions, accompagnés d'une preuve de validité, en tirant parti de la concision de ZK SNARK/STARK ; alors que Optimistic Rollups ne peut utiliser que la méthode la plus complexe, qui exige que toutes les transactions soient réexécutées par d'autres nœuds complets de L2.

Auparavant, W3Hitchhiker avait estimé à peu près que, sans tenir compte des développements futurs de l'EIP-4844 et des blobs, l'effet d'échelle du ZKR (Zero-Knowledge Rollups) pourrait être plusieurs fois supérieur à celui de l'OPR (Optimistic Rollups). Si l'on considère les portefeuilles intelligents liés à l'EIP-4337 (qui utilisent les empreintes digitales, les données d'iris au lieu de signatures par clé privée), l'avantage du ZKR serait encore plus évident, car il n'a pas besoin de publier les données binaires des empreintes digitales et des iris sur Ethereum, alors que Optimistic Rollups le fait.

Quant à Validium et Plasma/Optimium, ils utilisent en fait la couche DA hors chaîne d'Ethereum pour atteindre le DA. Par exemple, ImmutableX, qui a adopté un système de preuve de validité, a mis en place un ensemble de nœuds DAC (Data Availability Committee) spécialement conçus pour publier des données relatives à la DA ; Metis publie les données DA sur Memlabs, et Rooch et Manta utilisent Celestia. Actuellement, grâce à l'existence de DAS (solutions de disponibilité des données) et de systèmes antifraude, Celestia est l'un des projets de couche DA les plus fiables en dehors d'Ethereum.

Avertissement：

1. Cet article est repris de [Geek Web3]. Faire suivre le titre original：Malentendus concernant la disponibilité des données : DA = Publication des données ≠ Recherche de données historiques, tous les droits d'auteur appartiennent à l'auteur original [ Faust, Geek web3]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.