
Paradigm : Analyse détaillée des problèmes historiques de croissance d'Ethereum et de leurs solutions
TechFlow SélectionTechFlow Sélection

Paradigm : Analyse détaillée des problèmes historiques de croissance d'Ethereum et de leurs solutions
EIP-4444 permet de résoudre le problème de croissance historique d'Ethereum et libère de la place pour une augmentation du plafond de gaz.
Rédaction : Storm Slivkoff, Georgios Konstantopoulos
Traduction : Luffy, Foresight News
La croissance historique (history growth) est actuellement le principal goulot d'étranglement du scaling d'Ethereum. De manière inattendue, elle est devenue un problème encore plus important que la croissance de l'état. Dans quelques années, les données historiques dépasseront la capacité de stockage de nombreux nœuds Ethereum.
La bonne nouvelle est que :
-
la croissance historique est un problème plus facile à résoudre que la croissance de l'état ;
-
des solutions sont déjà en cours de développement actif ;
-
résoudre la croissance historique atténuera également le problème de croissance de l'état.
Dans cet article, nous poursuivons notre analyse des problèmes de scaling d'Ethereum abordés dans la partie 1, en recentrant désormais notre attention de la croissance de l'état vers la croissance historique. À l’aide d’un ensemble de données précis, notre objectif est 1) de comprendre techniquement les goulots d’étranglement du scaling d’Ethereum et 2) d’éclairer le débat sur la limite optimale de gaz d’Ethereum.
Qu'est-ce que la croissance historique ?
L'historique désigne l'ensemble des blocs et transactions exécutés par Ethereum tout au long de sa vie, depuis le bloc de genèse jusqu’au bloc actuel. La croissance historique correspond à l’accumulation continue de nouveaux blocs et nouvelles transactions au fil du temps.
La figure 1 illustre les relations entre la croissance historique, divers indicateurs de protocole et les contraintes matérielles des nœuds Ethereum. Contrairement à la croissance de l’état, la croissance historique est limitée par un ensemble différent de contraintes matérielles. Elle exerce une pression sur l’entrée/sortie réseau (IO), car les nouveaux blocs et transactions doivent être transmis à travers tout le réseau. Elle sollicite également l’espace de stockage des nœuds, chaque nœud Ethereum conservant une copie complète de l’historique. Si la croissance historique devient trop rapide et dépasse ces limites matérielles, les nœuds ne pourront plus maintenir un consensus stable avec leurs pairs. Pour un aperçu de la croissance de l’état et d’autres goulots d’étranglement, voir la partie 1 de cette série.

Figure 1 : Goulots d’étranglement du scaling d’Ethereum
Jusqu’à récemment, la majeure partie du débit réseau de chaque nœud était consacrée à la transmission de l’historique (par exemple, nouveaux blocs et transactions). Cette situation a changé avec l’introduction des blobs lors du hard fork Dencun. Les blobs occupent désormais une part importante de l’activité réseau des nœuds. Toutefois, les blobs ne font pas partie de l’historique, car 1) ils ne sont stockés par les nœuds que pendant deux semaines avant d’être supprimés, et 2) ils ne nécessitent pas de rejouer toutes les données depuis la genèse d’Ethereum. En raison du point (1), les blobs n’alourdissent pas significativement la charge de stockage des nœuds Ethereum. Nous reviendrons sur les blobs plus tard dans cet article.
Cet article se concentre sur la croissance historique et examine la relation entre historique et état. Bien que ces deux aspects partagent certaines contraintes matérielles communes, ils sont liés : résoudre l’un peut aider à résoudre l’autre.
À quelle vitesse croît l’historique ?
La figure 2 montre le taux de croissance historique depuis la genèse d’Ethereum. Chaque ligne verticale représente une augmentation mensuelle. L’axe des y indique la croissance mensuelle en gigaoctets. Les transactions sont classées selon leur « adresse cible » et mesurées en taille d’octets RLP (RLP). Les contrats non identifiables sont regroupés sous la catégorie « inconnu ». La catégorie « autre » inclut diverses petites catégories comme les infrastructures et les jeux.

