Investigadores de Ethereum informaron que un diseño de transmisión segmentada bajo la propuesta borrador EIP-8411 redujo el tiempo medio simulado de propagación de un payload de ejecución de 1 MiB de unos cinco segundos a aproximadamente 0,75 segundos, según un informe publicado en Ethereum Research.

La velocidad de propagación tiene un peso particular en una red de prueba de participación, donde los validadores tienen una ventana limitada para recibir y verificar cada nuevo bloque antes de atestiguarlo.

La prueba modeló 500 nodos con latencia geográfica, capacidad de carga de 50 Mbps y capacidad de descarga de 100 Mbps. El payload se envió desde un builder doméstico en lugar de un nodo de centro de datos de alto ancho de banda, una elección que puso a prueba el rendimiento del diseño sin infraestructura de centro de datos en el lado del emisor. Los investigadores ejecutaron código real de Prysm y go-libp2p-pubsub en una red simulada con un reloj virtual, repitiendo cada medición en 10 configuraciones aleatorizadas para no depender de una única topología.

Cuando el payload completo se envió como un único mensaje de GossipSub, alcanzó la mitad de la red en unos cinco segundos, mientras que los nodos más lentos lo recibieron en casi seis segundos. La variante segmentada ajustada redujo esas cifras a aproximadamente 0,75 segundos y un segundo, respectivamente.

EIP-8411 reemplaza la espera del payload completo por transmisiones segmentadas

EIP-8411 reemplaza el único tema de gossip execution_payload de EIP-7732 por un nuevo tema execution_payload_chunks. Los nodos ya no necesitan esperar el payload completo antes de retransmitirlo. En su lugar, pueden verificar y reenviar segmentos autenticados de forma independiente a medida que llegan, comprobando cada segmento contra una raíz de Merkle incluida en la execution bid del builder.

La propuesta se abrió el 4 de septiembre de 2026 y sigue siendo un EIP de red en estado Draft sin aprobar. Además, depende de EIP-7732, el diseño de separación proposer-builder integrado en, bajo el cual los builders construyen los payloads de ejecución y los ofrecen a los proposers mediante execution bids, separando la construcción de bloques de la propuesta de bloques.

Los resultados provienen de una simulación controlada con código de cliente en fase de prototipo, no de mediciones en la mainnet de Ethereum. Por lo tanto, cualquier mejora de rendimiento en el mundo real aún tendría que confirmarse. Los investigadores describieron su rama como “un harness, no una propuesta”.

Los hallazgos también se describieron en una publicación de 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 propagación más rápida implica una mayor sobrecarga de red

La capa de consenso de Ethereum utiliza GossipSub, un protocolo de gossip de publicación-suscripción, para difundir bloques y otros mensajes a través de su red entre pares. El modelo de gossip actual puede generar un retraso de almacenamiento y reenvío, ya que un nodo debe recibir y validar un mensaje grande completo antes de retransmitirlo. El diseño básico de Nivel 1 utiliza segmentos de 16 KiB junto con publicación por lotes. En las pruebas, redujo el tiempo medio de propagación de 1 MiB de cinco segundos a menos de un segundo. La latencia de cola también disminuyó de unos seis segundos a poco más de un segundo.

La contrapartida fue aproximadamente un tercio más de bytes recibidos que con el enfoque actual de mensaje completo. Las variantes más avanzadas atacan directamente esa sobrecarga de bytes duplicados. Bajo un enfoque llamado disciplined pulls, un nodo solicita un segmento faltante a un par. Si ese par agota el tiempo de espera, el nodo recurre a otro. Esto redujo el tráfico recibido a alrededor de 1,5 copias del payload por nodo. Sin embargo, la latencia de cola aumentó cuando los pares retuvieron segmentos que habían anunciado.

Un tercer nivel añade corrección de borrado Reed-Solomon. Produjo la latencia de cola más baja en las pruebas y siguió funcionando cuando los pares retuvieron segmentos. El costo fue una mayor demanda de ancho de banda en el origen.

Esa contrapartida es relevante para la hoja de ruta de escalado de Ethereum posterior a Glamsterdam. Se espera que límites de gas y payloads de ejecución más grandes generen una carga adicional en el ancho de banda de los nodos. Los investigadores también identificaron preguntas abiertas relacionadas con el tráfico de mensajes de control, el costo de CPU de procesar muchos mensajes más pequeños, la gestión de colas, el ajuste de temporizadores y la coordinación entre clientes.

El ACDC evalúa EIP-8411 para Hegotá

El ecosistema de Ethereum también discutió la posible inclusión de la propuesta en Hegotá, la actualización de red prevista después de Glamsterdam. En una publicación de X, Barnabé Monnot escribió:

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

Los desarrolladores de Ethereum solicitaron el estatus de Proposed for Inclusion para EIP-8411 en Hegotá, después del plazo normal de PFI de Hegotá. Proposed for Inclusion, o PFI, es el estatus que marca un EIP como candidato para una actualización de red específica. La agenda del ACDC #187 programó una discusión de PFI para el 17 de septiembre a las 14:00 UTC. Sin embargo, al momento del informe, esa llamada aún no se había realizado y no se había registrado ninguna decisión de inclusión.

Las implementaciones de prototipo para Prysm y go-libp2p-pubsub ya están publicadas. Los investigadores advirtieron que las configuraciones avanzadas de corrección de borrado siguen siendo características experimentales del entorno de prueba, en lugar de componentes confirmados de la especificación mínima de EIP-8411. Que EIP-8411 se convierta en parte de la infraestructura de escalado de Ethereum depende de una decisión futura de los desarrolladores principales.