Danksharding

Le Danksharding est ce qui permettra à Ethereum de devenir une blockchain véritablement évolutive, mais plusieurs mises à jour du protocole sont nécessaires pour y parvenir. Le Proto-Danksharding est une étape intermédiaire sur ce chemin. Tous deux visent à rendre les transactions sur la couche 2 aussi peu coûteuses que possible pour les utilisateurs et devraient permettre à Ethereum de traiter plus de 100 000 transactions par seconde.

Qu'est-ce que le Proto-Danksharding ?

Le Proto-Danksharding, également connu sous le nom d'EIP-4844 (opens in a new tab), est un moyen pour les rollups d'ajouter des données moins coûteuses aux blocs. Le nom provient des deux chercheurs qui ont proposé l'idée : Protolambda et Dankrad Feist. Historiquement, la capacité des rollups à rendre les transactions des utilisateurs peu coûteuses était limitée par le fait qu'ils publient leurs transactions dans CALLDATA.

Cette solution est onéreuse car ces données sont traitées par l’ensemble des nœuds d’Ethereum et restent sur la blockchain pour toujours, même si les rollups n'ont besoin des données que pendant une courte période. Le Proto-Danksharding introduit des « blobs » de données qui peuvent être envoyés et ajoutés aux blocs. Les données présentes dans ces blobs ne sont pas accessibles pour l'EVM et sont automatiquement supprimées après un laps de temps fixe (fixé à 4 096 périodes à l'heure actuelle, soit à peu près 18 jours). Cela signifie que les rollups peuvent envoyer leurs données à moindre frais et répercuter ces économies sur les utilisateurs finaux sous forme de transactions moins onéreuses.

Les rollups sont un moyen de faire évoluer Ethereum en regroupant les transactions hors chaîne, puis en publiant les résultats sur Ethereum. Un rollup est essentiellement composé de deux parties : les données et la vérification de l'exécution. Les données représentent la séquence complète de transactions traitées par un rollup pour générer le changement d'état publié sur Ethereum. La vérification de l'exécution consiste à faire réexécuter ces transactions par un acteur honnête (un « démonstrateur ») pour garantir que le changement d'état proposé est correct. Pour que la vérification de l'exécution soit possible, les données de transaction doivent être disponibles suffisamment longtemps afin que quiconque puisse les télécharger et les vérifier. Cela signifie que tout comportement malhonnête de la part du séquenceur de rollup peut être identifié et contesté par le démonstrateur. Cependant, ces données n'ont pas besoin d'être disponibles indéfiniment.

Les rollups publient des engagements liés à leurs données de transaction en chaîne et rendent également les données réelles accessibles sous forme de « blobs » de données. Cela signifie que les démonstrateurs peuvent vérifier la validité des engagements ou contester les données qu'ils estiment incorrectes. Au niveau des nœuds, les « blobs » de données sont stockés dans le client de consensus. Les clients de consensus attestent qu'ils ont vu les données et qu'elles se sont propagées sur le réseau. Si les données étaient conservées indéfiniment, ces clients deviendraient trop encombrés et cela augmenterait les besoins matériels pour faire fonctionner les nœuds. Au lieu de cela, les données sont automatiquement supprimées du nœud tous les 18 jours. Les attestations des clients de consensus démontrent qu'il y a eu suffisamment de possibilités pour que les démonstrateurs vérifient les données. Les données réelles peuvent être stockées en dehors de la blockchain par les opérateurs de rollup, les utilisateurs ou d'autres parties.

Comment les données des blobs sont-elles vérifiées ?

Les rollups publient les transactions qu'ils exécutent dans des blobs de données. Ils publient également un « engagement » envers ces données. Ils font cela en appliquant une fonction polynomiale aux données. Cette fonction peut ensuite être évaluée à différents points. Par exemple, si nous définissons une fonction extrêmement simple f(x) = 2x-1, nous pouvons alors évaluer cette fonction pour x = 1, x = 2, x = 3, ce qui donne les résultats 1, 3, 5. Un démonstrateur applique la même fonction aux données et l'évalue aux mêmes points. Si les données d'origine sont modifiées, la fonction ne sera pas identique, et par conséquent, les valeurs évaluées à chaque point ne le seront pas non plus. En réalité, l'engagement et la preuve sont plus complexes car ils contiennent une couche de fonctions cryptographiques.

Qu'est-ce que KZG ?

KZG est l'acronyme de Kate-Zaverucha-Goldberg – les noms des trois auteurs originaux (opens in a new tab) d'un schéma qui réduit un blob de données à un petit « engagement » cryptographique (opens in a new tab). Le blob de données soumis par un rollup doit être vérifié pour s'assurer que le rollup ne se comporte pas de manière incorrecte. Cela implique qu'un démonstrateur exécute à nouveau les transactions dans le blob pour vérifier que l'engagement était valide. Conceptuellement, cela correspond à la manière dont les clients d'exécution vérifient la validité des transactions Ethereum sur la couche principale à l'aide de preuves de Merkle. KZG est une preuve alternative qui applique une équation polynomiale aux données. L'engagement évalue le polynôme à des points de données tenus secrets. Un démonstrateur applique le même polynôme aux données et l'évalue aux mêmes valeurs, vérifiant que le résultat est bien identique. C'est une manière de vérifier que les données sont compatibles avec les techniques de zero-knowledge (Zk) utilisées par certains rollups et éventuellement d'autres parties du protocole Ethereum.

Qu'est-ce que la cérémonie KZG ?

La cérémonie KZG était un moyen pour de nombreuses personnes à travers la communauté Ethereum de collectivement générer une suite secrète aléatoire de nombres qui peuvent être utilisés pour vérifier certaines données. Il est très important que cette suite de nombres ne soit pas connue et ne puisse pas être recréée par qui que ce soit. Pour garantir cela, chaque personne qui participait à la cérémonie recevait une chaine de caractère provenant du participant précédent. Ils créent ensuite de nouvelles valeurs aléatoires (p. ex., en autorisant leur navigateur à mesurer le mouvement de leur souris) et les mélangent à la valeur précédente. Ils envoyaient ensuite la valeur au participant suivant et la détruisaient de leur machine locale. Tant qu’une personne présente à la cérémonie a fait cela honnêtement, la valeur finale sera inconnue d’un attaquant.

La cérémonie KZG de l'EIP-4844 était ouverte au public et des dizaines de milliers de personnes y ont participé pour ajouter leur propre entropie (aléatoire). Au total, elle compta plus de 140 000 contributions, faisant d'elle la plus large cérémonie de ce type dans le monde. Pour que la cérémonie soit compromise, il aurait fallu que 100 % de ses participants soient volontairement malhonnêtes. Du point de vue des participants, s'ils savent qu'ils ont agi honnêtement, il n'est pas nécessaire de faire confiance à quelqu'un d'autre car ils savent qu'ils ont sécurisé la cérémonie (ils ont individuellement satisfait à l'exigence d'au moins 1 participant honnête parmi N).

Quand un rollup publie des données dans un blob, il fournit un « engagement » qu'il publie sur la chaine. Cet engagement est le résultat de l'évaluation d'une fonction polynomiale appliquée aux données à certains points. Ces points sont définis par les nombres aléatoires générés lors de la cérémonie KZG. Les démonstrateurs peuvent ensuite évaluer le polynôme aux mêmes points afin de vérifier les données - si les valeurs sont identiques, alors les données sont correctes.

Si quelqu'un connaît les emplacements aléatoires utilisés pour l'engagement, il peut facilement générer un nouveau polynôme qui correspond à ces points spécifiques (c'est-à-dire une « collision »). Cela signifie qu'il pourrait ajouter ou supprimer des données du « blob » tout en fournissant une preuve valide. Pour empêcher cela, au lieu de donner directement aux démonstrateurs les emplacements des points secrets , ils reçoivent en réalité les emplacements masqués dans une « boîte noire » cryptée à l'aide de courbes elliptiques. Cela brouille les valeurs de telle manière que les valeurs originales ne peuvent pas être déchiffrées, mais avec un peu d'algèbre, les démonstrateurs et les vérificateurs peuvent toujours évaluer les polynômes aux points qu'ils représentent.

Ni le Danksharding ni le Proto-Danksharding ne suivent le modèle traditionnel de « fragmentation » qui visait à diviser la blockchain en plusieurs fragments. La fragmentation de la chaîne ne fait plus partie de la feuille de route. Au lieu de cela, le Danksharding utilise un échantillonnage de données distribué à travers les blobs pour faire passer Ethereum à l'échelle. Ceci est beaucoup plus simple à mettre en œuvre. Ce modèle est parfois désigné sous le nom de « data-sharding » ou « fragmentation de données ».

Qu'est-ce que le Danksharding ?

Le Danksharding est la réalisation complète du passage à l'échelle des rollups commencé avec le Proto-Danksharding. Le Danksharding apportera une grande quantité de stockage sur Ethereum pour que les rollups puissent publier leurs données de transaction compressées. Cela signifie qu'Ethereum pourra facilement accueillir des centaines de rollups individuels et rendra ainsi possible des millions de transactions par seconde.

Cela fonctionne en étendant le nombre de blobs attachés aux blocs de six (6) dans le Proto-Danksharding, à 64 dans le Danksharding complet. Le reste des changements requis concerne des mises à jour du fonctionnement des clients de consensus pour leur permettre de gérer les nouveaux blobs de grande taille. Plusieurs de ces modifications sont déjà prévues dans la feuille de route à d'autres fins, indépendamment du Danksharding. Par exemple, le Danksharding nécessite la mise en œuvre de la séparation entre le validateur et le constructeur de blocs. Il s'agit d'une mise à jour qui sépare les tâches de construction de blocs et de proposition de blocs entre différents validateurs. De même, l'échantillonnage de la disponibilité des données est requis pour le Danksharding, mais il est également nécessaire pour le développement de clients plus légers qui ne stockent pas toutes les données historiques (clients « sans état »).

La séparation entre les validateurs et les constructeurs de blocs est nécessaire pour éviter que chaque validateur ait à générer des engagements trop volumineux et des preuves pour 32 Mo de données de blobs. Cela mettrait trop de pression sur les validateurs à domicile et les obligerait à investir dans du matériel plus puissant, ce qui nuirait à la décentralisation. Au lieu de cela, des constructeurs de blocs spécialisés prennent en charge ce travail de calcul coûteux. Ensuite, ils mettent leurs blocs à disposition des proposeurs pour qu'ils les diffusent. Le proposeur de bloc choisit simplement le bloc le plus rentable. Tout le monde peut vérifier les blobs de manière simple et rapide, ce qui signifie que n'importe quel validateur normal peut vérifier si les constructeurs de blocs se comportent honnêtement. Cela permet de traiter les blobs de grande taille sans sacrifier la décentralisation. Les constructeurs de blocs qui se comportent mal pourraient simplement être expulsés du réseau et sanctionnés - d'autres prendront leur place car la construction de blocs est une activité profitable.

L'échantillonnage de la disponibilité des données est nécessaire pour que les validateurs puissent vérifier rapidement et efficacement les données de blobs. En utilisant l'échantillonnage de la disponibilité des données, les validateurs peuvent être tout à fait certains que les données de blobs étaient disponibles et que les engagements étaient corrects. Chaque validateur peut échantillonner au hasard quelques points de données et en créer une preuve, ce qui signifie qu'aucun validateur n'a à vérifier l'intégralité du blob. Si des données sont manquantes, elles seront rapidement identifiées et le blob sera rejeté.

Progrès actuels

L'implémentation complète du Danksharding prendra encore plusieurs années. Entre-temps, la cérémonie KZG s'est conclue avec plus de 140 000 contributions, et l'EIP (opens in a new tab) pour le Proto-Danksharding est arrivé à maturité. Cette proposition a été totalement implémentée dans tous les réseaux de tests, et a rejoint le réseau principal avec la mise à niveau du réseau Cancun-Deneb (« Dencun ») en mars 2024.

En savoir plus

Dernière mise à jour de la page : 16 février 2026

+14

Danksharding

Qu'est-ce que le Proto-Danksharding ?

Pourquoi les blobs rendent-ils les rollups moins chers ?

Pourquoi peut-on supprimer les données de blob ?