Le danksharding est l’objectif final prévu par Ethereum pour faire évoluer les données des rollups, construit autour de l’échantillonnage de disponibilité des données (DAS) : les nœuds légers vérifient qu’une énorme quantité de données de blobs a bien été publiée en ne téléchargeant que quelques fragments aléatoires et en utilisant le codage d’effacement pour confirmer mathématiquement que le reste existe. C’est la deuxième étape après EIP-4844, qui a déjà introduit les transactions transportant des blobs, et c’est la conception que les chercheurs d’Ethereum ont choisie plutôt qu’une approche fondée sur le sharding de l’exécution.
Points clés
- Le danksharding sépare la disponibilité des données de l’exécution : les rollups publient des données compressées, et Ethereum doit seulement confirmer que ces données ont été publiées, pas les exécuter.
- EIP-4844 (proto-danksharding) a été la première étape, avec l’ajout de transactions transportant des blobs ; le danksharding complet ajoute par-dessus le codage d’effacement et l’échantillonnage de disponibilité des données.
- L’échantillonnage de disponibilité des données permet à un nœud léger de vérifier des mégaoctets de données de blobs en ne téléchargeant qu’une poignée d’échantillons aléatoires, puis en s’appuyant sur les mathématiques pour confirmer le reste.
- Celestia, EigenDA et Avail sont des conceptions concurrentes qui vendent la même idée de disponibilité des données en tant que service en dehors de l’ensemble de validateurs d’Ethereum.
Pourquoi Ethereum ne peut pas simplement « agrandir les blocs »
L’argument en faveur du danksharding n’a de sens que si vous comprenez d’abord la contrainte qu’il résout. Chaque nœud d’une blockchain doit télécharger, vérifier et stocker chaque bloc. Si vous augmentez simplement la taille des blocs, par exemple de quelques centaines de kilo-octets à plusieurs mégaoctets, vous n’obtenez pas plus de débit. Vous obtenez un seuil matériel plus élevé, car même l’ordinateur portable grand public le moins cher doit encore suivre le rythme de la chaîne.
C’est la tension derrière le célèbre trilemme de la blockchain : un réseau veut être décentralisé (beaucoup de nœuds indépendants), sécurisé (aucun moyen facile de falsifier l’historique) et scalable (beaucoup de transactions bon marché). Augmenter fortement la taille des blocs améliore une propriété au détriment des autres, car les exigences pour les nœuds augmentent et le nombre d’opérateurs diminue.
La feuille de route d’Ethereum centrée sur les rollups est une réponse partielle. Au lieu de tout faire sur la couche 1, vous laissez les rollups de couche 2 exécuter des milliers de transactions, puis publier un résumé compressé sur Ethereum. Ethereum devient une couche de règlement et de données, pas un ordinateur mondial. Cela fonctionne, mais il y a un goulot d’étranglement : les rollups ont besoin d’un endroit bon marché et vérifiable pour publier leurs données, et cet endroit est actuellement le call data d’Ethereum, qui est coûteux et entre en concurrence avec tous les autres usages de l’espace de bloc.
Le danksharding est le plan destiné à supprimer ce goulot d’étranglement en donnant aux rollups un canal de données dédié et abondant, sans obliger chaque nœud à tout télécharger.
EIP-4844 : la première étape que vous avez déjà vue
Avant que le danksharding puisse exister, Ethereum a déployé le proto-danksharding, formalisé sous le nom EIP-4844, en mars 2024. C’est la partie que vous connaissez peut-être déjà sous le nom de blobs.
Un blob est un fragment de données attaché à une transaction qui vit sur un marché de frais séparé (souvent appelé marché du blob gas) et qui est automatiquement supprimé de la chaîne après environ 18 jours. Les nœuds n’ont pas à exécuter le contenu des blobs ; ils doivent seulement les stocker temporairement et prouver qu’ils ont été publiés. Des rollups comme Arbitrum, Optimism et Base sont passés de la publication de données compressées sous forme de calldata à leur publication sous forme de blobs, ce qui a immédiatement rendu les transactions de rollups plusieurs fois moins chères.
EIP-4844 est le compromis d’ingénierie. Il ne change pas la façon dont Ethereum vérifie la disponibilité des données. Il exige toujours que chaque nœud télécharge chaque blob en entier pour confirmer que le bloc est valide. Cela fonctionne avec quelques blobs par bloc, mais ne passe pas à l’échelle des volumes envisagés par le danksharding.
Considérez donc le proto-danksharding comme la rampe d’accès. Il introduit le format de transaction blob, le marché de frais séparé et les règles de consensus que le futur danksharding réutilisera. Le danksharding complet correspond au moment où Ethereum cesse d’obliger chaque nœud à télécharger chaque blob et commence plutôt à échantillonner.
Ce que signifie réellement la « disponibilité des données »
L’expression « les données sont disponibles » semble évidente, mais elle a un sens précis dans la recherche sur le consensus. Un bloc est considéré comme ayant ses données disponibles si chaque nœud honnête peut réellement récupérer les données sous-jacentes, pas seulement l’en-tête ou un engagement cryptographique sur celles-ci. Sans cette garantie, un producteur de blocs malveillant pourrait publier un en-tête de bloc qui paraît valide tout en retenant les données associées, et les nœuds complets n’auraient aucun moyen de détecter la fraude ni de reconstruire la chaîne.
C’est le problème de disponibilité des données, et c’est l’un des problèmes les plus difficiles à résoudre pour faire monter en charge les blockchains. C’est pourquoi les clients légers sur Bitcoin ne peuvent pas vérifier entièrement la chaîne : ils téléchargent les en-têtes de bloc, mais font confiance au fait que quelqu’un d’autre stocke les corps. Si un mineur retenait un jour les transactions d’un bloc, un client léger ne pourrait pas le savoir.
Ethereum veut offrir aux clients légers une vraie vérification plutôt que de la confiance. Cela exige un mécanisme grâce auquel un nœud peut confirmer qu’un vaste ensemble de données a bien été publié sans télécharger cet ensemble de données. L’échantillonnage de disponibilité des données est ce mécanisme, et le danksharding est la conception propre à Ethereum qui le déploie au niveau du consensus.
Codage par effacement, la mathématique qui permet à des échantillons d’impliquer le tout
DAS ne fonctionne que grâce au codage par effacement, une technique empruntée à la théorie du stockage et des communications. Le modèle mental le plus simple consiste à imaginer qu’on écrit un fichier de 1 Mo dans un tableur, puis qu’on ajoute 1 Mo de lignes redondantes qui sont des combinaisons linéaires des cellules d’origine. On a alors 2 Mo, mais on peut reconstruire le 1 Mo d’origine à partir de n’importe quel 1 Mo parmi les 2 Mo.
Dans le danksharding, les producteurs de blocs font à peu près la même chose avec les données des blobs. Ils prolongent les données sous-jacentes de chaque blob avec des fragments de parité supplémentaires calculés à l’aide d’un code de type Reed-Solomon, ce qui double la taille sur chaîne en échange d’une garantie puissante. Si les données sont ne serait-ce que partiellement disponibles, un nœud honnête peut tout reconstruire.
Pourquoi cela compte-t-il pour l’échantillonnage ? Supposons qu’un producteur de blocs tente de retenir un quart des données étendues afin que personne ne puisse les reconstruire. C’est statistiquement impossible à dissimuler, car les échantillons sont choisis uniformément au hasard dans l’ensemble de données étendu. Un nœud léger qui télécharge avec succès, disons, 30 fragments aléatoires et confirme qu’ils correspondent tous peut être mathématiquement certain, avec une probabilité ajustable, que l’ensemble complet des données peut être reconstruit par quelqu’un.
L’idée clé est que le codage par effacement transforme un problème qui consiste à tout télécharger en un problème de vérification aléatoire par sondage. Sans lui, l’échantillonnage serait inutile, car un producteur malveillant pourrait retenir un seul octet ciblé et aucun contrôle ponctuel ne le détecterait.
Comment l’échantillonnage de disponibilité des données fonctionne concrètement sur un nœud
Dans la conception du danksharding, les données de la chaîne sont conceptuellement organisées en une grille bidimensionnelle. Chaque ligne correspond aux données de blobs d’un slot, et chaque colonne est une bande de fragments étendus. Un producteur de blocs s’engage sur toute la grille au moyen d’engagements polynomiaux, les engagements KZG dans le plan actuel, qui servent d’empreinte cryptographique suffisamment compacte pour tenir dans un en-tête de bloc.
Les nœuds légers font alors ce qui suit pour chaque slot :
- Recevoir l’en-tête de bloc et les engagements KZG sur les données étendues.
- Télécharger une poignée de cellules aléatoires de la grille, en interrogeant différents pairs pour différentes positions.
- Vérifier chaque cellule téléchargée par rapport à son engagement. Une cellule incorrecte échoue immédiatement au contrôle.
- Accroître leur confiance, à chaque échantillon réussi, que la grille complète est disponible.
Après assez d’échantillons réussis, le nœud léger traite les données comme disponibles. Si le producteur de blocs avait tenté de retenir ne serait-ce qu’une petite fraction de la grille, la probabilité que tous les échantillons aléatoires tombent sur la partie honnête diminue de façon exponentielle. Avec quelques dizaines d’échantillons, la probabilité d’échec devient négligeable.
C’est la partie qui change l’histoire du matériel. Un nœud léger n’a plus besoin d’être un serveur costaud avec un SSD rapide. Il doit télécharger quelque chose de l’ordre de quelques kilo-octets par slot, puis diffuser ces échantillons sur le réseau. Cela permet aux solo stakers et aux validateurs à domicile de rester compétitifs, ce qui préserve la décentralisation.
Les risques dont personne ne parle honnêtement
Le danksharding est techniquement élégant, mais il comporte de vrais modes de défaillance. Une présentation honnête exige d’en parler.
Le premier risque est l’attaque de rétention de disponibilité des données. Un producteur de blocs pourrait toujours essayer de publier un en-tête puis de retenir assez de cellules pour que des nœuds légers honnêtes échouent à échantillonner. Si le réseau n’a pas assez de nœuds légers qui échantillonnent de manière redondante, un attaquant peut jouer avec l’aléa jusqu’à ce qu’assez de clients légers manquent les données disponibles et rejettent le bloc, ce qui provoque une défaillance de vivacité (la chaîne s’arrête). Les pistes d’atténuation étudiées consistent notamment à avoir plusieurs producteurs de blocs par slot et à obliger les nœuds légers à attendre que le réseau ait eu le temps de diffuser les échantillons, mais les deux augmentent la latence.
Le deuxième risque est le mode de défaillance du codage par effacement lui-même. Si un bogue ou une erreur d’implémentation rend l’encodage incohérent d’un client à l’autre, des nœuds légers honnêtes pourraient rejeter des blocs valides ou en accepter d’indisponibles. C’est en partie pourquoi la conception s’appuie sur des engagements KZG, qui peuvent prouver que des cellules individuelles sont cohérentes avec l’en-tête, et pourquoi d’importants réseaux de test, des devnets comme da-dedi inspiré de Celestia et les travaux EIP-7591, sont exécutés avant le déploiement sur le réseau principal.
Le troisième risque est la centralisation autour de l’infrastructure. Même si les exigences sur le papier pour un nœud léger sont minimes, les exigences réelles pour un validateur complet, ceux qui proposent et attestent réellement les blocs, continuent d’augmenter. Si les solo stakers se retirent parce que les tâches d’attestation exigent du matériel sophistiqué, le réseau devient plus centralisé, quel que soit le faible coût des clients légers.
Enfin, il y a le risque social de survendre la chose. L’expression « scalabilité illimitée » est souvent accolée au DAS, et c’est faux. Le codage par effacement double à peu près l’empreinte des données, donc il y a un coût réel. L’échantillonnage ne vérifie que la disponibilité, il ne permet pas magiquement au réseau de traiter plus d’exécution. Les rollups paient toujours l’exécution ailleurs, et les plafonds de débit demeurent, simplement à un niveau bien plus élevé qu’aujourd’hui.
Pourquoi Celestia, EigenDA et Avail se ressemblent
Ethereum n’est pas la seule équipe à miser sur l’échantillonnage de la disponibilité des données. Celestia a été lancé fin 2023 comme une blockchain autonome dont toute la fonction est de servir de couche de disponibilité des données. Elle utilise la même recette DAS et codage par effacement : les données sont encodées dans une grille 2D, les nœuds légers échantillonnent des cellules aléatoires, et un engagement de type KZG ancre l’ensemble de la grille.
L’argument est que les rollups et les app-chains n’ont pas du tout besoin de vivre sur Ethereum. Ils peuvent publier leurs données sur Celestia, payer des frais Celestia, et n’utiliser Ethereum, ou toute autre couche de règlement, que pour les preuves de fraude ou de validité. Celestia se positionne comme une brique de blockchain modulaire plutôt que comme une plateforme de smart contracts.
EigenDA a une forme différente. C’est un service de disponibilité des données construit sur EigenLayer, qui permet aux stakers ETH de choisir de sécuriser des services supplémentaires en restakant leur collatéral. L’argument d’EigenDA est qu’il hérite de la sécurité économique d’Ethereum, car les opérateurs qui font fonctionner son réseau de stockage sont aussi des validateurs Ethereum exposés à un véritable risque de slashing.
Avail, initialement issu de Polygon, emprunte une troisième voie : il se positionne comme une couche de disponibilité des données capable de servir de nombreuses chaînes, y compris des chaînes non Ethereum, et il utilise un schéma d’engagement polynomial différent, les engagements Kate pouvant être remplacés ou complétés par d’autres conceptions, afin de rester flexible. Polygon lui-même a lancé une chaîne Polygon POS qui utilisait historiquement une approche différente, tandis que les rollups plus récents « Polygon CDK » sont libres de choisir n’importe quelle couche DA.
Pourquoi Ethereum prend-il la peine de construire la sienne ? Pour deux raisons. Premièrement, la communauté Ethereum veut une sécurité DA soutenue par les stakers ETH plutôt que par un token séparé, ce qui maintient les hypothèses de confiance d’un rollup Ethereum au sein de l’écosystème Ethereum. Deuxièmement, la concurrence est saine. Savoir que Celestia existe pousse les chercheurs d’Ethereum à livrer, et inversement.
Ce que cela signifie pour vous en tant qu’utilisateur ou constructeur
Si vous effectuez simplement des transactions sur Ethereum ou sur un rollup, le danksharding se manifeste surtout par des frais moins élevés. Une fois les blobs abondants et bon marché, les rollups peuvent publier des lots plus volumineux et réduire encore davantage le gas. Les chiffres exacts dépendent de la dynamique du marché des frais de blobs et des améliorations de la compression des rollups, mais l’impact directionnel est réel : les transactions de rollup qui coûtent déjà quelques centimes peuvent tomber à des fractions de centime lorsque le nombre de blobs est élevé.
Si vous êtes développeur et choisissez une pile de rollup, la nouvelle décision consiste à choisir quelle couche DA utiliser. Les choix incluent désormais Ethereum native, après le danksharding complet, Celestia, EigenDA et Avail, chacun avec des hypothèses différentes en matière de coût, de sécurité et de bridge. Un rollup sur Celestia n’est pas aussi profondément lié aux stakers ETH, mais il peut être moins cher et plus flexible. Un rollup sur EigenDA hérite de la sécurité de l’ETH restaké, mais il n’est décentralisé qu’à la mesure de l’ensemble d’opérateurs d’EigenLayer. Rien n’est gratuit.
Si vous êtes staker ou validateur à domicile, le message pratique est plus rassurant qu’inquiétant. Les exigences des clients légers restent faibles, de sorte que le seuil matériel au quotidien n’augmente pas comme il le ferait avec des hausses naïves de la taille des blocs. Les exigences d’attestation peuvent tout de même augmenter, mais à un rythme plus maîtrisé, et des améliorations comme la séparation proposer-builder intégrée visent à réduire la charge opérationnelle.
Ce que vous ne devez pas faire, c’est supposer que le danksharding est « terminé ». Début 2026, il est encore sur des testnets, avec EIP-7591, PeerDAS, une étape intermédiaire, comme déploiement à court terme et le danksharding complet plus tard. Considérer n’importe quel calendrier comme garanti est la meilleure façon d’être déçu.
Gardez une longueur d’avance sur la feuille de route de mise à l’échelle d’Ethereum
Le danksharding, le DAS, les frais de blobs et les couches concurrentes de disponibilité des données évoluent rapidement, et les sources crédibles sont dispersées entre forums de recherche, brouillons EIP et appels des core developers. Zippfeed agrège les actualités sur la mise à l’échelle d’Ethereum avec un score de sentiment (bullish, neutral ou bearish) et une note d’importance, afin que vous puissiez distinguer les jalons de protocole qui changent réellement la donne de simples republications.