Actualización de Safe Network Dev 🇪🇸 11 agosto 2022

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

Con la actividad en curso en varias áreas dispares, si no no relacionadas, pensamos que sería un buen momento para resumir el estado general del proyecto que cubre los principales hilos de trabajo, dónde están y cómo se conectan.

Progreso general

@yogesh ha estado optimizando la configuración del servidor de ElasticSearch/Kibana para permitirnos monitorear más fácilmente nuestras gotas y está finalizando los documentos para traceroute.

@joshuef descubrió un proceso en sn_node que consume alrededor de 1/3 del tiempo de CPU y probablemente no sea necesario ya que hemos implementado esa funcionalidad en otro lugar, por lo que está viendo qué sucede si lo eliminamos.

@oetyng y @davidrusu han estado al frente de la conceptualización de la creación y los pagos de Genesis DBC, que el equipo ha estado desarrollando esta semana (ver más abajo), mientras que @anselme está en las etapas finales de la refactorización de DKG eliminando los subprocesos múltiples para simplificar , así como la eliminación de tiempos de espera (ver más abajo).

Desglose de actividades

Membresía, AE y consenso: unir los puntos

Membresía y Anti-Entropy (AE) se trata de que el sistema se mantenga actualizado, mientras que el consenso se usa para decidir sobre decisiones que cambian la composición de una sección y/o los datos que contiene.

Cada mensaje del sistema que se envía a través de la red contiene la clave de sección. El cliente envía lo que cree que es la clave de la sección actual cuando se comunica por primera vez con la sección, y si está desactualizada, los ancianos de la sección le envían la clave actual en el proveedor de autoridad de la sección (SAP), que también contiene una lista de los ancianos en la sección, para que pueda actualizar sus registros antes de volver a intentarlo. Esto es AE.

Ahora estamos considerando agregar Membresía a este intercambio de información también, para cerrar la brecha entre lo que los nodos entienden y votan, y lo que se comparte dentro del SAP. La membresía, como recordará, es la forma en que los ancianos realizan un seguimiento de los adultos y otros ancianos en su sección, para que puedan manejar nuevas uniones, divisiones, abandonos y promociones.

En particular, cuando analizamos los pagos a adultos individuales, será más rápido si sabemos dónde están: los adultos abandonan más rápido que los ancianos y es posible que hayan sido reubicados en otra sección o promovidos. Además, los adultos tienen una edad de nodo, y su pago será proporcional a eso. Por lo tanto, estamos analizando cómo incluir información sobre la generación actual de adultos de la Sección en mensajes sobre almacenamiento y pagos.

Los adultos pueden reclamar sus pagos en cualquier momento, incluso si han cambiado de sección, etc., porque el DBC se vuelve a emitir a su clave pública y pueden probar que estaban en la sección en ese momento en particular, como parte de esa generación en particular. Entonces, esta medida se trata más de reducir la cantidad de mensajes que vuelan.

Además de incluir a los Miembros en el proceso de intercambio de información, también hemos introducido un mecanismo de consenso en la forma en que funciona. La membresía utiliza el consenso para aceptar y eliminar miembros en una sección de manera sincronizada. Se asegura de que todos los ancianos tengan la misma opinión sobre el orden de las entradas y salidas en la sección. Esto es para evitar inconsistencias en el conjunto de miembros de cada anciano, ya que el registro de cambios de miembros es una cadena de solo anexar donde se requiere el consenso con la mayoría calificada para agregar un nuevo elemento.

Tiempo de llamada en los tiempos de espera: mayor certeza en las rondas DGK

En general, DKG no utiliza el consenso, sino que los participantes de DKG se aseguran de que nadie haga trampa enviando mensajes firmados y, una vez que obtienen todos los mensajes de los demás, envían un conjunto con los mensajes de todos y se aseguran de que todos firmen el mismo conjunto. Si hay una sola inconsistencia, dejan de participar en esta ronda de DKG, se considera fallida y nunca llegamos a ningún tipo de consenso sobre esta ronda. Esto asegura que una ronda DKG con miembros tramposos nunca llegue a su fin, después de todo, no queremos tramposos como ancianos.

