Los investigadores de Ethereum presentaron los resultados de una simulación en la que el tiempo medio de propagación de una carga útil de ejecución de 1 MiB a través de EIP-8411 cayó por debajo de un segundo, en comparación con aproximadamente cinco segundos al enviar un solo mensaje. Ethereum Research informó sobre esto el 17 de septiembre.
El modelo de propagación actual requiere que un nodo reciba y verifique un mensaje grande en su totalidad antes de reenviarlo. Los investigadores describen este retraso como un problema de 'almacenamiento y reenvío': la carga útil completa debe pasar por un salto de red antes de que comience el siguiente. EIP-8411 propone dividirla en segmentos fijos. Cada uno lleva una prueba de Merkle vinculada a la raíz fijada en la propuesta del constructor. Al recibir un segmento, el nodo puede verificarlo y comenzar a reenviarlo mientras los demás aún están en camino. Actualmente, la propuesta describe 64 segmentos.
La simulación involucró a 500 nodos con latencia geográfica, 50 Mbps de subida y 100 Mbps de bajada. La carga útil de 1 MiB se enviaba desde un constructor doméstico, sin centros de datos de alta velocidad. El envío de un solo mensaje tomó alrededor de cinco segundos para la mitad de los nodos y casi seis segundos para el extremo. La versión segmentada ajustada mostró una mediana de alrededor de 0,75 segundos y un extremo de alrededor de un segundo. Las mediciones se realizaron en un simulador con el código real de Prysm y go-libp2p-pubsub y relojes virtuales; cada configuración se probó en diez redes aleatorias.
El nivel base 1 combina segmentación con publicación por lotes: el constructor distribuye temprano diferentes segmentos a diferentes nodos vecinos, y varias partes de la carga útil comienzan a moverse por la red simultáneamente. Esto aumenta aproximadamente en un tercio el volumen de bytes recibidos, un costo por múltiples identificadores y mensajes de servicio.
El nivel 2 combate la duplicación: en lugar de enviar cada segmento a todos los vecinos, un nodo lo envía a un grupo limitado y notifica a los demás sobre su disponibilidad. El prototipo agrega solicitudes con reintentos: el nodo primero solicita el segmento a un vecino, espera un tiempo de espera y luego cambia a otro. Con 1 MiB, esto redujo el tráfico a aproximadamente 1,5 copias de la carga útil por nodo. Sin embargo, si un vecino anuncia un segmento y no lo entrega, el retraso en el extremo aumenta. El nivel 3 agrega codificación Reed-Solomon: la carga útil se codifica con partes redundantes, y un nodo puede recuperar los datos sin esperar todos los segmentos. Esto dio el menor retraso en el extremo y resistencia a la negativa de entrega, pero aumentó la carga en la fuente.
EIP-8411 aún no está activado. La propuesta se abrió el 4 de septiembre y permanece como borrador en el repositorio de EIPs. La propuesta requiere EIP-7732 y reemplaza su único tema de propagación de datos de ejecución por temas con segmentos. Los desarrolladores solicitaron el estado de 'propuesto para inclusión' para la actualización Hegotá, una actualización esperada después de Glamsterdam. La solicitud se presentó después del plazo habitual. En la llamada ACDC #187, programada para el 17 de septiembre a las 14:00 UTC, la discusión aún no se ha llevado a cabo y no se ha registrado una decisión sobre la inclusión en Hegotá. EIP-8411 también se propone como reemplazo de EIP-8142, que consideró la colocación de bloques en grandes objetos binarios, pero generó preguntas sobre las pruebas KZG en el lado del constructor.
Artículos relacionados
