Définition : de quoi parle-t-on ?

Proto‑Danksharding, aussi connu sous le nom d’EIP‑4844, est une évolution de la couche de données d’Ethereum visant à introduire un mécanisme appelé « blobs ». Ces blobs sont de gros blocs de données séparés du bloc principal et sont conçus pour réduire la charge sur le réseau tout en améliorant la scalabilité. Contrairement aux transactions classiques, les blobs ne contiennent pas d’état, ce qui les rend plus légers et plus rapides à valider.

À quoi cela sert-il ?

Le but principal du Proto‑Danksharding est de désengorger la blockchain en déplaçant une partie du volume de données vers les blobs, tout en conservant la sécurité et la décentralisation. En permettant aux nœuds de télécharger uniquement les parties pertinentes, la taille des blocs devient plus gérable, ce qui diminue les coûts de synchronisation et accélère la propagation des transactions. Cette approche ouvre la voie à des applications plus gourmandes en données, comme les jeux en ligne ou les marchés de données volumineuses.

Comment cela fonctionne, étape par étape

1. Créer un blob contenant les données hors chaîne Un développeur prépare un ensemble de données volumineuses, tel qu’un tableau de 10 000 enregistrements d’un jeu fictif, puis les regroupe dans un blob. Ce blob est envoyé à l’infrastructure Ethereum, où il est indexé par un identifiant unique, sans modifier l’état de la blockchain.
2. Référence du blob dans une transaction Ethereum La transaction principale contient un champ supplémentaire appelé « blobHash », qui référence l’identifiant du blob stocké. Lors de la validation, les nœuds récupèrent le blob via ce hash, vérifient son intégrité, puis n’incluent que le hash dans le bloc, réduisant ainsi la charge.
3. Synchronisation et récupération des blobs Les nœuds légers téléchargent uniquement les blobs dont ils ont besoin pour exécuter une application. Un mécanisme de batching permet de regrouper plusieurs demandes de blobs, limitant le nombre de requêtes et optimisant l’utilisation de la bande passante.
4. Validation et sécurité du blob Chaque blob est signé par le créateur et contient un champ de hachage. Les nœuds vérifient la signature et le hachage avant d’accepter le blob. Si un blob est compromis, sa signature invalide empêche son inclusion, préservant la cohérence de la chaîne.

Exemple concret (scénario fictif)

Imagine un festival futuriste où les organisateurs utilisent le Proto‑Danksharding pour distribuer des PDF de billets. Avant l'événement, ils encodent les billets sous forme de blobs et les publient sur le réseau. Lorsque le premier lot de billets est téléchargé, les validateurs vérifient les blobs et incluent des références dans le bloc principal. Deux jours plus tard, les acheteurs de billets récupèrent les blobs via des clients légers, confirmant l'authenticité sans télécharger toute la chaîne. Pendant le festival, une affluence soudaine de participants déclenche un nouveau lot de données ; le réseau traite ce nouveau blob en quelques minutes, maintenant les frais de transaction bas. Après l'événement, les analystes examinent les journaux de blobs pour évaluer les tendances de fréquentation. Le résultat : une billetterie plus fluide, des coûts réduits et des analyses post‑événement enrichies, tout en préservant les garanties de sécurité d'Ethereum.

Différences et cas d’utilisation

Blob vs Transaction Data

Les blobs sont des blocs de données volumineux stockés séparément du bloc principal, tandis que les transactions habituelles restent dans le bloc standard. Cette séparation permet aux validateurs de télécharger uniquement ce qui est nécessaire, réduisant la bande passante tout en conservant la vérifiabilité des opérations.

Cost Efficiency vs Storage

Les blobs bénéficient d’une frais de stockage nettement inférieur à ceux des transactions classiques. En déplaçant les données lourdes vers ce mécanisme, le coût de la mise à jour des nœuds diminue, ce qui rend la participation plus abordable pour les opérateurs de portefeuille tout en préservant la sécurité globale.

Node Participation vs Data Availability

Les nœuds du réseau ne sont pas obligés de télécharger l’intégralité des blobs, seulement les parties pertinentes pour leurs opérations. Ce traitement groupé (batching) réduit la charge sur le réseau, tout en assurant que les données essentielles restent disponibles pour la vérification et l’exécution des contrats.