Muchas rondas DKG pueden ocurrir al mismo tiempo, y es una carrera entre ellas para llegar a la terminación (o extinguirse). Cuando tenemos un DKG completo, el consenso de transferencia puede comenzar y decidir sobre los próximos ancianos. Dado que la transferencia utiliza el consenso, se asegura de que solo se seleccione un resultado de DKG, por lo que podemos tener varias finalizaciones de DKG simultáneas, pero solo una de ellas se seleccionará para la transferencia.

La generación de claves distribuidas (DKG, por sus siglas en inglés) es la forma en que los ancianos crean la clave de sección de manera segura, donde cada anciano solo conoce su propia clave compartida. En las pruebas, hemos encontrado algunos casos en los que DKG fallaba y se volvía a intentar de manera inconsistente debido al uso de tiempos de espera al esperar mensajes.

Estamos renovando nuestro DKG con una implementación más limpia y sin temporizador. Por ejemplo, si los siete nodos más antiguos de una sección no son los más antiguos, intentarán ejecutar DKG para crear una nueva clave de sección. Si no participan todos los candidatos mayores, permitimos que este DKG no finalice, y esto está bien porque no queremos que los nodos inactivos se conviertan en mayores. Podemos esperar a que vuelva a ocurrir otra rotación de miembros y desencadenar otro DKG. Aceptamos tener cLos DKG actuales compiten para convertirse en los nuevos ancianos. El consenso de traspaso decidirá quién gana en última instancia.

@anselme ha pasado mucho tiempo limpiando DKG, eliminando tipos de mensajes innecesarios del código DKG e integrando el nuevo DKG. Se ve mucho mejor ahora y pronto podremos probarlo.

Cambios de nodo

Hemos realizado algunos cambios en nuestro binario sn_node. Ahora debe pasar la ruta del archivo de contactos a cada nodo que se une a una red (--network-contacts-file). En lugar de que el nodo espere que los contactos se encuentren en algún lugar, otras herramientas se encargan de garantizar que se proporcione la ruta al nodo.

Hemos actualizado nuestra sn_launch_tool para hacer esto, por lo que si la está usando (o la CLI que la usa), la herramienta ahora proporciona a cada nodo de unión la ruta a --network-contacts-file.

--network-contacts-file es simplemente un archivo que proporciona a un nodo que se une oa un cliente de arranque la información que necesita para unirse a la red. Esta información se encuentra en SAP y en la parte SAP de PrefixMap.

Para los nodos nuevos, usamos el archivo PrefixMap del nodo de Génesis para proporcionar esta información (se encuentra en ~/.safe/node/local-test-network/sn-node-genesis/prefix_map), pero la herramienta también copia este archivo a la ubicación donde los clientes/CLI lo encontrarán de forma predeterminada (~/.safe/prefix_maps/default).

Podemos usar el mismo PrefixMap para permitir que tanto un nodo se una a una red como un cliente arranque en la red, ya que contiene los SAP a los que se pueden conectar. Desde su perspectiva, es lo mismo que una lista de contactos de red.

En el futuro, los clientes y los nodos pueden admitir otros tipos de archivos y formatos. Independientemente de los cambios allí, siempre necesitarán una lista de contactos de red para arrancar/conectarse a una red.

Como se describe en una actualización reciente, PrefixMap evolucionó recientemente de un archivo simple que asigna prefijos de sección a los SAP actuales, a un estructura más compleja que incluye la clave de sección completa DAG/árbol, por lo que es probable que este archivo cambie de nombre pronto.

Finalizando el pago de la red de las recompensas del 70 %

En última instancia, la red creará el 70% de SNT en el proceso de carga de datos de los clientes.

