Actualizaci贸n de Safe Network Dev 馃嚜馃嚫 18 de febrero de 2021

Esta es una traducci贸n autom谩tica. El original en ingl茅s est谩 aqu铆: Safe Network Dev Update - February 18, 2021

Resumen

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

  • Se ha agregado un nuevo conjunto de mensajes de infraestructura que sn_routing puede usar para manejar y devolver mejor los errores durante las divisiones de secci贸n y el abandono.
  • El trabajo para manejar SignatureShares inv谩lidos por parte de malos actores en transferencias ha comenzado, y ahora se est谩n elaborando y acordando sanciones para esos malos actores.
  • El trabajo del flujo de mensajer铆a est谩 a punto de completarse, lo que significa mucho menos c贸digo y complejidad para analizar los mensajes entrantes en sn_node, y despejar el camino para la integraci贸n de recompensas.
  • Se han lanzado nuevas versiones de CLI (v0.19.0) y authd (v0.1.1), haci茅ndolas compatibles con la 煤ltima versi贸n de sn_node (v0.26.16), adem谩s de incluir varias otras mejoras.
  • La primera aplicaci贸n de ejemplo ahora est谩 disponible en la caja sn_api, que demuestra c贸mo cargar un archivo en la red y luego buscarlo usando su XOR-URL.
  • Hemos estado dando pasos hacia la integraci贸n de sn_fs y BRB para crear un prototipo de sistema de archivos distribuido P2P tolerante a fallas bizantinas.
  • Las modificaciones de la cadena de la secci贸n sn_routing para resolver las bifurcaciones ya est谩n en su lugar, y nuestras pruebas indican una mejora considerable en la estabilidad de la red, especialmente alrededor de las divisiones.
  • Contribuciones de la comunidad a煤n m谩s fant谩sticas a la base del c贸digo :heartbeat:

Estado de la red de prueba: en espera

Como se discuti贸 la semana pasada, decidimos cambiar todos nuestros esfuerzos para incluir recompensas en la pr贸xima red de prueba. Las recompensas en s铆 han sido bloqueadas por trabajos relacionados para ajustar los flujos de mensajes despu茅s de que hicimos el cambio para hacer solo la acumulaci贸n de mensajes en sn_routing. Creemos que estamos en las etapas finales del trabajo del flujo de mensajes ahora, con lo que creemos que son algunos problemas finales que se est谩n solucionando (m谩s detalles a continuaci贸n). Una vez hecho esto, esto despeja el camino para que proceda la integraci贸n completa de las recompensas.

Al igual que con todos los avances innovadores, esperamos que se encuentren problemas durante las etapas de integraci贸n y prueba, por lo que no queremos establecer una escala de tiempo y ejercer presi贸n adicional sobre el equipo. Como siempre, lo mantendremos actualizado con el progreso preciso en estas actualizaciones semanales.

隆Gracias por su paciencia!

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

Mensajes perezosos

Para manejar mejor los problemas en la divisi贸n de la secci贸n y durante la rotaci贸n, hemos estado agregando un nuevo conjunto de mensajes de infraestructura que sn_routing puede usar para devolver errores como DKGINprocess cuando intentamos enviar mensajes a los ancianos durante esos momentos. Para hacer esto, los clientes / nodos proporcionar谩n la PublicKey actual para una secci贸n, hasta donde ellos saben, y podemos tomar medidas si, por ejemplo, est谩 desactualizada. Estos cambios se han agregado en sn_messaging, sn_client y sn_routing, y estamos buscando algunos peque帽os refactores para simplificar las cosas con los nodos.

En la parte posterior de esto, hemos estado consolidando a煤n m谩s el manejo de los clientes de dichos cambios de infraestructura, por lo que un cambio en la tuber铆a permitir谩 a los clientes reiniciar las veces que sea necesario. Adem谩s de esto, tambi茅n estamos eliminando errores que surgen con la refactorizaci贸n de acumulaci贸n de mensajes realizada durante las semanas anteriores.

