Disponibilité des données

« Ne faites pas confiance, vérifiez » est une maxime courante sur Ethereum. L'idée est que votre nœud peut vérifier indépendamment que les informations qu'il reçoit sont correctes en exécutant toutes les transactions dans les blocs qu'il reçoit de ses pairs pour s'assurer que les changements proposés correspondent précisément à ceux calculés indépendamment par le nœud. Cela signifie que les nœuds n'ont pas à faire confiance à l'honnêteté des expéditeurs du bloc. Cela n'est pas possible s'il manque des données.

La disponibilité des données fait référence à la confiance qu'un utilisateur peut avoir dans le fait que les données requises pour vérifier un bloc sont réellement disponibles pour tous les participants du réseau. Pour les nœuds complets sur la couche 1 (l1) d'Ethereum, c'est relativement simple ; le nœud complet télécharge une copie de toutes les données de chaque bloc - les données doivent être disponibles pour que le téléchargement soit possible. Un bloc avec des données manquantes serait rejeté plutôt que d'être ajouté à la chaîne de blocs. Il s'agit de la « disponibilité des données onchain » et c'est une caractéristique des chaînes de blocs monolithiques. Les nœuds complets ne peuvent pas être trompés pour accepter des transactions invalides car ils téléchargent et exécutent chaque transaction par eux-mêmes. Cependant, pour les chaînes de blocs modulaires, les rollups de couche 2 (l2) et les clients légers, le paysage de la disponibilité des données est plus complexe, nécessitant des procédures de vérification plus sophistiquées.

Prérequis

Vous devriez avoir une bonne compréhension des fondamentaux de la chaîne de blocs, en particulier des mécanismes de consensus. Cette page suppose également que le lecteur est familier avec les blocs, les transactions, les nœuds, les solutions de mise à l'échelle et d'autres sujets pertinents.

Le problème de la disponibilité des données

Le problème de la disponibilité des données est la nécessité de prouver à l'ensemble du réseau que la forme résumée de certaines données de transaction ajoutées à la chaîne de blocs représente réellement un ensemble de transactions valides, mais de le faire sans exiger que tous les nœuds téléchargent toutes les données. Les données de transaction complètes sont nécessaires pour vérifier les blocs de manière indépendante, mais exiger que tous les nœuds téléchargent toutes les données de transaction est un obstacle à la mise à l'échelle. Les solutions au problème de la disponibilité des données visent à fournir des garanties suffisantes que les données de transaction complètes ont été rendues disponibles pour vérification aux participants du réseau qui ne téléchargent pas et ne stockent pas les données par eux-mêmes.

Les nœuds légers et les rollups de couche 2 (l2) sont des exemples importants de participants au réseau qui nécessitent de solides garanties de disponibilité des données mais ne peuvent pas télécharger et traiter les données de transaction par eux-mêmes. Éviter de télécharger les données de transaction est ce qui rend les nœuds légers légers et permet aux rollups d'être des solutions de mise à l'échelle efficaces.

La disponibilité des données est également une préoccupation majeure pour les futurs clients Ethereum « sans état » qui n'ont pas besoin de télécharger et de stocker les données d'état afin de vérifier les blocs. Les clients sans état doivent toujours être certains que les données sont disponibles quelque part et qu'elles ont été traitées correctement.

Solutions de disponibilité des données

Échantillonnage de la disponibilité des données (DAS)

L'échantillonnage de la disponibilité des données (DAS) est un moyen pour le réseau de vérifier que les données sont disponibles sans imposer une charge trop importante à un nœud individuel. Chaque nœud (y compris les nœuds ne faisant pas de staking) télécharge un petit sous-ensemble sélectionné au hasard des données totales. Le téléchargement réussi des échantillons confirme avec une grande confiance que toutes les données sont disponibles. Cela repose sur le codage d'effacement des données, qui étend un ensemble de données donné avec des informations redondantes (la façon dont cela est fait est d'ajuster une fonction connue sous le nom de polynôme sur les données et d'évaluer ce polynôme à des points supplémentaires). Cela permet de récupérer les données d'origine à partir des données redondantes lorsque cela est nécessaire. Une conséquence de cette création de données est que si une partie des données d'origine est indisponible, la moitié des données étendues sera manquante ! La quantité d'échantillons de données téléchargés par chaque nœud peut être ajustée de sorte qu'il soit extrêmement probable qu'au moins un des fragments de données échantillonnés par chaque client soit manquant si moins de la moitié des données est réellement disponible.

