Un prototipo de Ethereum que divide las tareas de recuperación de blobs entre nodos reportó una reducción de 11 a 18 veces en el trabajo computacional estimado de reconstrucción en simulaciones de 1.000 nodos. Los resultados sugieren que los operadores podrían reducir el trabajo duplicado mediante un cambio menor que la propuesta completa de red RowDAS.
El informe del investigador Csaba Kiraly del 3 de septiembre describe el diseño reducido como un posible primer paso hacia RowDAS. Asigna las funciones de recuperación sin introducir los nuevos canales de red de fila en la propuesta completa.
Los blobs transportan datos utilizados por los rollups de capa 2. PeerDAS, el sistema de Ethereum para verificar que los datos de los blobs estén disponibles, permite que los nodos descarguen solo una parte de ellos. Los nodos de alta custodia mantienen al menos 64 de las 128 columnas de datos, suficiente para reconstruir los datos de los blobs faltantes; los supernodos mantienen las 128 completas.
Muchos nodos de alta custodia pueden repetir la misma reconstrucción. El diseño reducido asigna primero blobs específicos a ellos, permitiendo que otros reciban los datos recuperados en lugar de reconstruirlos inmediatamente por sí mismos.
Lo que muestran las simulaciones de recuperación de blobs de ethereum
En una configuración con cuatro blobs, 10% de supernodos y sin columnas retenidas, el costo estimado de reconstrucción en toda la red disminuyó de 48.6 segundos de CPU bajo el modelo PeerDAS a 2.75 segundos de CPU bajo el diseño reducido. Con un 20% de supernodos, las cifras correspondientes fueron 91 y 6.6 segundos de CPU.
Esos totales describen el trabajo de cómputo acumulado en la red simulada, no el tiempo de recuperación transcurrido. La contabilidad aplica un costo medido de 162 milisegundos por recuperación de blob en un procesador Ryzen 9 8945HS. Las velocidades de transacción y los ahorros en tarifas estuvieron fuera de las mediciones reportadas.
La línea base de PeerDAS ya incluye espera aleatorizada y comprobaciones que suprimen la reconstrucción duplicada. Por lo tanto, la comparación otorga crédito al comportamiento existente del cliente por el trabajo que ahorran esos retrasos.
Bajo la variante reducida, los nodos asignados comparten celdas recuperadas a través de canales existentes de distribución por columna. Los nodos de alta custodia mantienen un papel de recuperación diferida para cualquier elemento aún pendiente, preservando un mecanismo de respaldo tipo PeerDAS.
Full RowDAS, especificado en el borrador de EIP-8371, añadiría otra ruta de recuperación: los canales de fila permiten que los nodos más pequeños agrupen sus datos y los reconstruyan colectivamente cuando sus tenencias combinadas superen el umbral de recuperación. El diseño reducido mantiene la dependencia actual de los nodos de alta custodia y no puede proporcionar esa resiliencia adicional.
Las mediciones siguen limitadas a redes simuladas en proceso que utilizan criptografía real. Kiraly no informó resultados de devnet, y la configuración de 128 filas de subred del diseño completo sigue siendo una extrapolación a partir de cantidades más pequeñas de subredes. Se esperan simulaciones más grandes y pruebas en redes reales.
EIP-8371 mantiene sin cambios los límites de blobs, y la propuesta de división entre asignación de deberes y red de filas aún no se ha incorporado en su texto borrador. La oportunidad inmediata es más limitada: reducir el trabajo del procesador necesario para la recuperación, con los beneficios más amplios de resiliencia dependientes de una capa de filas posterior.
La publicación Ethereum puede tener una forma más sencilla de aliviar la carga de cómputo de su creciente ecosistema de rollups apareció por primera vez en CryptoSlate.