Disponibilité des données

« Ne pas faire confiance, vérifier » est une maxime courante dans Ethereum. L'idée est que votre nœud peut vérifier de façon indépendante 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 exactement à ceux calculés indépendamment par le noeud. Cela signifie que les nœuds n'ont pas à croire que les expéditeurs du bloc sont honnêtes. Ce n'est pas possible si les données sont manquantes.

La disponibilité des données fait référence à la confiance qu'un utilisateur peut avoir dans le fait que les données nécessaires à la vérification d'un bloc sont réellement disponibles pour tous les participants du réseau. Pour les nœuds complets sur la couche 1 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 jeté plutôt que d'être ajouté à la blockchain. Il s'agit de la « disponibilité des données sur la chaîne » et c'est une caractéristique des blockchains monolithiques. Les nœuds complets ne peuvent pas être amenés à accepter des transactions invalides car ils téléchargent et exécutent chaque transaction pour eux-mêmes. Cependant, pour les blockchains modulaires, les rollups de la couche 2 et les clients légers, le paysage de disponibilité des données est plus complexe, nécessitant des procédures de vérification plus sophistiquées.

Prérequis

Vous devez avoir une bonne compréhension des principes fondamentaux de la blockchain, 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 qui sont ajoutées à la blockchain représente vraiment un ensemble de transactions valides, mais sans obliger tous les nœuds à télécharger toutes les données. Les données de transaction complètes sont nécessaires pour la vérification indépendante des blocs, 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 suffisamment d'assurance que toutes les données de transaction ont été mises à la disposition des participants du réseau qui ne téléchargent pas et ne stockent pas les données pour eux-mêmes.

Les nœuds légers et les rollups de couche 2 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. Une opération de téléchargement des données de transaction non effectuée, c'est ce qui rend les light nodes légers, et permet à la fois aux rollups de se présenter en tant que véritables solutions pour résoudre les problèmes de scalabilité.

La disponibilité des données est également une préoccupation essentielle pour les futurs clients Ethereum « sans état » qui n'ont pas besoin de télécharger et de stocker les données d'état pour 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 mettre trop de pression sur un nœud individuel. Chaque nœud (y compris les nœuds non jalonnés) 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 à effacement de données, qui étend un ensemble de données donné avec des informations redondantes (pour ce faire, on ajuste une fonction connue sous le nom de polynôme sur les données et on évalue ce polynôme en des points supplémentaires). Les données originales peuvent ainsi être recouvertes, si nécessaire, sur un ensemble de données redondantes. Une conséquence de cette création de données est que si une partie des données originales n'est pas disponible, 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 après la mise en œuvre du Danksharding complet. Les nœuds Ethereum procéderont à un échantillonnage aléatoire des 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 mettent toutes leurs données à la disposition de la sécurisation des clients légers. De même, dans le cadre de la séparation proposant-constructeur, seul le constructeur de bloc serait tenu de traiter un bloc entier - les autres validateurs effectueraient une vérification en utilisant l'échantillonnage de disponibilité des données.

Comités de disponibilité des données

Les comités de disponibilité des données (DAC) sont des tiers de confiance qui fournissent ou attestent de la disponibilité des données. Les DAC peuvent être utilisés à la place du DAS, ou en combinaison avec celui-ci (opens in a new tab). Les garanties données par les comités en matière de sécurité, relèvent de leur mise en place spécifique. Ethereum utilise des échantillons aléatoires de sous-ensembles de validateurs 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 noeuds de confiance qui stocke des copies de données hors ligne. Le DAC est nécessaire pour la mise à disposition des données en cas de litige. Les membres de la DAC publient également des attestations en chaîne pour prouver que les données en question sont effectivement disponibles. Certains Validiums remplacent les DAC par un système de validation par preuve d'enjeu (PoS). Ici, tout le monde peut devenir un validateur et stocker des données hors chaîne. Cependant, ils doivent fournir une « obligation », qui est déposée dans un contrat intelligent. En cas d'intention malveillante, telle que la retenue des données du validateur, cet accord pourrait être résilié. Les comités de disponibilité des données basée sur la preuve d'enjeu sont bien plus sécuritaires que les DAC régulières, car ils encouragent directement les comportements honnêtes.

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é à vérifier indépendamment les en-têtes de bloc en réexécutant les transactions localement à la manière des nœuds complets.

