Le data availability sampling (DAS) est une technique par laquelle des nœuds légers vérifient que les données d'un bloc ont bien été publiées en ne téléchargeant qu'une poignée de fragments choisis au hasard, puis en s'appuyant sur les statistiques pour rendre la disparition de données extrêmement improbable. C'est l'idée centrale de mise à l'échelle derrière la feuille de route PeerDAS d'Ethereum et la couche de données de Celestia, et c'est ce qui permet aux blockchains d'augmenter la taille des blocs en toute sécurité sans obliger chaque utilisateur à tout télécharger.
Points clés
- Le DAS résout le problème de disponibilité des données en permettant aux clients légers de confirmer des blocs complets à partir d'échantillons minuscules et aléatoires, plutôt que de téléchargements entiers.
- Le codage par effacement, le plus souvent Reed-Solomon, gonfle les données pour que n'importe quel fragment puisse être reconstruit à partir d'un nombre suffisant de pairs, transformant une donnée manquante isolée en un non-événement statistique.
- Le PeerDAS d'Ethereum étend cette idée en répartissant les données sur un maillage pair-à-pair, de sorte que chaque nœud ne détienne qu'une fraction de l'espace total consacré aux blobs.
- La garantie probabiliste est ce qui rend le DAS sûr à grande échelle, mais elle signifie aussi que les clients légers parient sur les mathématiques, et non sur la certitude, ce qui est le compromis essentiel à comprendre.
Pourquoi les blockchains se heurtent à un mur à grande échelle
Chaque blockchain cache un goulot d'étranglement qui n'a rien à voir avec les transactions par seconde. Avant qu'un bloc puisse être considéré comme fiable, chaque nœud soucieux de sécurité doit s'assurer que les données qu'il contient existent bel et bien et sont téléchargeables. Si un producteur de blocs ne publie que l'en-tête du bloc et cache les transactions sous-jacentes, personne ne peut vérifier la chaîne, et un proposant malveillant pourrait en théorie voler des fonds ou réécrire l'historique.
Pendant la majeure partie de l'histoire de la crypto, la règle était simple : pour vérifier la chaîne, on téléchargeait la chaîne. Les utilisateurs de Bitcoin et des débuts d'Ethereum faisaient tourner des nœuds complets qui traitaient chaque octet. Cela fonctionnait à petite échelle, mais à mesure que la taille des blocs augmentait pour accueillir plus d'utilisateurs, le coût d'exploitation d'un nœud est passé à des centaines de gigaoctets, puis à des téraoctets d'espace disque et de bande passante. La décentralisation s'est érodée en silence, car seuls les opérateurs bien dotés pouvaient suivre le rythme.
Le problème de disponibilité des données est le nom formel de cette tension. Une blockchain doit publier suffisamment de données pour que n'importe qui puisse la vérifier, mais en publier trop exclut les utilisateurs ordinaires de la vérification. Les solutions de mise à l'échelle comme les rollups aggravent le problème au lieu de le résoudre, car elles renvoient des données de transaction compressées vers une chaîne parente. Plus de rollups, plus de données, et soudain la chaîne parente étouffe sous le poids de son propre succès.
C'est le mur que le DAS est conçu pour briser. L'objectif n'est pas de faire en sorte que chaque nœud télécharge moins de données au sens trivial de la compression des transactions. L'objectif est de rendre la vérification suffisamment peu coûteuse pour que des clients légers, la catégorie des portefeuilles sur un ordinateur portable, puissent confirmer des blocs volumineux en toute confiance, tout en permettant au réseau dans son ensemble d'atteindre des dizaines de milliers de transactions par seconde.
Ce que les clients légers pouvaient et ne pouvaient pas faire avant le DAS
Avant l'invention de l'échantillonnage, les clients légers menaient une existence précaire. Un client léger est un nœud qui ne télécharge pas la chaîne complète, mais qui se contente de vérifier les en-têtes de blocs et de demander à des nœuds complets des preuves concernant des transactions spécifiques. Les portefeuilles mobiles, les extensions de navigateur et les appareils embarqués se comportent en pratique comme des clients légers.
Le piège, c'est qu'on peut mentir à un client léger. Un petit ensemble de nœuds complets peut lui fournir un en-tête qui semble valide et des preuves qui paraissent correctes, alors que les données du bloc sont en réalité retenues à l'écart du reste du réseau. Le client léger n'a aucun moyen de s'en apercevoir, puisqu'il n'a jamais demandé à voir l'intégralité des données. C'est la classique attaque par indisponibilité des données, et c'est la raison pour laquelle, pendant des années, les clients légers ont été traités comme des citoyens de seconde zone, utiles pour les paiements mais pas pour les décisions critiques en matière de sécurité.
Pour y remédier, les concepteurs avaient besoin d'un moyen pour qu'un client léger exige la preuve que les données derrière un en-tête existent bien quelque part sur le réseau, sans télécharger ces données elles-mêmes. Interroger les nœuds complets ne suffit pas, car ils peuvent se liguer. Interroger tous les nœuds complets revient simplement à télécharger les données. Il fallait inventer quelque chose de statistique.
L'idée centrale : l'échantillonnage aléatoire comme garantie probabiliste
L'échantillonnage de disponibilité des données repose sur une intuition unique qui semble presque trop simple pour fonctionner. Si un bloc est découpé en nombreux petits fragments et qu'un client léger vérifie aléatoirement quelques-uns de ces fragments, la probabilité qu'un attaquant dissimule ne serait-ce qu'un seul fragment devient extrêmement faible à mesure que davantage de clients légers effectuent leurs échantillonnages.
Imaginez un bloc qui a été divisé en 1 000 morceaux. Un client léger choisit 10 morceaux au hasard et les demande au réseau. Si les 10 reviennent, le client n'a pas terminé. Il sait seulement que ces 10 morceaux existent. Mais multipliez cela par des millions de clients légers choisissant chacun leurs propres morceaux au hasard, et la probabilité qu'un fragment caché survive à toutes ces requêtes s'effondre vers zéro. Après suffisamment d'échantillonnages indépendants, le réseau peut considérer le bloc comme disponible avec une quasi-certitude mathématique, même si aucun nœud individuel n'a téléchargé l'ensemble.
C'est la garantie probabiliste au cœur du DAS. Ce n'est pas une promesse selon laquelle chaque nœud a vu chaque octet. C'est une promesse que les données existent, distribuées à travers le réseau, et que toute tentative de dissimuler un morceau exigerait de mentir à un si grand nombre d'échantillonnages aléatoires que la probabilité de s'en sortir est, en pratique, nulle.
Le codage par effacement : l'astuce qui fait fonctionner l'échantillonnage
L'échantillonnage aléatoire seul ne suffirait pas. Si un bloc est simplement découpé en 1 000 morceaux bruts, un attaquant n'a qu'à en cacher un seul pour briser la chaîne, et la probabilité qu'un client léger tombe sur le morceau caché est faible. Pour que les mathématiques fonctionnent, les blockchains ajoutent volontairement de la redondance, en utilisant une technique appelée codage par effacement.
Le schéma le plus courant est le codage de Reed-Solomon, une méthode de correction d'erreurs vieille de plusieurs décennies, conçue à l'origine pour les CD et les communications dans l'espace lointain. L'idée consiste à prendre les données du bloc d'origine, à les traiter comme un polynôme, puis à étendre ce polynôme afin que la même information soit encodée à travers davantage de points de données qu'à l'origine. Avec un code Reed-Solomon configuré pour doubler les données, un bloc d'origine de 1 000 morceaux devient un bloc étendu de 2 000 morceaux, dans lequel n'importe lesquels de ces 1 000 morceaux suffisent à reconstruire l'ensemble.
Pourquoi c'est important : désormais, un attaquant qui veut retenir des données doit retenir au moins la moitié du bloc étendu, et pas seulement un morceau. Les clients légers, quant à eux, continuent d'échantillonner au hasard à partir de l'ensemble étendu. La probabilité de manquer un morceau caché diminue considérablement, car l'attaquant doit cacher une part bien plus importante. C'est la combinaison du codage par effacement et de l'échantillonnage aléatoire qui transforme une garantie faible en une garantie forte, et c'est le cœur technique de chaque conception de DAS en production ou en tests sérieux.
PeerDAS : l'évolution pair-à-pair du DAS chez Ethereum
L'approche actuelle d'Ethereum en matière de DAS porte le nom de PeerDAS, et ce nom évoque le changement architectural. Dans une conception naïve du DAS, chaque nœud complet stocke toujours l'intégralité du bloc étendu. L'échantillonnage est réservé aux clients légers, et les nœuds complets supportent la charge de stockage. PeerDAS inverse cette logique. Dans PeerDAS, les données étendues sont également réparties en fragments sur le réseau pair-à-pair, de sorte que chaque nœud complet ne stocke qu'un sous-ensemble de l'espace total des blobs, et les données sont reconstruites à la demande en demandant les parts aux pairs.
Pour Ethereum, les données pertinentes sont ce qu'il appelle les blobs, les morceaux de données temporaires que les rollups publient à moindre coût. PeerDAS permet aux validateurs de ne stocker que quelques colonnes d'une matrice de blobs codée par effacement, tout en étant capables de servir n'importe quel échantillon aléatoire au réseau. La garantie mathématique est la même que celle du DAS classique, mais le coût en ressources est réparti, de sorte que le réseau peut augmenter la capacité totale en blobs sans faire croître les exigences par nœud au même rythme.
D'autres écosystèmes utilisent la même idée sous des noms différents. Celestia, souvent désigné par son ticker TIA, a été le premier réseau en production conçu dès le départ autour du DAS, se positionnant comme une couche modulaire de disponibilité des données à laquelle les rollups peuvent payer pour publier. NEAR a exploré des conceptions de type DAS dans le cadre de sa feuille de route sur le sharding. Partout, le même schéma apparaît : coder les données par effacement, échantillonner aléatoirement, et laisser les probabilités faire le travail de sécurité qui nécessitait auparavant une réplication complète.
Ce que cela signifie en pratique : des dizaines de milliers de TPS
Une fois la disponibilité des données peu coûteuse et prouvable, le reste de l'histoire de la scalabilité se débloque. Les rollups, le modèle de mise à l'échelle dominant sur Ethereum et de plus en plus sur d'autres chaînes, sont limités par la quantité de données qu'ils peuvent publier sur leur chaîne parente. Lorsque la couche de données de la chaîne parente peut croître parce que le DAS rend la vérification peu coûteuse, les rollups peuvent publier davantage de transactions compressées par bloc, et le débit effectif augmente.
Les chiffres cités par les chercheurs d'Ethereum, souvent de l'ordre de dizaines de milliers de transactions par seconde en L2, dépendent de ce type de mise à l'échelle des données. La même dynamique s'applique à Celestia et à toute chaîne qui adopte une architecture modulaire, où l'exécution et la disponibilité des données sont séparées et optimisées indépendamment. Sans le DAS, ces affirmations de débit exigeraient soit de centraliser les nœuds complets, soit de faire confiance à un petit comité de disponibilité des données, deux options qui constituent de mauvais compromis.
Il y a aussi un effet de second ordre, plus discret. À mesure que les clients légers deviennent fiables, l'univers des appareils capables de vérifier la chaîne s'élargit. Les téléphones, les navigateurs, et même le matériel embarqué peuvent participer à la sécurité. C'est bénéfique pour la décentralisation à long terme, car cela réduit le levier des grands opérateurs de nœuds et rend le réseau plus difficile à censurer ou à capturer.
Les compromis honnêtes que vous devriez connaître
Le DAS est puissant, mais ce n'est pas de la magie, et comprendre ses limites compte davantage que d'en mémoriser les avantages. La garantie probabiliste est réelle, mais elle reste une probabilité. Un client léger qui n'a effectué que quelques échantillons n'est pas pleinement protégé. Les implémentations de clients doivent choisir soigneusement le nombre d'échantillons, et le réseau doit supposer qu'un nombre suffisant de clients légers indépendants sont en ligne à tout moment pour que les calculs restent valables.
PeerDAS en particulier introduit de nouvelles hypothèses peer-to-peer. Le système ne fonctionne que si une fraction suffisamment grande de nœuds est en ligne pour servir les tranches qui leur sont assignées. Des partitions réseau prolongées, des attaques ciblées par déni de service contre les pairs, ou simplement une mauvaise découverte des pairs peuvent dégrader la garantie. Des atténuations existent, notamment la notation des pairs, les preuves de conservation des données et les modes de repli, mais il s'agit de domaines de recherche actifs plutôt que de problèmes résolus.
Il existe aussi des considérations économiques. À mesure que la capacité de données augmente, la question de savoir qui paie pour le stockage et la bande passante devient plus pressante. Ethereum y répond avec des frais de blob qui sont brûlés au fil du temps, et Celestia utilise un modèle similaire. Aucun de ces mécanismes n'est parfait, et ils évoluent en parallèle de la conception technique. Toute personne qui évalue une chaîne utilisant le DAS devrait accorder autant d'attention à son marché des frais et à sa structure d'incitations qu'à ses affirmations cryptographiques.
Comment suivre le data availability sampling de manière intelligente
Le data availability sampling passe des articles de recherche aux réseaux en production, et l'actualité qui l'entoure évolue chaque semaine. Les testnets PeerDAS d'Ethereum, les mises à niveau de Celestia et les conceptions concurrentes de NEAR et d'autres génèrent un flux régulier d'annonces, souvent habillées de battage médiatique. Distinguer les évolutions réelles du simple marketing demande plus qu'un rapide défilement sur Twitter. Zippfeed met en avant les titres liés à la disponibilité des données et à la scalabilité avec une notation de sentiment (bullish, neutral ou bearish) et un indice d'importance, afin que vous puissiez distinguer les étapes techniques du bruit sans avoir à lire chaque fil de discussion vous-même.