Et si le vrai goulet d’étranglement d’Ethereum n’était plus seulement le calcul des transactions, mais le temps qu’il faut à un gros message pour traverser le réseau ? C’est précisément la question que des chercheurs viennent de poser, chiffres à l’appui. Dans un environnement simulé de cinq cents nœuds, un payload d’exécution d’un mébioctet mettait environ cinq secondes à atteindre la moitié des destinataires lorsqu’il voyageait d’un seul bloc. Découpé selon le brouillon EIP-8411, le même volume tombait sous la seconde en médiane. Le 17 septembre 2026, ces résultats circulent au moment même où les développeurs consensus doivent décider s’il mérite d’entrer dans la file d’attente de Hegotá.
Ce Que Change Vraiment EIP-8411 Sur Le Réseau
Le problème n’est pas abstrait. Aujourd’hui, le modèle de gossip peut obliger un nœud à recevoir et à valider un message entier avant de le relayer. Les auteurs parlent d’un effet store-and-forward : le payload doit finir de traverser un saut avant d’en commencer un autre. Plus les blocs d’exécution grossissent, plus cette attente pèse sur les délais de consensus.
EIP-8411 propose de casser ce verrou. Le constructeur découpe le payload en pièces de taille fixe. Chaque segment porte une preuve d’inclusion Merkle liée à une racine déjà inscrite dans l’execution bid. Un nœud qui reçoit un seul morceau peut le vérifier et le renvoyer pendant que le reste arrive encore. Autrement dit, le réseau n’attend plus la photo complète pour commencer à la photocopier.
En une phrase. On remplace un seul topic execution_payload hérité d’EIP-7732 par un topic execution_payload_chunks, avec un engagement Merkle dans l’offre du builder.
Pourquoi Le Gros Message Devient Un Risque
Ethereum a déjà relevé sa limite de gaz à soixante millions fin 2025, après un signalement des validateurs. Des blocs plus riches signifient des payloads plus lourds. Or les échéances de slot ne s’étirent pas aussi vite que les fichiers. Si la donnée d’exécution met trop longtemps à se répandre, on augmente le risque de retards, de propositions manquées, ou de pression sur les nœuds domestiques.
Vitalik Buterin a souvent présenté la hausse de capacité de la couche 1, PeerDAS et le travail vers une ZK-EVM comme des pièces du même puzzle. La livraison plus rapide des payloads s’inscrit dans cette logique : on ne peut pas empiler du volume si le réseau met cinq secondes à faire circuler un mégaoctet depuis un builder « à la maison ».
Les mesures ne viennent pas du réseau principal. Elles viennent d’un banc d’essai qui exécute du vrai code Prysm et go-libp2p-pubsub contre un réseau simulé et une horloge virtuelle.
Le Cœur Technique : Preuves, Morceaux, Relais
Le brouillon, toujours étiqueté Draft dans le dépôt des EIP, évoque soixante-quatre chunks et une structure Merkle qui relie chaque pièce à l’engagement initial. L’ajout consensus le plus visible, selon les chercheurs, c’est précisément cette racine. Le prototype conserve le format filaire gossipsub, la construction du maillage, le degré des pairs et le système de score. On change surtout la façon de publier et de relayer les fragments.
La documentation actuelle décrit les payloads d’exécution comme les données de transactions et d’état produites par le client d’exécution, puis transportées via le processus de consensus. Les validateurs reçoivent d’abord le bloc proposé sur le réseau gossip consensus, puis envoient la partie exécution à leur client d’exécution pour validation. Accélérer ce second voyage, c’est soulager toute la chaîne de décision du slot.
Les Chiffres Qui Font Lever Les Sourcils
Le scénario le plus parlant date du 17 septembre. Cinq cents nœuds, latences géographiques, cinquante mégabits par seconde en envoi, cent en réception, un payload d’un mébioctet parti d’un builder résidentiel, aucun nœud de centre de données ultra-rapide. Dix graines de réseau aléatoires pour chaque mesure.
En message unique, il fallait environ cinq secondes pour toucher la moitié des nœuds, près de six secondes en queue. La version segmentée et réglée tombait vers 0,75 seconde en médiane, et près d’une seconde en queue. Avec des segments de seize kibioctets et une publication par lots, le rapport affirme une médiane passée sous la seconde et une queue un peu au-dessus d’une seconde, contre six secondes auparavant.
| Mode | Médiane | Queue |
|---|---|---|
| Message unique | environ 5 s | près de 6 s |
| Segmentation réglée | près de 0,75 s | près de 1 s |
| Tier 1, 16 KiB + lots | sous 1 s | un peu plus de 1 s |
Ces ordres de grandeur captivent parce qu’ils parlent au constraste. On ne promet pas un miracle sur le réseau réel. On montre qu’un goulot de conception, le message monolithique, peut être attaqué sans jeter gossipsub par la fenêtre.
Tier 1 : Découper Et Publier En Éventail
Le premier étage combine segmentation et publication par lots. Au lieu d’envoyer toutes les copies d’un même segment avant de passer au suivant, le builder disperse tôt des pièces différentes vers des pairs différents. Plusieurs zones du payload se mettent à voyager en parallèle. C’est contre-intuitif si l’on pense « un fichier, une file ». C’est naturel si l’on pense « un essaim ».
Le prix apparaît tout de suite : environ un tiers de octets reçus en plus par rapport à l’approche actuelle. Beaucoup de pièces identifiées séparément, plus de messages de contrôle pour les annoncer. Les auteurs jugent ce surcoût acceptable au premier palier, surtout si l’objectif est de casser le mur des cinq secondes.
Ils ont aussi testé des pièces de huit kibioctets. Le gain de latence n’était plus là, alors que le trafic de contrôle augmentait. D’où le choix recommandé de seize kibioctets comme base du prototype.
Tier 2 : Moins De Doublons, Plus De Discipline
Le deuxième étage s’attaque aux copies inutiles. Plutôt que de pousser chaque segment à tous les pairs éligibles du maillage, un nœud n’en pousse qu’à un sous-groupe et annonce la disponibilité aux autres. Les pairs demandent ce qui leur manque seulement si besoin.
Le prototype y ajoute des disciplined pulls. On demande d’abord un segment à un pair, on attend un délai fixé, puis on bascule vers une autre source si rien n’arrive. À un mébioctet, ce régime ramène le trafic reçu autour de 1,5 copie de payload par nœud, contre bien plus de doublons dans les variantes moins tenues. L’intérêt grandit quand la bande montante est rare, ce qui est exactement le cas d’un builder résidentiel.
Le revers est classique en pair-à-pair. Un pair malveillant ou saturé peut annoncer un segment et ne jamais le livrer. Les chercheurs ont simulé cette rétention. Plus elle monte, plus la queue de latence souffre dans le modèle à requêtes. Ils ont alors testé des délais plus courts et plusieurs sources possibles pour limiter l’exposition.
Tier 3 : Codes Correcteurs Et Reconstruction
Le troisième étage ajoute un codage d’effacement Reed-Solomon. On compresse le payload, on produit des pièces de parité, on découpe. Un nœud peut reconstruire sans avoir chaque segment original, dès qu’il en a assez. Dans les essais, ce modèle donnait la meilleure queue et restait utilisable quand certains fragments étaient retenus.
Le coût se paie à la source : la parité augmente le volume émis. Les auteurs le disent sans fard. Certaines configurations avancées, y compris ce codage, restent des pièces du banc d’essai et ne font pas forcément partie du minimum spécifié par EIP-8411. La branche de recherche est même présentée comme « un harnais, pas une proposition ».
Vitesse d’abord, un tiers de volume en plus.
Moins de copies, risque de rétention.
Meilleure queue, source plus gourmande.
Hegotá, PFI Et Le Calendrier Serré
EIP-8411 n’est pas activé. Le dépôt GitHub a été ouvert le 4 septembre et reste un EIP réseau en brouillon. Il suppose EIP-7732, la séparation enshrined entre proposant et constructeur. Les développeurs ont demandé un statut PFI, Proposed for Inclusion, pour Hegotá, la mise à niveau attendue après Glamsterdam.
Lors de la discussion All Core Developers Execution du 10 septembre, le dossier a été renvoyé vers l’appel consensus, parce que le changement touche surtout le networking de cette couche. La demande arrive après la date limite habituelle des PFI Hegotá. Les promoteurs le présentent comme remplaçant d’EIP-8142, qui explorait le placement de blocs dans des blobs mais soulevait des doutes sur les preuves KZG côté builder et la réutilisation des sous-réseaux de disponibilité des données.
L’agenda ACDC numéro 187 prévoyait la discussion PFI le 17 septembre à 14 heures UTC. Au moment où les résultats de tests ont été publiés, l’appel n’avait pas encore eu lieu. Aucune décision d’inclusion n’était donc enregistrée. Hegotá se resserre déjà autour de l’abstraction de compte, du scaling, de la résistance à la censure et d’autres chantiers. Un latecomer doit convaincre vite, avec des preuves et des compromis clairs.
Ce Que Le Prototype Montre, Et Ce Qu’Il Ne Promet Pas
Des branches existent pour Prysm et go-libp2p-pubsub. La variante recommandée côté Prysm se cache derrière un drapeau –enable-segmented-payload-gossip. La branche libp2p implémente les politiques de relais et de requête utilisées dans l’étude. Utile pour reproduire. Insuffisant pour rêver d’un basculement immédiat sur le réseau principal.
Les questions ouvertes s’accumulent : trafic de contrôle plus dense, coût processeur de nombreux petits messages, autres mappings de segments, files d’attente, réglage des minuteries, et l’effet éventuel d’une pile réseau plus tournée vers QUIC. Les auteurs veulent encore comparer le topic unique de la variante A, des approches de messages partiels, et des modèles où chaque segment aurait son propre topic gossip.
Cette prudence compte. Trop d’annonces crypto transforment une simulation honnête en destin inévitable. Ici, le texte source insiste : la topologie, la bande passante et le trafic du réseau réel peuvent diverger du modèle. Cinq cents nœuds, une horloge virtuelle et dix graines, ce n’est pas l’Atlantique aux heures de pointe.
Le Lien Avec La Capacité De La Couche 1
Pourquoi s’acharner sur une seconde gagnée ? Parce que la seconde, en consensus, n’est pas cosmétique. Un slot a une géométrie temporelle. Si le payload d’exécution arrive trop tard, le validateur travaille dans le brouillard ou jette du travail. Multipliez cela par des milliers de nœuds et par des payloads qui enflent avec le gaz, et vous obtenez une friction systémique.
La hausse à soixante millions de gaz n’était qu’une étape. D’autres hausses se discutent régulièrement. PeerDAS vise à mieux répartir la charge de disponibilité des données. Les travaux ZK-EVM promettent de changer la façon de vérifier l’exécution. Entre ces chantiers, la propagation reste le tuyau invisible. On le remarque seulement quand il siffle.
EIP-8411 ne prétend pas remplacer ces autres leviers. Il cherche à ce que le tuyau suive le débit. C’est une ingénierie de plomberie, moins glamour qu’une nouvelle primitive cryptographique, tout aussi décisive si l’on veut des nœuds encore opérables depuis une ligne grand public.
Une Lecture Politique Du Protocole
Derrière le jargon se joue une question de qui peut encore construire et valider. Un builder en appartement, avec cinquante mégabits montants, est volontairement au centre du scénario. Si seuls les racks de centre de données peuvent diffuser à temps un gros payload, la séparation proposant-constructeur perd une partie de son pluralisme. Accélérer sans exiger une bande de data-center, c’est aussi un choix d’écosystème.
Le surcoût d’un tiers au premier palier, puis la chasse aux doublons au deuxième, dessinent un compromis social autant que technique. On accepte un peu plus d’octets pour gagner du temps, puis on reprend le volume quand la latence est déjà cassée. Les codes correcteurs ajoutent une assurance contre la rétention, au prix d’une source plus généreuse. Chaque palier dit : qui paie, qui attend, qui peut tricher.
Ce Qu’Il Faut Surveiller Après L’Appel Du 17 Septembre
Même sans décision connue au moment du rapport, la suite se lit déjà. Les clients consensus devront dire si le changement de topic et la racine Merkle valent une case PFI. Les équipes d’exécution devront estimer le coût processeur des petits messages. Les opérateurs de nœuds regarderont le trafic de contrôle. Les chercheurs, eux, devront sortir du harnais et rapprocher le prototype d’une spécification minimale crédible.
Trois signaux peseront plus que les communiqués. Premier, la stabilité des queues quand on injecte de la rétention et du bruit. Deuxième, le volume réellement observé hors simulation. Troisième, la capacité à expliquer le design en une page aux développeurs déjà saturés par Hegotá. Un EIP arrivé après la date limite n’a pas le luxe d’être flou.
En attendant, le contraste reste le meilleur résumé : cinq secondes contre moins d’une, pour le même mébioctet, dans un monde volontairement handicapé côté bande passante. Ce n’est pas encore le réseau principal. C’est assez pour justifier une discussion sérieuse, et trop peu pour déclarer la course gagnée.
Pour Les Lecteurs Qui Veulent Garder Le Fil
Retenez l’image plutôt que l’acronyme. Ethereum cherche à faire voyager un gros colis non plus comme une caisse scellée, mais comme une liasse de enveloppes tamponnées, chacune vérifiable, chacune relaisable. La racine Merkle est le tampon. Gossipsub reste le facteur. Les tiers sont des réglages de tournée. Hegotá sera, ou non, le premier bureau qui accepte le nouveau timbre.
Si la discussion du 17 septembre ouvre la porte, le travail basculera du banc vers la spécification, puis vers les clients, puis vers des tests publics autrement plus brutaux qu’une horloge virtuelle. Si elle la referme, le dossier reviendra avec d’autres mesures, d’autres mappings, peut-être une pile QUIC. Dans les deux cas, la contrainte reste : des payloads plus gros dans des délais qui, eux, refusent de gonfler.
C’est moins une révolution de protocoles qu’une leçon de physique de réseau appliquée à une blockchain qui veut grandir sans chasser les nœuds modestes. Les prochaines semaines diront si cette leçon entre dans Hegotá ou reste, encore un peu, un très bon harnais de laboratoire.
