Ethereum : l’EIP-7975 arrive au terme prévu de sa consultation sur les reçus de blocs

Une échéance pour le transport des reçus

L’EIP-7975, une proposition technique pour Ethereum, affiche le 1er novembre 2026 comme date limite de sa phase de dernière consultation, appelée Last Call. Le document porte toujours ce statut lors de notre vérification. Rédigé par Felix Lange, Jochem Brouwer et Giulio Rebuffo, il a été créé le 16 juin 2025. Le fait à suivre ce dimanche est donc cette échéance de revue, et non la création d’une proposition ou l’annonce d’une activation générale.

Le texte concerne la façon dont les logiciels de nœuds se transmettent les reçus de transactions. Son objectif est de permettre le téléchargement d’une liste de reçus en plusieurs parties, au lieu d’imposer qu’elle tienne dans une seule réponse. Le passage du protocole de communication eth/69 à eth/70 décrit cette nouvelle capacité. Il ne constitue pas, à lui seul, une preuve que tous les clients ou tous les nœuds l’utilisent déjà.

Éviter qu’une réponse dépasse la taille acceptée

Les auteurs expliquent qu’une hausse de la limite de gas des blocs peut augmenter la taille maximale de leurs listes de reçus. Dans certains scénarios, une réponse pourrait dépasser la limite de dix mébioctets couramment appliquée aux messages par les clients. Le document identifie alors un risque d’échec de synchronisation. Il décrit un problème potentiel de taille des échanges, sans annoncer qu’une panne générale d’Ethereum est en cours ou que cette limite a déjà été franchie partout.

Le mécanisme ajoute un indicateur précisant si la dernière liste renvoyée est incomplète. Le nœud peut ensuite demander les reçus restants dans une nouvelle requête, en indiquant où reprendre pour le premier bloc demandé. Cette pagination organise le transfert ; elle ne supprime pas les reçus et ne transforme pas une réponse partielle en liste complète. Elle permet au destinataire de poursuivre la récupération plutôt que de dépendre d’un message unique trop volumineux.

Des vérifications nécessaires sur les données partielles

Cette souplesse crée aussi une surface de risque supplémentaire. Une liste partielle ne peut pas être vérifiée immédiatement de la même manière qu’une liste entière contre la référence inscrite dans l’en-tête du bloc. La proposition prévoit donc des contrôles sur le nombre de reçus, leur taille par rapport à la limite de gas de la transaction correspondante et le volume total autorisé par celle du bloc. Découper les messages ne dispense pas de borner les données conservées avant leur validation.

Sur le plan de la compatibilité, les auteurs indiquent que les anciens clients peuvent continuer à utiliser eth/69 pendant le déploiement de la nouvelle version. Ils précisent également que cette proposition ne change pas les règles de consensus de la machine virtuelle Ethereum et ne nécessite pas de hard fork. Cela ne vaut toutefois ni adoption automatique ni calendrier de généralisation. Les prochaines preuves seront l’évolution du statut et la prise en charge effective par les logiciels ; la date de consultation ne suffit pas à affirmer une mise en service.