Actualización de Safe Network Dev 🇪🇸 4 de febrero de 2021

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

Resumen

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

  • El lanzamiento esperado de la red de prueba de hoy tuvo que ser suspendido ya que no pudimos obtener recompensas a tiempo, y deshabilitar lo que teníamos hasta ahora todavía no era suficiente.
  • Poder ver que se producen divisiones de red en los últimos días, con los últimos desarrollos en, nos ha permitido encontrar y eliminar algunos problemas de múltiples secciones previamente desconocidos.
  • El trabajo de simplificación de la API de caja qp2p para administrar las conexiones y las transmisiones internamente y quitar algo de presión al consumidor de la API, ahora está siendo revisado por pares.
  • Se ha generado y probado un BRB PR para corregir la pérdida aleatoria de paquetes que interfiere con las operaciones de BRB, y se espera que se fusione en breve.
  • Un agradecimiento especial a los miembros de la comunidad @bzee, @mav y @scorch por sus esfuerzos durante la última semana con la fusión de múltiples RP de la comunidad.

Estado de la red de prueba: en espera

Nuestro objetivo al comienzo de la semana era incluir recompensas en una red de prueba pública y abrirla a la comunidad hoy, sin embargo, todavía se requerían varios cambios para que funcionara, y no pudimos terminar eso por hoy.

Debido a eso, eliminamos el flujo de recompensas para ver si podíamos obtener una red lo suficientemente estable, e hicimos algunos progresos con eso, pero hemos tenido obstáculos en el camino que nos han ralentizado.

Nuestro estado actual es que ahora tenemos una última versión de una red de prueba internamente, pero no hemos tenido tiempo real para probarla. Esperamos que sea probable que haya más problemas menores, por lo que me gustaría un tiempo para probarlo internamente antes de hacerlo público con confianza.

Todavía tenemos que discutir y decidir si lanzaremos una red de prueba con recompensas excluidas, o si los problemas con los que nos estamos encontrando significan que sería mejor continuar con la implementación completa de las recompensas, que esperamos que tome unos días más. (más pruebas). La estabilidad de la red de prueba que tenemos ahora, con las recompensas deshabilitadas, debería ayudarnos a decidir, pero de cualquier manera no prevemos poner una red de prueba un viernes, preferiríamos esperar hasta la próxima semana para permitirnos apoyar plenamente eso.

La gran mayoría de nuestro tiempo esta semana se ha centrado en la red de pruebas, pero aquí hay un resumen de parte del trabajo general que hemos estado haciendo …

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, un PR de @bzee que permite la configuración programática de los nodos se ha fusionado para dominar hoy. ¡Buen trabajo! : manos_alzadas:

Hemos creado un nuevo rasgo de “Firma” en “sn_data_types” para abstraer el signo y la verificación de nuestros diversos flujos en nodos / transferencias, y hemos estado probando y solucionando errores algunos flujos centrados en la integración de las nuevas consultas de infraestructura de enrutamiento. Esto ha trasladado las operaciones de arranque al enrutamiento en sí, en contraposición a dentro de los nodos. Anteriormente, estábamos limitados a consultar solo a los ancianos (y a los ancianos de nuestra propia sección) para obtener información de arranque de red. Mover esto a sn_routing significa que podemos consultar cualquier nodo y obtener la información de contacto correcta … esencialmente permitiendo a los clientes operar en una red de múltiples secciones.

Más allá de eso, hemos estado depurando varios problemas con las divisiones de sección ahora que hemos podido ver eso en acción (aunque limitado debido a los problemas antes mencionados), y la aplicación web node-logger de @ mav ha demostrado ser una gran herramienta. para ver rápidamente los flujos entre nodos y reducir la salida del registro de nuestra red de varias secciones a algo un poco más legible por humanos.

