Los investigadores de Ethereum han reportado una propagación mediana inferior a un segundo para una carga útil de ejecución simulada de 1 MiB utilizando el diseño de difusión segmentada de EIP-8411, en comparación con aproximadamente cinco segundos al enviar la carga útil como un solo mensaje.
Resumen
- Las pruebas redujeron la propagación mediana para una carga útil de 1 MiB de cinco segundos a menos de un segundo.
- EIP-8411 divide las cargas útiles de ejecución en fragmentos que los nodos pueden verificar y reenviar antes de completarse por completo.
- Una raíz de Merkle en la oferta de ejecución permite a los nodos validar cada segmento de carga útil recibido de forma independiente.
- Las pruebas de prototipo utilizaron 500 nodos simulados, ancho de banda de un constructor doméstico, latencia geográfica y diez semillas de red aleatorizadas.
- Los desarrolladores de Ethereum discutirán EIP-8411 para su inclusión en Hegotá en el ACDC el 17 de septiembre de 2026 hoy.
Ethereum Research publicó los últimos resultados de las pruebas el 17 de septiembre, detallando un prototipo que divide las cargas útiles de ejecución en piezas más pequeñas para que los nodos puedan verificar y reenviar cada segmento antes de recibir la carga útil completa. Los hallazgos provienen de simulaciones y código de cliente prototipo, no de mediciones de la red principal de Ethereum.
La propuesta sigue siendo un EIP de red en borrador en el repositorio de EIPs de Ethereum. Su diseño actual reemplaza el único tema de gossip execution_payload introducido mediante EIP-7732 con un tema execution_payload_chunks y confirma las piezas a través de una raíz de Merkle incluida en la oferta de ejecución del constructor.
Ethereum EIP-8411 elimina la espera de la carga útil completa
El modelo de gossip existente de Ethereum puede requerir que un nodo reciba y valide un mensaje grande antes de reenviarlo a sus pares. Los investigadores detrás de EIP-8411 describen el retraso resultante como un problema de almacenar y reenviar porque la carga útil completa debe cruzar un salto de red antes de comenzar el siguiente.
Con la propagación segmentada, un constructor divide la carga útil en piezas fijas. Cada segmento lleva una prueba de inclusión de Merkle vinculada a la raíz comprometida en la oferta de ejecución. Un nodo receptor puede verificar un segmento y comenzar a enviarlo mientras las piezas restantes aún están llegando.
Además, la discusión del EIP en Ethereum Magicians describe el cambio planificado como reemplazar el mensaje de carga útil único de EIP-7732 con fragmentos verificables de forma independiente. El borrador actualmente propone 64 fragmentos y una estructura de prueba de Merkle que vincula cada pieza al compromiso de carga útil original. Los investigadores dijeron que el compromiso de Merkle representa la principal adición a nivel de consenso requerida para la segmentación básica. El último prototipo de investigación mantiene intactos el formato de cable gossipsub existente, la construcción de malla de red, el grado de pares y el sistema de puntuación mientras cambia cómo se publican y reenvían las piezas de carga útil.
La documentación de Ethereum actualmente describe las cargas útiles de ejecución como datos relacionados con transacciones y estado generados por el cliente de ejecución y transportados a través del proceso de consenso. Los validadores reciben los bloques propuestos a través de la red de gossip de consenso antes de enviar los datos de ejecución a sus clientes de ejecución para su validación.
La simulación reduce la mediana de 1 MiB de cinco segundos
Las cifras de rendimiento más sólidas en el informe del 17 de septiembre provienen de una simulación controlada. Los investigadores modelaron 500 nodos utilizando latencia de red geográfica, capacidad de carga de 50 Mbps y capacidad de descarga de 100 Mbps, con una carga útil de 1 MiB originada desde un constructor doméstico y sin nodos de centro de datos de alto ancho de banda.
Bajo esa configuración, enviar la carga útil como un mensaje gossipsub completo tomó aproximadamente cinco segundos en llegar a la mitad de los nodos receptores y cerca de seis segundos en la cola. Una versión segmentada ajustada alcanzó una mediana cercana a 0,75 segundos y una cola cercana a un segundo.
Los investigadores enfatizan que las mediciones provienen de un arnés de simulación que ejecuta código real de Prysm y go-libp2p-pubsub contra una red simulada y un reloj virtual. Cada medición utilizó diez configuraciones de red aleatorizadas. Las condiciones de la red principal podrían diferir de la topología, el ancho de banda y las suposiciones de tráfico modeladas.
Su diseño básico de Nivel 1 combina segmentación con publicación por lotes. Usando segmentos de 16 KiB, el informe dice que la propagación mediana para una carga útil de 1 MiB cayó de cinco segundos a menos de un segundo, mientras que la latencia de cola disminuyó de aproximadamente seis segundos a poco más de un segundo.
La publicación por lotes cambia la forma en que la fuente envía las piezas. En lugar de enviar cada copia de un segmento antes de comenzar el siguiente, el constructor distribuye diferentes piezas a diferentes pares desde el principio, permitiendo que varias secciones de la carga útil comiencen a moverse por la red a la vez. Los investigadores dijeron que el Nivel 1 requirió aproximadamente un tercio más de bytes recibidos que el enfoque actual de mensaje completo. La contrapartida proviene de enviar muchas piezas identificadas de forma independiente y los mensajes de control adicionales necesarios para anunciarlas.
Los niveles más avanzados reducen el tráfico de red duplicado
Un segundo nivel propuesto aborda los datos duplicados. En lugar de enviar cada segmento a todos los pares de malla elegibles, los nodos pueden enviar piezas a un grupo limitado mientras anuncian la disponibilidad a los demás. Los pares solicitan los segmentos faltantes solo cuando es necesario.
El prototipo combina ese sistema con lo que sus autores llaman extracciones disciplinadas. Un nodo solicita inicialmente un segmento a un par, espera un tiempo de espera definido y pasa a otra fuente si el primer par no lo entrega.
Con un tamaño de carga útil de 1 MiB, la investigación dice que las extracciones disciplinadas redujeron el tráfico recibido a alrededor de 1,5 copias de la carga útil por nodo, en comparación con un tráfico duplicado considerablemente mayor en variantes menos controladas. Los investigadores descubrieron que reducir los duplicados se volvía cada vez más útil cuando el ancho de banda de subida disponible era limitado.
El enfoque crea otra contrapartida. Un par malicioso o sobrecargado podría anunciar un segmento y luego negarse a proporcionarlo. Los investigadores probaron un escenario de retención en el que algunos nodos anunciaban segmentos pero no respondían a las solicitudes. En niveles de retención más altos, el diseño ajustado basado en extracciones mostró una latencia de cola creciente. Los autores probaron tiempos de espera más cortos y múltiples fuentes de solicitud posibles como métodos para limitar esa exposición.
Su tercer nivel añade codificación de borrado Reed-Solomon. Una carga útil se comprime, se codifica con piezas de paridad adicionales y se divide en segmentos. Los nodos pueden reconstruir la carga útil después de recopilar suficientes piezas sin esperar cada segmento original.
Los investigadores dijeron que el modelo codificado tuvo la latencia de cola más baja en sus pruebas y permaneció funcional cuando algunos segmentos fueron retenidos. El costo fue un mayor ancho de banda en la fuente de publicación porque los datos de paridad aumentan la cantidad enviada.
EIP-8411 ahora enfrenta una discusión de inclusión en Hegotá
EIP-8411 no es actualmente una característica activada de Ethereum. La propuesta en GitHub se abrió el 4 de septiembre y sigue etiquetada como un EIP de red en borrador a la espera de revisión. La propuesta requiere EIP-7732, el diseño de separación proponente-constructor consagrado de Ethereum.
Los desarrolladores de Ethereum han solicitado que EIP-8411 reciba el estado PFI, o Propuesto para Inclusión, para Hegotá, la actualización de red esperada después de Glamsterdam. Durante la discusión de ejecución de Todos los Desarrolladores Principales del 10 de septiembre, los desarrolladores dijeron que la propuesta debería ser considerada por la llamada de desarrolladores de la capa de consenso porque el cambio afecta principalmente a la red de consenso.
La solicitud llegó después de la fecha límite normal de PFI para Hegotá. Sus proponentes propusieron EIP-8411 como reemplazo de EIP-8142, que había explorado colocar bloques en blobs pero generó preocupaciones sobre la prueba KZG del lado del constructor y la reutilización de subredes de disponibilidad de datos.
La agenda de ACDC #187 programa una discusión de PFI sobre EIP-8411 para el 17 de septiembre a las 14:00 UTC. En el momento de este informe, la llamada aún no había tenido lugar, por lo que no se había registrado ninguna decisión de incluir EIP-8411 en Hegotá.
Los desarrolladores han estado reduciendo el conjunto de características de Hegotá en abstracción de cuentas, escalado, resistencia a la censura y otros trabajos de protocolo. EIP-8411 entró en ese proceso más tarde que muchas propuestas y aún necesita una decisión de inclusión por parte de los desarrolladores principales.
La propuesta de red está vinculada al trabajo de Ethereum para aumentar la capacidad de la Capa 1. Límites de gas más grandes pueden llevar a cargas útiles de ejecución más grandes, aumentando la cantidad de datos que los validadores deben recibir dentro de plazos de consenso fijos. El límite de gas de Ethereum alcanzó los 60 millones a finales de 2025 después de que los validadores señalaran su apoyo al aumento.
Vitalik Buterin ha descrito una mayor capacidad de la Capa 1, PeerDAS y el futuro trabajo de ZK-EVM como partes del plan de escalado de Ethereum. Se está investigando una entrega de carga útil más rápida junto con esos cambios porque los mensajes de red más grandes ejercen más presión sobre el ancho de banda de los nodos y los plazos de propagación.
El código prototipo está disponible pero sigue siendo experimental
Los investigadores han publicado implementaciones prototipo para Prysm y go-libp2p-pubsub. La rama recomendada de Prysm, la variante-a, contiene una serie de cambios detrás de una bandera –enable-segmented-payload-gossip, mientras que la rama acompañante de libp2p implementa las políticas de reenvío y solicitud utilizadas en el estudio.
Los autores describen explícitamente su rama de investigación como “un arnés, no una propuesta”. Algunas características medidas en el artículo, incluidas las configuraciones avanzadas de codificación de borrado, siguen siendo componentes experimentales del entorno de prueba y no forman necesariamente parte de la especificación mínima de EIP-8411.
Las preguntas abiertas identificadas por los investigadores incluyen el aumento del tráfico de mensajes de control, los costos de CPU derivados del procesamiento de muchos mensajes más pequeños, mapeos de segmentos alternativos, la gestión de colas, el ajuste de temporizadores y si una pila de red más nueva centrada en QUIC podría producir resultados diferentes.
Los autores planean realizar más comparaciones entre el diseño de tema único utilizado por la variante A, los enfoques de mensajes parciales y los modelos que asignan temas de gossip separados a segmentos individuales. El prototipo actual mantiene piezas de 16 KiB como su línea base recomendada después de que las simulaciones mostraran que las piezas más pequeñas de 8 KiB no producían mayores ganancias de latencia mientras aumentaban el tráfico de control.