Penalizar a los malos actores

Tambi茅n se est谩 trabajando en el manejo de SignatureShares inv谩lidas por parte de malos actores en transferencias. Hasta ahora, hemos estado aprobando una transferencia siempre que las acciones v谩lidas de 鈥渦mbral + 1鈥 se agreguen con 茅xito, ignorando las acciones defectuosas que no son necesarias para esa agregaci贸n. Ahora introduciremos mecanismos de penalizaci贸n en la red para castigar a los nodos en consecuencia despu茅s de la verificaci贸n. Estamos comenzando nuestra refactorizaci贸n desde sn_transfers, ya que ah铆 es donde ocurren las acumulaciones para las transferencias de pago, y luego avanzamos a trav茅s de las capas.

Flujo de mensajes

Al pasar a la acumulaci贸n solo en sn_routing, necesit谩bamos eliminar la informaci贸n 煤nica en los mensajes, para que los Ancianos firmaran el mismo mensaje.
Con esto, el patr贸n de origen y destino tuvo que cambiarse y, mientras tanto, lo hicimos m谩s simple, adelgazando la interfaz de mensajer铆a entre sn_node y sn_routing, y usando las mismas primitivas sobre el l铆mite.

Como ahora se est谩 llevando a cabo el arranque del cliente en la capa sn_routing, estas primitivas de ubicaci贸n tuvieron que extenderse con una variante de cliente. Se implement贸 un registro de clientes conectados en 鈥渟n_routing鈥 junto con proporcionar una clave p煤blica y una firma sobre la direcci贸n del socket en el arranque del cliente. Ahora hay mucho menos c贸digo y complejidad para analizar los mensajes entrantes.mensajes en sn_node. Hasta ahora se han eliminado un total de unas 1000 l铆neas.

API y CLI

Esta semana se lanzaron nuevas versiones de la CLI (v0.19.0) y authd (v0.1.1), que incluyen todas las correcciones, mejoras y nuevas funciones implementadas desde la versi贸n anterior. Como de costumbre, se pueden actualizar con $ safe update y $ safe auth update respectivamente. Estas aplicaciones son compatibles con la 煤ltima versi贸n de sn_node v0.26.16, as铆 que para aquellos que actualicen, aseg煤rese de actualizar tambi茅n su binario sn_node ($ safe node install o $ safe node update).

@scorch ha detectado que la 煤ltima versi贸n de clippy se quejaba en Windows por la CLI y la base de c贸digo authd, y envi贸 una soluci贸n. Esto nos llev贸 a mejorar las comprobaciones recortadas en nuestros scripts de CI para que se ejecuten no solo en Linux sino tambi茅n en Windows, lo que deber铆a evitar que esto vuelva a ocurrir.

Con la adici贸n (por @mav) de una nueva API en nuestro tipo de datos de secuencia CRDT para obtener una entrada que especifique un 铆ndice 煤nico en lugar de un rango, @mav ahora cambi贸 nuestro sn_api para hacer uso de esta nueva API para recuperar una versi贸n espec铆fica de una secuencia.

Tambi茅n se han realizado un par de mejoras en esta nueva CLI (v0.19.0) que permite al usuario configurar informaci贸n de arranque para una red usando una IP (v4 o v6) y un n煤mero de puerto. Para obtener m谩s detalles de este nuevo comando, consulte a la secci贸n correspondiente en la Gu铆a del usuario de CLI.

Para aquellos que tengan curiosidad por ver c贸mo est谩 evolucionando la API de Rust y c贸mo se ver谩 al crear una aplicaci贸n con ella, una primera aplicaci贸n de ejemplo ahora est谩 disponible en la caja sn_api que demuestra c贸mo subir un archivo a la red y luego buscarlo usando su XOR-URL. Esperamos que esto inspire a otros a crear otras aplicaciones de ejemplo simples para nuestra API Rust Safe, descubra oportunidades de mejora a medida que comenzamos a usarlas, y tambi茅n ser谩 un buen recurso para los nuevos desarrolladores que deseen escribir aplicaciones seguras.

