Définition

Le calldata constitue, dans Ethereum, l’espace utilisé pour transmettre à un contrat intelligent les informations nécessaires à l’exécution d’une transaction, sans qu’elles soient conservées dans l’état du réseau. Il s’agit d’un espace de données en lecture seule, qui n’est ni modifiable ni stocké dans l’état du réseau. Par “état”, on entend les informations permanentes qu’Ethereum conserve, comme les soldes et le stockage des contrats et qui ne sont pas temporaires. Le calldata sert donc principalement à fournir les éléments nécessaires à l’appel d’une fonction, par exemple son identifiant et ses paramètres, et disparaît une fois la transaction traitée, bien que son contenu reste inscrit de manière permanente dans l’historique du bloc auquel la transaction appartient. Cette caractéristique distingue le calldata du stockage contractuel, c’est-à-dire l’espace où un contrat enregistre de manière permanente les données qu’il souhaite conserver d’un bloc à l’autre, alors que le calldata ne sert qu’à transmettre des informations lors de l’exécution d’une transaction sans être retenu dans l’état. Elle le distingue également des blobs introduits par EIP-4844, dont le contenu n’est conservé que temporairement par le réseau avant d’être supprimé. Ainsi, le calldata constitue un mécanisme d’entrée transitoire sur le plan fonctionnel, mais permanent sur le plan historique, garantissant qu’une transaction exécutée peut toujours être vérifiée sans pour autant entraîner de modification persistante de l’état de la chaîne de blocs.

Les limites structurelles du calldata et l’apport d’EIP-4844

Le calldata occupe une place particulière dans l’architecture d’Ethereum : il permet de transmettre à un contrat les informations nécessaires à l’exécution d’une transaction sans être intégré à l’état du réseau. Toutefois, cette apparente simplicité fonctionnelle présente plusieurs limites structurelles dès lors que le calldata est utilisé pour publier des volumes importants de données. La première de ces limites tient à son caractère permanent : bien que le calldata ne soit pas stocké dans l’état, son contenu demeure inscrit de manière définitive dans l’historique des blocs. Cette permanence est appropriée pour vérifier l’exactitude de transactions passées, mais elle implique que tout octet publié contribue irréversiblement à l’accroissement de la taille de la chaîne de blocs. À mesure que l’activité du réseau augmente, cette accumulation élève les exigences de stockage et rend progressivement plus coûteuse l’exécution d’un nœud complet, ce qui menace l’accessibilité du protocole.

Une seconde limite réside dans l’absence de distinction entre les usages. Le calldata a été conçu pour accompagner ponctuellement l’exécution d’un contrat, mais il est devenu, avec l’essor des solutions de seconde couche (L2), un moyen de publier les données nécessaires à la vérification de leurs transactions. Or, cette utilisation détournée surchargeait involontairement le réseau puisque les données destinées à n’être consultées qu’une seule fois étaient conservées indéfiniment, alors même qu’elles ne jouaient aucun rôle dans l’exécution future du protocole. Enfin, parce que le calldata partageait le même mécanisme de tarification que les transactions classiques, toute augmentation de la demande, même issue des rollups, se traduisait par une hausse généralisée des frais, affectant les utilisateurs du réseau qui n’étaient pourtant pas concernés par ces publications.

L’EIP-4844 a été introduite pour répondre à ces limites. Plutôt que de modifier le comportement du calldata, elle crée un espace de données distinct, les blobs, permettant la publication d’informations sans qu’elles soient intégrées de manière permanente dans la chaîne de blocs. Le contenu d’un blob est accepté par le réseau pour une durée limitée, suffisante pour garantir sa disponibilité, tandis qu’un engagement cryptographique inscrit on-chain assure la vérifiabilité à long terme. Cette approche dissocie pour la première fois la conservation durable de la preuve de la conservation matérielle des données. En parallèle, l’introduction d’un marché de frais indépendant empêche la publication massifiée de données de perturber le coût des transactions ordinaires. L’EIP-4844 ne constitue un moyen de maintenir la croissance de l’activité d’Ethereum sans que celle-ci ne se traduise par une croissance irréversible de la data stocké dans la chaîne de blocs du protocole, tout en préparant l’évolution vers le danksharding et une mise à l’échelle durable.