Figure 2 : Évolution du taux de croissance historique d’Ethereum
Plusieurs points clés émergent de ce graphique :
-
La croissance historique est 6 à 8 fois plus rapide que celle de l’état : le pic récent atteint 36,0 Gio/mois, contre 19,3 Gio/mois actuellement. Le pic de croissance de l’état était d’environ 6,0 Gio/mois, avec une moyenne actuelle de 2,5 Gio/mois. Une comparaison plus détaillée entre historique et état sera présentée plus loin.
-
Avant Dencun, la croissance historique s’accélérait : alors que l’état croissait de façon quasi linéaire depuis des années (voir partie 1), l’historique suivait une croissance superlinéaire. Une croissance linéaire du taux de croissance entraîne une croissance quadratique globale ; une croissance superlinéaire conduit donc à une expansion encore plus rapide. Cette accélération s’est brutalement arrêtée après Dencun, marquant la première baisse significative du taux de croissance historique dans l’histoire d’Ethereum.
-
Les Rollups étaient la principale source de croissance historique récente : chaque couche 2 (L2) publie une copie de ses transactions sur la chaîne principale, générant ainsi une grande quantité de données historiques. Cependant, Dencun permet désormais aux L2 d’utiliser des blobs plutôt que l’historique pour publier leurs données, réduisant considérablement leur impact. Nous reviendrons plus en détail sur les rollups plus loin.
Qui contribue le plus à la croissance historique d’Ethereum ?
La répartition de la croissance historique par catégorie de contrat reflète l’évolution des usages d’Ethereum. La figure 3 présente la contribution relative des différentes catégories de contrats, en normalisant les mêmes données que celles de la figure 2.

Figure 3 : Contribution des différentes catégories de contrats à la croissance historique
Ces données révèlent quatre périodes distinctes dans l’usage d’Ethereum :
-
Débuts (violet) : les premières années d’Ethereum ont été marquées par peu d’activités. La plupart de ces contrats anciens sont aujourd’hui difficiles à identifier, classés ici comme « inconnus ».
-
Ère ERC-20 (vert) : bien que la norme ERC-20 ait été finalisée fin 2015, elle n’a pris de l’ampleur qu’en 2017-2018, devenant la principale source de croissance historique en 2019.
-
Ère DEX / DeFi (marron) : les contrats DEX et DeFi existent depuis 2016 et ont commencé à attirer l’attention en 2017. Ce n’est toutefois qu’avec l’été DeFi 2020 qu’ils sont devenus la catégorie dominante. Entre 2021 et 2022, ils représentaient plus de 50 % de la croissance historique.
-
Ère des Rollups (gris) : début 2023, les L2 ont commencé à traiter plus de transactions que la chaîne principale. Dans les mois précédant Dencun, ils généraient environ les deux tiers de l’historique d’Ethereum.
Chaque ère marque une complexité croissante dans l’usage d’Ethereum. Cette évolution vers des cas d’usage plus sophistiqués constitue une forme de scaling qui ne peut être mesurée simplement par le nombre de transactions par seconde.
En avril 2024, les rollups ne constituent plus la majorité de la croissance historique. On ignore encore si les DEX et la DeFi redeviendront dominants ou si de nouveaux modèles d’usage émergeront.
Et les blobs, alors ?
Le hard fork Dencun a introduit les blobs, transformant radicalement la dynamique de croissance historique en permettant aux rollups de publier leurs données via des blobs bon marché au lieu de l’historique. La figure 4 zoome sur la période autour de Dencun. Ce graphique est similaire à la figure 2, mais chaque barre verticale représente un jour au lieu d’un mois.

Figure 4 : Impact de Dencun sur la croissance historique
Plusieurs conclusions peuvent être tirées :
-
Depuis Dencun, la croissance historique des rollups a chuté d’environ deux tiers : la plupart ont migré des données d’appel (call data) vers les blobs, réduisant fortement leur empreinte historique. Toutefois, certains rollups utilisaient encore les données d’appel en avril 2024.
-
La croissance totale de l’historique a baissé d’environ un tiers : Dencun n’a affecté que les rollups. Les autres catégories ont vu une légère hausse. Même après Dencun, la croissance historique reste huit fois supérieure à celle de l’état (voir section suivante).
Bien que les blobs aient ralenti la croissance historique, ils restent une fonctionnalité récente. Il est encore incertain à quel niveau le taux de croissance va se stabiliser.
Quelle croissance historique est acceptable ?
Augmenter la limite de gaz accroît le taux de croissance historique. Ainsi, toute proposition visant à relever cette limite (comme Pump the Gas) doit tenir compte des contraintes matérielles des nœuds.
Pour déterminer un taux acceptable, il faut d’abord évaluer combien de temps le matériel actuel peut supporter la situation. Le réseau pourrait probablement continuer indéfiniment, car il est peu probable que la croissance historique retrouve ses pics pré-Dencun. En revanche, la charge de stockage augmente constamment. Avec la stratégie actuelle, les disques durs des nœuds seront inévitablement saturés par l’historique.
La figure 5 montre l’évolution de la charge de stockage des nœuds Ethereum et projette son évolution sur trois ans, en se basant sur le taux d’avril 2024. Ce taux pourrait varier selon les futurs changements d’usage ou de limite de gaz.

