Actualización de Safe Network Dev 🇪🇸 20 de enero de 2022

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

Un área clave de enfoque en este momento es la membresía, cómo 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. Esta funcionalidad es manejada por la caja sn_membership. Los algoritmos de esta caja se están sometiendo actualmente a pruebas rigurosas antes de integrarse en la red. Esta no es una característica nueva, como tal, sino más bien un refuerzo forense de la casa intermedia que hemos tenido hasta ahora y una formalización de los algoritmos. La mayor parte del equipo está trabajando actualmente en algún aspecto de la membresía.

Progreso general

El cajón sn_membership está siendo manejado por @davidrusu. Casi todas las pruebas están pasando ahora, por lo que se trata principalmente de ordenar.

@bochaco está analizando los flujos dentro de la membresía: ¿cuál es el orden de los eventos cuando se une un nuevo nodo o asciende el adulto mayor?

Un aspecto cubierto por el manejo de membresía es el traspaso de ancianos, asegurándose de que los ancianos recién ascendidos tengan toda la información correcta, llaves, etc. @anselme ha llevado esto a un buen lugar ahora y está prácticamente listo para funcionar.

Lejos de la membresía, @chriso ha estado trabajando en problemas con las pruebas nocturnas y, después de haber terminado la documentación de CLI, ahora está escribiendo NRS.

En el frente de datos, @yogesh se enfoca en probar la replicación de datos, y @joshuef ha actualizado qp2p a la última versión de quinn.

Mientras tanto, @danda se está desconectando de los DBC. La integración de Ring CT está prácticamente terminada y las mentas son el siguiente paso, aunque se necesita más trabajo para que las mentas funcionen correctamente con Ring CT.

@happy being ha hecho una pequeña y encantadora PR actualización del registro de nodos. Esto debería ayudar a ahorrar espacio en cualquier nodo iniciado y hacer que los registros sean más fáciles de seguir con comandos como tail -f.

Afiliación

Las operaciones de membresía cubren los nuevos nodos que se unen a la sección, la gestión de la capacidad, la expulsión de los nodos que se comportan mal o la reducción de la antigüedad de los nodos, la promoción de adultos a ancianos y la garantía de que los nuevos ancianos estén debidamente equipados.

Como recordatorio, las secciones tienen siete ancianos y (a menos que las pruebas futuras muestren lo contrario) entre 60 y 100 adultos. Los adultos se agitan con frecuencia, con abandonos, nuevas incorporaciones y nodos más antiguos que llegan cuando se reubican desde otras secciones. Los ancianos deben realizar un seguimiento de la membresía de la sección para que sepan cuándo permitir que se unan nuevos adultos y también cuándo se dan de baja los ancianos y se asciende a un adulto. Conservan una lista de todos los adultos y ancianos actuales en su sección.

La membresía de la sección está restringida por el tamaño máximo de la sección. Cuando tenemos tales restricciones en un sistema distribuido, a menudo necesitamos recurrir al consenso para decidir entre opciones en competencia. En nuestro caso de membresía, los ancianos deben decidir cuál de los (muchos) nodos que esperan para unirse a una sección debe permitirse la entrada.

No estábamos usando un algoritmo de consenso hasta este punto, los procesos actuales para administrar la membresía a veces fallan cuando ocurren eventos inesperados.

La nueva caja sn_membership proporciona un algoritmo de consenso BFT sin líder que proporciona un buen rendimiento en un modelo de red eventualmente síncrono. Después de un régimen de prueba despiadado, ahora está listo para integrarse en la red.

sn_membership funciona junto con antientropía (AE) y generación de claves distribuidas (DKG) para administrar la membresía de la sección. Aquí hay algunos flujos.

Unión de nodos

Un nodo de unión interactúa con un anciano, intercambiando mensajes JoinRequests hasta que se acepta provisionalmente y recibe el desafío de prueba de recursos y se lo devuelve al anciano.

