Actualización de Safe Network Dev 🇪🇸 21 de enero de 2021

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

Resumen

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

  • Hemos encontrado y fusionado una solución para un problema de “retraso” que había estado haciendo todo lo posible para permanecer sin resolver.
  • Se ha generado un borrador de RP para el flujo de recompensas y está a punto de completarse.
  • Algunas pruebas de red de clientes rotas, que nos han impedido avanzar con la prueba de la solución para un problema de mensajería de KeySection y DataSection (el problema final que bloquea una red de prueba pública), ahora deberían resolverse y las pruebas ahora se reanudarán.
  • Fusionamos los PR de CI / CD en cada una de nuestras cajas BRB, lo que resultó en una cobertura de prueba automatizada, control de versiones y nuestros primeros lanzamientos de las cajas BRB en crates.io.
  • @JimCollinson proporciona otra actualización cautivadora sobre el progreso de la aplicación Safe Network y UX.

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

Resolución de problemas de retraso

Ha habido mucho buceo profundo en la última semana para intentar encontrar la fuente del retraso significativo que hemos estado experimentando al ejecutar redes de prueba internas. Y aunque no estamos del todo “arreglados”, tenemos una idea mucho mejor aquí, y una solución bastante simple ahora se ha fusionado.

El quid de este problema era que algo bloqueaba el manejo de las solicitudes de los clientes por parte de un nodo. Esto puede estar relacionado con alguna concurrencia de nodos subóptima (que también estamos buscando corregir), pero la raíz parece provenir de conexiones caídas que bloquean la capacidad de respuesta de los nodos, por lo que han estado esperando efectivamente la conexión. ser completamente abandonado por las capas inferiores: esta espera es el retraso que hemos estado viendo.

Parece que un simple ajuste al tiempo de espera inactivo de un nodo (reduciéndolo de 30 a ~ 5 segundos … estamos experimentando para encontrar números óptimos ahora) desbloqueará los nodos lo suficiente como para que podamos volver a hacer que las pruebas de los clientes funcionen correctamente. Entonces, mientras estamos investigando para ver si hay un problema en el grupo de conexiones de qp2p y refactorizando un poco sn_node, podemos avanzar ahora probando todo una vez más.

Flujo de recompensas

Anteriormente hemos mencionado el trabajo en curso sobre el flujo de recompensas. Los Ancianos pagan las recompensas en una sección, utilizando un actor AT2 distribuido (es decir, el “actor de la sección”) y firmas agregadas. Cada vez que hay un cambio en la constelación de Elder, la clave de sección cambia y el actor distribuido pasa a la nueva clave transfiriéndole todas las fichas. Hay una ruta inicial diferente en el flujo de transferencia para el actor de sección (y cualquier actor de múltiples propietarios), en comparación con los actores de propietario único, donde la validación de una transferencia es propuesta por una mayoría, antes de que haya una validación en las réplicas.
La transición desde el nodo de génesis, así como las pruebas para esto, se completaron y confirmaron, ahora estamos trabajando en las transiciones posteriores.

Mientras trabajábamos en lo anterior, encontramos que el estado Elder no era consistente entre las operaciones dependientes en tal transición, y por lo tanto esta semana refinamos la representación y manejo de este estado. Se generó un borrador de RP para el flujo de recompensas, que contiene todo el trabajo mencionado anteriormente, ya que ahora está casi terminado.

Problema de mensajería de KeySection y DataSection

En una actualización de desarrollo anterior, mencionamos que estábamos investigando la eliminación del posible trabajo de agregado de firmas duplicado realizado por sn_node durante el intercambio de mensajes entre KeySection y DataSection. Hay un WIP PR agregado de firma de eliminación creado para este propósito. Este PR pasa las pruebas unitarias sn_node, y hemos estado usando pruebas de red sn_client para llevar a cabo una verificación adicional. Sin embargo, debido a otros trabajos de refactorización en sn_node y sn_client, llevados a cabo en paralelo, las pruebas de red de sn_client se han interrumpido por otras razones, por lo que el trabajo de verificación ha tenido que quedar en espera por un tiempo.

Creemos que este trabajo de eliminación de duplicaciones abordará un problema de mensajería de KeySection y DataSection que observamos durante nuestras ejecuciones internas de testnet a fines del año pasado, algo que deberíamos poder verificar a través de la prueba de red sn_client. Este es actualmente el último bloqueador restante esperado para poder albergar una red de prueba pública, por lo que no hemos podido avanzar con las pruebas internas aquí mientras tanto.

Sin embargo, con la reciente fusión de algunos trabajos de refactorización en both sn_node y sn_client, ahora volvemos a esto como una prioridad, y esperamos poder trabajar con los casos de prueba sin complicaciones.

API y CLI

Después de la introducción de la caja sn_messaging, donde ahora están definidos todos los tipos de mensajes del cliente, estábamos trabajando para hacer los cambios necesarios en sn_api y CLI para que sean todos compatibles nuevamente con los mensajes sn_node y sn_routing. Esto ahora está completo y todos los cambios se han fusionado en las ramas principales de todas estas cajas. También hemos hecho algunos progresos al intentar mover las definiciones de los mensajes sn_routing a la caja sn_messaging, aunque esta es una tarea en curso con una prioridad menor que la mayoría de las otras cosas en las que estamos trabajando.

También hemos fusionado algunas API mejoras hechas por @Scorch en la caja qjsonrpc que hace que los parámetros de ruta sean genéricos. Por eso queremos agradecerle su contribución. : manos_alzadas:

BRB - Difusión confiable bizantina

El martes marcó otro hito cuando fusionamos los PR de CI / CD, lo que resultó en una cobertura de prueba automatizada, control de versiones y nuestros primeros lanzamientos de brb crates on crates.io.

