Actualización de Safe Network Dev 🇪🇸 26 de noviembre de 2020

Esta es una traducción automática. El original en inglés está aquí: Safe Network Dev Update - November 26, 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

Después de agregar la semana pasada la firma de operaciones CRDT de secuencia, esta semana hemos estado integrando esto en la pila, con algunos cambios en sn_node aquí y sn_client aquí y aquí para que se firmen todas las operaciones antes de pasarlas a la red. Esto destacó algunos otros problemas con respecto al almacenamiento en caché local de secuencias (cuándo usar local frente a red, etc.). Hemos optado por eliminar este caché por ahora a través de este PR por simplicidad. Esto ha ayudado a apuntalar el conjunto de pruebas, lo que nos permite ver con mayor claridad algunos flujos de tipo CRDT en acción, por ejemplo, los cambios de empuje no se retiran * inmediatamente * de la red, por lo que tenemos que esperar los cambios esperados allí.

Con los cambios anteriores en, también hemos estado depurando algunos problemas de inicio de nuevas secciones que surgieron a raíz de estos, con algunos pequeños ajustes de cliente agregados aquí para evitar fallas si un anciano no está disponible (pero muchos otros todavía lo están). Con esto en, ahora podemos ver un subconjunto de pruebas sn_client pasando contra una sección de once miembros en CI.

El resto de las fallas que estamos viendo se deben principalmente a algunos errores ocultos al elegir los destinos y la recuperación de fragmentos en la replicación de fragmentos de datos de blobs que habilitamos la semana pasada. Tenga la seguridad de que estamos bien encaminados con las correcciones para ellos y estamos marcando la última de las pruebas fallidas del conjunto de pruebas del cliente e2e. La búsqueda de estos errores también destacó que aún faltaban algunos elementos de la mensajería y que ahora eran necesarios para acercar el flujo de control / manejo de errores un paso más a lo que llamamos “mensajería perezosa”. Se está trabajando para solucionar este problema.

Lazy Messaging es donde recibimos un mensaje que no podemos manejar por cualquier motivo (desincronizado, número de secuencia futuro, etc.) y devolvemos ese mensaje al remitente con nuestro último historial conocido. El remitente entonces sabe que debe proporcionarnos el enlace que falta (también podemos hacer lo inverso (aunque no hay error) y actualizar el remitente si son ellos los que están detrás). Esto nos evita retener mensajes hasta que se ordenen, lo que podría explotarse para atacar la red, y sería un código más complejo. La mensajería perezosa está mucho más cerca de un modelo de actor de transmisión de mensajes, y lo hemos extendido para manejar eventos parcialmente ordenados.

Con un cambio en la nueva dinámica de unión de nodos en Enrutamiento, consulte PR # 2234, también comenzamos a actualizar sn_node para que los nodos asuman la responsabilidad de permitiendo que nuevos nodos se unan a la red. Efectivamente, los mayores de la red ahora realizarán un seguimiento de la oferta / demanda de recursos en su sección y, en consecuencia, solicitarán el enrutamiento para permitir que los nuevos nodos, que están en cola, se unan a su sección.

También comenzamos a adaptar authd y CLI a la nueva terminología UI / UX, por ejemplo, pasando de" Cuentas “a” Safes “, así como también haciendo los cambios necesarios para que authd almacene las aplicaciones. 'pares de claves en la red utilizando un Mapa como el tipo de datos de almacenamiento para el” Seguro ". Continuaremos con esta tarea para alinear todos los comandos CLI y las funciones de autenticación con estas nuevas terminologías, así como con la nueva API sn_client.

Una vez que haya terminado con las actualizaciones anteriores, las correcciones y los errores que arrojen, estaremos listos para encender nuestras redes de prueba internas una vez más a toda velocidad, ordenar los diversos módulos, verificar su estabilidad, atar cabos sueltos ¡y espero entregarles un regalo de Navidad anticipado! :guiño:

BRB - Bizantino Reemisión responsable

Esta semana, nuestro consultor ha avanzado la idea de Generation Clock mencionada la semana pasada y presentó un algoritmo de pseudocódigo al equipo para que comente. Este enfoque híbrido impone un orden total sobre operaciones de unión y abandono poco frecuentes, pero solo un orden parcial sobre operaciones de datos mucho más frecuentes. En lenguaje sencillo, esto significa que join / leave debe estar acotado (es decir, no podemos permitir que existan nodos que no respondan) y usar una forma de orden total, pero podemos manejar muchas hojas a la vez, etc., mientras que pueden ocurrir operaciones de datos regulares. con altos niveles de concurrencia, siempre que cada uno sea de una fuente diferente (Actor en el lenguaje CRDT). Hasta ahora la propuesta parece sólida y el siguiente paso es implementarla en código y escribir algunas pruebas. Más sobre eso la próxima semana.

