Introduction : situer les blobs dans Ethereum avant de les définir

Au sein d’Ethereum, chaque transaction ou contrat intelligent peut produire ou transmettre des données. Jusqu’à l’introduction récente d’EIP-4844 (une nouvelle mise à jour), le protocole ne faisait aucune distinction entre les différentes façons de stocker ces données. Toutes étaient enregistrées au sein des blocs de la chaîne de blocs du protocole et conservées indéfiniment par les nœuds du réseau. Cette caractéristique assurait une intégrité maximale des données, mais elle créait aussi une contrainte structurelle : plus les utilisateurs publiaient de données, plus le réseau grossissait, rendant l’exécution d’un nœud complet toujours plus exigeante et demandant en infrastructure.

Ce problème est devenu critique lorsque Ethereum a commencé à s’appuyer massivement sur des solutions de seconde couche (L2), comme les rollups. Ces chaînes de blocs exécutent des transactions, qui aurait dû être traiter sur Ethereum, hors de la chaîne principale, et publient uniquement les entrées et les sorties finales des transactions traitées. Avant EIP-4844, ces données étaient intégrées via le calldata, un champ de la transaction conçu à l’origine pour transmettre des paramètres à un contrat, et non comme espace de publication volumineux. Cependant, l’utilisation croissante du calldata faisait augmenter les frais d’utilisation du protocole et contribuait à la croissance permanente de la chaîne de blocs.

C’est dans ce contexte précis qu’apparaissent les blobs.

Définition 

Les blobs désignent, des ensembles de données introduits par la mise à jour EIP-4844 du protocole Ethereum afin de permettre la publication d’informations sans qu’elles soient intégrées au stockage permanent de la chaîne de blocs. Dans le fonctionnement normal du réseau, chaque bloc conserve de manière définitive les transactions validées et la mise à jour de l’état, c’est-à-dire l’ensemble des informations persistantes nécessaires au fonctionnement des comptes et des contrats intelligents du protocole. Les blobs s’en distinguent par deux caractéristiques fondamentales : d’une part, leur contenu n’est jamais inscrit dans un bloc et ne modifie pas l’état, ce qui signifie que le réseau ne les considère pas comme des données structurelles ou nécessaires à l’exécution future du protocole et d’autre part, leur présence est strictement temporaire, puisqu’ils ne sont conservés par les nœuds que pendant une période limitée, après laquelle leur contenu disparaît sans affecter l’intégrité de la chaîne. Afin que cette suppression n’empêche pas la vérification, seul un engagement cryptographique est enregistré dans le bloc (KZG), garantissant qu’un blob donné a existé et qu’il n’a pas été altéré. Les blobs constituent ainsi un mécanisme de publication de données non permanente mais vérifiable, permettant au protocole d’absorber un volume accru d’information sans augmenter la taille historique du réseau, tout en maintenant les exigences fondamentales de sécurité, de cohérence et de disponibilité propres à la chaîne de blocs.

Une solution à la croissance excessive des données

Dans l’architecture initiale d’Ethereum, la conservation permanente de toutes les données publiées constituait une limite structurelle. L’état, qui regroupe les soldes des comptes et le stockage des contrats intelligents, doit être disponible en continu afin de permettre l’exécution correcte des transactions. Parallèlement, les données publiées dans le calldataétaient également stockées indéfiniment, bien que leur fonction première ne soit pas de participer au fonctionnement futur du protocole, mais de rendre certaines opérations vérifiables. Cette situation est devenue problématique avec l’essor des solutions de seconde couche (L2), dont la sécurité repose sur la publication régulière de grandes quantités d’informations. Plus ces données étaient inscrites dans le calldata, plus la chaîne de blocs s’alourdissait de manière irréversible, augmentant les exigences matérielles pour les nœuds et menaçant l’accessibilité du réseau.
Les blobs ont été introduits afin de permettre la publication de données sans qu’elles soient intégrées au stockage permanent. Ils constituent un espace distinct dans lequel le réseau accepte des informations pour une durée limitée, suffisante pour garantir leur disponibilité et leur vérification, mais sans obligation de conservation indéfinie.

Fonctionnement technique et rôle des engagements cryptographiques