Le DAS sera utilisé pour s'assurer que les opérateurs de rollup rendent leurs données de transaction disponibles une fois que le danksharding complet aura été mis en œuvre. Les nœuds Ethereum échantillonneront de manière aléatoire les données de transaction fournies dans les blobs en utilisant le schéma de redondance expliqué ci-dessus pour s'assurer que toutes les données existent. La même technique pourrait également être employée pour s'assurer que les producteurs de blocs rendent toutes leurs données disponibles pour sécuriser les clients légers. De même, dans le cadre de la séparation proposant-constructeur (PBS), seul le constructeur de blocs serait tenu de traiter un bloc entier - les autres validateurs vérifieraient en utilisant l'échantillonnage de la disponibilité des données.

Comités de disponibilité des données

Les comités de disponibilité des données (DAC) sont des parties de confiance qui fournissent ou attestent de la disponibilité des données. Les DAC peuvent être utilisés à la place de, ou en combinaison avec (opens in a new tab) le DAS. Les garanties de sécurité qui accompagnent les comités dépendent de la configuration spécifique. Ethereum utilise des sous-ensembles de validateurs échantillonnés de manière aléatoire pour attester de la disponibilité des données pour les nœuds légers, par exemple.

Les DAC sont également utilisés par certains validiums. Le DAC est un ensemble de nœuds de confiance qui stocke des copies de données hors ligne. Le DAC est tenu de rendre les données disponibles en cas de litige. Les membres du DAC publient également des attestations onchain pour prouver que lesdites données sont bel et bien disponibles. Certains validiums remplacent les DAC par un système de validateur de preuve d'enjeu (PoS). Ici, n'importe qui peut devenir un validateur et stocker des données hors chaîne. Cependant, ils doivent fournir une « caution », qui est déposée dans un contrat intelligent. En cas de comportement malveillant, comme la rétention de données par le validateur, la caution peut subir une réduction. Les comités de disponibilité des données de preuve d'enjeu sont considérablement plus sûrs que les DAC réguliers car ils incitent directement à un comportement honnête.

Disponibilité des données et nœuds légers

Les nœuds légers doivent valider l'exactitude des en-têtes de bloc qu'ils reçoivent sans télécharger les données du bloc. Le coût de cette légèreté est l'incapacité de vérifier indépendamment les en-têtes de bloc en réexécutant les transactions localement de la même manière que le font les nœuds complets.

Les nœuds légers Ethereum font confiance à des ensembles aléatoires de 512 validateurs qui ont été assignés à un comité de synchronisation. Le comité de synchronisation agit comme un DAC qui signale aux clients légers que les données dans l'en-tête sont correctes en utilisant une signature cryptographique. Chaque jour, le comité de synchronisation est actualisé. Chaque en-tête de bloc alerte les nœuds légers sur les validateurs qui devraient signer le prochain bloc, de sorte qu'ils ne peuvent pas être trompés en faisant confiance à un groupe malveillant prétendant être le véritable comité de synchronisation.

Cependant, que se passe-t-il si un attaquant parvient d'une manière ou d'une autre à transmettre un en-tête de bloc malveillant aux clients légers et à les convaincre qu'il a été signé par un comité de synchronisation honnête ? Dans ce cas, l'attaquant pourrait inclure des transactions invalides et le client léger les accepterait aveuglément, car il ne vérifie pas indépendamment tous les changements d'état résumés dans l'en-tête de bloc. Pour se protéger contre cela, le client léger pourrait utiliser des preuves de fraude.

Le fonctionnement de ces preuves de fraude est qu'un nœud complet, voyant une transition d'état invalide se propager sur le réseau, pourrait rapidement générer un petit élément de données démontrant qu'une transition d'état proposée ne pourrait pas provenir d'un ensemble donné de transactions et diffuser ces données à ses pairs. Les nœuds légers pourraient récupérer ces preuves de fraude et les utiliser pour rejeter les mauvais en-têtes de bloc, s'assurant ainsi qu'ils restent sur la même chaîne honnête que les nœuds complets.

Cela repose sur le fait que les nœuds complets ont accès aux données de transaction complètes. Un attaquant qui diffuse un mauvais en-tête de bloc et qui ne parvient pas non plus à rendre les données de transaction disponibles serait en mesure d'empêcher les nœuds complets de générer des preuves de fraude. Les nœuds complets pourraient être en mesure de signaler un avertissement concernant un mauvais bloc, mais ils ne pourraient pas étayer leur avertissement avec des preuves, car les données n'ont pas été rendues disponibles pour générer la preuve !