También estamos trabajando en el flujo de actualización de datos que se requiere para los Ancianos recién ascendidos en una sección, que deberían actualizarse con todos los datos que mantienen el resto de los Ancianos. Dado que estos datos serían de tamaño relativamente grande, idealmente querríamos transmitir los datos para que el nodo no se bloquee con esa tarea, por lo tanto, también jugaremos un poco con qp2p para habilitar la transmisión de datos directamente a los nodos bajo pedido.

Durante la última semana, hicimos algunas adiciones a la caja qp2p para administrar las conexiones y los flujos internamente para quitar algo de presión al consumidor de API. Este trabajo se completó y actualmente se está revisando en este PR, y la nueva API también se ha integrado con el enrutamiento con todas las pruebas aprobadas. Nos estábamos reteniendo para que se lanzara una iteración de la red de prueba pública antes de fusionarlos, pero con el retraso podemos decidir fusionarnos antesde antemano. Las pruebas han demostrado que este cambio ha simplificado considerablemente las cosas y esto hará que la depuración de cualquier problema de red p2p sea mucho más simple.

API y CLI

La semana pasada se enviaron varios RP comunitarios más, que se fusionaron y ya forman parte de una nueva versión de CLI, recién publicada hoy (v0.18.0).

Gracias a este PR enviado por @mav, la validación de NRS ahora excluye un conjunto más grande de caracteres que nunca tendría un propósito razonable al ser incluido en ningún URL. Tener un límite de longitud total de URL de NRS de 255 bytes, donde cada subnombre no puede tener más de 63 bytes de longitud, ahora se aplica con este otro PR .

Los comandos CLI safe auth ahora dan prioridad al argumento --config sobre el uso de variables de entorno, esto también está ahora en su lugar en la nueva versión gracias a PR # 700, también enviado por @mav.

En el lado de qjsonrpc PR # 698 enviado por @Scorch implementa una aplicación básica de ejemplo cliente / servidor usando la API qjsonrpc. Un cliente qjsonrpc envía un mensaje ping a un servidor qjsonrpc, y el servidor responde con un mensaje ack. Esta aplicación de ejemplo muestra de forma sencilla y ordenada cómo se puede utilizar qjsonrpc para crear cualquier aplicación que utilice JSON-RPC sobre QUIC. Ha habido mucha más actividad y exploración realizada por @Scorch con más ideas sobre qjsonrpc - para aquellos interesados ​​en más detalles y / o en participar en este esfuerzo, eche un vistazo a su propio hilo de desarrollo donde ha estado compartiendo todo it. :aplaudir:

BRB - Difusión confiable bizantina

Generamos un PR en brb_node_qp2p para corregir la pérdida aleatoria de paquetes que estaba interfiriendo con BRB operaciones. Esto hace que el nodo sea estable en caso de que algún miembro de la comunidad técnica desee interactuar “directamente” con BRB en un entorno CLI. Las instrucciones de uso básicas para hacerlo están aquí (Tenga en cuenta que debe compilar el código usted mismo, al menos por ahora).

Las discusiones de diseño para integrar BRB con BLS Distributed Key Generation (DKG) han continuado con varias opciones presentadas. Parece que el acuerdo se está fusionando en torno a una de las opciones. Los detalles sobre estos planes deberían estar disponibles en futuras actualizaciones a medida que comience el trabajo.

Enrutamiento

Plan del proyecto

Hemos dado un primer paso para mover todas las definiciones de mensajes de sn_routing a la caja de sn_messaging, donde no solo residirán las definiciones de mensajes, sino también cualquier lógica relacionada con la serialización de las mismas. La iteración inicial de esto, junto con tener un tipo de mensaje unificado para clientes y nodos que se conectan a una sección, ahora está en su lugar en las últimas versiones de sn_routing y sn_client. Nuestro siguiente paso en este sentido es finalmente mover todas las definiciones de tipos de mensajes a la caja sn_messaging, permitiéndonos desacoplar la lógica actual de sn_routing de lo que se convertiría en la API de la red.

Enlaces útiles


No dudes 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

1 me gusta