Esta es una traducción automática. El original en inglés está aquí: Safe Network Dev Update - November 19, 2020
Resumen
Estas son algunas de las cosas principales a destacar desde la última actualización de desarrollo:
- qp2p tuvo algo de atención esta semana con mejoras de rendimiento realizadas, particularmente en torno a la agrupación de conexiones.
- Se está reintroduciendo la replicación de fragmentos en el código.
- Estamos entusiasmados de escuchar acerca de un artículo académico reciente de los autores de AT2 titulado Dynamic Byzantine Reliable Broadcast, que parece proporcionar una solución formalmente probada para nuestra problema.
- En sn_routing estamos en el proceso de agregar un join_flag para cambiar si aceptamos nuevos nodos en la red o no.
Cliente seguro, nodos y qp2p
Plan del proyecto Safe Network Transfers
Plan de proyecto de cliente seguro
Plan de proyecto de nodo de red segura
En primer lugar, esta semana en qp2p implementamos la agrupación de conexiones. Esto significa que si un nodo quiere conectarse a un par y la conexión se ha abierto antes (y aún está abierta), reutilizaremos la conexión existente en lugar de establecer una nueva. Esto mejora el rendimiento porque establecer una conexión es caro (implica un protocolo de enlace TLS, entre otras cosas). Esto también mejora la ergonomía porque los usuarios de qp2p ya no necesitan preocuparse por el almacenamiento en caché de la conexión. También implementamos la deduplicación de conexiones, lo que significa que varios intentos de conexión simultáneos al mismo par se resolverán todos en la misma conexión en lugar de abrir una conexión separada cada uno. Esto nuevamente mejora el rendimiento.
Hemos estado volviendo a la replicación de fragmentos de datos de Blob en sn_node. Comenzando con un factor de replicación 4x, los adultos de la red serán los principales responsables de almacenarlos. Estamos portando la implementación anterior de las bóvedas pre-asíncronas a la nueva base de código, adaptándola a los últimos cambios de almacenamiento, consulta, etc. También hemos estado haciendo un poco de mantenimiento en todos los ámbitos esta semana al cazar ‘desenvolver’ furtivo s, esperabasypánico` de nuestro código de producción y pruebas, esencialmente estabilizando nuestro código base y capturando todas las excepciones. Esta es la mejor práctica y algo que hemos estado posponiendo durante demasiado tiempo. Esté atento a las comprobaciones de CI adicionales que se agregarán en los próximos días en nuestras cajas, lo que garantiza que no se cuelen de nuevo en nuestro código.
Invertimos un poco de tiempo en investigar y pensar en cómo las API eventualmente deberán evolucionar para admitir la firma de solicitudes del cliente utilizando múltiples pares de claves en lugar de solo uno. Por ejemplo, un cliente puede querer almacenar un archivo que sería propiedad de una clave pública, mientras que el pago por dicha operación se haría usando una segunda clave pública que posee los fondos, y tal vez el cliente pueda usar un tercer par de claves para cifrar el contenido del archivo. Esto no es algo que estemos considerando de alta prioridad en este momento, más una PoC para ayudarnos a identificar los desafíos y darnos cuenta de cómo evolucionar eventualmente las API de nuestros clientes.
CRDT
El trabajo continúa en la membresía dinámica en DSB y esta semana nuestro consultor ha escrito un caso de prueba que demuestra un problema de concurrencia con las operaciones de datos mientras un miembro abandona el grupo. Una implementación correcta de la membresía dinámica siempre debe pasar la prueba mientras nuestra implementación ingenua actual falla, por lo que ahora tenemos algo concreto con lo que medir.
Con ese fin, estamos entusiasmados con un artículo académico reciente de los autores de AT2 titulado Dynamic Byzantine Reliable Broadcast. Proporciona una cita: “* la primera especificación de una primitiva de difusión confiable bizantina dinámica (dbrb) que es susceptible de una implementación asíncrona *”. En otras palabras, este documento proporciona una solución formalmente probada para exactamente nuestro problema.
Nuestro consultor está revisando este documento, así como otra posible solución utilizando algo llamado Generation Clock que podría no requerir tanto red de comunicacion.
Enrutamiento
Como se mencionó en la actualización de la semana pasada, el trabajo para permitir que un nodo se reincorpore con el mismo nombre fue aprobado y combinado esta semana. Esto significa que cualquier nodo que se reincorpore se reubicará inmediatamente con la mitad de su edad, siempre que la edad reducida a la mitad sea mayor que “MIN_AGE” (actualmente “4”). Esto está diseñado para desalentar los reinicios maliciosos.
Durante las pruebas internas, habíamos observado que el nodo génesis a veces se degradaba demasiado rápido, esto se debía a un cambio reciente en el que ahora creamos nodos con un rango de edades durante la fase de inicio. Para resolver esto, decidimos Iniciar el primer nodo con una edad superior, actualmente configurado en 32. Esto ahora se ha fusionado con master. Esto asegura que el nodo de génesis se mantenga estable como anciano durante un tiempo suficientemente largo, lo que facilita muchas cosas para las pruebas y la configuración de la red de prueba.
El trabajo en curso para mejorar la detección de pares perdidos avanza bien. Ya hemos aprovechado la nueva función de agrupación de conexiones en qp2p, que nos permitió simplificar el código. Algunas pruebas de integración iniciales muestran que la refactorización funciona bien. Este RP ahora está pasando por una revisión y prueba final, por lo que es de esperar que se fusione pronto.
Para asegurarnos de que cuando los recursos de un nodo estén cerca de agotarse, habrá nuevos nodos fluyendo para compartir la carga de trabajo, vamos a permitir que los nodos le digan al enrutamiento que acepte nuevos nodos o no. Esta restricción sobre cuándo la red acepta nuevos nodos también ayudará a prevenir ataques de sybil al no permitir que los atacantes potenciales agreguen nodos ilimitados a voluntad.
Además de esto, también estamos buscando realizar algunos cambios para ayudarnos a conocer el estado exacto del enrutamiento durante el inicio de la red y más allá, tenemos dos RP en curso Indicación para el inicio de la sección y el evento de activación PromotedToAdult y notificar cuando se cambie la clave durante la reubicación. Estos cambios en curso nos ayudarán a garantizar que el enrutamiento se comporte según lo previsto y debería completarse pronto, una vez que los diseños de la API se acuerden entre los nodos y el enrutamiento.
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.