L'essai d'EIP-8411 d'Ethereum met en lumière les compromis de bande passante de la diffusion segmentée
Points clés
- •Un système de diffusion segmentée proposé dans le brouillon EIP-8411 a réduit le temps médian de propagation simulé d'une charge utile d'exécution de 1 Mio d'environ cinq secondes à environ 0,75 seconde lors de tests utilisant le vrai code Prysm et go-libp2p-pubsub.
- •La simulation a modélisé 500 nœuds avec une latence géographique et une bande passante de qualité domestique, en excluant délibérément les nœuds à haute bande passante des centres de données côté émission.
- •EIP-8411 remplace le sujet de gossip unique execution_payload d'EIP-7732 par un sujet execution_payload_chunks, permettant aux nœuds de vérifier et de transmettre des segments authentifiés indépendamment par rapport à une racine de Merkle incluse dans l'enchère d'exécution du builder.
- •La propagation plus rapide a entraîné des compromis : la conception segmentée de base a ajouté environ un tiers d'octets reçus en plus, tandis qu'une variante avec codage d'effacement Reed-Solomon a atteint la latence de queue la plus faible au prix d'une demande de bande passante accrue à la source.
- •Les développeurs ont demandé le statut Proposed for Inclusion pour EIP-8411 dans la mise à niveau du réseau Hegotá, bien que la discussion ACDC prévue n'ait pas encore eu lieu et qu'aucune décision d'inclusion n'ait été enregistrée au moment du rapport.

