Malentendu sur la disponibilité des données : DA = publication des données ≠ récupération des données historiques

Introduction : Qu'est-ce que la disponibilité des données exactement ? **Peut-être que la première impression de la plupart des gens est que « des données historiques à un certain moment peuvent être obtenues », mais c'est en fait le plus grand malentendu du concept de DA. **Récemment, L2BEAT Lianchuang, le proposant de Danksharding, et le fondateur de Celestia ont clarifié ce malentendu. Ils ont souligné que La disponibilité des données devrait en fait faire référence à la « publication des données », mais la plupart des gens comprennent DA comme des « données historiques ». peuvent être récupérés", et cette dernière implique en réalité des problèmes de stockage des données.

Par exemple, Dankrad a mentionné il y a quelque temps le mécanisme de retrait/évacuation forcé de la couche 2. Il a souligné que le retrait forcé de Validium doit obtenir le dernier état L2 pour construire Merkle Proof, mais que Plasma n'a besoin que du dernier état L2 d'il y a 7 jours (ce est différent des deux. Il est lié à la méthode de détermination de la Stateroot légale de l'utilisateur).

Avec cela, Dankrad a clairement souligné que Validium exige que DA assure la sécurité des fonds des utilisateurs, mais pas Plasma. Ici, le cas d'utilisation de Dankrad souligne la différence entre l'AD et la récupération de données historiques, à savoir que l'AD a tendance à n'impliquer que des données nouvellement publiées. **

Dans L2BEAT, la différence entre la disponibilité des données DA et le stockage des données DS est encore renforcée. Bartek de L2BEAT a souligné à plusieurs reprises que l'AD et le stockage de données/données historiques sont deux choses différentes, et que les utilisateurs peuvent obtenir les données L2 dont ils ont besoin uniquement parce que les nœuds qui fournissent les données sont « assez bons pour vous ». En outre, L2BEAT prévoit également d'utiliser « l'existence de nœuds de stockage de données avec des autorisations ouvertes » comme nouvel indicateur pour évaluer le Rollup en plus du DA.

Les remarques ci-dessus des membres de la communauté Ethereum/Fondation Ethereum indiquent qu'ils normaliseront les concepts liés à la couche 2 à l'avenir et fourniront une définition plus détaillée de la couche 2 elle-même. Parce que de nombreux termes entourant Rollup et L2 ne sont en fait pas bien expliqués, comme par exemple depuis combien de temps les données sont considérées comme des « données historiques » - certaines personnes pensent que parce que les contrats intelligents ne peuvent appeler les données de bloc passées que dans 256 blocs, par conséquent, les données 256 blocs ( 50 minutes) sont considérées comme des « données historiques ».

À proprement parler, le « Rollup » évoqué par Celestia et la Fondation Ethereum sont deux choses différentes. Cet article vise à clarifier la différence entre le concept de DA et le stockage de données. À partir de la source de DA, de l'échantillonnage de la disponibilité des données et de l'implémentation de DA de Rollup, nous vous expliquerons ce qu'est la disponibilité des données - la publication des données. **

Source du concept DA

Concernant ce à quoi fait référence le problème de « disponibilité des données », **Le fondateur de Celestia, Mustafa, a expliqué ceci : **DA est, lorsque le générateur de blocs propose un nouveau bloc, comment s'assurer que toutes les données du bloc sont libérées sur le réseau ? Si le générateur de blocs ne libère pas toutes les données du bloc, il ne peut pas détecter si le bloc contient des transactions incorrectes.

Mustafa a également souligné qu'Ethereum Rollup publie simplement des données de bloc L2 sur la chaîne Ethereum et s'appuie sur ETH pour garantir la disponibilité des données.

**Sur le site officiel d'Ethereum, il y a le résumé suivant sur DA : **Le problème de disponibilité des données peut être résumé par une question : "Comment vérifier si les données d'un nouveau bloc sont disponibles ?"... Pour la lumière clients En général, le problème de disponibilité des données fait référence à la vérification de la disponibilité d'un bloc sans télécharger l'intégralité du bloc.

**Le site officiel d'Ethereum distingue également clairement la différence entre la disponibilité et la récupération des données : **La disponibilité des données fait référence à la capacité du nœud à télécharger des données de bloc lorsqu'un bloc est proposé. En d'autres termes, la disponibilité des données est pertinente lorsqu'un bloc n'a pas encore atteint un consensus... La récupération de données fait référence à la capacité d'un nœud à récupérer des informations historiques de la blockchain... bien que l'archivage puisse nécessiter une blockchain. Données historiques, mais les nœuds peuvent valider les blocs. et traiter les transactions sans utiliser de données historiques.

**De l'avis de Ren Hongyi, contributeur de Celestia Chine et partenaire de W3Hitchhiker, **Layer2 suppose à l'avance qu'Ethereum est suffisamment sécurisé et décentralisé, et que le séquenceur peut envoyer en toute sécurité et audacieusement des données DA à Ethereum, et que ces données se propageront sans entrave. À tous les nœuds complets Ethereum. Le nœud complet L2 lui-même doit exécuter le client Geth, qui est un sous-ensemble du nœud complet Ethereum, afin qu'il puisse recevoir des données DA de couche 2.

** Aux yeux du Dr Qi Zhou, fondateur d'EthStorage, la définition de DA est que personne ne peut conserver les données de transaction soumises par les utilisateurs au réseau. Le modèle de confiance correspondant est que nous devons uniquement faire confiance au protocole L1 lui-même et n'avons pas besoin d'introduire d'autres hypothèses de confiance.

Qi Zhou a souligné que la méthode actuelle de mise en œuvre DA d'Ethereum est en fait la diffusion P2P (protocole gossip).Chaque nœud complet téléchargera et propagera de nouveaux blocs et stockera les données Rollup. Bien entendu, les nœuds complets Ethereum ne stockeront pas de manière permanente les blocs historiques et pourront supprimer automatiquement les données pendant un certain temps (il semble que ce soit 18 jours) après la mise en ligne de 4844. **Il n'y a pas beaucoup de nœuds d'archives dans le monde qui stockent toutes les données historiques. **EthStorage a l'intention de combler cette lacune dans le système Ethereum et d'aider la couche 2 à mettre en place son propre nœud exclusif de persistance des données.

Les premières discussions de la Fondation Ethereum sur la disponibilité des données peuvent être trouvées dans les tweets et les documents github de Vitalik en 2017. À cette époque, il pensait que si nous voulons garantir l'évolutivité/la haute efficacité de la blockchain, nous devons améliorer la configuration matérielle du nœud complet (un nœud complet est un nœud qui télécharge un bloc complet et vérifie sa validité, et le validateur qui fait le consensus est un sous-ensemble du nœud complet). Cependant, si la configuration matérielle du nœud complet est améliorée, les coûts d’exploitation augmenteront, ce qui entraînera une centralisation de la blockchain.

Sur ce point**, Vitalik a déclaré qu'une solution peut être conçue pour résoudre les risques de sécurité causés par la centralisation de nœuds complets hautes performances. ** Il prévoit d'introduire le codage d'effacement et l'échantillonnage aléatoire des données pour concevoir un protocole permettant aux nœuds légers dotés de matériel bas de gamme de savoir qu'il n'y a aucun problème avec le bloc même s'ils ne connaissent pas le bloc complet.

Sa pensée initiale était en fait liée à l’idée mentionnée dans le livre blanc Bitcoin. Cette idée dit que les nœuds légers n'ont pas besoin de recevoir le bloc complet, et lorsqu'il y a un problème avec le bloc, le nœud complet honnête émettra une « alarme » pour avertir le nœud léger. Cette idée peut être étendue aux preuves de fraude ultérieures, mais rien ne garantit que des nœuds complets honnêtes puissent toujours obtenir suffisamment de données, et il ne peut pas non plus être jugé a posteriori si le proposant du bloc a retenu certaines données et ne les a pas divulguées.

Par exemple, un certain nœud A peut émettre un certificat de fraude prétendant avoir reçu un bloc incomplet du nœud B. Mais à l’heure actuelle, il est impossible de juger si ce bloc incomplet a été forgé par A lui-même ou envoyé par B. Vitalik a souligné que ce problème peut être résolu grâce à l'échantillonnage de la disponibilité des données DAS (évidemment, la disponibilité des données implique essentiellement des problèmes de publication des données).

Vitalik propose une discussion rapide de ces problèmes et de leurs solutions dans "Une note sur la disponibilité des données et le codage d'effacement". **Il a souligné que le certificat DA est essentiellement un « complément » du certificat de fraude. **

Échantillonnage de la disponibilité des données

Mais évidemment, le concept DA n'est pas si simple à expliquer, car le document github de Vitalik a été corrigé 18 fois. Les dossiers montrent que la dernière correction a été soumise le 25 septembre 2018. Juste la veille, le 24 septembre 2018, Les fondateurs de Celestia, Mustafa et Vitalik, ont publié conjointement un article qui deviendra célèbre à l'avenir——Preuves de fraude et de disponibilité des données : Maximiser la sécurité des clients légers et faire évoluer les blockchains avec des majorités malhonnêtes

Il est intéressant de noter que le premier auteur de cet article est Mustafa plutôt que Vitalik (l'autre auteur est maintenant chercheur à Sui Public Chain). L'article mentionnait le concept de preuve de fraude, expliquait le principe de l'échantillonnage de la disponibilité des données DAS et concevait grossièrement un protocole mashup de DAS + codage d'effacement bidimensionnel + preuve de fraude. **Le document mentionne clairement que le système de preuve DA est essentiellement un complément nécessaire à la preuve de fraude. **

Si l'on part du point de vue de Vitalik, le rôle de ce protocole peut se résumer ainsi :

Supposons qu'une chaîne publique dispose de N validateurs de nœuds de consensus dotés d'un matériel haut de gamme. Leur débit de données est important et leur efficacité est très élevée. Bien qu'une telle blockchain ait un TPS élevé, le nombre de nœuds de consensus N est relativement petit, il est relativement centralisé et la probabilité de collusion de nœuds est élevée.

Cependant, au moins un des N nœuds de consensus sera honnête. **Tant qu'au moins les validateurs 1/N sont honnêtes, **vérifiez que le bloc n'est pas valide et sont prêts à diffuser une preuve de fraude si nécessaire, les nœuds légers ou les validateurs honnêtes peuvent savoir qu'il y a un problème de sécurité dans le réseau , et peut utiliser des nœuds malveillants Slash et un consensus social sur Forks et d'autres méthodes sont utilisées pour restaurer le réseau à la normale.

Cependant, comme Vitalik l'a mentionné précédemment, si un nœud complet honnête reçoit un bloc et constate qu'il lui manque certaines parties et publie un certificat de fraude, il est difficile de déterminer si le proposant du bloc n'a pas publié cette partie des données ou a été bloqué. À mi-chemin, d'autres nœuds l'ont refusé ou le nœud qui a émis le certificat de fraude a agi de sa propre initiative.

De plus, si la plupart des nœuds s'entendent, les validateurs honnêtes 1/N seront isolés et pourraient ne pas être en mesure d'obtenir de nouveaux blocs. Ceci est considéré comme un scénario d'attaque par rétention de données. Il convient de noter qu'à l'heure actuelle, le nœud honnête ne sait pas si l'état du réseau est mauvais ou si d'autres personnes ont conspiré pour dissimuler des données. Il ne sait pas non plus si d'autres nœuds sont également isolés et il est difficile de juger si le nœud est honnête. la majorité des gens ont conspiré pour dissimuler des données.

En résumé, il doit y avoir un moyen de garantir que le validateur honnête puisse obtenir les données nécessaires à la vérification du bloc avec une très forte probabilité ; en même temps, il doit être possible de déterminer qui est impliqué dans des attaques de rétention de données** - c'est le proposant du bloc qui n'a pas publié. S'il y a suffisamment de données, on dit toujours qu'elles sont retenues par d'autres nœuds, ou que la plupart des nœuds sont de connivence. De toute évidence, ce modèle de sécurité offre bien plus de garanties que « l'hypothèse majoritaire honnête » des chaînes de points de vente ordinaires, et l'échantillonnage de disponibilité des données DAS est la méthode de mise en œuvre spécifique.

Nous supposons maintenant qu'il existe de nombreux nœuds lumineux dans le réseau, peut-être 10 N, et que chaque nœud lumineux est connecté à plusieurs validateurs** (pour faciliter l'analyse, il est supposé que chaque nœud lumineux est connecté à tous les N validateurs). Ces nœuds légers lanceront plusieurs fois un échantillonnage de données vers le validateur, demandant à chaque fois de manière aléatoire une petite partie des données (en supposant qu'elles ne représentent que 1 % d'un bloc). Par la suite, ils propageront les fragments extraits aux Validateurs qui ne disposent pas de ces données. Tant qu'il y a suffisamment de nœuds légers et que les temps d'échantillonnage des données sont suffisamment fréquents, même si certaines demandes peuvent être rejetées, tant que la plupart d'entre elles reçoivent une réponse, il peut être garanti que tous les validateurs finiront par obtenir suffisamment de nœuds légers. données nécessaires à la vérification du bloc. . Cela peut compenser l'impact des données retenues par des nœuds autres que le proposant du bloc. **

(Source de l'image : W3 Auto-stoppeur)

Et si la plupart des Validateurs s'entendent et refusent de répondre aux requêtes de la plupart des nœuds légers, les gens se rendront facilement compte qu'il y a un problème avec la chaîne (car même si la vitesse du réseau de certaines personnes n'est pas bonne, elle ne sera pas aussi mauvaise que les requêtes). de la plupart des nœuds légers) ont été rejetés). Par conséquent, le système susmentionné peut détecter la plupart des comportements collusoires avec une très forte probabilité, même si, bien entendu, cette situation elle-même se produit rarement.

À ce stade, nous pouvons résoudre les incertitudes provenant de l’extérieur du proposant du bloc. **Si le proposant du bloc s'engage dans la rétention de données, *par exemple, il ne publie pas suffisamment de données nécessaires pour vérifier le bloc dans le bloc (après l'introduction du codage d'effacement bidimensionnel, un bloc contient 2k*2k fragments, et La récupération des données originales du bloc nécessite au moins environ k*k fragments, soit 1/4. Le proposant souhaite que les autres soient incapables de restaurer les données originales, et au moins k+1*k+1 fragments ont besoin à retenir), *Il sera éventuellement détecté par un validateur honnête, qui diffusera la preuve de la fraude pour avertir les autres *****ers. **

Selon Vitalik et Mustafa, ils ont en fait combiné des idées qui avaient été proposées auparavant et ont ajouté certaines innovations. Du point de vue du point de départ et de la mise en œuvre de l'ensemble du concept, il est évident que ce que l'on appelle la « disponibilité des données » se réfère à la question de savoir si les données nécessaires à la vérification du dernier bloc ont été publiées par le proposant du bloc et peuvent être vérifiées par le vérificateur Nous recevons. **Il s'agit de « si les données sont entièrement publiées » plutôt que de « si les données historiques peuvent être récupérées ».

Comment implémenter le DA d'Ethereum Rollup

Avec la conclusion précédente, regardons l'implémentation DA d'Ethereum Rollup. Elle est en fait relativement claire : **Le proposant du bloc dans Rollup est le séquenceur, qui émettra des vérifications sur Ethereum de temps en temps. . **Pour être précis, il s'agit d'initier une transaction sur le contrat spécifié, d'insérer les données impliquées dans DA dans les paramètres d'entrée personnalisés et enfin d'être enregistrées dans le bloc Ethereum. Étant donné qu'Ethereum est suffisamment décentralisé, vous pouvez être sûr que les données soumises par le séquenceur seront reçues avec succès par le « validateur ». Mais ce qui joue le rôle de « vérificateur » dans les différents réseaux Rollup est différent.

*(Le séquenceur Arbitrum publie des lots de transactions sur un contrat sur Ethereum. Le contrat lui-même ne vérifie pas ces données, mais lance uniquement un événement que le nœud complet L2 peut écouter, indiquant à ce dernier que le séquenceur a publié le lot de transactions. ) *

Plus précisément, ZK Rollup utilise le contrat Verifier sur Ethereum pour agir en tant que « vérificateur ». **ZKR n'a besoin que de publier au moins State Diff + Validity Proof, **c'est-à-dire les changements d'état + la preuve de validité. Le contrat du vérificateur détectera la preuve de validité pour déterminer si elle peut correspondre au State Diff. Après avoir réussi la vérification, le bloc/lot L2 émis par le séquenceur est considéré comme valide.

(Source : ancien livre blanc de Polygon Hermez)

Le Rollup le plus optimiste publiera plus de données sur Ethereum, car il ne peut s'appuyer que sur les nœuds complets L2 pour télécharger les données et vérifier la validité du bloc. **Dans ce cas, au moins la signature numérique de chaque transaction L2 doit être divulguée (les signatures agrégées sont généralement utilisées désormais), et si un contrat est appelé, les paramètres d'entrée doivent être divulgués. De plus, l'adresse de transfert de la transaction et le La valeur occasionnelle pour empêcher les attaques par relecture doit être divulguée. Mais par rapport aux données complètes des transactions, il y a encore quelques élagages.

**Par rapport à ZK Rollup, le coût DA du Rollup optimiste est plus élevé, **car ZK Rollup n'a besoin de divulguer les changements d'état final qu'après l'exécution d'un lot de transactions et est livré avec un certificat de validité, profitant de la simplicité de ZK SNARK/STARK ; Optimistic Rollup ne peut utiliser que la méthode la plus lourde, permettant à toutes les transactions d'être réexécutées sur d'autres nœuds complets L2.

W3hitchhiker a précédemment estimé approximativement que sans prendre en compte les futurs 4844 et blobs, l'effet d'expansion de ZKR peut atteindre plusieurs fois celui de l'OPR, et si en considérant 4337 portefeuilles intelligents associés (en remplaçant les signatures de clé privée par des données d'empreintes digitales et d'iris), ZKR's les avantages seront plus évidents, car il n'est pas nécessaire de publier les données binaires des empreintes digitales et de l'iris sur Ethereum, contrairement à Optimistic Rollup).

Quant à Validium et Plasma/Optimium, ils utilisent en fait la couche DA sous la chaîne Ethereum pour implémenter DA. Par exemple, ImmutableX, qui utilise un système de preuve de validité, a construit un ensemble de nœuds DAC (Data Availability Committee) pour publier des données liées à DA ; Metis publie des données DA sur Memlabs, et Rooch et Manta utilisent Celestia. À l'heure actuelle, il semble qu'en raison de l'existence du DAS et du système anti-fraude, **Celestia soit l'un des projets de couche DA les plus crédibles en dehors d'Ethereum. **

les références

5