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

Dimitar · 4 Octubre, 2022 03:51

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

Hemos simplificado el código y eliminado muchos problemas técnicos al eliminar todos los procesos de subprocesos múltiples asincrónicos innecesarios en el código del nodo. Al mismo tiempo, persisten algunos problemas con las comunicaciones lentas, que creemos que pueden ser causados por Quic, por lo que estamos investigando eso.

Aparte de la corrección de errores, el nuevo código síncrono sn_sdkg ahora está listo para la integración. @anselme nos explica eso esta semana.

Progreso general

Qi_ma está analizando cómo los ancianos verifican la “edad del nodo” de un nodo cuando deciden reubicarlo en una nueva sección, ya que observamos un comportamiento anómalo allí, incluidos los nodos “zombies” que pueden unirse a la red.

@ChrisO está experimentando con Quinn, que es una implementación de Rust del protocolo Quic para establecer y mantener conexiones entre pares. Desafortunadamente, Quic es algo así como una caja negra, y creemos que algunos de los problemas de conectividad que estamos experimentando pueden deberse a la forma en que funciona, específicamente que las comunicaciones a menudo son lentas, lo que causa problemas cuando se agota el tiempo de espera de los procesos. Chris tiene una caja de arena de Quinn configurada y está viendo lo que sucede cuando le enviamos diferentes tipos de mensajes. Al mismo tiempo, @bzee está analizando la estructura de las comunicaciones qp2p para confirmar que estamos usando a Quinn de la manera más eficiente posible. El problema clave es recibir flujos simultáneos de forma asincrónica mientras se permiten esperas en las respuestas (devolver un observador para ver los mensajes de respuesta en el mismo canal).

@roland está trabajando en pruebas de fuzz para la nueva caja sn_sdkg, que @anselme describe en detalle a continuación.

Integración sn_sdkg

La generación de claves distribuidas (también conocida como DKG) es la forma en que los ancianos de la sección generan la clave de la sección de una manera segura que mantiene la clave de la sección en secreto. Al final de DKG, cada anciano conoce solo su propia clave secreta compartida, de esa manera nadie ve la clave secreta de la sección completa. Este es un mecanismo para mitigar el rango de acción de los ancianos potencialmente malos: así es como Safe Network puede garantizar que, mientras tengamos menos de 5/7 ancianos malos, no puedan firmar nada con autoridad de sección. Se requiere autoridad de sección para cambiar datos, promocionar o indicar nodos y acuñar tokens, por lo que esto es muy importante.

Recientemente, hemos estado trabajando en un nuevo DKG que es más resistente a la pérdida de paquetes y que no usa temporizadores, por lo que no puede fallar debido a tiempos de espera y tráfico de red lentos. Esta publicación describe cómo funciona este nuevo DKG. Para esta implementación, utilizamos la caja sn_sdkg de generación de claves distribuidas síncronas, que se basa en el algoritmo de generación de claves síncronas de poanetwork en su caja hbbft.

Cómo funciona DKG

Los ancianos activan DKG cuando notan que los miembros más antiguos no son los ancianos, o cuando una sección se divide y necesitan elegir candidatos para ancianos. Al darse cuenta de esto, los ancianos actuales les piden a los candidatos que inicien una nueva sesión de DKG con un mensaje DkgStart, para que puedan generar la siguiente clave de sección.

El primer paso en nuestro DKG es generar claves BLS temporales, que se utilizan para el cifrado en el proceso DKG. Cada nodo en Safe Network tiene una clave ed25519, pero aunque esas claves son excelentes para las firmas, no podemos cifrarlas de manera segura. Necesitamos otra forma.

Dado que nuestros nodos no tienen claves BLS (los ancianos tienen una clave compartida BLS pero no una clave BLS simple), generamos una clave única solo para esta sesión DKG y la descartamos después de su uso. Sin embargo, necesitamos que los otros nodos confíen en esta clave BLS porque es completamente nueva, por lo que antes de que suceda algo más, cada candidato transmite su clave pública BLS recién generada en un mensaje que contiene su firma (hecha con su clave ed25519 confiable) sobre la nueva clave pública BLS única que usarán para esta sesión DKG.

Una vez que los candidatos tengan todas las claves públicas de BLS para esta sesión de DKG, pueden comenzar a votar. La votación tiene 3 etapas:

Partes: cada nodo envía una Parte que se usará para la generación final de la clave, contiene datos encriptados que se usarán para generar su clave compartida.
Acks: los nodos verifican las Partes y envían sus Acks (reconocimientos) sobre las Partes. Estos Acks también se utilizarán para la generación de claves.
AllAcks: todos se aseguran de tener el mismo conjunto de Acks y Partes enviando su versión de los conjuntos. ¡Esta última parte está ahí para asegurarse de que los candidatos terminen generando la misma clave de sección!

Una vez finalizada la votación, los candidatos pueden generar sus acciones de clave secreta junto con la nueva clave pública de la sección de Parts y Acks.

Chismes y eventual terminación

En una red, los mensajes se pueden perder y eso puede generar situaciones en las que a algunos candidatos les faltan votos y otros esperan una respuesta a votos que nunca llegaron. Para contrarrestar este problema, ¡tenemos chismes! De vez en cuando, si un nodo no ha recibido ningún mensaje DKG nuevo cuando espera alguno, enviará todos sus votos a los demás. Esto tiene dos propósitos:

uno es para informar a los demás de los votos, y conseguirlosp para acelerar con los votos que podrían haber perdido
el otro es para mostrar a los otros participantes que a nuestro nodo le faltan votos, para que otros puedan responder a su vez con sus votos y ayudarnos a alcanzarlos

De hecho, si un nodo recibe un mensaje de chisme que le falta información, responderá con su conocimiento. Esto sucede incluso después de la finalización (finalización de la ronda de votación), porque a veces, cuando un nodo finaliza (y, por lo tanto, deja de chismear porque no espera más votos), seguirá recibiendo chismes de otros nodos que no llegaron allí. aún. En ese caso, el nodo informado responderá a este chisme con su conocimiento para que los otros nodos también puedan llegar a la terminación. Eventualmente, a través de este proceso, cada candidato llega a la terminación.

DKG simultáneos

En esta implementación, adoptamos DKG concurrentes. A veces, justo después de que se activa DKG, un nuevo nodo se une a la sección y parece ser un mejor candidato a mayor porque la edad de su nodo es muy alta. En este caso, el conjunto actual de mejores candidatos mayores cambia, y los mayores actuales envían otro mensaje DkgStart a los nuevos candidatos.

La sesión anterior de DKG no se detiene, ¡ahora es una carrera entre los dos! Queremos que los ancianos sean nodos muy confiables. En cierto modo, el proceso intensivo de DKG es una prueba para comprobar que estos candidatos son aptos para ser mayores. Si varios DKG terminan al mismo tiempo, está bien, el “Consenso de traspaso” se asegurará de que los ancianos actuales elijan solo un ganador. Las sesiones de DKG que no ganaron la carrera pueden terminar o no, pero en realidad no importa, eventualmente se eliminarán cuando los nodos se den cuenta de que perdieron.

Conclusión

En resumen, el nuevo DKG se enfoca en ser muy resistente a la pérdida de mensajes, eliminando la necesidad de temporizadores y asegurándose de que todos lleguen a la finalización sin posibles tiempos de espera. También hace que los DKG simultáneos sean una función para seleccionar a los mejores candidatos en una carrera hasta la terminación entre DKG.

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.