Avantages et intérêts possibles

• Proto‑Danksharding réduit la taille des blocs de données en déplaçant une partie du contenu vers des blobs séparés, ce qui diminue la bande passante requise pour les nœuds complets et accélère la propagation des transactions. Cette approche est particulièrement utile pour les applications de finance décentralisée qui génèrent de gros volumes de données.
• Les blobs sont stockés dans la couche d'exécution mais retirés de la couche d'état, ce qui permet aux nœuds légers de rester à jour sans télécharger l'intégralité de l'état. Cela ouvre la porte à une participation plus large et à une meilleure résilience du réseau, tout en maintenant la sécurité grâce aux preuves de disponibilité.

Inconvénients et limites

• Les blobs ne sont pas persistants dans la couche d'état, ce qui signifie que les nœuds complets ne les conservent pas de façon native. Cela crée un risque de perte de données si les archivers ne sont pas maintenus, et oblige les développeurs à mettre en place des mécanismes de récupération supplémentaires.
• Le mécanisme de preuves de disponibilité repose sur des nœuds d'archivage qui doivent conserver les blobs hors chaîne. Si le réseau ne dispose pas d'un nombre suffisant d'archivistes, la disponibilité des données peut être compromise, limitant l'efficacité de la scalabilité et exposant les participants à des risques de centralisation.

Risques réels à connaître

• Le premier risque lié à l'introduction des blobs réside dans la complexité accrue des mécanismes de validation, où la nécessité de synchroniser les données de blob avec les blocs principaux peut entraîner des retards de propagation et une fragilité accrue du réseau si certains nœuds ne parviennent pas à suivre le rythme, ce qui compromet la disponibilité globale du service.
• Un autre risque est la dépendance à un protocole de consensus encore en phase de test, ce qui expose les participants à des vulnérabilités non découvertes ; si un défaut permettrait à un acteur malveillant de falsifier la disponibilité des blobs, les transactions dépendant de ces données pourraient être invalidées ou exécutées avec des informations erronées, entraînant des pertes financières.
• La réduction de la taille des blobs, tout en augmentant le volume de données transitant hors du bloc principal, crée une contrainte supplémentaire sur la bande passante des nœuds intermédiaires ; si la capacité réseau ne suffit pas, les nœuds pourraient ne plus pouvoir télécharger les blobs à temps, ce qui ralentirait la création de blocs et provoquerait des délais de confirmation plus longs, affectant l'expérience utilisateur.
• Enfin, l'implémentation de blobs introduit un champ de gouvernance supplémentaire, car les paramètres de taille et de fréquence des blobs doivent être ajustés en fonction de la demande ; une mauvaise gestion de ces paramètres peut conduire à une surcharge du réseau, à un coût d'opération accru pour les validateurs et à une fragmentation du réseau, compromettant la cohérence des données.

Comment vérifier concrètement

• Pour vérifier que les blobs sont correctement indexés, on peut exécuter un nœud full et interroger l'API RPC pour la présence d'un blob associé à un bloc donné ; cette opération ne révèle toutefois pas la cohérence interne des données contenues dans le blob.
• La validation de la preuve de disponibilité de blob peut se faire en simulant un client de consensus qui vérifie la présence d'un fragment de blob dans un segment de 4 KiB ; toutefois, le test reste indépendant de la persistance réelle des données sur le réseau.
• On peut inspecter l'empreinte cryptographique d'un blob via l'API eth_getBlobTransactionByHash afin de confirmer son intégrité ; cette méthode ne garantit pas l'absence de corruption lors du stockage sur les nœuds intermédiaires.
• Pour confirmer que les blobs ne consomment pas d'espace d'état permanent, on peut comparer la taille du state root avant et après l'insertion d'un blob ; cependant, cette vérification ne tient pas compte des éventuels frais de stockage sur les nœuds de longue durée.

Pour aller plus loin

Ces références officielles permettent de recouper les règles et les mises en garde ; elles ne valident pas un projet particulier.

• AMF — informations et prévention pour les épargnants
• Débuter en crypto
• Checklist avant transfert
• Assistant anti-arnaque
• SOS crypto

FAQ