Figure 5 : Taille de l’historique, de l’état et de la charge de stockage des nœuds complets
Plusieurs observations clés :
-
L’historique occupe environ trois fois plus d’espace que l’état. Cet écart devrait s’agrandir, puisque la croissance historique est huit fois plus rapide.
-
1,8 Tio est un seuil critique : de nombreux nœuds devront alors mettre à niveau leur disque dur. Un disque de 2 To offre seulement 1,8 Tio d’espace utilisable. Notez que TB (10¹² octets) et TiB (1024⁴ octets) sont des unités différentes. Pour beaucoup d’opérateurs de nœuds, le seuil réel est encore plus bas, car les validateurs post-fusion doivent exécuter simultanément un client de consensus avec le client d’exécution.
-
Ce seuil sera atteint dans 2 à 3 ans. Toute augmentation de la limite de gaz accélérera ce délai. Atteindre ce seuil imposera une charge de maintenance non négligeable et nécessitera l’achat de matériel supplémentaire (par exemple, un disque NVMe à 300 $).
Contrairement aux données d’état, les données historiques sont append-only et rarement consultées. Elles pourraient donc théoriquement être stockées séparément sur des supports moins coûteux. Certains clients comme Geth permettent déjà cela.
Outre la capacité de stockage, l’IO réseau est une autre contrainte majeure. Contrairement au stockage, elle ne posera pas de problème immédiat, mais deviendra cruciale si la limite de gaz augmente.
Pour évaluer combien de croissance historique un nœud typique peut supporter, il faut analyser les relations entre cette croissance et des indicateurs de santé réseau comme le taux de réorganisations, les manques de slot, les manques de finalisation, les manques de preuve ou de comité de synchronisation, ou encore les retards de soumission de blocs. Cette analyse dépasse le cadre de cet article, mais des informations complémentaires sont disponibles dans des études antérieures sur la santé de la couche de consensus. Par ailleurs, le projet Xatu de la Fondation Ethereum construit des jeux de données publics pour faciliter ces analyses.
Comment résoudre la croissance historique ?
La croissance historique est un problème plus simple à régler que celui de l’état. Elle pourrait presque entièrement être résolue par la proposition EIP-4444. Cette EIP modifierait chaque nœud pour qu’il ne conserve plus l’historique complet, mais seulement les données des douze derniers mois. Après mise en œuvre d’EIP-4444, le stockage ne serait plus un goulot d’étranglement du scaling d’Ethereum, et des augmentations futures de la limite de gaz ne seraient plus contraintes. EIP-4444 est essentielle à la durabilité à long terme du réseau ; sans elle, la croissance historique obligerait à des remplacements matériels réguliers.
La figure 6 montre l’impact d’EIP-4444 sur la charge de stockage des nœuds au cours des trois prochaines années. Identique à la figure 5, elle ajoute des lignes plus claires représentant la charge après mise en œuvre d’EIP-4444.

