Actualización de Safe Network Dev 🇪🇸 13 octubre 2022

Software
1

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

1
1830×430 391 KB

Hemos estado hablando durante un tiempo sobre el proceso refactorizado para elegir nuevos ancianos de sección y administrar divisiones. Esta semana, @anselme profundiza en el pensamiento detrás del enfoque de cinturones y aparatos ortopédicos para esto.

Progreso general

@Chriso está refactorizando los procesos para firmar fragmentos y registros y probar el almacenamiento y el doble gasto de DBC.

@roland está trabajando en pruebas para sn_sdkg AE y la funcionalidad de membresía que se describe a continuación.

Mostafa ha estado investigando mecanismos de consenso descentralizados y está revisando nuestra configuración actual.
@davidrusu está reelaborando el proceso de unión para incluir una actualización del conocimiento de la red antes de unirse.

Y @anselme y @dirvine están refactorizando el proceso de autoridad como se describe la semana pasada.

@bzee, @bochaco y @joshuef están trabajando para depurar la estabilidad de nivel inferior. Hemos visto una combinación de manejo lento de mensajes y errores en la administración de conexiones que causan problemas en ocasiones. Así que estamos tomando una inmersión profunda aquí. Hemos hecho algunos progresos, simplificando la forma en que se manejan los mensajes y nos mantenemos en este frente, ya que parece que será una refactorización bastante prometedora, tanto en términos de simplicidad del código como de estabilidad.

Todo sobre sn_sdkg

DKG con sn_sdkg

  • Basado en la generación de claves de poanetwork en hbbft
  • Elimina temporizadores
  • Presenta chismes
  • Adopta DKG concurrente
  • Una carrera entre DKGs a Handover

Acabamos de integrar sn_sdkg (generación de claves distribuidas sincrónicas de Safe Network), reemplazando la versión anterior donde vimos fallas y tiempos de espera cuando las redes eran lentas. La causa raíz es probablemente que estamos usando temporizadores. Este nuevo proceso DKG no utiliza temporizadores, de hecho, no queremos ningún temporizador en Safe, en ningún lugar, en absoluto.

DKG no está activo, es solo algo que los nodos hacen en segundo plano cuando reciben mensajes del sistema y pueden ejecutar varias sesiones al mismo tiempo.

Además de usar anti-entropía (AE), sn_sdkg también introduce chismes, para asegurarse de que los nodos reciban los mensajes que puedan faltar, para que todos sean eventualmente consistentes.

Recorrámoslo.

Los ancianos envían DkgStart

  • división de sección
  • entrega de sección

El primer paso en el proceso es que los ancianos envíen un mensaje DkgStart. Esto sucede cuando surge una de dos situaciones. La primera es cuando llega un nodo a una sección que es más antigua que uno o más de los antiguos actuales. En este caso, tenemos que traspasar: se promueve el nuevo nodo y se transmite el conocimiento de la sección. El segundo escenario es cuando la sección se vuelve demasiado grande y se divide.

pub struct DkgSessionId {
    /// Prefijo de la sesión para la que somos candidatos mayores
    prefijo pub: prefijo,
    /// Otros ancianos en esta sesión de dkg
    Ancianos del pub: BTreeMap<XorName, SocketAddr>,
    /// La longitud de la rama principal de la cadena de sección.
    pub section_chain_len: u64,
    /// Los miembros de arranque para la siguiente instancia de Membresía.
    pub bootstrap_members: BTreeSet<NodeState>,
    /// La generación de miembros en la que se creó una instancia de SAP
    pubmembership_gen: Generación,
}

Cuando hay un evento DkgStart, los ancianos generan información en una estructura llamada DkgSessionId (el formato se llama ‘struct’ en Rust). Firman esta estructura con su clave compartida BLS y la intercambian con los otros ancianos. Cada DkgSessionId proporciona información básica sobre el estado actual de las cosas y es exclusivo de una ronda DKG.

El prefijo es el prefijo de la sección actual. En el caso de una entrega no cambia. En el caso de una división, sí, y agregamos un uno o un cero a nuestro prefijo actual dependiendo de si estamos en el lado 0 o 1 de la división.

El campo ‘ancianos’ contiene todos los nuevos ancianos candidatos para esta sesión de DKG, nodos con una edad de nodo igual o mayor que la de un anciano actual.

section_chain_length (por cambiar de nombre) es la distancia desde la clave de sección actual hasta Génesis. Podemos pensar en ello como la “generación de la sección”.

membership_gen también muestra la generación de miembros. Es diferente a la generación de secciones. Cada sección tiene muchas generaciones de miembros y la longitud de la cadena no cambia.

bootstrap_members son los ancianos actuales en la sección.

Una vez que los nodos reciben DkgSessionIds de todos los ancianos actuales, pueden iniciar una sesión DKG.

¡Vamos!

Pasos Dkg

diagrama de flujo LR;
A[DkgStart] --> B[Clave efímera]

Todos los ancianos actuales y candidatos reciben un mensaje DkgStart dirigido a ellos y en el que se incluyen como ancianos en la estructura DkgSessionId.

Luego, cada uno de estos nodos genera una clave BLS única y efímera que solo se usa para esta ronda DKG. Esta clave efímera está firmada con su clave ed25519, que sirve como su identidad, para que los otros nodos puedan verificar si es válida.

