Ethereum a quadruplé la durée de disponibilité des Block-Level Access Lists prévues pour Glamsterdam. Depuis le 19 octobre 2026, l’EIP-7928 impose 14 299 époques, contre 3 533 auparavant. Cette fenêtre représente environ 63,5 jours.
Le changement ne signifie pourtant pas systématiquement quatre fois plus de stockage pour chaque nœud. Les logiciels pourront conserver ces listes ou les régénérer. L’enjeu concerne surtout la reconstruction des données historiques.
Points clés sur Ethereum et l’EIP-7928 :
- Disponibilité prolongée : les BAL doivent rester accessibles pendant 14 299 époques, soit environ 63,5 jours.
- Stockage non systématique : les clients peuvent servir les listes depuis une base locale ou les reconstruire.
- Glamsterdam en préparation : le testnet Hoodi doit activer la mise à jour le 26 octobre, pas le mainnet.
Ethereum : pourquoi l’EIP-7928 passe à 63,5 jours
La modification a été fusionnée le 19 octobre dans le dépôt officiel des propositions techniques. Elle synchronise la disponibilité des BAL avec celle des données nécessaires aux clients de consensus.
De 3 533 à 14 299 époques pour les Block-Level Access Lists
Une époque comprend 32 créneaux, ou slots, d’environ douze secondes. La nouvelle durée atteint donc approximativement 63,5 jours. L’ancienne obligation couvrait près de 15,7 jours. Cette modification multiplie ainsi la période minimale par environ 4,05. Le nouveau seuil correspond à la valeur « HISTORY_PRUNE_EPOCHS » décrite dans l’EIP-4444.
Les Block-Level Access Lists, appelées BAL, décrivent les comptes et emplacements de stockage consultés pendant l’exécution d’un bloc. Elles enregistrent également des changements d’état. Le réseau peut exploiter ces informations pour préparer des lectures disque et des validations parallèles. L’EIP-7928 vise donc une infrastructure plus efficace, sans garantir immédiatement davantage de transactions par seconde.
Pourquoi les couches de consensus et d’exécution doivent coopérer
Un nœud complet combine généralement un client de consensus et un client d’exécution. Le premier peut éviter d’archiver une deuxième copie complète de certains anciens payloads. Il réclame alors les éléments manquants au second. Cette reconstruction nécessite les transactions, les retraits et la BAL du bloc concerné.
Avec seulement 3 533 époques de disponibilité, un décalage pouvait apparaître. Le consensus devait encore fournir certaines données alors que l’exécution pouvait avoir supprimé leurs listes. L‘EIP-7928 corrige cette incohérence de calendrier. Les méthodes « engine_getPayloadBodiesByHashV2 » et « engine_getPayloadBodiesByRangeV2" doivent désormais pouvoir fournir les BAL pendant cette fenêtre. Cette architecture cherche ainsi à préserver l’interopérabilité de ses logiciels.
L’EIP-7928 impose-t-elle quatre fois plus de stockage aux nœuds Ethereum ?
La nouvelle règle porte sur l’accessibilité des listes, pas sur leur conservation brute permanente. Plusieurs implémentations restent possibles.
Stockage direct ou régénération : deux stratégies possibles
Un client d’exécution peut conserver les BAL pour répondre rapidement aux demandes. Il peut aussi les recalculer à la demande, si les données requises existent encore. Le texte laisse ce choix technique ouvert. Dans le second cas, le besoin de stockage peut diminuer, mais le processeur doit effectuer davantage de travail.
Une stratégie de régénération n’est pas gratuite. Les demandes répétées peuvent accroître les accès disque et les calculs associés. Les performances dépendront des bases de données, des mécanismes de compression et des configurations. La proposition ne fixe donc aucun supplément universel en gigaoctets. Ce texte change une obligation de service, pas une taille physique garantie.
Pourquoi aucune estimation unique en gigaoctets ne tient
La documentation de l’EIP-8159 mentionne environ 70 Kio par BAL comme référence indicative. Une étude plus récente citée dans le dossier mesure 92,1 Kio compressés en moyenne sur 1 000 blocs. Les observations s’étendent de 8,6 à 191,4 Kio. Ces chiffres ne préjugent pas des futurs blocs.
La taille varie avec les transactions, la limite de gas et la compression. Sur le client Lodestar, une optimisation permet d’archiver certaines enveloppes autour d’un kilooctet. Ses développeurs évoquent une économie supérieure à 99 % sur cette archive spécifique. L’EIP-7928 soutient cette approche en garantissant l’accès aux BAL nécessaires. Ce gain ne concerne pas automatiquement tous les nœuds.
Ethereum Glamsterdam : calendrier, tests et conséquences
La modification de l’EIP-7928 reste une préparation technique. Glamsterdam n’est pas encore activé sur le réseau principal Ethereum. La proposition demeure au statut Last Call jusqu’au 1er novembre 2026.
Selon l’Ethereum Foundation, Sepolia a activé Glamsterdam le 6 octobre. Le prochain rendez-vous concerne Hoodi le 26 octobre à 17:42:48 UTC, à l’époque 132 352. Sa limite de gas doit atteindre 200 millions simultanément. Aucune date définitive n’est annoncée pour le mainnet Ethereum.
L’EIP-8159 complète l’EIP-7928 en organisant les échanges directs de BAL entre clients d’exécution. Les listes reçues sont vérifiées grâce à leur empreinte cryptographique inscrite dans les en-têtes. Cet échange facilite la synchronisation et les futurs traitements parallèles. Il ne signifie pas que chaque application bénéficiera immédiatement d’un gain mesurable.
Pour les exploitants de nœuds Ethereum, l’enjeu sera surtout la compatibilité des versions et des politiques de conservation. Le test Hoodi permettra d’éprouver ces interfaces dans des conditions supplémentaires. Les résultats devront précéder toute annonce définitive pour le mainnet.
Le changement central est qu’Ethereum exige une disponibilité plus longue des BAL, sans imposer partout leur stockage intégral. L’EIP-7928 facilite ainsi la reconstruction des payloads tout en laissant plusieurs choix d’implémentation.
FAQ : Ethereum et EIP-7928
L’EIP-7928 introduit les Block-Level Access Lists. Elles décrivent les accès et modifications d’état d’un bloc Ethereum pour faciliter les traitements parallèles.
Non. Elle quadruple la période de disponibilité des BAL, pas nécessairement leur espace disque. Les clients peuvent les stocker ou les régénérer.
Hoodi doit activer Glamsterdam le 26 octobre 2026 à 17:42:48 UTC. Aucune date de déploiement sur Ethereum mainnet n’est fixée.
Sources : Ethereum EIPs, modification fusionnée le 19 octobre, spécification EIP-7928, EIP-4444, EIP-8159 et Ethereum Foundation, calendrier de Hoodi. Situation au 20 octobre 2026.
Disclaimer : article informatif, sans conseil en investissement. Les spécifications Ethereum peuvent encore évoluer avant le déploiement sur le réseau principal.
