¡El informe de Devnet de PeerDAS de Sunnyside del 7/14 ya está aquí! ¡Sumergámonos en el estado actual de PeerDAS! ¿Cuánto blob podemos manejar y cuál es el cuello de botella?

Entre esos esfuerzos, el papel de Sunnyside es ejecutar devnets semanales en muchas configuraciones diferentes y proporcionar a los desarrolladores principales las ideas resultantes: •Dónde están los límites actuales de PeerDAS •Exactamente qué componentes crean cuellos de botella •Qué tan bien funcionan en la práctica optimizaciones como Supernodes y GetBlobV2

Nuestro objetivo principal es probar de manera rápida y flexible de formas que complementen lo que otros equipos como @ethPandaOps están haciendo en fusaka-devents, proporcionando retroalimentación oportuna que apoye la implementación continua de PeerDAS.

En esta semana, operamos 12 devnets y ejecutamos 3 suites de pruebas, utilizando la última imagen fusaka-devnet-2 de @ethPandaOps: 1. Rendimiento de Blob (máx. blobs por bloque) 2. Ancho de banda de red (prueba de carga sostenida) 3. Limitación de ancho de banda (30 / 20 / 10 Mbps)

1 – Prueba de rendimiento de blobs Los resultados de la prueba mostraron que la mayoría de los clientes CL podían manejar 84 blobs por bloque o más, y se mantenían estables con al menos 40 blobs. Algunos clientes registraron un recuento máximo de blobs relativamente más bajo en comparación con devnets anteriores, pero esto puede deberse a que el número de validadores por nodo en este devnet se redujo de 100 a 8, lo que a su vez disminuyó la tasa de participación de cada nodo en la subred.

2 – Prueba de Ancho de Banda de Red A diferencia de las devnets anteriores, donde la red a menudo se volvía inestable con un alto número de blobs, esta vez todas las devnets funcionaron de manera estable durante un período prolongado (~16 horas) incluso con 60 o 72 blobs por bloque. Aunque esto no garantiza estabilidad a nivel de producción, muestra que al menos algunas combinaciones de CL-EL han logrado un nivel de robustez mucho mayor a través de la optimización 🚀

3 – Prueba de Limitación de Ancho de Banda Para comprobar si los verdaderos stakers en casa pueden participar sin problemas una vez que PeerDAS esté activo, esta prueba aplicó límites de red y examinó qué factores se convierten en cuellos de botella en varios escenarios restringidos. A través de múltiples pruebas, descubrimos que el uso de ancho de banda de los nodos aumenta periódicamente, especialmente cerca del inicio de un slot cuando se difunden blobs, y que estos picos limitan el rendimiento general de la red. El tráfico de ráfagas ocurrió de manera uniforme en todos los nodos en lugar de ser causado por un cliente CL o EL en particular, y una vez que comenzaron las ráfagas, la red no pudo aumentar más el rendimiento de blobs. En otras palabras, el tráfico de ráfagas es el mayor cuello de botella en entornos con ancho de banda limitado, y necesitamos encontrar formas de mitigarlo.

Además, nos comunicamos con varios equipos de clientes y fomentamos mejoras para problemas relacionados con la sincronización y los pares.

La devnet de Sunnyside sigue en funcionamiento 🏗️; realizando interop-devnets con múltiples combinaciones de clientes, pruebas de ancho de banda más granulares, pruebas de spam que incluyen transacciones normales y pruebas de retroalimentación/sincronización, para identificar cuellos de botella en entornos que se asemejan más a las condiciones de mainnet.