Actualización de Safe Network Dev 🇪🇸 22 septiembre 2022

Esta es una traducción automática. El original en inglés está aquí: Update 22 September, 2022

No hay nada importante que informar esta semana en el frente tecnológico, por lo que lo mantendremos en un informe de progreso general en lugar de la inmersión profunda habitual. Sin embargo, más para informar sobre el frente del equipo, donde estamos felices de dar la bienvenida a un nuevo miembro del equipo. Mostafa es un desarrollador de blockchain experimentado que proviene de Malasia.

¡Bienvenido al equipo, Mostafa!

Hola. Este es Mostafá. Soy un ingeniero de software. Encantada de conocerte.

Una vez, cuando era estudiante, decidí visitar un antiguo templo de fuego (un edificio de más de 2000 años) que estaba ubicado en un lugar salvaje. Encontrar el templo del fuego fue difícil, así que le pedí ayuda a algunas personas locales. Curiosamente, la llamaron la “Casa del Diablo” y cuando les pregunté por qué dijeron, “porque los humanos no pueden construir tal cosa, debe ser el diablo”. Esto estaba en mi mente recientemente cuando leí la historia de los puentes del diablo en Europa. Los puentes que se construyeron hace siglos y aún funcionan. La gente los llama puentes del diablo, porque no pueden creer que un humano los haya construido, debe ser el diablo.

Nadie sabe quién construyó el puente del diablo o el templo del fuego, pero todavía están en pie. ¡Construyamos una red diabólica!

Progreso general

El trabajo SectionTree ya está hecho :muscle:
Un recordatorio de @roland por qué volvimos a implementar algunas partes del SectionTree…

El SectionTree (anteriormente NetworkPrefixMap) es una estructura de datos que encapsula nuestro conocimiento actual sobre la red. Se puede considerar como un árbol en el que cada nodo es una SectionKey firmada por su padre SectionKey, excepto el nodo raíz (genesis_key). Las hojas del árbol también contienen el SAP de la sección mientras descartan los SAP de los que no son hojas.

Dado que cada ‘Cliente/Nodo’ puede tener una vista de red diferente, el ‘Árbol de secciones’ puede variar mucho entre los participantes. Además, es necesario enviar partes del árbol (SectionTreeUpdate, que agrupa la cadena de prueba + SAP) a cualquier persona que lo solicite y estar seguro de que no estropearán su árbol al intentar actualizarlo.

La SecuredLinkedList se usó anteriormente para construir el SectionTree, pero tenía un par de problemas que provocaban inserciones incorrectas y no cumplía con CRDT. Por lo tanto, se volvió a implementar como un CRDT (específicamente MerkleRegister), y la antigua SecuredLinkedList se reemplazó con la nueva SectionsDAG. ¡Ahora podemos estar seguros de que se comporta como se espera sin importar el orden o la duración de la actualización!

@roland ahora pasó a las pruebas de generación de claves distribuidas (DKG) con @anselme. Como se explicó en las últimas semanas, ha habido problemas con el proceso DKG que no siempre termina. Después de algunas pruebas intensivas, ahora se ve bastante estable y @anselme está escribiendo documentación para el proceso de prueba.
Una nota de Anselme sobre el próximo DKG…

El próximo DKG, más resistente y sin temporizadores

El proceso DKG es actualmente un proceso activo que utiliza temporizadores que, en casos de gran actividad de la red, a menudo fallan debido a los tiempos de espera. Recientemente, hemos estado trabajando en un nuevo DKG que no utiliza temporizadores, sino que permite que los mensajes se retrasen y admite caídas de paquetes pesados. Cuando los nodos no reciben mensajes por un tiempo, chismean sobre su conocimiento con los demás con la esperanza de ponerlos al día, o incluso obtener actualizaciones de ellos si la información enviada no está actualizada. De esta manera, eventualmente todos los nodos llegarán a la terminación DKG.

Ahora también adoptamos DKG simultáneos con esta nueva implementación. Ahora es una carrera entre DKG y cualquier grupo de candidatos que llegue al final antes de que los demás tengan la oportunidad de convertirse en el nuevo grupo de ancianos. Algunas sesiones de DKG pueden estancarse o terminar tarde, pero no las consideramos fallas, participaron en la carrera y simplemente perdieron. Queremos que el próximo grupo de ancianos sea lo más confiable posible, por lo que elegir al ganador en esta carrera DKG también es una forma de elegir los mejores nodos. Eventualmente, después de la rotación de secciones, estas sesiones de DKG se vuelven obsoletas y, cuando los candidatos se dan cuenta de que perdieron la carrera, saben que pueden parar.

Otro dúo dinámico @bochaco y @chriso han estado depurando las pruebas de DBC. Descubrieron un problema técnico por el cual el SAP (lista de ancianos actuales) se elimina por error durante el proceso de prueba del cliente, lo que desestabiliza la red.

Mientras tanto, @bochaco continúa trabajando en el otro flujo de actividad principal en este momento, simplificando los procesos de mensajería y utilizando hilos únicos donde sea posible.

@joshuef y @davidrusu también están trabajando en aspectos de la racionalización de mensajes, Josh está investigando cómo extraer el módulo comms del código node, para ver si eso podría prestarse mejor a los subprocesos múltiples, mientras que David está desacoplando algunos de el código compartido por las cajas sn_node y network_knowledge, que con suerte eliminará algunos de los errores de unión de nodos que hemos estado viendo.


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.