Enrutamiento

Plan del proyecto

Como se discutió en semanas anteriores, el trabajo para mejorar la detección de pares perdidos se aprobó y fusionó esta semana. Esto aprovecha la función de agrupación de conexiones en qp2p. Este cambio significa que la base del código de enrutamiento se ha simplificado y ahora permite agregar pruebas de integración más complejas para verificar las características del código de producción.

Algunas funciones de la API funcionan: Indicación para el inicio de la sección y el captador de edad y
notificar cuando se cambió la llave durante la reubicación - también se completó esta semana. Con estos en su lugar, los nodos ahora estarán más informados sobre el estado del enrutamiento durante el inicio y el par de claves actualizado que se está utilizando.

Durante las pruebas, observamos un problema en el que durante el arranque, cuando el mensaje NodeApproval fue seguido inmediatamente por otro mensaje, diga Relocate, el bootstrap se completó * después * de que se procesó el NodeApproval. Esto dejaba cualquier mensaje siguiente, como Relocate, en el búfer del canal intermedio para que nunca fuera sacado y procesado, es decir, estábamos perdiendo ese mensaje. Hemos fusionado un PR de reparación Corregir la pérdida de mensajes durante el arranque para resolver este problema. Elimina el canal intermedio, reemplazándolo con una envoltura simple alrededor del receptor ConnectionEvent. Por lo tanto, el modelo “empujar / tirar” se cambia a un modelo simple de “tirar”. De esta forma, un mensaje nunca se recupera del canal si no está listo para procesarlo.

El trabajo para permitir que los nodos le digan al enrutamiento que acepte nuevos nodos o no mencionado en la actualización de la semana pasada también se completó y fusionó esta semana. El enrutamiento asume que los nodos mayores rastrearán todos los nodos adultos en la sección y cuando detecten que la capacidad de almacenamiento promedio (o algún otro recurso) sea demasiado baja, cambiarán la bandera para que la sección comience a aceptar nuevos nodos. Todos los nodos mayores deberían detectar esto más o menos al mismo tiempo, para que se pueda llegar a un consenso. Además de dar la vuelta a la bandera, si la sección ya tiene infantes, uno de ellos será promovido con su edad aumentada en uno, lo que efectivamente hará que se reubique y vuelva a unirse inmediatamente como adulto.

Aplicación de red segura y UX

Feature Tracker / Screens & Flows / Onboarding Prototype

Gracias por todos sus comentarios sobre los cambios propuestos al léxico seguro. Hemos comenzado a filtrar estos cambios a través de los flujos de UX y los prototipos de la aplicación Safe Network, y debería verlos aparecer en los distintos archivos de Figma a medida que trabajamos en todo.

Si bien no está directamente relacionado con los cambios de idioma, un pequeño proyecto paralelo interesante que surgió del trabajo fue una revisión de algunos de los flujos de incorporación, por ejemplo, cuando un usuario está listo para crear su propia caja fuerte.

Si recuerda, la versión existente establecía todas las opciones que tenía un usuario para crear una caja fuerte (o cuenta como estaba en ese momento), y les dejaba seleccionar la ruta adecuada, con instrucciones paso a paso.

Se veía así:


Pero, ¿podríamos hacerlo más suave? ¿Podríamos quizás hacerlo menos abrumador y ayudar a un usuario a poner en funcionamiento rápidamente su caja fuerte sin ayuda externa, y luego hacer que siga ganando tokens de red segura para arrancar?

A continuación, se muestra un pequeño prototipo del nuevo enfoque en el que se puede hacer clic (solo camino feliz), solo para darle una idea.

Esta no será la única ruta para obtener una caja fuerte, habrá otros flujos alternativos con un poco menos de agarre de la mano, pero por primera vez, será interesante ver cómo se compara con el enfoque existente.

También es un patrón que podría aplicarse a otras áreas de la aplicación, como ganar tokens la primera vez, crear un SafeID o elegir credenciales sólidas.

Es un poco más de trabajo para nosotros desde un punto de vista de diseño y lógica de flujo, pero si es más fluido y menos intimidante para el usuario, y tiene más cajas fuertes y nodos en la red, valdrá la pena.

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.