Actualización de Safe Network Dev 🇪🇸 18 de noviembre de 2021

Esta es una traducción automática. El original en inglés está aquí: Update 18 November 2021

Así que esta semana le entregamos a Gab
Como sabes, él no es de los que presumir
Pero ha solucionado silenciosamente un problema de mensajería.
Al almacenar SectionChains en un DAG
OK, no es un Lambo ni siquiera un Jaguar
Pero para operaciones de red es realmente fabuloso
Dale un vistazo si ese es tu bolso

Progreso general

@danda ha creado diagramas UML para todas las cajas de Safe Network, lo que facilita ver cómo encajan todos juntos. Para los que no son expertos en tecnología, la capacidad de buscar los nombres de los bloques de código y cómo se vinculan les da una idea del funcionamiento de la red. Al igual que ver todos los engranajes de un reloj, es posible que no comprenda todos los detalles del paso y la cantidad de dientes, pero puede ser bueno ver los engranajes detrás del bisel para comprender mejor su funcionamiento. Puede ver versiones desnudas, compactas y completas de cada caja, con niveles crecientes de detalle, con bloques verdes que representan rasgos, estructuras azules y enumeraciones amarillas. El sitio se ve mejor en Chrome.

Una representación SVG ‘desnuda’ de la caja sn_dbc

Mientras tanto, @qi_ma y @ lionel.faber están centrando su atención en implementar el patrón Anti-Entropy en el proceso de generación de claves distribuidas.

OK para Gabriel (@bochaco).

Manejo del conocimiento de la red

El conocimiento de la red describe los procesos mediante los cuales los Ancianos realizan un seguimiento de la topología de la red. Debido a que Safe es asincrónico y siempre cambia, esto se hace según la necesidad de saberlo, por lo que cuando un nodo contacta con otro nodo, primero obtiene su conocimiento en sincronía mediante el intercambio de mensajes Anti-Entropy (AE).

Para reducir la mensajería, ahora tenemos un DAG para realizar un seguimiento de todas las SectionChains y un PrefixMap para almacenar los SAP de la sección actual. A continuación, se explica cómo afecta eso a la verificación de AE ​​y SAP cuando se rechaza un mensaje inicial.

SectionChain

Un SectionChain es una de las herramientas más importantes disponibles para un nodo, ya que le permite verificar si un dato o un mensaje es válido (tiene autoridad de red).

Una SectionChain es una lista enlazada de claves de sección, donde la clave de cada bloque de la cadena está firmada por la clave del bloque anterior, hasta la clave de génesis.

Cada bloque de la cadena contiene la clave de sección que los Ancianos usaban, en ese momento en particular, para firmar todos los procedimientos del acuerdo. Cada vez que los Ancianos cambian (abandono), se genera una nueva clave de sección y se agrega un nuevo bloque a la Cadena de Sección.

¿Cómo se usa para verificar mensajes y datos? Bueno, cualquier pieza de contenido o información firmada por una clave de sección se puede verificar mirando SectionChain. Si la clave se encuentra allí, significa que el contenido / información fue firmado por la sección en el pasado y, por lo tanto, tiene autoridad de red.

Reintento y redireccionamiento anti-entropía

La red utiliza un conjunto de mensajes Anti-Entropy (AE) para que los nodos se sincronicen sobre la topología de la red y la sección a la que pertenecen. Cada mensaje enviado a un nodo u otra sección debe incluir la clave de sección actual del destino para que el mensaje sea aceptado por el destinatario. Si este no es el caso, el destinatario rechazará el mensaje y se lo devolverá al remitente dentro de un mensaje “AE-Retry”. El mensaje “AE-Retry” contiene información actualizada sobre su sección, es decir, el Proveedor de autoridad de la sección actual (SAP), que enumera los Ancianos de la sección actual y la clave de la sección actual (consulte el capítulo AE en el Manual).

Un flujo de eventos similar se desencadena cuando se envía un mensaje a una sección incorrecta, lo que puede deberse a que el remitente carece de la información más reciente sobre la topología de la red. El destinatario también rechazará el mensaje devolviéndolo al remitente dentro de un mensaje “AE-Redirect”. En este caso, el mensaje AE-Redirect contiene el SAP de la sección a la que se debe reenviar el mensaje.

Cuando el remitente recibe un nuevo SAP a través de un mensaje “AE-Retry” o “AE-Redirect”, primero debe verificar que sea un SAP válido y confiable, es decir, verificar que el SAP corresponda a la red en la que confía el remitente.

