I ricercatori di Ethereum hanno riferito che un design di trasmissione segmentata nell'ambito della proposta in bozza EIP-8411 ha ridotto il tempo mediano di propagazione simulato di un payload di esecuzione da 1 MiB da circa cinque secondi a circa 0,75 secondi, secondo un documento su Ethereum Research.

La velocità di propagazione riveste particolare importanza in una rete proof-of-stake, in cui i validatori hanno una finestra limitata per ricevere e verificare ogni nuovo blocco prima di attestarlo.

Il test ha simulato 500 nodi con latenza geografica, capacità di upload di 50 Mbps e capacità di download di 100 Mbps. Il payload è stato inviato da un builder domestico anziché da un nodo in data center ad alta banda, una scelta che ha verificato le prestazioni del design senza infrastrutture data center sul lato mittente. I ricercatori hanno eseguito codice reale Prysm e go-libp2p-pubsub su una rete simulata con orologio virtuale, ripetendo ogni misurazione su 10 configurazioni randomizzate per evitare di dipendere da una singola topologia fortunata.

Quando l'intero payload è stato inviato come un unico messaggio GossipSub, ha raggiunto metà della rete in circa cinque secondi, mentre i nodi più lenti lo hanno ricevuto in quasi sei secondi. La variante segmentata ottimizzata ha ridotto tali valori rispettivamente a circa 0,75 secondi e un secondo.

EIP-8411 sostituisce l'attesa dell'intero payload con trasmissioni segmentate

EIP-8411 sostituisce l'unico topic gossip execution_payload di EIP-7732 con un nuovo topic execution_payload_chunks. I nodi non devono più attendere il payload completo prima di inoltrarlo. Possono invece verificare e inoltrare frammenti autenticati in modo indipendente man mano che arrivano, controllando ciascun frammento rispetto a una radice di Merkle riportata nell'execution bid del builder.

La proposta è stata aperta il 4 settembre 2026 e rimane una EIP di rete in bozza non approvata. Dipende inoltre da EIP-7732, il design di Ethereum per la separazione proposer-builder integrata nel protocollo, in base al quale i builder costruiscono i payload di esecuzione e li offrono ai proposer tramite execution bid, separando la costruzione del blocco dalla proposta del blocco.

I risultati provengono da una simulazione controllata che utilizza codice client prototipale, non da misurazioni sulla mainnet di Ethereum. Pertanto, gli eventuali guadagni nel mondo reale dovranno ancora essere confermati. I ricercatori hanno descritto il loro ramo come "un harness, non una proposta".

I risultati sono stati descritti anche in un post su 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

Una propagazione più rapida comporta un maggiore overhead di rete

Il layer di consenso di Ethereum utilizza GossipSub, un protocollo gossip publish-subscribe, per diffondere blocchi e altri messaggi nella rete peer-to-peer. L'attuale modello gossip può creare un ritardo di tipo store-and-forward, poiché un nodo deve ricevere e convalidare un intero messaggio di grandi dimensioni prima di inoltrarlo. Il design di base di Tier 1 utilizza segmenti da 16 KiB insieme alla pubblicazione in batch. Nei test, ha ridotto il tempo mediano di propagazione da 1 MiB da cinque secondi a meno di un secondo. Anche la latenza di coda è diminuita da circa sei secondi a poco più di un secondo.

Il compromesso è stato di circa un terzo di byte ricevuti in più rispetto all'attuale approccio a messaggio intero. Varianti più avanzate puntano direttamente a tale overhead di byte duplicati. Secondo un approccio, denominato disciplined pulls, un nodo richiede un segmento mancante a un peer. Se quel peer non risponde entro il tempo limite, il nodo passa a un altro. Questo ha ridotto il traffico ricevuto a circa 1,5 copie del payload per nodo. Tuttavia, la latenza di coda è aumentata quando i peer hanno trattenuto segmenti che avevano annunciato.

Un terzo livello aggiunge la codifica a cancellazione Reed-Solomon. Ha prodotto la latenza di coda più bassa nei test e ha continuato a funzionare quando i peer trattenevano i segmenti. Il costo è stata una maggiore richiesta di alla sorgente.

Questo compromesso è rilevante per la roadmap di scaling di Ethereum post-Glamsterdam. Limiti di gas più elevati e payload di esecuzione più grandi sono attesi per sottoporre a ulteriore pressione la banda dei nodi. I ricercatori hanno inoltre individuato questioni aperte riguardanti il traffico di messaggi di controllo, il costo CPU dell'elaborazione di molti messaggi più piccoli, la gestione delle code, la regolazione dei timer e il coordinamento tra client.

L'ACDC valuta EIP-8411 per Hegotá

L'ecosistema di Ethereum ha anche discusso la possibile inclusione della proposta in Hegotá, l'aggiornamento della rete atteso dopo Glamsterdam. In un post su X, Barnabé Monnot ha scritto:

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
https://x.com/barnabemonnot/status/2100575903461839032?ref_src=twsrc%5Etfw

Gli sviluppatori di Ethereum hanno richiesto lo stato Proposed for Inclusion per EIP-8411 in Hegotá dopo il normale termine PFI di Hegotá. Proposed for Inclusion, o PFI, è lo stato che contrassegna una EIP come candidata per uno specifico aggiornamento della rete. L'ordine del giorno dell'ACDC #187 prevedeva una discussione PFI per il 17 settembre alle 14:00 UTC. Al momento della segnalazione principale, tuttavia, la chiamata non si era ancora svolta e nessuna decisione di inclusione era stata registrata.

Le implementazioni prototipali per Prysm e go-libp2p-pubsub sono già state pubblicate. I ricercatori hanno avvertito che le configurazioni avanzate con codifica a cancellazione rimangono funzionalità sperimentali dell'ambiente di test, anziché componenti confermati della specifica minima di EIP-8411. Che EIP-8411 diventi parte dell'infrastruttura di scaling di Ethereum dipende da una futura decisione dei core developer.