Con el sistema anterior, una vez que pasaba la prueba, el nodo estaría dentro, pero esto era un riesgo de seguridad y podía causar bloqueos (ver más abajo). Ahora el anciano envía una propuesta para agregar el nodo usando el protocolo sn_membership a otros ancianos de la sección. sn_membership se completa una vez que tenemos Super-Mayority over Super-Mayority, es decir, una gran mayoría de ancianos ve que una gran mayoría de ancianos ha aceptado esta propuesta. Una vez que sn_membership ha comenzado, se garantiza que se completará (siempre y cuando no se viole nuestra suposición de red eventualmente síncrona).

Una vez que la propuesta alcanza el consenso entre los ancianos, el anciano envía la aprobación al nodo que se une.

Promoción de adultos y traspaso de mayores

Si un anciano se da cuenta de que los ancianos actuales no son los siete nodos más antiguos, genera una votación para promover a los adultos mayores y degradar a los ancianos más jóvenes para dejar paso.

El algoritmo Elder Handover que controla este proceso, que ahora está listo para integrarse en la caja sn_membership, es el siguiente.

Un anciano recibe una gran mayoría de las acciones completas de DKG para comprobar que los ancianos actuales son los siete miembros más antiguos.

El anciano propone un nuevo conjunto deancianos

Los ancianos siguen un consenso de estilo sn_membership para decidir sobre un solo mensaje NewElders. Este paso es necesario cuando tenemos una cadena complicada de eventos que terminan con múltiples grupos de nodos compitiendo para completar DKG y convertirse en los próximos ancianos.

Se pasa una lista de los miembros de la sección actual al nuevo mayor, se actualiza el proveedor de autoridad de la sección (SAP) y se agrega un nuevo bloque a la cadena de la sección.

El papel del consenso

Entonces, ¿por qué es necesario el consenso para ser miembro cuando otras partes de la red confían en AE para mantenerse actualizadas?

Aquí hay un ejemplo. Digamos que una sección está casi llena. El límite de tamaño de la sección es de 50 nodos (solo por ejemplo) y actualmente hay 49 miembros. Un nuevo nodo envía una JoinRequest a un anciano. Bajo un sistema sin consenso, el antiguo verifica la capacidad y ve que hay capacidad, intercambia mensajes AE y, siempre que el nuevo nodo pase la prueba de prueba de recursos, está dentro.

Pero en esta etapa, la sección está lista para dividirse, lo que cuando varios nodos intentan unirse puede generar conflictos de prioridades:

Digamos, en el caso extremo, que los siete ancianos reciban JoinRequests simultáneamente desde siete nodos diferentes. Los siete ancianos ven que tenemos espacio para un nodo más, y dado que cada uno de los siete nodos pasó sus pruebas de prueba de recursos, cada anciano permitirá que su nodo se una a la sección.

Pero, tras los chismes contra la entropía entre los ancianos, descubren que sus compañeros ancianos no aceptarán los nuevos nodos de los demás, ya que llevaría la capacidad de la sección por encima del límite. Los ancianos se encuentran en una situación de cerebro dividido donde cada anciano tiene una visión diferente de la membresía de la sección.

Para evitar que suceda este problema, los ancianos llegan a un consenso sobre qué nodos se permitirán. Con sn_consensus, cada uno de los siete ancianos puede proponer hasta un cambio. Esto significa que se pueden decidir hasta siete cambios (unirse/abandonar) en una sola ronda.

En el caso anterior, sn_membership significará algo de trabajo adicional en comparación con los ancianos que actúan por su cuenta, pero esta sobrecarga solo es visible cuando tenemos muchas opciones en competencia. sn_membership se reduce con gracia a Byzantine Reliable Broadcast (BRB) cuando los ancianos están de acuerdo en general sobre las acciones a tomar, solo pagamos los gastos generales de consenso cuando los ancianos comienzan a tener desacuerdos. sn_membership es un método pacífico para resolver desacuerdos :slight_smile:


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.