Actualización de Safe Network Dev 🇪🇸 3 de diciembre de 2020

Esta es una traducción automática. El original en inglés está aquí: Safe Network Dev Update - December 3, 2020

Resumen

Estas son algunas de las cosas principales a destacar desde la última actualización de desarrollo:

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

Esta semana fue un hito para sn_node con la primera versión y publicación de esa caja con su nuevo nombre, y el primero desde julio. Ha habido muchos cambios allí en los meses desde entonces, como el registro de cambios así que destaca claramente, y como hemos estado tratando de mantenerlo informado en estas actualizaciones. Estas versiones no significan que el desarrollo haya finalizado en sn_node, solo que lo consideramos lo suficientemente estable como para fusionar el Continuous Delivery pipeline PR creado anteriormente . El desarrollo continúa al ritmo, y ahora cada RP fusionado dará como resultado una nueva versión generada automáticamente.

Fusionamos el trabajo con manejo de errores mejorado en sn_node, que despeja el camino para la progresión. Después de eliminar el almacenamiento en caché de las secuencias la semana pasada, esta semana expusimos al cliente a algunas condiciones de red más normales, lo que resultó en varias pruebas fallidas. Con algunos ajustes en las pruebas del cliente para dar cuenta de esto, ahora son estables nuevamente. Además de esto, hemos estado mirando el inicio de la sección, que localmente ha estado funcionando bien, pero CI ha estado teniendo dificultades con. Hemos establecido que algo de esto se debe a que las máquinas de CI son lentas, y el aumento de los tiempos de espera entre los nodos que comienzan allí nos ha brindado resultados más confiables. Todavía hay algunos errores por solucionar aquí.

Hemos avanzado un poco más con algunas de las pruebas fallidas durante las pruebas de extremo a extremo de la red, específicamente con respecto al almacenamiento de datos utilizando el tipo de datos Blob. Identificamos algunos problemas que se filtraron durante algunos de los refactores, y con los arreglados ahora vemos que las pruebas pasan de manera consistente. Ahora vamos a volver a habilitar el sistema de replicación de fragmentos cuando los nodos abandonan la red. Una vez hecho esto, todos los flujos de Blob se volverán a habilitar en la implementación refactorizada de sn_node.

Otra característica en la que hemos estado trabajando esta semana es la regulación del almacenamiento en una sección, y finalmente en la red, a través de PR # 1153. A partir de ese PR, los nodos de almacenamiento de datos monitorean su almacenamiento en cada escritura que realizan, advirtiendo a sus mayores de sección si alcanzan su capacidad máxima. Luego, los ancianos mantienen un registro de estos nodos llenos y cuando alcanzan un umbral de nodos llenos en la misma sección, votarían para aceptar nuevos nodos para unirse a su sección, cerrando las puertas una vez que se satisfaga la oferta / demanda, manteniendo así un equilibrio en la red. Estaremos iterando con varios ajustes a las métricas en los próximos días.

Se ha planteado un PR para Rust-CRDT para que LSeq esté en línea con otros tipos de CRDT que necesitan “aplicar” para ser llamado modificando el tipo de datos en sí. Estamos usando esto en nuestro tipo de datos “Secuencia” para asegurarnos de que todas las operaciones estén firmadas.

Los cambios en sn_api y CLI continuaron la semana pasada, adaptándose a las nuevas API de sn_client y, como se mencionó la semana pasada, también tratando de migrar a nuevas terminologías de UX. Tenemos la mayoría de las pruebas sn_api aprobadas ahora usando una sección local, y ahora estamos tratando de finalizar estos cambios y resolver las pruebas fallidas, lo que con suerte debería significar que los comandos CLI y las pruebas E2E estarán en funcionamiento nuevamente.

Y finalmente, para permitir una mayor cobertura de prueba de transferencias, pagos,d recompensa módulos, esta semana se ha iniciado una reestructuración de ese código y cambios en la granularidad de acceso.

BRB - Difusión confiable bizantina

Continúa el trabajo en el enfoque Generation Clock para la membresía dinámica. Se espera un código prototipo funcional para el final de la semana.

En una pista paralela, la caja de bft-crdts se divide en cajas separadas en un esfuerzo de modularización. La idea es definir 3 rasgos: uno para la implementación de BRB, uno para los tipos de datos que se transmitirán y protegerán, y otro para la capa de red.

De esta manera, las implementaciones de los tres rasgos se pueden mezclar y combinar. Por ejemplo, podemos usar un uso de red en memoria para casos de prueba, un impl qp2p para enrutamiento en Safe Network, y un tercero podría usar una implementación de sockets TCP / IP para otra cosa. Por el lado de los datos, ya tenemos una implementación de banco AT2 y una implementación de CRDT orswot.

Enrutamiento

Plan del proyecto

Como se mencionó anteriormente, sn_node fue publicado y lanzado por primera vez en su forma actual esta semana. Para no quedarse atrás, el equipo de enrutamiento también ha publicado y publicado sn_routing, ¡el primer lanzamiento en casi 2.5 años! Consulte el registro de cambios para ver una muestra de los cambios realizados. Al igual que con sn_node, estas versiones no significan que el desarrollo haya terminado en sn_routing, solo que lo consideramos lo suficientemente estable como para fusionar el Continuous Delivery pipeline PR creado anteriormente . El desarrollo continúa al ritmo, y ahora cada RP fusionado dará como resultado una nueva versión generada automáticamente.

Esta semana implementamos una medida para defendernos de los ataques de venta de claves. Un ataque de venta de claves es cuando un nodo que ha construido su reputación vende su clave secreta a una entidad potencialmente malintencionada que luego puede asumir su rol y causar daño. Este tipo de ataque es muy difícil de prevenir por completo, pero al menos dificultamos el acceso de la gente a la clave secreta asegurándonos de que la clave no esté expuesta o almacenada en el disco.

También trabajamos para presentar el proceso de realizar pruebas de recursos durante el arranque, que se ha fusionado hoy. Esto desafía a los posibles nuevos nodos de unión para garantizar que estén lo suficientemente calificados para compartir la carga de trabajo de la red. Con la verificación de verificación de recursos en su lugar, todos los nodos recién unidos se considerarán como “adultos” inmediatamente; el manejo de los nodos “infantiles” ya no es necesario.

También hemos estado trabajando actualización de la sección de refactorización que tiene como objetivo simplificar la base de código de manejo de DKG. Los dos principales cambios propuestos para lograrlo son:

  1. Las fallas de DKG ya no se informarán a los mayores de la sección actual, sino que se reiniciará.
  2. Se eliminará el acumulador de resultados de DKG separado, en lugar de utilizar el acumulador de votos normal.

Sin embargo, después de las discusiones durante el proceso de revisión, se detectaron más problemas que hemos decidido resolver. Por lo tanto, el RP se ha cambiado a estado Borrador y se espera que esté listo para su revisión nuevamente, con las adiciones, pronto.

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.