Les nœuds légers d'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 une DAC qui signale aux clients légers que les données dans l'en-tête sont correctes en utilisant une signature cryptographique. Le comité de synchronisation effectue des rafraîchissements journaliers des données. Chaque en-tête de bloc informe les nœuds légers des validateurs qui devraient signer le bloc suivant, afin qu'ils ne puissent pas être amenés à faire confiance à un groupe malveillant se faisant passer pour 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 à des 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 du bloc. Pour se prémunir contre cela, le client léger pourrait utiliser des preuves de fraude.

La façon dont ces preuves de fraude fonctionnent est qu'un nœud complet, voyant une transition d'état invalide faire l'objet de commérages dans le réseau, pourrait rapidement générer une petite partie 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 aux pairs. Les nœuds légers pourraient récupérer ces preuves de fraude et les utiliser pour éliminer les en-têtes de bloc défectueux, en s'assurant d'un maintien sur la même chaîne honnête que les nœuds complets.

Cela repose sur des nœuds complets ayant accès à des données de transaction complètes. Un attaquant qui diffuse un mauvais en-tête de bloc et 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 la présence d'un bloc défectueux, mais ils ne pourraient pas assurer la mise en place de leur avertissement avec une preuve, du fait de l'absence de disponibilité des données pour générer la preuve !

DAS : la solution au problème de disponibilité des données. 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 une disponibilité totale des données après le téléchargement de 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 auprès des clients effectuant des demandes de données aléatoires. Le code d'effacement corrige cela en reconstruisant de petites parties de données manquantes qui peuvent être utilisées 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.

Note : Le DAS et les preuves de fraude n'ont pas encore été implémentés pour les clients légers Ethereum à preuve d'enjeu, mais ils figurent sur la feuille de route, et prendront 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 et font ensuite confiance aux en-têtes de blocs signés qu'ils reçoivent.

Disponibilité des données et rollups de couche 2

Les solutions de mise à l'échelle de couche 2, 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 par lots sur Ethereum. Les lots représentent des milliers de transactions individuelles hors chaîne en une seule transaction sur Ethereum. Cela réduit la congestion de 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 disponibles les données de transaction pour cette vérification, ils pourraient 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 contrôler les données. Si quelqu'un identifie un problème, il peut générer une étanchéité à la fraude et l'utiliser pour défier le rollup. Cela provoquerait l'annulation de la chaîne et l'omission du bloc invalide. Ce n'est pas possible si les données sont manquantes. Actuellement, il existe deux façons pour les rollups optimistes de publier les données de transaction sur la couche de niveau 1. Certains rollups rendent les données disponibles en permanence en tant que CALLDATA qui reste en permanence sur la chaîne. Avec l'introduction de l'EIP-4844, certains rollups publient plutôt leurs données de transaction dans un stockage blob moins coûteux. Il ne s'agit pas d'un stockage permanent. Les vérificateurs indépendants doivent interroger les blobs et soulever leurs objections dans un délai d'environ 18 jours avant que les données ne soient supprimées de la couche de niveau 1 d'Ethereum. La disponibilité des données n'est garantie que par le protocole Ethereum pour cette courte fenêtre fixe. Ensuite, cela incombe à 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 blob.

Les rollups à preuve à divulgation nulle de connaissance (ZK) n'ont pas besoin de publier des données de transaction, car les garantissent l'exactitude des transitions d'état. Cependant, la disponibilité des données reste un problème parce que nous ne pouvons pas garantir la fonctionnalité du ZK-rollup (ou interagir avec elle) sans 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 des informations contenues dans un bloc nouvellement ajouté.

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

Disponibilité des données par rapport à la récupération des données. La disponibilité des données est l'assurance que des nœuds complets ont été en mesure de vérifier l'ensemble des transactions associées à un bloc spécifique et d'y accéder. 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 blockchain. Ces données historiques ne sont pas nécessaires pour vérifier de nouveaux blocs, elles sont seulement requises pour synchroniser des nœuds complets à partir du bloc d'origine 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ération des données. La récupérabilité des données peut être assurée par un petit nombre de nœuds d'archive gérés par des tiers, ou elle peut être répartie sur le réseau à l'aide d'un stockage de fichiers décentralisé tel que le Réseau Portal (opens in a new tab).