CRDT

David Rusu, autor de rust-crdt as铆 como nuestra implementaci贸n de BRB, ha estado revisando el c贸digo de LSeq despu茅s de que @mav informara problemas con cuando se realizan muchas inserciones. Reemplaz贸 la implementaci贸n de ID que se basaba en el documento LSeq original con un n煤mero racional de la caja num. Esto hace que el c贸digo LSeq sea mucho m谩s simple y tambi茅n da como resultado una mejor distribuci贸n (m谩s uniforme), resolviendo el problema y permitiendo la inserci贸n de un n煤mero arbitrario de elementos. LSeq tambi茅n ha sido renombrado a List. Solicitud de extracci贸n.

BRB - Difusi贸n confiable bizantina

驴Recuerda sn_fs, nuestro prototipo de un sistema de archivos que usa el 谩rbol CRDT? Bueno, esta semana hemos estado dando pasos hacia la integraci贸n de sn_fs y BRB a fin de crear un prototipo de sistema de archivos distribuido P2P tolerante a fallas bizantinas.

Primero bifurcamos brb_node_qp2p y creamos brb_node_tree, que demuestra el env铆o de operaciones crdt_tree a trav茅s de brb. Luego modificamos la caja sn_fs y la convertimos en una biblioteca. M谩s recientemente, creamos una caja brb_node_snfs en la que reunimos todo. A partir de hoy, hemos podido abrir dos (o m谩s) nodos y ejecutar operaciones de directorio como mkdir, rmdir. Las operaciones se reflejan en el sistema de archivos montado de cada par. Las operaciones de archivo a煤n no funcionan, pero deber铆an hacerlo pronto.

Cabe destacar que este es un trabajo de prueba de concepto b谩sico. Hay muchos detalles por resolver antes de que se pueda poner en pr谩ctica.

Enrutamiento

Plan del proyecto

Las modificaciones de la cadena de secciones para resolver las bifurcaciones, como se discuti贸 en la actualizaci贸n de la semana pasada, ya est谩n implementadas en su mayor铆a. Actualmente estamos realizando pruebas internas utilizando la herramienta de prueba de esfuerzo para identificar cualquier problema restante. Parece que la estabilidad de la red ha mejorado bastante, especialmente en las divisiones. Sin embargo, todav铆a quedan algunos problemas y estamos ocupados depur谩ndolos, pero en general somos optimistas acerca de este enfoque.

Tambi茅n fusionamos un PR para arreglar una explosi贸n de mensaje, esto sucedi贸 cuando un anciano se desconect贸, pero los ancianos restantes a煤n intentar铆an enviarles el Offline vote, que por supuesto no se entregar铆a y, por lo tanto, desencadenar铆a m谩s votaciones Offline.

Fusionamos otro RP para responder con error a la solicitud de un cliente si hay un DKG en curso. Un DKG (Generaci贸n de clave distribuida) en curso significa que la secci贸n est谩 a punto de pasar a un nuevo grupo de ancianos y, por lo tanto, es posible que las cosas no sean completamente estables o consistentes en este momento, por lo que es mejor informar al cliente para que retroceda e intente again poco tiempo despu茅s.

[ACTUALIZACI脫N 22 de febrero] - Navegador seguro

Algo que originalmente olvidamos agregar a esta actualizaci贸n: man_facepalming:

@bzee ha creado un PR para que sn_nodejs est茅 actualizado con los 煤ltimos cambios de API, que es necesario para que Safe Browser se actualice a volver a ser compatible con el resto del paisaje seguro. Tambi茅n ha estado analizando las limitaciones de la biblioteca actual y 隆viendo oportunidades para mejorar las cosas!.

隆Gracias @bzee! : tada: y disculpas por faltar originalmente tus contribuciones en el OP.

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.