La synchronisation des nœuds Ethereum réduite à moins d'une demi-journée grâce aux optimisations de l'EIP-4444
Points clés
- •L'EIP-4444 a été activé le 8 juillet 2025, permettant aux clients d'exécution d'Ethereum de supprimer les données historiques antérieures à la transition vers la preuve d'enjeu de septembre 2022.
- •La mise à niveau réduit les besoins de stockage des nœuds de 300 à 500 Go et permet aux nouveaux nœuds de se synchroniser entièrement en moins d'une demi-journée, certaines configurations fonctionnant avec moins de 0,5 To de stockage total.
- •Le mécanisme d'expiration partielle de l'historique visait initialement environ 33 000 epochs de rétention des données avant d'être révisé à environ 82 000 epochs, soit environ un an d'historique de la chaîne.
- •Les cinq principaux clients d'exécution d'Ethereum — Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12 et Reth v1.5.0 — ont publié la prise en charge de cette fonctionnalité.
- •Les nœuds d'archive qui servent les requêtes historiques des explorateurs de blocs et des plateformes d'analyse continueront de stocker toutes les données, tandis que le Portal Network et d'autres solutions pair-à-pair similaires sont conçus pour maintenir l'historique purgé récupérable pendant la transition.

Suite à l'activation de l'EIP-4444 le 8 juillet 2025, les clients d'exécution d'Ethereum peuvent désormais purger les données historiques créées avant la Merge — la transition du réseau vers la preuve d'enjeu en septembre 2022 — réduisant les besoins de stockage de 300 à 500 Go et permettant aux nouveaux nœuds de se synchroniser en moins d'une demi-journée. Avec des paramètres agressifs, les opérateurs peuvent faire fonctionner un nœud entièrement fonctionnel sur un disque de 2 To tout en maintenant le stockage total en dessous de 0,5 To.
Ce que l'EIP-4444 change réellement
Cette amélioration repose sur ce que l'on appelle « l'expiration partielle de l'historique ». Plutôt que d'exiger de chaque nœud qu'il stocke l'historique complet de la blockchain Ethereum, l'EIP-4444 permet aux nœuds de supprimer les données plus anciennes après une période de rétention définie. La conception initiale prévoyait environ 33 000 epochs — chacune étant une unité de temps de consensus de 6,4 minutes — un chiffre ensuite révisé à environ 82 000 epochs, soit environ un an d'historique de la chaîne.
La validation de la tête de chaîne actuelle repose sur des points de contrôle de subjectivité faible, des états récents que les clients obtiennent d'une source de confiance au lieu de vérifier toute la chaîne depuis la genèse. La couche de consensus peut devenir opérationnelle en quelques minutes grâce à la synchronisation par point de contrôle, tandis que la couche d'exécution n'a plus besoin de télécharger et de vérifier une décennie de reçus de transactions. Pour les opérateurs nécessitant un accès aux archives, les mécanismes de récupération des données historiques restent disponibles en tant que fonctionnalité optionnelle.
Les cinq principaux clients d'exécution d'Ethereum ont déployé la prise en charge. Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12 et Reth v1.5.0 incluent chacun les options et configurations nécessaires.
Pourquoi le stockage devenait un problème
Avant l'EIP-4444, un nœud complet nécessitait plus de 400 Go d'espace disque, et ce chiffre ne pouvait qu'augmenter. Chaque nouveau bloc, chaque interaction avec un contrat intelligent, chaque transfert de jeton sajoutait au total.
Une distinction importante s'impose : ce changement concerne les nœuds complets et les validateurs, et non les nœuds d'archive. Les nœuds d'archive, qui servent les requêtes historiques des explorateurs de blocs et des plateformes d'analyse, continueront de tout stocker.
L'équation de l'accessibilité
Une synchronisation en moins d'une demi-journée avec moins de 0,5 To de stockage signifie qu'une machine grand public relativement modeste dotée d'un bon SSD peut participer au réseau Ethereum. Pour les opérateurs, cela se traduit par la possibilité de vérifier les transactions et les soldes sur leur propre matériel plutôt que de dépendre de fournisseurs tiers. Cela contraste avec les processus de synchronisation de plusieurs jours et les besoins de stockage de plus d'un téraoctet auxquels étaient auparavant confrontés les nouveaux opérateurs de nœuds.
L'EIP-4444 s'inscrit dans la phase « Purge » de la feuille de route d'Ethereum, que Vitalik Buterin a décrite comme axée sur la réduction de la complexité du protocole et des exigences des nœuds.
La question restante est de savoir comment le réseau gérera la période de transition alors que les nœuds commencent à purger à des rythmes différents et que les données historiques deviennent distribuées plutôt que répliquées universellement. Le Portal Network et d'autres solutions de disponibilité des données en pair-à-pair sont conçus pour combler cette lacune, garantissant que les requêtes historiques pourront toujours être résolues même lorsque la plupart des nœuds seront passés à autre chose.
Source : CryptoBriefing