Un blob correspond à un ensemble de données attaché à une transaction spécifique, appelée blob-carrying transaction, dont le contenu n’est pas inscrit dans un bloc. Contrairement au calldata, qui est inclus dans l’historique et conservé définitivement, le blob est traité comme une donnée externe au bloc. Le protocole n’enregistre sur la chaîne que son engagement cryptographique, appelé KZG commitment.
Un engagement cryptographique est un mécanisme permettant de garantir qu’une information existait sous une forme donnée au moment de sa publication, sans que son contenu soit rendu public ni conservé indéfiniment. Ainsi, si un acteur souhaite vérifier un blob, il peut présenter les données accompagnées d’une preuve, et un nœud pourra confirmer leur authenticité en les comparant à l’engagement inscrit dans la chaîne de blocs.
Ce dispositif introduit pour la première fois une séparation explicite entre la vérifiabilité, qui demeure permanente car inscrite dans l’historique, et le stockage, qui devient temporaire. Il s’agit d’une évolution majeure de la gestion des données dans Ethereum, permettant de maintenir l’intégrité du protocole sans accroître sa taille historique.

Un stockage volontairement temporaire

Les nœuds conservent le contenu des blobs pour une durée limitée d’environ dix-huit jours, ce qui correspond au temps nécessaire pour que les données publiées soient mises à disposition, vérifiées et intégrées dans les mécanismes de sécurité des solutions de seconde couche (L2). Une fois ce délai écoulé, le contenu peut être supprimé sans compromettre la cohérence du réseau, puisque l’engagement cryptographique demeure inscrit dans la chaîne de blocs et continue d’assurer la preuve de leur existence passée.
Ce fonctionnement marque un changement conceptuel important dans lequel Ethereum admet désormais que certaines données n’ont pas vocation à être préservées indéfiniment, dès lors que leur intégrité peut être attestée de manière durable. Cette approche réduit ainsi l’accumulation de données volumineuses et limite la croissance des exigences de stockage pour les nœuds.

Un marché de frais séparé pour éviter la concurrence avec les transactions

Avant l’introduction d’EIP-4844, toutes les données publiées, y compris celles utilisées par les solutions de seconde couche (L2) étaient soumises au même mécanisme de tarification que des transactions ordinaires. L’usage intensif du calldata entraînait donc une hausse générale des frais, indépendamment du type d’activité concerné.
C’est pourquoi, les blobs s’accompagnent donc d’un marché de frais distinct, régi par sa propre dynamique d’offre et de demande, ce qui permet d’éviter que la publication de données externes ne perturbe le coût des transactions classiques. Cette séparation constitue un élément central de la stratégie de mise à l’échelle d’Ethereum qui admet que la chaîne principale se recentre sur son rôle de couche de vérification, tandis que l’exécution des transactions se déplace hors-chaîne, sans renchérir l’accès au réseau.

Position dans l’évolution d’Ethereum : une étape vers le danksharding

Le proto-danksharding introduit par EIP-4844 ne représente pas la phase finale du sharding des données, mais une étape intermédiaire visant à mettre en place les fondations cryptographiques, économiques et opérationnelles nécessaires à son déploiement futur. Le danksharding a pour objectif d’augmenter considérablement la capacité de publication des données sur Ethereum sans pour autant imposer aux nœuds la conservation ou le téléchargement de l’ensemble de l’historique.
Dans cette perspective, les blobs constituent une transition contrôlée qui permet d’accroître immédiatement la capacité de publication pour les solutions de seconde couche (L2) tout en préparant le réseau à une architecture plus scalable, sans compromettre la sécurité ni l’accessibilité du protocole.

Conclusion

Les blobs sont des segments de données de grande capacité introduits par EIP-4844 dans Ethereum afin de permettre la publication temporaire de données vérifiables sans inscription permanente dans la chaîne de blocs. Attachés à des transactions spécialisées et représentés on-chain par un engagement cryptographique de type KZG, ils sont conservés par les nœuds pour une durée limitée, disposent d’un marché de frais distinct et constituent une étape essentielle vers le danksharding, dont l’objectif est d’accroître la scalabilité du réseau tout en limitant les exigences de stockage et de validation.