Tendencias del momento
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
¡Otro informe ha sido publicado! El informe de Devnet 8/4 de PeerDAS por Sunnsyide Labs está aquí.
¿Tienes curiosidad sobre cómo se comportan los nodos en condiciones de producción con PeerDAS? 🧵

21 jul 2025
¡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?
Esta vez, Sunnyside Labs ejecutó 2 tipos de devnets basados en la imagen fusaka-devnet-2 de @ethPandaOps, para verificar la estabilidad de la red en un entorno más realista:
1. Devnet de interoperabilidad (clientes CL/EL mixtos con 50% de supernodo)
2. Devnet Perfect PeerDAS (cada nodo custodia exclusivamente una columna de datos única)
Para cada configuración de devnet, realizamos 3 nuevos escenarios de prueba:
1. Blobs con Transacciones Grandes
Esto es para investigar cómo las transacciones regulares afectan la competencia de propagación de bloques con la propagación de la columna de datos a través de los nodos. Hemos mantenido cada bloque en la prueba para alcanzar 22 Mgas (tamaño de bloque de 2MB).
2. Límite de Ancho de Banda + Transacciones Grandes
Esta prueba es para investigar el comportamiento de la red en condiciones de nodos con ancho de banda limitado, como los stakers domésticos. El ancho de banda se establece en 100/50Mbps para supernodos y 50/25Mbps para nodos completos, según las recomendaciones de EIP-7870.
3. Prueba de Sincronización de Génesis
La sincronización de génesis se prueba en los devnets para encontrar bloqueadores o errores en el proceso de sincronización.
Aquí están las ideas que obtuvimos de estas pruebas:
1 - Las transacciones grandes tienen un bajo impacto en la red, bajo una red sin restricciones.
En ambos Interop Devnet y Perfect PeerDAS Devnet, la red soportó 60 blobs sin muchos problemas, incluso con transacciones adicionales además de los blobs. Este resultado es el mismo que el escenario base con solo blobs.
Esto indica que las transacciones ordinarias, además de los blobs, tienen un impacto mínimo en la estabilidad de la red bajo ninguna restricción de recursos.
2 - El límite de ancho de banda afecta a la red en varios caminos
Con los enlaces de subida limitados a 100/50Mbps para supernodos y 50/25Mbps para nodos completos, el rendimiento de blobs colapsó a 20 blobs/bloque en la red de desarrollo Interop y 30 blobs/bloque en la red de desarrollo Perfect PeerDAS.
Bajo estos límites, un aumento brusco en los mensajes IWANT en el tema beacon_block mostró que los bloques de beacon estaban teniendo dificultades para propagarse. Además, una vez que los nodos alcanzaron sus techos de salida, las mempools de EL expusieron muchos menos blobs, evidenciado por una fuerte caída en las tasas de éxito de getBlobsV2.
Las discusiones internas apuntan al límite de subida de 50 Mbps en los supernodos como el principal culpable: ese techo en EIP-7870 está diseñado para constructores de bloques locales, no para supernodos que sirven a la red más amplia. Por lo tanto, estas pruebas fueron más severas que las condiciones del mundo real.
Sunnyside Labs realizará una prueba de seguimiento esta semana con un mayor ancho de banda para supernodos para medir el impacto exacto de esta restricción.
3 - La sincronización de Genesis funciona para el devnet de Interop, pero falló en el devnet de Perfect PeerDAS
La sincronización de Genesis se completó sin problemas en el devnet de Interop, pero se detuvo justo después de la época de actualización de Fulu en Perfect PeerDAS. Si un nodo no puede obtener todas las columnas durante la sincronización de Genesis, debería consultar idealmente a pares adicionales para llenar los vacíos, lo cual aún no está implementado en ningún cliente. Si esta obtención de columnas entre pares se convierte en una característica necesaria antes del Fusaka sigue siendo un tema abierto; se espera una decisión en la ACD del próximo jueves.
4 - Relleno de custodia de validadores exitoso en @Teku_Consensys
El relleno de custodia de validadores permite a un cliente detectar columnas históricas faltantes y recuperarlas automáticamente de pares.
Nuestra prueba dedicada confirmó que la implementación de Teku funciona a la perfección: identificó huecos y los rellenó completamente sin problemas en condiciones normales. Se identificó un pequeño error en un caso límite donde había un gran hueco en la cadena sin blobs, que fue rápidamente solucionado por el equipo.
Otros clientes están trabajando ahora en esta función, y se probará en las futuras devnets de Sunnyside a medida que se complete la implementación.
Sunnyside Labs continuará ejecutando devnets esta semana, centrándose en los siguientes temas:
- Interoperabilidad de Devnet con límites de ancho de banda de supernodo más altos y períodos de tiempo más largos
- Más análisis de las pruebas de sincronización de génesis en el devnet de Perfect PeerDAS
- Más devnets centrados en el tamaño máximo de bloque (en formato comprimido snappy), nodos corruptos con blobber y finalización en red dividida.
1,19K
Parte superior
Clasificación
Favoritos