Actualización de Safe Network Dev 🇪🇸 30 junio 2022

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

Los ancianos utilizan la generación de claves distribuidas (DKG) para decidir entre dos posibles cursos de acción alternativos. Cada anciano genera una clave compartida y la envía con su voto, y si se recibe una gran mayoría (5 de 7) de estas claves compartidas, se agregan para crear la clave completa requerida para validar la decisión. Desarrollamos nuestro propio sistema para hacer esto utilizando criptografía BLS, que funciona bien la mayor parte del tiempo, pero no todo el tiempo. Desafortunadamente, cuando falla, la red puede detenerse. Esta semana, @anselme brinda una guía para principiantes de DKG, y él y @davidrusu explican cómo buscamos hacer que nuestra implementación de DKG sea más sólida.

Progreso general

@davidrusu y @joshuef han estado investigando más para hacer que sn_node sea de un solo subproceso en la medida de lo posible para deshacerse del problema causado por el bloqueo. Esto requerirá un poco de refactorización, moviendo Comm, el código que maneja la mensajería entre nodos, fuera de sn_node para que pueda sostenerse mejor por sí mismo y potencialmente tener su propio hilo.

Mientras tanto, @bochaco ha estado trabajando en minting of the initial genesis DBC por parte del primer nodo de la red, el manejo de los libros gastados para que los nodos no necesita consultar con otras secciones para ver si una transacción es válida y otros pasos en la integración de DBC.

@bzee se está atascando en algoritmos de dispersión de información (IDA), que, como recordarán, es la forma en que estamos reduciendo el almacenamiento y los requisitos de ancho de banda de la red, y @roland está trabajando en algunas pruebas de módulos de escritura para DKG y ayudando a @Anselme con la nueva caja sn_sdkg (s aquí significa síncrono).

Hacia un DKG más estable para Safe

La generación de claves distribuidas (DKG) es necesaria para que Safe Network garantice que cada anciano en una sección tenga un fragmento único de la clave de la sección: la clave compartida. Permite que la red genere una clave secreta para cada sección, sin que un solo nodo conozca la clave de la sección completa. Esto hace que Safe Network sea más resistente a los nodos bizantinos, ya que no necesita confiar en todos los ancianos.

La implementación actual de DKG tiene una falla que nos ha estado molestando durante muchos meses: el uso de temporizadores. DKG requiere la participación total de todos los nodos que deseen poder firmar. En tiempos de alta actividad de la red, los nodos pueden tener una copia de seguridad y no participar en las sesiones de DKG de manera oportuna.

Con nuestra implementación actual, si los nodos tardan demasiado en contribuir a DKG, la sesión de DKG fallará. Hemos querido eliminar cualquier comportamiento relacionado con el tiempo en Safe Network, adoptando flujos concurrentes y asíncronos como predeterminados.

Hemos estado buscando una alternativa al DKG basado en temporizador durante un tiempo y creemos que finalmente encontramos algo que funcionará a partir del trabajo de Membresía y Traspaso que hemos hecho.

DKG para el resto de nosotros

Aunque DKG puede parecer algo muy técnico y complejo, siento que su utilidad y los mecanismos básicos se pueden explicar a un niño de 6 años.

Imagina un reino con un rey. El rey tiene un sello de marfil que nadie puede falsificar. Cualquier carta con el sello de aprobación del rey es vista por todo el reino como digna de confianza.

sello de marfil == clave secreta
sello de aprobación en una carta == carta con la firma del rey

Un día el rey se da cuenta de que es viejo. El rey tiene cuatro herederos y quiere ser justo, así que le pide a su maestro artesano que rompa su sello de marfil en cuatro partes iguales, cada una de las cuales puede imprimir una parte del sello del rey. Luego entrega uno de estos pequeños sellos a sus cuatro hijos. Ahora, para recrear el sello de aprobación del rey, los niños deben usar sus diminutos sellos de marfil e imprimir sus partes del sello una al lado de la otra hasta que puedan ver el sello completo nuevamente.

4 piezas de sello de marfil == multisig
pequeño sello == clave compartida

Después de un tiempo, los herederos se dan cuenta de que este mecanismo está ralentizando el reino porque requerir todas las piezas del sello cada vez es una operación tediosa, algunos de ellos están lejos y viajando a veces, por lo que obtener todas las piezas del sello puede ser bastante complicado. Entonces tienen una idea: están de acuerdo en que mientras uno pueda ver más de la mitad del sello del rey en una carta (3/4+ sello), el sello se considera válido y lleva la autoridad del reino.

3/4+ sello == criptografía de umbral

Un día, los herederos se dan cuenta de que el maestro artesano fue deshonesto y se quedó con una copia del sello de marfil original del rey y que los estaba vendiendo en todo el reino a algunos malhechores. Los herederos deciden entonces crear un nuevo sello para su reino. Pero para evitar el error de la última vez, cada uno de ellos contrata a un artesano para crear una sola pieza nueva de un nuevo sello. Cada heredero tiene su propio sello que crearon de su lado. Al unirlos entre sí ely obtener un nuevo sello real que es único y que ningún sello único puede falsificar. Decretan que la unión de más de la mitad de estos sellos representa la autoridad del reino. Como nadie vio nunca el sello completo, pueden estar seguros de que nadie hará trampa esta vez.

