Esta es una traducción automática. El original en inglés está aquí: Update 27 October, 2022
Las últimas semanas han estado quitando las capas de la red y asegurando que lo que hay debajo sea estable. Esta semana hablaremos sobre cómo esperamos integrar este trabajo y qué debería significar para nosotros en el futuro.
Progreso general
Mostafa profundiza en los mecanismos de consenso y cómo podemos aplicarlos a algunos trabajos de Safe Network, incluidos los problemas de membresía que tratamos a continuación.
@davidrusu y @dirvine también están concentrados en esto, trabajando en los casos extremos y asegurándose de que se resuelvan con nuestros mecanismos planificados.
@bochaco sigue trabajando en la implementación de mensajería y errores de conectividad, junto con @joshuef y @qi_ma. La rama de trabajo que hemos estado manteniendo delante de main se ve bien.
Luego está la cuestión de qué sucede exactamente cuando se realiza una solicitud GET. ¿Qué debe firmarse y qué información mínima debe enviarse con el fragmento para que el adulto pueda ser identificado, monitoreado y castigado si falla? @ansleme y @oetyng están mirando esto principalmente ahora.
Y en el frente de prueba, @chriso está modificando el ejecutor autohospedado para GitHub Actions CI/CD para simplificar la bifurcación que hemos estado usando.
Próximos pasos en estabilidad
Recientemente, hemos estado presionando mucho para estabilizar las capas inferiores de la red (como vimos la semana pasada). Hemos estado simplificando la administración de la conexión y eliminando varias capas de código de “reintento” de las capas sn_client y sn_node, que ofuscaban errores poco frecuentes (que se volvieron más frecuentes en el transcurso de una red de prueba de ejecución más larga y muchas pruebas). Hemos estado trabajando en esto en las capas de gestión de conexiones y almacenamiento de nodos, así como en la membresía.
Como nos hemos centrado en esta inestabilidad, nos hemos movido para usar una configuración de CI más simple. Esto tiene pruebas que funcionan en secuencia, pero funcionan de manera mucho más consistente, excepto por algunos problemas que surgen en main. Pero esto es con una configuración de administración de conexión mucho más simple, y se eliminó gran parte de la capa de ‘reintento’.
Todavía no hemos puesto esto a prueba en la red de prueba, ya que todavía estamos tratando de resolver los problemas restantes: la membresía se detiene… (se está probando una solución para esto); pruebas API ocasionalmente lentas, que parecen estar relacionadas con la falta de sincronización de la membresía; y fallas muy ocasionales en las pruebas de DBC.
Esperamos fusionar nuestra rama de trabajo en main muy pronto. Una vez que tengamos eso, buscaremos bloquear estas ganancias de estabilidad con algunas mejoras adicionales de CI.
Más pruebas
Agregaremos pruebas para verificar todas las rutas de adultos y ancianos (reactivando pruebas divididas, equilibrio de datos en abandono, etc.) y verificando a todos y cada uno de los adultos que deben almacenar datos almacenan datos. Eventualmente, esto debería permitirnos pasar a una configuración más simple y feliz para las comunicaciones del cliente (es decir, comunicarse con solo un anciano… esperar un ACK antes de intentar la verificación), lo que reducirá aún más la carga de la red.
Una vez que tengamos eso en su lugar, buscaremos forzar a todos los RP a través de un flujo de trabajo de CI ajustado. Estaremos optimizando las pruebas para que solo se ejecuten inicialmente en máquinas Linux (ya que son las más rápidas). Con la suite completa ejecutándose solo cuando se ha revisado el PR (a través de BORS, nuestro robot CI).
Con suerte, esto debería acelerar el ciclo de retroalimentación en nuestras relaciones públicas, con BORS proporcionando la carne de CI y probando en todas las plataformas una vez que se haya revisado la relación pública.
Y si bien eso por sí solo no está a un millón de millas de lo que tenemos ahora… CI debería ser más estable, más útil (BORS gestiona las relaciones públicas pendientes y se reorganiza automáticamente; como es posible que hayamos hablado aquí antes)… Y… Luego, agregaremos una red de prueba de gota completa al flujo de BORS, lo que significará que main solo contendrá código que haya pasado todas las pruebas que tenemos, en cada plataforma, en todas las condiciones de red.
Y con “principal” confiable, probado y liberable, estaremos mucho mejor ubicados para trabajar en mejoras, puntos de referencia y nuevas características sin perder estabilidad.
Enlaces útiles
- Sitio web de red segura
- Introducción a la red segura
- Aspectos básicos de la red
- Hoja de ruta
- Glosario
No dude en responder a continuación con enlaces a las traducciones de esta actualización para desarrolladores y los moderadores las agregarán aquí.
Como proyecto de código abierto, siempre estamos buscando retroalimentación, comentarios y contribuciones de la comunidad, así que no sea tímido, únase y creemos la red segura juntos.