Cuando los clientes cargan datos, primero deben pagar las secciones donde se almacenarán los datos. Estos pagos se comparten entre los nodos de cada sección (lo más probable es que los ancianos y adultos almacenen los datos proporcionados, prorrateados según la edad).

Sin embargo, una cierta proporción (por decidir) de los pagos también resultará en la acuñación de nuevos SNT en forma de DBC. El valor total del nuevo DBC será el mismo que el monto del pago. El nuevo DBC se compartirá entre todos los nodos de la sección.

Para seleccionar aquellos pagos que darán como resultado un nuevo SNT, se realiza una prueba, por ejemplo, algún tipo de coincidencia que involucre un hash del pago y el prefijo de la dirección de la sección. La probabilidad de pasar la prueba dependerá de la tasa deseada de creación de SNT (anteriormente, la tasa de cultivo).

Los ancianos revisan cada pago para ver si pasa esta prueba. El incentivo de esta verificación (que es rápida y requiere recursos mínimos) es la oportunidad de ganar SNT. La mayoría de los pagos no pasarán la prueba y procederán con normalidad, pero cuando hay una coincidencia, los ancianos usan ese pago para acuñar un ‘Génesis DBC’. Este Genesis DBC es completamente nuevo y aumenta la cantidad total de SNT disponible para gastar. Su monto total es el mismo que el monto del pago por carga y su valor se divide entre todos los nodos de la sección, ponderado por la “edad del nodo”.

Para gastar un DBC, debe volver a emitirse a las claves públicas de los nuevos propietarios. Para esto, devolvemos el Genesis DBC al cliente y hacemos que vuelva a emitir nuevos DBC a los nodos, más un DBC para sí mismo como incentivo. El monto de este incentivo necesita ser calculado.

Una vez que se han vuelto a emitir los DBC, se notifica a los nodos destinatarios y ahora pueden gastar su DBC cuando lo deseen.

Minting nuevo SNT solo ocurre con nuevo almacenamiento de datos. Las transferencias SNT no dan como resultado la creación de un nuevo DBC.

Probablemente cambiaremos el nombre ‘Génesis DBC’ ya que hay muchos DBC de este tipo, por lo que la palabra ‘génesis’ es confusa.

Finalización de la agricultura/pago del almacenamiento

Con el concepto de emisión de tokens funcionando muy bien, también podemos ver cómo encajan nuestros planes de pagos de datos y, felizmente, vemos que encajan bastante bien. Es un flujo del que hemos hablado anteriormente, con clientes que solicitan cotizaciones de la sección para un conjunto de datos determinado y luego realizan los pagos correspondientes. Lo bueno es que esto está inherentemente por lotes, por lo que un conjunto de reediciones de DBC puede funcionar para cualquier cantidad de datos.

Este proceso nos da un recibo con el que podemos validar que se ha pagado un dato determinado, y que podemos adjuntar a los datos de manera efectiva para que sea “Válido en la red”, es decir, se puede volver a cargar sin tener que pagar por eso, por ejemplo.

Este recibo formará parte del proceso de pago de la red como se describe anteriormente.

Uso de rondas de chismes para membresía dentro de la sección yactualización de intersecciones de PrefixMap

Introducimos un enfoque chismoso para la creación de un nuevo SAP para garantizar que la red siempre sea accesible desde todas las secciones. Este mecanismo asegura que la información se distribuya logarítmicamente (muy rápido y eficiente). Cuando un anciano recibe un nuevo SAP de cualquier parte de la red, seleccionará dos ancianos al azar de cualquier sección y les reenviará el mensaje. AE se asegurará de que los nodos se actualicen en ambas direcciones y también terminará la ronda de chismes. Este es un “chisme de intersección” y solo concierne a los ancianos.

Interno a la sección, tenemos cambios de membresía que incluyen adultos. Estos cambios seguirán el mismo patrón para garantizar que todos los miembros estén actualizados con cualquier cambio de membresía. Esto es ‘chisme dentro de la sección’.


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.