La solution à ce problème de disponibilité des données est le DAS. Les nœuds légers téléchargent de très petits morceaux aléatoires des données d'état complètes et utilisent les échantillons pour vérifier que l'ensemble de données complet est disponible. La probabilité réelle de supposer à tort la disponibilité complète des données après avoir téléchargé N morceaux aléatoires peut être calculée (pour 100 morceaux, la probabilité est de 10^-30 (opens in a new tab), c'est-à-dire incroyablement improbable).

Même dans ce scénario, les attaques qui retiennent seulement quelques octets pourraient vraisemblablement passer inaperçues par les clients effectuant des requêtes de données aléatoires. Le codage d'effacement résout ce problème en reconstruisant de petits morceaux de données manquants qui peuvent être utilisés pour vérifier les changements d'état proposés. Une preuve de fraude pourrait alors être construite en utilisant les données reconstruites, empêchant les nœuds légers d'accepter de mauvais en-têtes.

Remarque : Le DAS et les preuves de fraude n'ont pas encore été mis en œuvre pour les clients légers Ethereum de preuve d'enjeu, mais ils sont sur la feuille de route, prenant très probablement la forme de preuves basées sur les ZK-SNARK. Les clients légers d'aujourd'hui s'appuient sur une forme de DAC : ils vérifient les identités du comité de synchronisation, puis font confiance aux en-têtes de bloc signés qu'ils reçoivent.

Disponibilité des données et rollups de couche 2

Les solutions de mise à l'échelle de couche 2 (l2), telles que les , réduisent les coûts de transaction et augmentent le débit d'Ethereum en traitant les transactions hors chaîne. Les transactions de rollup sont compressées et publiées sur Ethereum par lots. Les lots représentent des milliers de transactions individuelles hors chaîne en une seule transaction sur Ethereum. Cela réduit la congestion sur la couche de base et réduit les frais pour les utilisateurs.

Cependant, il n'est possible de faire confiance aux transactions « résumées » publiées sur Ethereum que si le changement d'état proposé peut être vérifié indépendamment et confirmé comme étant le résultat de l'application de toutes les transactions individuelles hors chaîne. Si les opérateurs de rollup ne rendent pas les données de transaction disponibles pour cette vérification, ils pourraient alors envoyer des données incorrectes à Ethereum.

Les rollups optimistes publient des données de transaction compressées sur Ethereum et attendent un certain temps (généralement 7 jours) pour permettre à des vérificateurs indépendants de vérifier les données. Si quelqu'un identifie un problème, il peut générer une preuve de fraude et l'utiliser pour contester le rollup. Cela entraînerait le retour en arrière de la chaîne et l'omission du bloc invalide. Cela n'est possible que si les données sont disponibles. Actuellement, il existe deux façons pour les rollups optimistes de publier des données de transaction sur la couche 1 (l1). Certains rollups rendent les données disponibles en permanence sous forme de CALLDATA qui vivent en permanence onchain. Avec la mise en œuvre de l'EIP-4844, certains rollups publient plutôt leurs données de transaction sur un stockage de blobs moins cher. Il ne s'agit pas d'un stockage permanent. Les vérificateurs indépendants doivent interroger les blobs et soulever leurs contestations dans un délai d'environ 18 jours avant que les données ne soient supprimées de la couche 1 d'Ethereum. La disponibilité des données n'est garantie par le protocole Ethereum que pour cette courte fenêtre fixe. Après cela, cela devient la responsabilité d'autres entités de l'écosystème Ethereum. N'importe quel nœud peut vérifier la disponibilité des données en utilisant le DAS, c'est-à-dire en téléchargeant de petits échantillons aléatoires des données du blob.

Les rollups à divulgation nulle de connaissance (ZK) n'ont pas besoin de publier de données de transaction puisque les garantissent l'exactitude des transitions d'état. Cependant, la disponibilité des données reste un problème car nous ne pouvons pas garantir la fonctionnalité du ZK-rollup (ou interagir avec lui) sans avoir accès à ses données d'état. Par exemple, les utilisateurs ne peuvent pas connaître leurs soldes si un opérateur retient des détails sur l'état du rollup. De plus, ils ne peuvent pas effectuer de mises à jour d'état en utilisant les informations contenues dans un bloc nouvellement ajouté.

Disponibilité des données vs récupérabilité des données

La disponibilité des données est différente de la récupérabilité des données. La disponibilité des données est l'assurance que les nœuds complets ont pu accéder et vérifier l'ensemble complet des transactions associées à un bloc spécifique. Il ne s'ensuit pas nécessairement que les données sont accessibles pour toujours.

La récupérabilité des données est la capacité des nœuds à récupérer des informations historiques de la chaîne de blocs. Ces données historiques ne sont pas nécessaires pour vérifier de nouveaux blocs, elles ne sont requises que pour la synchronisation des nœuds complets à partir du bloc genèse ou pour répondre à des requêtes historiques spécifiques.

Le protocole Ethereum de base est principalement concerné par la disponibilité des données, et non par la récupérabilité des données. La récupérabilité des données peut être fournie par une petite population de nœuds d'archive gérés par des tiers, ou elle peut être distribuée sur le réseau en utilisant un stockage de fichiers décentralisé tel que le Portal Network (opens in a new tab).