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
Partesque transmiten a los demás - Los participantes verifican todas las
Partesy generanAcks(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
PartsyAcks
¡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
Partesen 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
- 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.