Pasos Dkg

diagrama de flujo LR;
A[DkgStart] --> B[Clave efímera] --> C[Votación]

Luego viene la etapa de votación en la que cada nodo puede generar sus propias claves para votar. Usamos un proceso tomado de Poanetwork de generación de claves en hbbft, lo que garantiza que cada nodo solo pueda generar su propia clave y no use información de otros nodos para generar una clave separada para la ronda DKG.

Los nodos están votando sobre cuáles de los candidatos y ancianos existentes deberían ser ahora los ancianos de sección.

Pasos Dkg

diagrama de flujo LR;
A[DkgStart] --> B[Clave efímera] --> C[Votación] --> D{Generación de clave}

Una vez que finaliza la votación, el candidato genera una nueva clave que envía a los ancianos actuales para demostrar que es elegible para convertirse en un anciano (porque una gran mayoría de nodos lo han firmado con la clave recién acuñada). Entonces DKG es una especie de prueba para un buen candidato. Si no terminan DKG, no son lo suficientemente buenos.

Concurrencia

diagrama de flujo LR;
A[DkgStart1] --> B[Clave efímera] --> C[Votación] --> D{Generación de clave1}

diagrama de flujo LR;
A[DkgStart2] --> B[Clave efímera] --> C[Votación] --> D{Generación de clave2}

Se pueden realizar varias sesiones de DKG a la vez. Cada vez que hay un nuevo miembro en la sección, es posible que (si el nuevo nodo es más antiguo que cualquiera de los antiguos actuales) tengamos una nueva sesión de DKG, por lo que si mientras una sesión está en curso se une un nuevo nodo, puede comenzar otra sesión de DKG. Algunos terminarán, otros simplemente expirarán y fallarán. Es una carrera, y elegimos el primero que termina. Más tarde, si resulta que hay un nodo más antiguo que no es un mayor, el proceso comienza de nuevo.

Resuelto por traspaso

diagrama de estado-v2
Dkg1 --> Entrega
Entrega --> Ganador: Dkg1
Dkg2 --> Entrega
Dkg3 --> Entrega

Si hay empate, solo queremos un ganador, es decir, un nuevo anciano. El traspaso es un proceso que utiliza el consenso para decidir cuál debe ganar.

AE activo

diagrama de estado-v2
DkgStart --> Clave efímera
EphemeralKey --> EphemeralKey: Incluye DkgStart AE
Clave efímera --> Votación
Votación --> Votación:Incluye EphemeralKeys AE
Votación --> Terminación

En estas etapas mencionadas anteriormente, recibir un mensaje DkgStart, crear una clave efímera y votar, debemos compensar los problemas de red y los nodos lentos. Por ejemplo, necesitamos las llaves de todos para empezar a votar, si no nos quedamos atascados. Por lo tanto, incluimos AE en cada mensaje relacionado con la clave para proporcionar información de que podría faltar un nodo. AE es una forma ligera y eficiente de asegurarse de que todos los nodos estén al día.

enum SystemMsg {

    DkgStart(DkgSessionId),

    DkgEphemeralPubKey {
        /// El identificador de la sesión DKG para la que es este mensaje.
        sesión_id: DkgSessionId,
        /// Autorización de sección para el mensaje de inicio de DKG
        section_auth: Prueba de autoridad<Prueba de autenticación de sección>,
        /// La clave bls efímera elegida por el candidato
        pub_clave: BlsPublicKey,
        /// La firma ed25519 del candidato
        firma: Firma,
    },

    DkgVotes {
        /// El identificador de la sesión DKG para la que es este mensaje.
        sesión_id: DkgSessionId,
        /// Las claves públicas bls efímeras utilizadas para esta ronda Dkg
        pub_keys: BTreeMap<XorName, (BlsPublicKey, Firma)>,
        /// El mensaje DKG.
        votos: Vec<DkgSignedVote>,
    },

    DkgAE(DkgSessionId),

    ...
}

En el código, un mensaje del sistema, que es el tipo de mensaje que se usa para los procesos que pueden cambiar la estructura de la red, se parece al anterior. Esto encapsula todos los procesos de los que hemos hablado.

Resiliencia

  • AE activo
  • Votación AE
  • Chisme
    • al esperar votos
    • al recibir votos desactualizados

Para concluir, tenemos múltiples mecanismos de resiliencia al manejar traspasos y divisiones.

AE activo significa que a los nodos se les envía información del paso anterior en caso de que se lo hayan perdido.

También tenemos chismes como respaldo. Si estás en una sesión de DKG, estás listo para recibir claves efímeras o votos de alguien. Si no aparecen, envías tu conocimiento actual a los demás con la esperanza de que te actualicen. Además, si recibe AE desactualizados de alguien, puede actualizarlos.

Así que el chisme tiene dos propósitos. Para asegurarnos de que estamos actualizados para poder avanzar, y para actualizar a otros, para que podamos llegar a la terminación.

Junto con AE y permitiendo la competencia entre los procesos DKG, esto proporciona un proceso mucho más sólido para promover nuevos ancianos y manejar divisiones. Durante las divisiones, tenemos dos DKG en lugar de uno.

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.