Des chercheurs d'Ethereum ont rapporté une propagation médiane inférieure à une seconde pour une charge utile d'exécution simulée de 1 Mio utilisant la conception de diffusion segmentée de l'EIP-8411, contre environ cinq secondes lors de l'envoi de la charge utile en un seul message.
Résumé
- Les tests réduisent la propagation médiane pour une charge utile de 1 Mio de cinq secondes à moins d'une seconde.
- L'EIP-8411 divise les charges utiles d'exécution en morceaux que les nœuds peuvent vérifier et transmettre avant l'achèvement complet.
- Une racine de Merkle dans l'offre d'exécution permet aux nœuds de valider chaque segment de charge utile reçu indépendamment.
- Les tests du prototype ont utilisé 500 nœuds simulés, une bande passante de constructeur domestique, une latence géographique et dix graines de réseau aléatoires.
- Les développeurs d'Ethereum discuteront de l'EIP-8411 pour son inclusion dans Hegotá lors de l'ACDC le 17 septembre 2026 aujourd'hui.
Ethereum Research a publié les derniers résultats de tests le 17 septembre, détaillant un prototype qui divise les charges utiles d'exécution en morceaux plus petits afin que les nœuds puissent vérifier et transmettre chaque segment avant de recevoir la charge utile complète. Les conclusions proviennent de simulations et de code client prototype, et non de mesures sur le réseau principal Ethereum.
La proposition reste un EIP de réseau à l'état de brouillon dans le dépôt des EIP d'Ethereum. Sa conception actuelle remplace le sujet de gossip unique execution_payload introduit par l'EIP-7732 par un sujet execution_payload_chunks et engage les morceaux via une racine de Merkle incluse dans l'offre d'exécution du constructeur.
L'EIP-8411 d'Ethereum supprime l'attente de la charge utile complète
Le modèle de gossip existant d'Ethereum peut exiger qu'un nœud reçoive et valide un grand message avant de le transmettre à ses pairs. Les chercheurs derrière l'EIP-8411 décrivent le délai résultant comme un problème de stockage et de transmission, car la charge utile complète doit franchir un saut réseau avant de commencer le suivant.
Avec la propagation segmentée, un constructeur divise la charge utile en morceaux fixes. Chaque segment porte une preuve d'inclusion de Merkle liée à la racine engagée dans l'offre d'exécution. Un nœud récepteur peut vérifier un segment et commencer à le transmettre tandis que les autres morceaux arrivent encore.
De plus, la discussion de l'EIP sur Ethereum Magicians décrit le changement prévu comme le remplacement du message de charge utile unique de l'EIP-7732 par des morceaux vérifiables indépendamment. Le brouillon propose actuellement 64 morceaux et une structure de preuve de Merkle qui lie chaque morceau à l'engagement de charge utile original. Les chercheurs ont déclaré que l'engagement de Merkle représente le principal ajout au niveau du consensus requis pour la segmentation de base. Le dernier prototype de recherche conserve le format de fil gossipsub existant, la construction du maillage réseau, le degré des pairs et le système de notation intacts tout en modifiant la façon dont les morceaux de charge utile sont publiés et transmis.
La documentation d'Ethereum décrit actuellement les charges utiles d'exécution comme des données liées aux transactions et à l'état générées par le client d'exécution et transportées tout au long du processus de consensus. Les validateurs reçoivent les blocs proposés via le réseau de gossip de consensus avant d'envoyer les données d'exécution à leurs clients d'exécution pour validation.
La simulation réduit la médiane de 1 Mio de cinq secondes
Les chiffres de performance les plus forts du rapport du 17 septembre proviennent d'une simulation contrôlée. Les chercheurs ont modélisé 500 nœuds en utilisant une latence réseau géographique, une capacité de téléchargement de 50 Mbps et une capacité de téléchargement de 100 Mbps, avec une charge utile de 1 Mio provenant d'un constructeur domestique et aucun nœud de centre de données à haut débit.
Dans cette configuration, l'envoi de la charge utile en un seul message gossipsub complet a pris environ cinq secondes pour atteindre la moitié des nœuds récepteurs et près de six secondes en queue. Une version segmentée optimisée a atteint une médiane proche de 0,75 seconde et une queue proche d'une seconde.
Les chercheurs soulignent que les mesures proviennent d'un harnais de simulation exécutant du code réel Prysm et go-libp2p-pubsub contre un réseau simulé et une horloge virtuelle. Chaque mesure a utilisé dix configurations réseau aléatoires. Les conditions du réseau principal pourraient différer de la topologie, de la bande passante et des hypothèses de trafic modélisées.
Leur conception de base de niveau 1 combine la segmentation avec la publication par lots. En utilisant des segments de 16 Kio, le rapport indique que la propagation médiane pour une charge utile de 1 Mio est passée de cinq secondes à moins d'une seconde, tandis que la latence de queue est tombée d'environ six secondes à un peu plus d'une seconde.
La publication par lots modifie la façon dont la source envoie les morceaux. Au lieu d'envoyer chaque copie d'un segment avant de commencer le suivant, le constructeur distribue tôt différents morceaux à différents pairs, permettant à plusieurs sections de la charge utile de commencer à circuler simultanément dans le réseau. Les chercheurs ont déclaré que le niveau 1 nécessitait environ un tiers de plus d'octets reçus que l'approche actuelle par message complet. Le compromis provient de l'envoi de nombreux morceaux identifiés indépendamment et des messages de contrôle supplémentaires nécessaires pour les annoncer.
Des niveaux plus avancés réduisent le trafic réseau en double
Un deuxième niveau proposé s'attaque aux données en double. Au lieu de pousser chaque segment vers tous les pairs éligibles du maillage, les nœuds peuvent pousser des morceaux vers un groupe limité tout en annonçant leur disponibilité aux autres. Les pairs ne demandent les segments manquants que lorsque cela est nécessaire.
Le prototype combine ce système avec ce que ses auteurs appellent des tirages disciplinés. Un nœud demande initialement un segment à un pair, attend un délai défini et se tourne vers une autre source si le premier pair ne parvient pas à le fournir.
Avec une taille de charge utile de 1 Mio, la recherche indique que les tirages disciplinés ont réduit le trafic reçu à environ 1,5 copie de charge utile par nœud, contre beaucoup plus de trafic en double dans des variantes moins contrôlées. Les chercheurs ont constaté que la réduction des doublons devenait de plus en plus utile lorsque la bande passante de téléversement disponible était limitée.
L'approche crée un autre compromis. Un pair malveillant ou surchargé pourrait annoncer un segment puis refuser de le fournir. Les chercheurs ont testé un scénario de rétention dans lequel certains nœuds annonçaient des segments mais ne répondaient pas aux demandes. À des niveaux de rétention plus élevés, la conception ajustée basée sur les tirages a montré une latence de queue croissante. Les auteurs ont testé des délais plus courts et plusieurs sources de demande possibles comme méthodes pour limiter cette exposition.
Leur troisième niveau ajoute le codage par effacement Reed-Solomon. Une charge utile est compressée, encodée avec des morceaux de parité supplémentaires et divisée en segments. Les nœuds peuvent reconstruire la charge utile après avoir collecté suffisamment de morceaux sans attendre chaque segment d'origine.
Les chercheurs ont déclaré que le modèle codé avait la latence de queue la plus faible dans leurs tests et restait fonctionnel lorsque certains segments étaient retenus. Le coût était une bande passante plus élevée à la source de publication, car les données de parité augmentent la quantité envoyée.
EIP-8411 fait maintenant face à une discussion d'inclusion dans Hegotá
EIP-8411 n'est actuellement pas une fonctionnalité Ethereum activée. La proposition GitHub a été ouverte le 4 septembre et reste étiquetée comme un EIP de réseau à l'état de brouillon en attente d'examen. La proposition nécessite EIP-7732, la conception de séparation proposant-constructeur consacrée d'Ethereum.
Les développeurs Ethereum ont demandé que EIP-8411 reçoive le statut PFI, ou Proposé pour Inclusion, pour Hegotá, la mise à niveau du réseau attendue après Glamsterdam. Lors de la discussion All Core Developers Execution du 10 septembre, les développeurs ont déclaré que la proposition devrait être examinée par l'appel des développeurs de la couche de consensus, car le changement affecte principalement le réseau de consensus.
La demande est venue après la date limite normale de PFI pour Hegotá. Ses partisans ont proposé EIP-8411 comme remplacement de EIP-8142, qui avait exploré le placement de blocs dans des blobs mais avait soulevé des inquiétudes concernant la preuve KZG côté constructeur et la réutilisation des sous-réseaux de disponibilité des données.
L'ordre du jour de l'ACDC #187 prévoit une discussion sur le PFI d'EIP-8411 pour le 17 septembre à 14h00 UTC. Au moment de ce rapport, l'appel n'avait pas encore eu lieu, donc aucune décision d'inclure EIP-8411 dans Hegotá n'avait été enregistrée.
Les développeurs ont réduit l'ensemble des fonctionnalités de Hegotá à travers l'abstraction de compte, la mise à l'échelle, la résistance à la censure et d'autres travaux de protocole. EIP-8411 est entré dans ce processus plus tard que de nombreuses propositions et nécessite encore une décision d'inclusion des développeurs principaux.
La proposition de réseau est liée aux travaux d'Ethereum sur l'augmentation de la capacité de la couche 1. Des limites de gaz plus élevées peuvent conduire à des charges utiles d'exécution plus importantes, augmentant la quantité de données que les validateurs doivent recevoir dans des délais de consensus fixes. La limite de gaz d'Ethereum a atteint 60 millions fin 2025 après que les validateurs ont signalé leur soutien à l'augmentation.
Vitalik Buterin a décrit une capacité de couche 1 plus élevée, PeerDAS et les futurs travaux sur ZK-EVM comme faisant partie du plan de mise à l'échelle d'Ethereum. Une livraison plus rapide des charges utiles est étudiée parallèlement à ces changements, car des messages réseau plus volumineux exercent plus de pression sur la bande passante des nœuds et les délais de propagation.
Le code prototype est disponible mais reste expérimental
Les chercheurs ont publié des implémentations prototypes pour Prysm et go-libp2p-pubsub. La branche Prysm recommandée de la variante-a contient une série de modifications derrière un flag –enable-segmented-payload-gossip, tandis que la branche libp2p qui l'accompagne implémente les politiques de transfert et de requête utilisées dans l'étude.
Les auteurs décrivent explicitement leur branche de recherche comme « un harnais, pas une proposition ». Certaines fonctionnalités mesurées dans l'article, y compris les configurations avancées de codage par effacement, restent des composants expérimentaux de l'environnement de test et ne font pas nécessairement partie de la spécification minimale EIP-8411.
Les questions ouvertes identifiées par les chercheurs incluent l'augmentation du trafic de messages de contrôle, les coûts CPU liés au traitement de nombreux messages plus petits, les mappages de segments alternatifs, la gestion des files d'attente, le réglage des minuteries et la question de savoir si une pile réseau plus récente axée sur QUIC pourrait produire des résultats différents.
Les auteurs prévoient d'autres comparaisons entre la conception à sujet unique utilisée par la variante A, les approches à message partiel et les modèles qui attribuent des sujets de gossip distincts à des segments individuels. Le prototype actuel conserve des pièces de 16 Kio comme référence recommandée après que les simulations ont montré que des pièces plus petites de 8 Kio ne produisaient pas de gains de latence supplémentaires tout en augmentant le trafic de contrôle.