sellos creados por separado que forman un sello único == DKG

En Safe Network, los ancianos utilizan DKG para generar la clave de sección que lleva la autoridad de sección. En terminología SN, la clave de génesis (clave del primer nodo de la red) es como el sello del rey. Una vez que se unen más miembros, el nodo de génesis y los nuevos nodos realizan DKG para crear una nueva clave de sección. Cada uno crea su propia clave compartida (pequeños sellos), pero nunca han visto las claves de los demás, por lo que nadie tiene la clave completa en sus manos. Cada vez que hay un cambio de mayores (los herederos), los nodos realizan DKG para crear una nueva clave de sección. Esto es bastante seguro porque uno necesitaría controlar una gran mayoría de los nodos antiguos para tener autoridad de sección (más de la mitad del sello del reino).

DKG de Poanetwork

hbbft de Poanetwork (algoritmo de consenso tolerante a fallas bizantinas Honey Badger) tiene una implementación bastante sencilla de DKG que no utiliza temporizadores. Su código ha sido auditado por algunos expertos en criptografía, por lo que también es una gran ventaja sobre el nuestro.

El algoritmo de generación de claves de HBBFT en pocas palabras:

  • Cada uno de los participantes genera Partes que transmiten a los demás
  • Los participantes verifican todas las Partes y generan Acks (agradecimientos) para cada uno de ellos, también transmitidos a los demás
  • Finalmente, cada uno puede generar su propia clave compartida a partir de Parts y Acks

¡Sin embargo, hay una trampa! ¡Todos necesitan procesar los mismos conjuntos de Parts y Acks!

De sus documentos:

Si el Ack de Alice fue manejado por Bob pero no por Carol, Bob y Carol podrían recibir diferentes conjuntos de claves públicas y compartir claves secretas que no coinciden.
Una forma de garantizar esto es enviar los mensajes a un libro de contabilidad público antes de manejarlos.

Aunque no hay temporizadores involucrados, este algoritmo requiere que los nodos se esperen unos a otros.

Integración con caja fuerte

Necesitamos asegurarnos de que todos los participantes tengan acceso a los mismos conjuntos de Parts y Acks. Los documentos de Poanetwork sugieren usar un libro mayor distribuido como una cadena de bloques para garantizar que todos los participantes tengan los mismos conjuntos. No tenemos una cadena de bloques en Safe, pero está bien. ¡Nuestro equipo tuvo una idea con la transmisión de mensajes firmados que no requieren un consenso total! Funciona de la siguiente manera:

  • Enviar Partes en un mensaje firmado
  • Espere hasta que entren las 7 ‘Partes’, transmita el conjunto firmado
  • Espere hasta que lleguen los 7 conjuntos idénticos firmados de Partes
  • Enviar Acks
  • Espere hasta que ingresen los 7 ‘Acks’, transmita el conjunto firmado
  • Espere hasta que entren los 7 conjuntos idénticos firmados de Acks
  • Una vez que un nodo recibe 7 conjuntos firmados con los mismos ‘Acks’, puede generar la clave compartida a partir de las ‘Partes’ y ‘Acks’ acordadas.

El hecho de que tengamos esa ronda adicional de transmisión de todos a todos para que todos los nodos vean que todos los nodos han visto las mismas Partes y Acks hace que este algoritmo sea resistente a una cierta cantidad de nodos bizantinos. También es fácil probar que un nodo hizo trampa al mostrar dos mensajes diferentes y contradictorios que firmaron.

Aunque este algoritmo simple asegura que los nodos estén de acuerdo en las mismas Partes y Acks, no garantiza la terminación en caso de una cierta cantidad de pérdida de mensajes. Eso está bien, lo abrazamos y no lo vemos como un fracaso.

Si se pierden suficientes mensajes, asumimos que este grupo de candidatos no era apto para convertirse en ancianos en primer lugar. En cada evento de abandono (nodo que se une o deja una sección), los ancianos verifican si los 7 miembros más antiguos de la sección son los ancianos actuales. Si ese no es el caso, les piden a los miembros más antiguos que inicien DKG. Este proceso se denomina Transferencia.

Los eventos de abandono pueden ocurrir a un ritmo bastante rápido, por lo que son posibles varios DKG simultáneos. Es una carrera entre múltiples DKG, y el que termine primero gana el derecho de pasar por el proceso de entrega. Es posible que muchos DKG se queden sin terminar o atascados debido a la pérdida de mensajes, pero eso está bien, es parte del juego. Cada nodo mantiene sus estados DKG actuales en un conjunto temporal que se restablece en cada traspaso.

Este algoritmo convierte a DKG en un proceso pasivo: es solo manejo de mensajes. No hay temporizadores, ni obtención de datos en otros nodos, solo un conjunto temporal de DKG en curso que esperan ser completados o descartados después de la próxima entrega.

Si por algún motivo se caen varios mensajes y no se puede terminar un DKG, esto se maneja fácilmente. Podemos dejarlo en Disfunción para rastrear eventualmente los nodos inactivos/lentos y rechazarlos. Esto a su vez desencadena cabandono, y ese abandono desencadena una nueva ronda de DKG.

Enlaces


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.