Figure 6 : Impact d’EIP-4444 sur la charge de stockage des nœuds Ethereum
Observations principales :
-
EIP-4444 diviserait par deux la charge actuelle de stockage, passant de 1,2 Tio à 633 Gio.
-
EIP-4444 stabiliserait la charge historique de stockage : si le taux de croissance reste constant, les données seraient supprimées au même rythme qu’elles sont produites.
-
Après EIP-4444, il faudrait de nombreuses années pour que la charge de stockage atteigne les niveaux actuels, car seule la croissance de l’état contribuerait désormais à cette augmentation — et elle est nettement plus lente.
Même après EIP-4444, les nœuds conserveraient un an d’historique, ce qui reste gérable même à une échelle mondiale. Une fois la méthode validée, la durée de conservation pourrait être réduite à quelques mois, voire semaines.
Comment sauvegarder l’historique d’Ethereum ?
EIP-4444 soulève une question : si les nœuds ne conservent plus l’historique, où sera-t-il stocké ? L’historique est crucial pour la vérification, la comptabilité et l’analyse d’Ethereum. Heureusement, sa préservation est un problème simple, nécessitant seulement 1/n fournisseurs honnêtes de données — contrairement au consensus d’état, qui exige 1/3 à 2/3 de participants honnêtes. Un nœud peut vérifier l’authenticité d’un jeu de données historiques en 1) rejouant toutes les transactions depuis la genèse et 2) confirmant qu’elles aboutissent à la même racine d’état que la chaîne actuelle.
Plusieurs méthodes sont envisageables :
-
Torrents/P2P : les torrents sont la méthode la plus simple et robuste. Les nœuds pourraient régulièrement archiver des tranches d’historique et les partager via des fichiers torrent publics (ex. un nouveau fichier tous les 100 000 blocs). Des clients comme Erigon effectuent déjà partiellement ce processus, mais de façon non standardisée. Pour l’uniformiser, tous les clients devraient adopter le même format, paramètres et réseau P2P. Les nœuds choisiraient librement leur participation selon leur capacité. L’avantage : un standard ouvert éprouvé, bien supporté par les outils existants.
-
Réseau Portal : le Réseau Portal est un nouveau réseau conçu pour héberger les données Ethereum. Similaire aux torrents, il offre des fonctions supplémentaires facilitant la vérification. Son avantage : ces couches de validation offrent une utilité aux clients légers, leur permettant d’interroger efficacement les jeux de données.
-
Hébergement cloud : des services comme S3 d’AWS ou R2 de Cloudflare offrent des solutions performantes et économiques. Toutefois, cela implique des risques juridiques et opérationnels, car rien ne garantit que ces services accepteront toujours d’héberger des données cryptographiques.
Les défis restants sont davantage sociaux que techniques. La communauté Ethereum doit coordonner les détails d’implémentation pour intégrer ces solutions directement dans chaque client. En particulier, la synchronisation complète depuis la genèse (plutôt que par snapshot) devra récupérer l’historique depuis des fournisseurs externes. Ces modifications ne nécessitent pas de hard fork, et pourraient donc être déployées avant le prochain hard fork Pectra.
Ces méthodes de sauvegarde historique pourraient aussi être utilisées par les L2 pour stocker leurs blobs publiés sur la chaîne principale. Toutefois, la sauvegarde des blobs est 1) plus difficile en raison du volume massif de données, et 2) moins critique, car les blobs ne sont pas nécessaires pour rejouer l’historique principal. Ils restent indispensables pour que chaque L2 puisse rejouer son propre historique. Ainsi, une forme de sauvegarde des blobs est importante pour l’écosystème Ethereum. En outre, si les L2 développent une infrastructure solide de stockage de blobs, ils pourraient aussi facilement conserver les données historiques de la L1.
Une comparaison directe des jeux de données stockés par différents types de nœuds, avant et après EIP-4444, serait utile. La figure 7 illustre la charge de stockage selon les types de nœuds Ethereum. Les données d’état comprennent les comptes et contrats, les données historiques les blocs et transactions, et les données d’archive un ensemble d’index optionnels. Les tailles sont basées sur un snapshot récent de Reth, mais les autres clients devraient afficher des valeurs similaires.

Figure 7 : Charge de stockage selon les types de nœuds Ethereum
Autrement dit :
-
Les nœuds archive stockent les données d’état, historiques et d’archive. Ils servent quand on a besoin d’interroger facilement l’état historique de la chaîne.
-
Les nœuds complets stockent uniquement les données d’état et historiques. La plupart des nœuds actuels sont de ce type. Leur charge de stockage est environ la moitié de celle d’un nœud archive.
-
Les nœuds complets post-EIP-4444 stockeront les données d’état et l’historique des douze derniers mois seulement. Cela réduit la charge de 1,2 Tio à 633 Gio et stabilise la taille de l’historique.
-
Les nœuds sans état, ou « nœuds légers », ne stockent aucune donnée et peuvent valider instantanément à la pointe de la chaîne. Ce type deviendra possible une fois que Verkle ou un autre schéma de preuve d’état sera intégré à Ethereum.
Enfin, plusieurs autres EIP peuvent limiter le taux de croissance historique, au-delà de l’adaptation passive. Elles aideraient à rester dans les limites d’IO réseau à court terme, et dans celles de stockage à long terme. Bien qu’EIP-4444 reste indispensable à la durabilité, ces autres EIP permettraient à Ethereum de scaler plus efficacement :
-
EIP-7623 : réévalue le prix des données d’appel, rendant plus coûteuses les transactions très gourmandes en call data. Cela poussera certains usages à migrer vers les blobs, réduisant ainsi la croissance historique.
-
EIP-4488 : impose une limite au volume total de call data par bloc, plaçant une borne stricte sur la croissance historique.
Ces EIP sont plus faciles à implémenter qu’EIP-4444 et pourraient servir de solution temporaire avant son déploiement.
Conclusion
Cet article vise à comprendre 1) le fonctionnement de la croissance historique et 2) les solutions possibles, grâce à des données concrètes. Beaucoup de ces données sont difficiles à obtenir par des moyens traditionnels, et nous espérons que leur publication apporte un nouvel éclairage sur ce problème.
La croissance historique, comme goulot d’étranglement du scaling d’Ethereum, n’a pas encore reçu l’attention qu’elle mérite. Même sans augmenter la limite de gaz, la pratique actuelle d’Ethereum obligera de nombreux nœuds à mettre à niveau leur matériel dans quelques années. Heureusement, la solution existe déjà : EIP-4444. Nous pensons qu’il faut accélérer sa mise en œuvre afin de libérer de la marge pour de futures augmentations de la limite de gaz.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News