Para hacerlo, el nodo debe verificar que la clave de sección que se encuentra en el SAP recibido sea criptográficamente verificable con la SectionChain hasta la clave de génesis, de lo contrario, un nodo malicioso podría redirigirlo a otro (no seguro) red o a secciones o pares malintencionados. Es por eso que cada mensaje Anti-Entropy también lleva una ProofChain para que el remitente original pueda verificar y confiar en el nuevo SAP.

Una ProofChain son los bloques más recientes de SectionChain; no necesitamos enviar la SectionChain completa si estuvimos en contacto recientemente con otra sección, solo el delta.

¿Qué ha cambiado?

Hasta ahora, cada nodo mantendría una copia de su propia SectionChain y SAP.Esto se usó para validar cualquier mensaje entrante o nuevo SAP recibido en mensajes AE, y también para construir una ProofChain al enviar mensajes AE a otros pares.

Lo cual estuvo bien para las secciones que conocemos, pero para las secciones distantes y desconocidas creó un poco de trabajo adicional.

Digamos que enviamos un mensaje y se devuelve diciendo que necesitamos redirigirlo a una sección que no hemos contactado antes, e incluyendo el SAP de esa sección desconocida. Conocemos la sección por su prefijo de dirección XOR, pero no sabemos nada más sobre ella, ni sobre nosotros. No hemos visto su SAP antes y no tenemos una ProofChain. Entonces, antes de que podamos reenviar el mensaje a la nueva sección, necesitamos enviar mensajes adicionales para intercambiar SectionChains, que es complejo y propenso a errores.

Esta es la razón por la que hemos estado trabajando recientemente para que todos los nodos realicen un seguimiento de las cadenas de secciones de todas las demás secciones. Esto permite que cada nodo proporcione una ProofChain a sus pares no solo cuando los actualiza con el SAP de su propia sección, sino también cuando un mensaje “AE-Redirect” les dice que lo hagan para una sección remota.

Esto elimina parte del tráfico y la complejidad de AE, y también permite a los nodos asegurarse de que solo interactúan con pares en los que confían para pertenecer a la misma red, verificando criptográficamente cualquier clave de sección que reciben hasta la clave de génesis.

Pero, ¿cómo podemos almacenar esta información de manera segura y eficiente, para que los nodos puedan acceder a ella cuando lo necesiten y para que se actualice en divisiones y abandonos?

Ahora hemos implementado un DAG (gráfico acíclico dirigido) para realizar un seguimiento de todas las SectionChains y un PrefixMap (un registro que asigna el prefijo de una sección a su SAP) para almacenar los SAP actuales de todas las secciones.

El DAG

La red comienza con una clave de génesis, que es el primer bloque en la SectionChain de la sección de génesis, y la clave del primer nodo está firmada por la clave de génesis para crear el segundo bloque en esta SectionChain. A medida que los nodos comienzan a unirse a esta primera sección, es decir, la sección de génesis, SectionChain sigue creciendo.

En algún momento, cuando la sección de génesis haya crecido en tamaño con suficientes miembros para dividirse en dos secciones separadas, los dos conjuntos de pares que se convertirán en Ancianos acordarán cuál se convertirá en su propia clave de sección (a través del proceso DKG). Una vez que hayan terminado de ponerse de acuerdo sobre las dos nuevas claves de sección, el conjunto actual de Ancianos llegará a un acuerdo para dividir la sección, firmando las dos nuevas claves de sección con la clave de sección actual y creando dos ramas en la Cadena de Sección de la sección génesis.

Este proceso se repite en cada una de las dos nuevas ramas, independientemente entre sí. Se dividen en más secciones, creando más ramas en sus respectivas cadenas de secciones. Esto naturalmente forma un DAG, cada uno de los vértices contiene una clave de sección y la firma hecha con la clave de sección del vértice anterior.

Dada cualquier clave de sección, su ProofChain se puede construir a partir del DAG mediante la recopilación de todos los vértices (claves de sección y firmas) que están en la ruta desde la clave de génesis hasta esa clave de sección. Tenga en cuenta que, dado que las secciones nunca se fusionan, solo se dividen, siempre hay una ruta única desde la clave de génesis hasta cualquier otra clave de sección en el DAG, en otras palabras, hay una cadena de prueba única de la clave de génesis para cualquier clave de sección determinada.

Este desarrollo se detalla en este PR.


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.