Ethereum : les listes d’accès par bloc arrivent à leur échéance de dernière consultation

Une consultation sur l’organisation du travail des nœuds

Le document officiel de l’EIP-7928 indique le 1er novembre 2026 comme échéance de dernière consultation. Cette proposition Ethereum, créée le 31 mars 2025 et portée par plusieurs contributeurs, reste affichée au statut Last Call lors de la vérification. Elle décrit des listes d’accès à l’échelle du bloc, ou BAL, pour préciser quelles parties de l’état sont utilisées. La date du jour constitue donc un jalon de revue : elle ne prouve pas une adoption finale, ni une accélération déjà disponible sur le réseau principal.

Le problème visé est pratique. Pour traiter des opérations en parallèle, un nœud doit savoir à l’avance quels comptes et quelles cases de stockage elles vont consulter ou modifier. Les listes facultatives associées à certaines transactions ne donnent pas une garantie suffisante. Le projet propose un relevé obligatoire au niveau du bloc, incluant les accès effectifs et les valeurs résultant des changements. Le bénéfice attendu porte sur les lectures de disque, la validation et le calcul de la racine d’état.

Un inventaire qui doit correspondre à l’exécution

Le mécanisme ajouterait à l’en-tête du bloc une empreinte cryptographique de la liste. Les données détaillées seraient encodées séparément et transmises entre les couches de consensus et d’exécution par l’Engine API. Le nœud devrait ensuite vérifier que l’inventaire fourni correspond exactement aux accès réellement produits. Une liste manquante, incorrecte ou comportant des entrées injustifiées pourrait invalider le bloc. L’inventaire n’est donc pas une indication que le validateur devrait simplement croire.

La liste couvre les adresses consultées même lorsqu’elles ne subissent aucun changement, ainsi que les emplacements de stockage et les modifications de soldes, de code ou de compteurs. Elle distingue également les opérations précédant les transactions, celles des transactions elles-mêmes et celles intervenant après leur exécution. Des règles imposent un ordre déterministe et empêchent les doublons. Cette précision vise à permettre à différents logiciels de calculer la même représentation, condition nécessaire pour comparer leurs empreintes sans ambiguïté.

Des gains envisagés, avec des coûts supplémentaires

Le texte envisage notamment des lectures parallèles et une reconstruction de l’état à partir des changements enregistrés, sans rejouer chaque transaction pour cette reconstruction. Cela ne supprime pas l’obligation de vérifier la validité des blocs. Il cite une analyse de mille blocs d’octobre 2026, dans un cadre à 60 millions de gas, donnant une taille moyenne compressée d’environ 92,1 kibioctets pour les listes. Cet échantillon illustre un coût de données supplémentaire ; il ne constitue pas une garantie de performance pour tous les usages.

La proposition reconnaît aussi le risque de lectures de stockage artificielles qui imposeraient des entrées-sorties inutiles avant détection. Une limite liée au gas du bloc borne le nombre d’éléments, tandis que les clients doivent éviter de rejeter des listes pourtant valides. L’ajout modifie la structure des blocs et l’Engine API, et nécessiterait un hard fork. Pour les opérateurs, le dossier reste ainsi un compromis entre parallélisation, transmission de données et vérification. Le passage de la date du 1er novembre ne suffit pas à transformer ce travail de normalisation en déploiement achevé.