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 
Enlaces útiles
- Sitio web de red segura
- Introducción a la red segura
- Aspectos básicos de la red
- Hoja de ruta
- Glosario
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.