Actualización de Safe Network Dev 🇪🇸 5 de enero de 2023

Dimitar · 7 Enero, 2023 08:59

Esta es una traducción automática. El original en inglés está aquí: Update 05 January, 2023

Feliz año nuevo a todos Es genial estar de vuelta, estamos decididos a hacer que este realmente cuente Todo el equipo ha logrado aprovechar un poco de tiempo de inactividad y está ansioso por comenzar. Durante el receso, también hemos estado arreglando algunas cosas y considerando algunas posibles mejoras, incluido el tamaño óptimo de los nodos y las secciones y cambios en la antigüedad y reubicación del nodo. Para el primero de estos, hemos estado ejecutando redes de prueba internas con nodos más pequeños y secciones más grandes. Estos han ido bastante bien y han revelado uno o dos problemas más relacionados con las comunicaciones y el traspaso en los que hemos trabajado. El segundo es una optimización del diseño que tratará los nodos más jóvenes de manera diferente a los más antiguos. Más detalles sobre eso en las próximas dos semanas.

Progreso general

Una ruptura en la rutina puede ser un buen momento para pensar en qué se puede hacer mejor y atar cabos sueltos. Aquí hay un resumen de lo que ha estado haciendo el equipo desde la última actualización.

Dividir el mensaje general NodeMsg::Propose en cuatro variantes distintas para mayor claridad.

RequestHandover: cuando los nodos terminan DKG y solicitan una entrega a los ancianos actuales (nodo->anciano)
SectionHandoverPromotion: cuando los ancianos les dicen a esos nodos que son promovidos como ancianos (anciano->nodo)
SectionSplitPromotion: cuando los ancianos les dicen a esos nodos que son promovidos como ancianos en cualquier lado de una división (anciano->nodo)
ProposeSectionState: cuando los ancianos deciden patear nodos o aceptar nuevos nodos dentro de una sección (anciano->anciano)

Esta distinción hace explícito quién firma y quién recibe/agrega las firmas.

Cortar mensajes innecesarios
Solucionamos un problema costoso en el que los mensajes AE verificaban repetidamente el SectionTree para cada mensaje, incluso cuando ya se había verificado.

Optimización de AE
Experimentamos con ralentizar el sondeo de AE alrededor de las divisiones para reducir la cantidad de mensajes que vuelan, y también refactorizamos el conocimiento de la sección de red global para apuntar a uno aleatorio. anciano en tres secciones aleatorias cada cinco minutos. Anteriormente, el valor predeterminado era todos los ancianos en tres secciones cada 30 segundos. Esto resultó en una gran reducción del uso de la CPU y la memoria en torno a las divisiones, y el tiempo más largo debería ser suficiente para nuestras necesidades: después de todo, las divisiones no ocurren cada 30 segundos.

Alto uso de memoria al esperar para unirse
Probamos un error que ha estado causando un alto uso de memoria en los nodos mientras esperan para unirse, como se ve en redes de prueba recientes. Estaremos listos para poner esto a prueba en una red de prueba comunitaria en breve. También evitamos el almacenamiento en caché de sesiones de conexión para nodos no unidos.

Refactorización de comunicaciones
Un feo candado en el código para send-streams en sn_node ha sido refactorizado. Además, estamos probando comunicaciones de “ruta feliz” mediante las cuales los clientes pueden enviar un mensaje a un solo anciano en lugar de a todos.

También eliminamos el código de seguimiento de nodos y los bloqueos relacionados que eran posibles puntos de falla. Estábamos viendo muchos mensajes como consecuencia de un envío fallido/cambios en el nivel de almacenamiento que estaban bloqueando los nodos.

Cambios en los parámetros de almacenamiento
Se agregó un margen a la capacidad de almacenamiento, por lo que esperamos una cantidad mínima de almacenamiento, pero los nodos pueden almacenar más. Esto debería ayudar a aliviar los errores de “no se pudo almacenar” antes de dividirnos. También configuramos ancianos para almacenar datos (antes no lo hacían) y usamos su capacidad de almacenamiento mínima local como indicador de cuándo dividir, como se discutió en el foro.

Con esto ahora tenemos el siguiente flujo:

Los nodos reciben datos.
Cada vez que superamos un cierto nivel de almacenamiento utilizado (por primera vez) permitimos que se unan nuevos nodos.
2.1 Cuando un nodo solicita unirse, vemos que las uniones están permitidas y los ancianos inician una votación para agregar el nodo.
Cuando se une un nuevo nodo, las uniones están deshabilitadas, verificamos si hemos alcanzado min_capacity
3.1. No hemos llegado a min_capacity, continúe con normalidad.
3.2. Hemos llegado a min_capacity, limpie el exceso de almacenamiento.
3.3 Si todavía estamos en o por encima de min_capacity, activa allow_joins_until_split a prueba de fallos.
3.4. Cuando un nodo solicita unirse, vemos que las uniones están permitidas y los ancianos inician una votación para agregar el nodo.
El nodo de unión alivia la carga de almacenamiento.

Enlaces útiles

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.