Actualización de Safe Network Dev 🇪🇸 21 julio 2022

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

Algo así como una precuela esta semana mientras observamos cómo las cadenas de secciones y los SAP encajan con los cambios de PrefixMap anunciados la semana pasada.

Progreso general

No hay grandes revelaciones esta semana, más del trabajo constante de prueba, optimización y depuración que marca esta fase del desarrollo.

@davidrusu ha estado buscando formas de monitorear la red y administrar Node Age, incluida la forma en que los adultos pueden demostrarles a los mayores que están vivos y coleando, incluso si no hay mucha actividad en la red.

@bzee continúa investigando OpenTelemetry, la herramienta de monitoreo de código abierto, con algunos refactores ya implementados para habilitar el registro a través del protocolo OTLP. Con suerte, esto debería permitirnos iniciar sesión en el servidor elástico, donde podemos obtener más fácilmente una descripción general del estado de las redes de prueba.

Y @joshuef continúa jugando con la optimización de la memoria. Hemos eliminado algunos reintentos demasiado entusiastas que potencialmente mantenían vivas las conexiones y mensajes pendientes en la memoria mientras el envío se reintentaba y reintentaba y reintentaba (tanto en la capa qp2p como en el nodo). También ha estado haciendo otros ajustes más pequeños que han ayudado a reducir considerablemente la carga de la memoria.

@yogesh tiene un PR establecido para permitir que la información de seguimiento de la ruta se devuelva al cliente. Esto enumerará todos los nodos involucrados en el flujo de mensajes para una consulta/cmd determinado, lo que debería ayudar con la depuración.

Cadenas de secciones y SAP

SectionChains proporciona un registro de cambios de ancianos dentro de una sección, actuando como prueba de que el conjunto actual de ancianos es válido. No podemos confiar en la palabra de un anciano individual de que es quien dice ser, ni podemos confiar en el grupo actual; ese sería un vector de ataque obvio. En su lugar, usamos las maravillas de la criptografía para crear una cadena de secciones, una lista enlazada segura que demuestra que los ancianos son quienes dicen ser, al vincular la clave de sección actual hasta la clave de génesis.

La clave ‘Génesis’ se puede considerar como una ‘prueba de red’. Es la primera clave creada por el primer nodo en la primera sección: la sección con el prefijo 0. Tan pronto como ese primer nodo solitario se une a otro nodo (tratando de resistirse a llamarlo Eva, ya que se volverá confuso rápidamente), se crea una nueva clave de sección B, que está firmada por la clave de génesis. Cuando se une un nuevo nodo C, nuevamente se crea una nueva clave de sección, esta vez firmada por B, y así sucesivamente.

Los días de firma de la clave Génesis terminan tan pronto como firma la clave B. Sin embargo, sigue siendo extremadamente útil como prueba de que la clave de la sección actual y todas las que la preceden son válidas, no infiltradas por un atacante, porque criptográficamente es muy fácil probar que la clave actual de cualquier sección está finalmente vinculada a ‘Génesis’, independientemente del tiempo que dure SectionChain se convierte en.

Firma

Pero, ¿qué entendemos por firmar? Firmar simplemente significa usar nuestra clave secreta para agregar algunos bits únicos a un mensaje o archivo. Cualquiera que tenga nuestra clave pública puede comprobar que fuimos nosotros quienes la firmamos (y en la mayoría de los casos que el archivo no ha cambiado tras la firma).

Para usar el ejemplo clásico, Alice envía un mensaje a Bob y lo firma con su clave secreta, lo que significa que crea una “firma” única a partir de una combinación del contenido del mensaje y su clave secreta. Bob puede estar seguro de que fue firmado por Alice porque puede verificar la firma con su clave pública. La espía Eve también tiene la clave pública de Alice, pero no puede engañar a Bob alterando el mensaje de Alice, ya que ya no tendría una firma válida.

En lugar de individuos como Alice y Bob, en una sección estamos tratando con decisiones grupales que deben ser aprobadas por una gran mayoría de ancianos. Para ser tolerante a fallas bizantinas (lo que significa que un tercio de los nodos pueden ser disfuncionales sin causar fallas), cinco de los siete ancianos deben firmar un mensaje. En lugar de que cada anciano realice un proceso como Alice y Bob, una forma mucho más eficiente de hacerlo es a través de la generación de claves distribuidas (DKG), donde cada anciano contribuye con una clave compartida. Tan pronto como tengamos cinco de estas claves compartidas, cinco cualesquiera, creamos una clave de firma válida y se valida la decisión. Este es el equivalente a la clave secreta de la sección que firma el mensaje, aunque con BLS no existe una clave secreta.

Eso está muy bien siempre que solo tengamos una sección, pero eventualmente, a medida que la red crezca, la sección se dividirá para crear nuevas secciones 01 y 11 con nuevos ancianos y nuevas claves de sección firmadas por la sección principal. Estas nuevas secciones experimentarán una rotación de personas mayores con el tiempo, y en cada ocasión se creará una nueva clave de sección DKG. Eventualmente, se forma una estructura de árbol con génesis como raíz y cada rama genera dos nuevas ramas a medida que la red se expande.

Lo importante es que cada clave de sección actual en cada sección tiene un camino por las ramas hasta la clave de génesis. Es decir, podemos demostrar que estamos en la red correcta y que el proceso de dar la bienvenida a nuevos nodos ha sido válido en cada paso, al menos hasta el DKG está preocupado. Pero tan pronto como hay más de una sección, cada sección tiene un camino diferente de regreso al ‘Génesis’, en cuyo punto la cadena de la sección se convierte en un DAG (gráfico acíclico dirigido) en lugar de una cadena lineal.

El proveedor de autoridad de sección (SAP)

La cadena de secciones es una herramienta simple pero vital. Cada nodo y cliente tiene una SectionChain. Como cliente o nodo, nos dice que la sección actual con la que estamos hablando es criptográficamente válida y que estamos en la red correcta (como lo demuestra la clave Genesis), en lugar de una bifurcación, pero eso es todo. .

Cuando un nodo o cliente se une a la red, se le otorga el SectionChain y el SAP. El SAP nos habla de los ancianos actuales. Es una lista de los mayores actuales (cada mayor tiene un ID único, una IP y un puerto) firmados por una de las claves en SectionChain. Esto significa que cuando nos conectamos a un nodo en esta lista, podemos estar seguros de que es válido porque, una vez más, la firma se puede rastrear hasta Génesis. El SAP también contiene la clave de sección actual.

Como se explicó la semana pasada, el SAP está incluido en PrefixMap, que asigna cada prefijo de sección a todas las claves en el historial de esa sección. Además de poder verificar que cualquier dato que estemos manejando sea correcto (tendrá el mismo prefijo que la sección), esto también significa que cuando nos movemos entre las secciones no tenemos que agarrar toda la cadena de la sección nuevamente. En su lugar, podemos descender por el árbol tanto como sea necesario, hasta llegar a una sección que ya existe en nuestra cadena de secciones y tomarla desde allí, lo que obviamente es más eficiente.

La próxima semana, más información sobre cómo encaja todo.


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.