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

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

Resumen

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

  • ¡El chat seguro de la comunidad de puertas abiertas del viernes pasado fue un gran éxito! Muchas gracias a todos los involucrados, particularmente a @sotros25 y @m3data por sus excelentes presentaciones. :clap:
  • @jimcollinson está ejecutando un AMA en Reddit - ¡involúcrate!
  • Profundizar y depurar redes de múltiples secciones ha sido el tema principal de esta semana, con varias nuevas capturas de manejo de errores introducidas a medida que eliminamos los problemas que pueden causar fallas en las redes.
  • Se acaban de lanzar nuevas versiones de sn_api (v0.20.0), sn_authd (v0.2.0) y CLI (v0.20.0), haciéndolo compatible con el último sn_node.
  • Ahora hemos completado el desarrollo en el MerkleReg mencionado la semana pasada, por lo que se ha comenzado a trabajar para integrarlo en sn_data_types.
  • Esta semana vio los primeros archivos transmitidos de un nodo SNFS a otro a través de BRB. :tada:
  • En el enrutamiento, finalmente fusionamos la resolución de la bifurcación PR.
  • También en el enrutamiento, fusionamos tres PR separados (# 2349, # 2351 y # 2336) implementando correcciones para varios problemas que surgieron durante las pruebas de estrés. Ahora se considera que el enrutamiento está listo para una red de prueba estable.

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

Mas y mas cerca…

Continuamos probando y depurando redes de múltiples secciones esta última semana. Estamos más cerca que nunca, tentadoramente, pero todavía no estamos allí (¡también es frustrante para nosotros!). Es un lugar interesante para depurar, hay muchos registros y mensajes, y vienen en todo tipo de órdenes, así que realmente estamos probando los bordes aquí.

Más correcciones

Se han lijado algunas asperezas menores. Ahora estamos manejando algunas situaciones de error que pueden surgir de transferencias de sección dividida, o de hecho cualquier transferencia, que ingresa y arroja errores porque ya no es válido como ya lo hemos visto y aplicado. Ahora también estamos manejando algunos errores de sn_transfers que pueden ocurrir cuando no hay historial; esto puede surgir de nuevos ancianos que aún no tienen historial. Anteriormente, esto estaba causando un error y rompiendo el flujo.

Abordar el problema raíz

Pero el problema más importante en el progreso de las divisiones de sección en el nivel sn_node, es conseguir que los nuevos Ancianos de las respectivas secciones de hermanos estén al día con los Ancianos de la sección principal y que manejen las solicitudes como si ya fueran Ancianos. Sin eso, la transición básicamente quedaría en un punto muerto. Ahora, mientras no tengan todo lo que se necesita para ser un Anciano, algunas de esas solicitudes devolverán un error, pero eso básicamente está bien.

Estamos avanzando con dos tareas aquí en paralelo; uno en el que estamos haciendo algunos ajustes rápidos que permiten que lo descrito anteriormente nos ponga en marcha para la red de prueba, y otro en el que hacemos algunos ajustes también en el nivel de sn_routing, para coordinar mejor las transiciones. Con eso también estamos progresando en la ambición de que todos los ingenieros participen de un extremo a otro de alguna manera, lo que creemos que es necesario para un sistema de este tipo que funcione bien.

Navegador seguro

También esta semana, en el Navegador seguro pasamos un poquito de tiempo desempolvando el repositorio (¡ha pasado un tiempo!) Actualizando las dependencias para que no tengamos un montón de problemas de seguridad cuando estemos listos para ir allí. (@bzee parece haber estado progresando bien con su conversión napi de sn_nodejs, ¡lo cual es genial de ver!). Esta no es una noticia emocionante, pero es una cosa menos que abordar cuando estamos satisfechos con la estabilidad de la red de prueba.

API y CLI

Se acaba de lanzar una nueva versión de sn_api (v0.20.0), sn_authd (v0.2.0) y CLI (v0.20.0) con algunas mejoras en la forma en que los archivos y los contenedores NRS se almacenan en la red. como con los nuevos subcomandos bin-version para auth & node para consultar su versión binaria. Como de costumbre, puede usar la CLI para actualizar ($ safe update y $ safe auth update), o instalar la última CLI como se detalla en la Guía del usuario. Estas nuevas versiones son compatibles con la última versión de sn_node v0.28.1.

Como se mencionó la semana pasada, hemos estado migrando nuestro tipo de datos de Secuencia para contener ahora una Política inmutable que elimina todas las complejidades que trae a nuestro enfoque CRDT. Con thaEn este momento, la semana pasada pudimos adaptar todas nuestras API y tipos de mensajes en todos los ámbitos para eliminar la capacidad de modificar las políticas.

Debido a la refactorización y otros cambios en los meses anteriores en la forma en que el cliente envía los mensajes a la red, tuvimos que deshabilitar temporalmente nuestras pruebas E2E sn_api en CI, ya que deben adaptarse a la nueva naturaleza más asincrónica de la mensajería. . Ahora hemos comenzado a adaptarlos lentamente para que vuelvan a nuestro sistema de IC.

CRDT: tipos de datos replicados sin conflictos

Ahora hemos completado el desarrollo en MerkleReg mencionado la semana pasada: rust-crdt # 111, por lo que se ha comenzado a trabajar para integrarlo en sn_data_types. Como recordatorio, MerkleReg será el nuevo CRDT de respaldo para el tipo de secuencia. Admite un historial de ramificación que se puede recorrer (similar al historial de una ramificación de git).

También esta semana, se descubrió que GList / List CRDT tenían un problema al insertar entre índices que usaban el mismo identificador, por lo que esto se ha resuelto rápidamente en rust-crdt # 112.

BRB - Difusión confiable bizantina

La integración del Sistema de archivos de red segura (SNFS) con BRB ha resultado muy fructífera en el descubrimiento de algunas características que faltan en BRB:

  1. No se notificó al cliente cuando se aplicó una operación. Los clientes necesitan esta información para reenviar paquetes potencialmente descartados. Esto se ha resuelto con los paquetes “Delivered”: brb # 27.
  2. Cuando BRB ejecutaba una operación en un cliente, confiaba en la pila de red para enviarse paquetes a sí misma. Esto causaría condiciones de carrera para clientes altamente concurrentes cuando las operaciones se ejecutan en rápida sucesión. Ahora hacemos un cortocircuito con estos paquetes y los manejamos antes de regresar al cliente: brb # 29.
  3. Para hacer frente a los paquetes caídos, hemos agregado una API para reenviar paquetes para los cuales aún no habíamos recibido una respuesta para: brb # 29.

SNFS - Sistema de archivos de red seguro

¡Buenas noticias! Esta semana se transmitieron los primeros archivos de un nodo SNFS a otro a través de BRB. :tada:

Inicialmente realizamos la transmisión BRB sincrónicamente con la operación FUSE, pero resultó demasiado lenta. Se realizó una mejora para poner en cola las operaciones y regresar inmediatamente a FUSE. Luego, un subproceso separado envía perezosamente las operaciones a los pares en el orden de origen y garantiza que se apliquen cada una. Este es un paso necesario hacia un sistema de archivos que se puede usar sin conexión y luego sincronizar con sus pares cuando se restaura la conectividad. Con este cambio en su lugar, el sistema de archivos se siente en términos de velocidad como usar un sistema de archivos de sistema operativo normal como ext4 en Linux con un SSD. Quizás no tan rápido todavía, pero en el mismo orden de magnitud.

En las pruebas de ayer, descubrimos que dos subprocesos están usando más CPU de lo que deberían después de que se hayan producido y completado comunicaciones intensas, y ahora el proceso está inactivo. Ambos hilos están ocupados ejecutando código de Quinn (red) por razones desconocidas. Esta semana se lanzó una nueva versión de Quinn que puede solucionarlo, así que lo probaremos lo antes posible.

Enrutamiento

Plan del proyecto

Esta semana finalmente fusionamos la resolución de la bifurcación PR. El quid del PR es una nueva implementación de la estructura de datos SectionChain que ahora es un CRDT adecuado. Esto significa que garantiza la (eventual) consistencia independientemente del orden en que se apliquen las operaciones, cómo se agrupen o incluso se dupliquen. Incluso si se insertan varias claves distintas en él, todos eventualmente estarán de acuerdo en cuál es la más reciente y, por lo tanto, quiénes son los ancianos actuales (porque cada clave de sección está asociada de forma única con un solo grupo de ancianos). Y todo esto se logra sin involucrar ningún mecanismo de consenso complicado. Esto es precisamente lo que queríamos cuando eliminamos Parsec y ahora finalmente está aquí.

Esto fue seguido por tres RP separados (# 2349, # 2351 y # 2336) implementando correcciones para varios problemas que surgieron durante las pruebas de estrés. Éstos son algunos de los más notables:

  • Evite el bucle infinito de solicitud-respuesta durante el arranque ignorando las respuestas de redireccionamiento duplicadas, lo que provocó pérdidas masivas de memoria.
  • Se corrigió el rechazo accidental de respuestas de arranque válidas en la reubicación: provocó que un nodo reubicado en una sección diferente se atascara.
  • Se corrigió la invalidación accidental de la firma de mensajes Sync reenviados y devueltos: los nodos a veces no se actualizaban correctamente sobre el estado de su sección.
  • Notifique a los ancianos reubicados sobre su expulsión de su sección original; no hacerlo hizo que nuncaprogresar en su reubicación.
  • Asegúrese de que la información de la sección de hermanos sea confiable después de la división; de no hacerlo, los nodos olvidaron quiénes eran los nodos de su sección de hermanos justo después de la división y, por lo tanto, no pudieron contactarlos. Esto provocó además que algunos nodos se atascaran durante el arranque.
  • Permitir múltiples resultados DKG pendientes: no hacerlo a veces hacía que los nodos olvidaran sus claves secretas compartidas y, por lo tanto, no pudieran firmar mensajes de sección.
  • Utilice una clave única para las sesiones de DKG que tengan los mismos participantes; no hacerlo a veces provocó que el resultado de DKG se corrompiera y, por lo tanto, los nodos no pudieron firmar los mensajes de la sección.

Después de estas correcciones, las redes internas que estamos ejecutando parecen mucho más estables. Con esto, ahora consideramos que el enrutamiento está listo para una red de prueba.

Comunidad y marketing

Chat seguro

La primera de nuestras charlas seguras comunitarias de puertas abiertas fue el viernes, ¡y qué delicia! Si bien la agenda se centró en el tema del marketing comunitario de la Red, con algunas excelentes presentaciones de @sotros25 y @m3data, las discusiones fueron más amplias que eso, como se puede imaginar.

No solo fue genial ver algunas caras (¡aunque las cámaras eran opcionales!), ¡Parece que se perfila como un entorno importante para la colaboración y tramar grandes planes!

Si aún no lo ha hecho, puede ponerse al día con la conversación aquí:

Sin duda, publicaremos más de estos, así que permanezca atento y le informaremos cuándo debe mantener sus diarios en claro.

Soy un diseñador de UX que ayuda a construir la nueva Internet: ¡Pregúntame cualquier cosa!

@jimcollinson está ejecutando un AMA en Reddit y, bueno, todos los canales sociales realmente.

Responderá tantas preguntas como pueda y guardará algunas de las más frecuentes y jugosas para una sesión de preguntas y respuestas de YouTube para que sean accesibles, fáciles de compartir y, con suerte, se quedarán un poco más.

¡Por favor únase!

Experiencia de usuario de la aplicación Safe Network

A medida que mejoramos el proceso de incorporación para las personas que crean una caja fuerte en la red por primera vez, le dimos un adelanto de hace unos meses, hemos estado trabajando en el uso de un poco más de este enfoque más conversacional para principiantes en más áreas de la aplicación. No extensamente, pero podría ayudar a empujar a las personas en la dirección correcta desde los ‘estados sin contenido’.

Uno de esos lugares es la utilidad de creación de invitaciones, donde los usuarios existentes pueden ayudar a conseguir un amigo en la red segura.

Trabajar para simplificar este flujo también nos ha llevado a analizar el proceso de invitación en general y darle forma.

Si recuerda, previamente habíamos planeado permitir que los clientes recarguen automáticamente o carguen invitaciones para contabilizar la inflación / deflación de los tokens. Esto tenía algunos inconvenientes, uno era que solo funcionaría inicialmente cuando el cliente estaba abierto, y el otro era que también agregaba cierta complejidad a los flujos en circunstancias en las que la recarga automática estaba habilitada, pero la billetera se había quedado sin fondos para apoyarlo.

En resumen, lo que se pretendía hacer la vida más simple podría funcionar bien en el camino feliz, pero sería un poco engorroso fuera de él.

Al mismo tiempo, también aplazamos otra función de invitación útil hasta después de MVE: la capacidad de agregar fondos adicionales a una invitación cuando se la regala a un amigo.

¡Pero ya no! Podemos hacer que la compensación por inflación sea más comprensible y sólida, pero un poco más manual, si seguimos adelante y construimos recargas manuales.

Así que es un poco dos por uno. Obtendrá una gestión de invitaciones más comprensible y podrá agregar tantas fichas como desee a una.

Ayuda a un amigo a ingresar a la Red y devuélvele el almuerzo, todo de una vez.

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.