Una mejora importante desde la actualización de la semana pasada que se incluyó en esta versión es la compatibilidad con tipos genéricos de Actor a través de rasgos de óxido. Esto significa que el código ahora es lo suficientemente flexible para admitir la mayoría / cualquier algoritmo o biblioteca de criptografía de clave pública sin más cambios en las bibliotecas centrales. El soporte para ed25519 ya está incluido, pero buscaremos agregar soporte BLS. Incluso se podrían agregar dispositivos de firma de hardware en el futuro.

Las mejoras adicionales incluyen:

  • La CLI brb_node_qp2p tiene algunas correcciones de visualización y un nuevo comando de reintento en caso de que se pierdan paquetes.
  • Inicio sesión. Todas las llamadas a println se han cambiado a las funciones de registro adecuadas.

Trabajo en progreso:

  • Se están mejorando los casos de prueba para devolver resultados y eliminar las llamadas que entrarían en pánico ()
  • Se están agregando comentarios de documentos para que el código sea más útil para otros desarrolladores

¡Finalmente, más buenas noticias! Nuestro especialista en CRDT, y el gran cerebro detrás de las cajas brb, acordó extender su contrato por otros 3 meses para ayudarlo con más funciones e integración. : tada:

Enrutamiento

Plan del proyecto

Esta semana fusionamos otro lote de correcciones para problemas descubiertos con la herramienta de prueba de esfuerzo. Con esto dentro, parece que estamos en un lugar mucho mejor. Todavía tenemos problemas con las bifurcaciones (divergencias en la cadena de secciones) que a veces ocurren durante una rotación muy fuerte. Este problema se solucionará mediante la integración del nuevo algoritmo de membresía, trabajo que ya se encuentra en etapa de planificación.

También fusionamos un par de cambios menores. Primero, nos aseguramos de que los nodos nunca creen conexiones con los clientes; en cambio, cuando un nodo necesita enviar algo a un cliente, reutiliza la conexión que creó el cliente. previamente. Si no existe tal conexión, informa un error. Esto por sí solo no soluciona nada, pero hace que ciertas fallas se manifiesten de una manera más obvia, lo que simplifica la depuración. De manera similar, mejoramos el manejo de errores (PR bajo revisión) para que los errores ahora sean más específicos y contengan más información, nuevamente para simplificar la depuración.

Finalmente, solucionamos un problema de larga data con nuestra canalización de integración continua donde una tarea seguiría fallando constantemente. Aunque no fue crítico, todavía nos impidió ver esa marca de verificación verde satisfactoria: heavy_check_mark: antes de fusionar un PR. Resulta que fuimos un poco demasiado estrictos en la forma en que tratamos las advertencias del compilador. Esta solución también se implementó en varias de nuestras otras cajas.

Aplicación de red segura y UX

Feature Tracker / Pantallas y flujos

Si recuerda la actualización de UX en noviembre, lo llevamos a través de las actualizaciones propuestas al léxico de Safe Network, presentando una nueva metáfora de una cuenta segura para reemplazar, tokens en lugar de Safecoin, y desaprobar el uso del término Vault.

Bueno, estos cambios han comenzado a abrirse camino hacia los diseños de IU candidatos donde pueden comenzar a demostrar su valía en los píxeles de experiencia del usuario, en lugar de solo en papel.

Si salta al archivo Figma para los diseños de aplicaciones de red segura, comenzará a verlos en acción, así como algunas otras mejoras.

Es un archivo grande pero con cientoseds de diferentes pantallas y flujos, por lo que no siempre es fácil asimilar todo lo que está sucediendo. Así que aquí hay algunos aspectos destacados:

Desbloqueo de tu caja fuerte

Aquí vemos la metáfora de una caja fuerte para los datos del usuario que se introduce, bloqueándola y desbloqueándola, con algunas señales visuales que, con suerte, también refuerzan eso.

También notará que el menú de acción se ha promocionado a la barra de aplicaciones superior, a través de una hamburguesa tradicional. Y que ahora también es accesible en el estado bloqueado. Pero más sobre eso más adelante.

Trabajar con tokens

Además de marcar el comienzo del final del período de Safecoin, los cambios en la pantalla de la billetera incluyen una sección de Tokens general, un poco de mejora de la interfaz de usuario y un botón de acción New Transaction más multifunción. Es una forma de iniciar una nueva transacción, omitiendo parte del flujo un poco más largo que teníamos anteriormente, y también otro punto de entrada para comenzar a ganar Tokens.

Ganar fichas

Con la desaprobación del término Vault, aquí podemos ver una exploración de cómo podemos favorecer un verbo como Ganar para iniciar flujos para ofrecer recursos a la red a cambio de tokens de red segura.

Este flujo se puede iniciar desde varios puntos, incluso desde la pestaña Ganancias en la pantalla Token, desde la pantalla de inicio o de aplicaciones, y desde la propia utilidad (así como desde el Menú de acciones o un comando escrito).

Un par de pasos para configurar las cosas, y estamos en marcha.

El menú Acción

Ya ha visto esto en una vista previa, pero aquí está el Menú de acción, llamado así porque puede usarlo para buscar y acceder a todas las funciones de la aplicación, así como para iniciar comandos directamente.

Ahora se puede acceder a la parte superior izquierda de la aplicación, y aquí puede verlo en los estados bloqueado y desbloqueado.

Un pequeño recordatorio de cómo se pueden buscar y ejecutar comandos también. Práctico.

Siéntase libre de profundizar en el archivo Figma para ver todos los detalles sobre esto, con una multitud de flujos individuales explorados y documentados.

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.