¡El informe PeerDAS Devnet 7/14 de Sunnyside está aquí! Profundicemos 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 alimentar a los desarrolladores principales con los conocimientos resultantes: •Dónde se encuentran 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 principal objetivo es probar de manera rápida y flexible de manera que complemente lo que otros equipos como @ethPandaOps están haciendo en fusaka-devents, proporcionando comentarios oportunos que respalden la implementación continua de PeerDAS.

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

1 – Prueba de rendimiento de blobs Los resultados de las pruebas mostraron que la mayoría de los clientes de CL podían controlar 84 blobs por bloque o más, y se mantuvieron estables con al menos 40 blobs. Algunos clientes registraron un recuento máximo de blobs relativamente más bajo en comparación con las redes de desarrollo anteriores, pero esto puede deberse a que el recuento de validadores por nodo en esta red de desarrollo se redujo de 100 a 8, lo que a su vez redujo la tasa de participación en la subred de cada nodo.

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

3 – Prueba de restricción de ancho de banda Para comprobar si los participantes de viviendas reales 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 limitados. A través de múltiples pruebas, descubrimos que el uso del ancho de banda de los nodos aumenta periódicamente, especialmente cerca del comienzo de una ranura cuando se cotillean los blobs, y que estos picos limitan el rendimiento general de la red. El tráfico de ráfagas se produjo de manera uniforme entre 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áfaga es el mayor cuello de botella en entornos con ancho de banda limitado, y debemos 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 compañeros.

La red de desarrollo de Sunnyside todavía está funcionando 🏗️; realización de redes de desarrollo de interoperabilidad con múltiples combinaciones de clientes, pruebas de ancho de banda más granulares, pruebas de spam que incluyen transacciones normales y pruebas de reposición/sincronización, para identificar cuellos de botella en entornos que se asemejan más a las condiciones de la red principal.