Les chercheurs d'Ethereum ont rapporté qu'un système de diffusion segmentée proposé dans le brouillon EIP-8411 a réduit le temps médian de propagation simulé d'une charge utile d'exécution de 1 Mio d'environ cinq secondes à environ 0,75 seconde, selon un article publié sur Ethereum Research.
La vitesse de propagation revêt une importance particulière dans un réseau à preuve d'enjeu, où les validateurs disposent d'une fenêtre limitée pour recevoir et vérifier chaque nouveau bloc avant de l'attester.
Le test a modélisé 500 nœuds avec une latence géographique, une capacité de téléversement de 50 Mbps et une capacité de téléchargement de 100 Mbps. La charge utile a été envoyée par un builder domestique plutôt que par un nœud à haute bande passante situé dans un centre de données, un choix qui a permis de tester les performances du système sans infrastructure de centre de données côté émission. Les chercheurs ont exécuté du vrai code Prysm et go-libp2p-pubsub sur un réseau simulé avec une horloge virtuelle, en répétant chaque mesure sur 10 configurations randomisées afin de ne pas dépendre d'une seule topologie.
Lorsque la charge utile complète a été envoyée en un seul message GossipSub, la moitié du réseau l'a reçue en environ cinq secondes, tandis que les nœuds les plus lents l'ont reçue en près de six secondes. La variante segmentée optimisée a ramené ces chiffres à environ 0,75 seconde et une seconde, respectivement.
EIP-8411 remplace l'attente de la charge entière par des diffusions segmentées
EIP-8411 remplace le sujet de gossip unique execution_payload d'EIP-7732 par un nouveau sujet execution_payload_chunks. Les nœuds n'ont plus besoin d'attendre la charge utile complète avant de la relayer. Ils peuvent plutôt vérifier et transmettre des segments authentifiés indépendamment au fur et à mesure de leur arrivée, en contrôlant chaque segment par rapport à une racine de Merkle incluse dans l'enchère d'exécution du builder.
La proposition a été ouverte le 4 septembre 2026 et demeure un EIP réseau au stade de brouillon non approuvé. Elle dépend également d'EIP-7732, la conception d'Ethereum institutionnalisant la séparation proposeur-builder, selon laquelle les builders construisent les charges ut d'exécution et les proposent aux proposeurs via des enchères d'exécution, séparant la construction de blocs de leur proposition.
Les résultats proviennent d'une simulation contrôlée utilisant un code client prototype, et non de mesures sur le mainnet d'Ethereum. Tout gain de performance en conditions réelles devrait donc encore être confirmé. Les chercheurs ont décrit leur branche comme « un harnais, pas une proposition ».
Les conclusions ont également été présentées dans une publication X :
Ethereum researchers just exposed the hidden dependency behind fast block propagation: datacenters. Then they removed them.
1 MiB payload. 500 nodes. Home-grade bandwidth. No high-bandwidth datacenter nodes.
GossipSub: ~5s median
Segmented propagation: ~0.75s
But the more… pic.twitter.com/cytAvwJtwr
— slymnogunc (@slymnogunc) September 17, 2026
https://x.com/slymnogunc/status/2100558704584151054?ref_src=twsrc%5Etfw
Une propagation plus rapide s'accompagne d'une surcharge réseau accrue
La couche de consensus d'Ethereum utilise GossipSub, un protocole de gossip de type publication-abonnement, pour diffuser les blocs et autres messages à travers son réseau pair-à-pair. Le modèle de gossip actuel peut créer un délai de stockage-transfert, car un nœud doit recevoir et valider l'intégralité d'un grand message avant de le relayer. La conception de base de niveau 1 utilise des segments de 16 Kio associés à une publication par lots. Lors des tests, elle a réduit le temps médian de propagation de 1 Mio de cinq secondes à moins d'une seconde. La latence de queue a également diminué, passant d'environ six secondes à un peu plus d'une seconde.
Le compromis a été d'environ un tiers d'octets reçus en plus par rapport à l'approche actuelle consistant à transmettre le message entier. Des variantes plus avancées ciblent directement cette surcharge d'octets dupliqués. Selon une approche appelée « disciplined pulls » (récupérations disciplinées), un nœud demande un segment manquant à un pair. Si ce pair ne répond pas dans les délais, le nœud se tourne vers un autre. Cela a réduit le trafic reçu à environ 1,5 copie de la charge utile par nœud. Toutefois, la latence de queue a augmenté lorsque des pairs retenaient des segments qu'ils avaient annoncés.
Un troisième niveau ajoute un codage d'effacement Reed-Solomon. Il a produit la latence de queue la plus faible lors des tests et a continué de fonctionner lorsque des pairs retenaient des segments. Le coût était une demande de bande passante accrue à la source.
Ce compromis est pertinent pour la feuille de route de mise à l'échelle d'Ethereum post-Glamsterdam. Des limites de gaz et des charges utiles d'exécution plus importantes devraient exercer une pression supplémentaire sur la bande passante des nœuds. Les chercheurs ont également identifié des questions ouvertes concernant le trafic de messages de contrôle, le coût CPU du traitement de nombreux messages plus petits, la gestion des files d'attente, le réglage des minuteries et la coordination entre clients.
L'ACDC examine EIP-8411 pour Hegotá
L'écosystème Ethereum a également discuté de l'inclusion possible de la proposition dans Hegotá, la mise à niveau du réseau attendue après Glamsterdam. Dans une publication X, Barnabé Monnot a écrit :
After a month of community outreach, @ethlabs_org is shipping a major piece on a faster Ethereum with faster L1 blocks, collecting perspectives from all corners of the ecosystem. Ethereum core developers are in the final stretches of deciding what to include in Hegotá, the…
— Barnabé Monnot | barnabé.eth (@barnabemonnot) September 17, 2026
Les développeurs d'Ethereum ont demandé le statut « Proposed for Inclusion » pour EIP-8411 dans Hegotá après l'échéance normale de PFI de Hegotá. « Proposed for Inclusion » (PFI) est le statut qui marque un EIP comme candidat pour une mise à niveau spécifique du réseau. L'ordre du jour de l'ACDC #187 prévoyait une discussion PFI le 17 septembre à 14h00 UTC. Au moment du rapport initial, toutefois, cet appel n'avait pas encore eu lieu et aucune décision d'inclusion n'avait été enregistrée.
Les implémentations prototypes pour Prysm et go-libp2p-pubsub ont déjà été publiées. Les chercheurs ont toutefois averti que les configurations avancées de codage d'effacement restent des fonctionnalités expérimentales d'environnement de test plutôt que des composants confirmés de la spécification minimale d'EIP-8411. Le fait qu'EIP-8411 devienne un élément de l'infrastructure de mise à l'échelle d'Ethereum dépend d'une future décision des développeurs principaux.