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

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

Resumen

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

  • ¡Feliz año nuevo! :fireworks:
  • Nos complace anunciar que el trabajo de Membresía dinámica se ha completado y hoy hemos publicado varias cajas de Transmisión confiable bizantina (BRB) en GitHub :tada:. Todos están vinculados desde la caja de brb central.
  • Hemos estado trabajando duro, incluso durante las vacaciones, para mejorar nuestra capa de errores y comunicaciones, incluida la creación de una nueva caja de sn_messaging.
  • Estamos en el proceso de preparar algunas correcciones menores para una nueva versión de parche de la CLI
  • También estamos cerca de tener CLI y authd construidos con musl, lo que significa compatibilidad con una gama más amplia de plataformas.
  • Tenemos una nueva herramienta de prueba de estrés para enrutamiento con el RP actualmente en revisión. Esta nueva herramienta está diseñada para descubrir los límites del enrutamiento en términos de cómo maneja los cambios de membresía (abandono) y ya nos ha llamado la atención sobre algunos problemas.

Actualización de Testnet

Gracias a todos los que se han tomado el tiempo de probar el código testnet lanzado antes de Navidad. Con todo el equipo de MaidSafe ahora de regreso en sus escritorios, continuamos trabajando en algunos problemas que identificamos antes del lanzamiento y otros que usted destacó para nosotros. Una vez que estemos satisfechos de que estos problemas se hayan resuelto, anunciaremos otra iteración, con la intención de albergar una red de prueba pública para que todos los que puedan conectarse.

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

Hemos estado trabajando para mejorar nuestra historia de errores en todas nuestras bibliotecas y hemos pasado al uso de thiserror en todos los nodos / tipos de datos / cliente / transferencias para proporcionar una mejor cadena de errores y una mayor encapsulación de funcionalidad. Anteriormente, usábamos muchos errores mixtos, extrayendo muchos de sn_data_types a otras bibliotecas. Ahora tenemos errores específicos en cada lib, para esa lib, y solo propagamos errores de libs inferiores como otra versión de los errores de lib actual.

Además de esto, hemos extraído sn_messaging de sn_data_types en su propia caja para separar nuestra capa de comunicaciones, así como los errores que Enviará desde / hacia otros nodos y clientes. Este es un pequeño paso hacia la definición más clara de una ‘API’ de red de mensajes y errores y proporciona una separación más limpia de los errores de las bibliotecas internas al cliente.

Como parte de este esfuerzo, estamos explorando diferentes tipos de serialización, con el objetivo final de tener uno que sea independiente del lenguaje de programación. En este momento nos estamos enfocando en una serialización JSON simple (a diferencia del bincode que se usa actualmente), pero también estamos jugando con Msgpack.

El efecto de golpe de todo esto ha sido un código más limpio y flujos de error mucho más claros en todas las librerías involucradas, lo cual es genial.

En conjunto, hemos eliminado los “desafíos” del cliente del flujo de arranque del nodo / cliente. Estos se usaban anteriormente para verificar que un cliente tenía claves, a fin de evitar ataques de reproducción de mensajes. Pero con idempotency proveniente de los tipos de datos AT2 y CRDT, esto se manejará allí. Aún más simplificación tanto para el cliente como para el nodo, y aclara aún más las operaciones de red como mensajes firmados únicamente.

Anteriormente, para evitar ataques de venta de claves en la red, eliminamos todas las API expuestas de SecretKey de sn_routing y las incluimos solo en su caja. Sin embargo, descubrimos que había múltiples complicaciones en el árbol de dependencia causadas por esta eliminación, por lo que acordamos recuperar esas API para permitirnos avanzar rápidamente con la red de prueba durante las vacaciones. Hemos decidido abordar este problema de frente de inmediato y hemos comenzado a refactorizar las cajas sn_transfers y sn_node, donde guardamos y usamos esas SecretKeys fuera de sn_routing.

El trabajo de firma agregada llevado a cabo por sn_node durante el intercambio de mensajes entre KeySection y DataSection posiblemente esté duplicado con el trabajo de acumulación de consenso de enrutamiento, ya que ambos están siendo realizados por nodos mayores. Estamos investigando y llevando a cabo un trabajo de refactorización tratando de eliminar esta parte de la caja sn_node y confiar en los mensajes de consenso de sn_routing.

Y se está llevando a cabo un último trabajo para eliminar la administración de “flujos” de los nodos. Esto fue puesto enlugar para mantener comunicaciones con los clientes, pero con los cambios recientes de qp2p podemos confiar en la agrupación de conexiones allí para manejar esto por nosotros, y así eliminar mucha complejidad del manejo de clientes del nodo. También estamos en el proceso de refactorizar los ejemplos de qp2p en partes separadas para demostrar el echo_service y los sistemas de mensajería de manera clara y distintiva. Estamos realizando pruebas con estos ejemplos con reenvío de puertos manual para admitir potencialmente enrutadores no compatibles con IGD en otras redes de prueba.

API y CLI

Nos hemos centrado en cambios y mejoras en el lado de la red, sin embargo, todavía hemos estado trabajando para solucionar algunos errores menores que han sido reportados por la comunidad al usar testnet y, por lo tanto, están preparando algunas correcciones menores para una nueva versión de parche de la CLI.

Además, estamos intentando que nuestra próxima versión de CLI y authd se compile con musl, que como sabemos nos permitirá ejecutar estas aplicaciones. en muchas más plataformas utilizando los mismos artefactos publicados. Ya pudimos construirlos manualmente (muchas gracias a @mav y @tfa por sus aportes y contribuciones a esto), por lo que ahora estamos buscando incluir esto en nuestro IC en los próximos días.

BRB - Difusión confiable bizantina

Nos complace anunciar que el trabajo de Membresía dinámica se ha completado y hoy hemos publicado varias cajas de Difusión confiable bizantina (BRB) en GitHub: tada :. Todos están vinculados desde el brb crate central.

El sistema BRB consta de:
1. El protocolo de transmisión BRB central para que los miembros de un quórum repliquen datos en forma BFT.
2. El protocolo de membresía dinámica para que los nodos se unan dinámicamente y dejen un quórum activo.
3. Contenedores de tipos de datos que encapsulan tipos de datos compatibles (por ejemplo, CRDT) para su transferencia a través de BRB.
4. Pruebas completas para verificar la corrección.
5. brb_node_qp2p: una aplicación / nodo CLI de ejemplo para invocar manualmente la funcionalidad BRB.

Para aquellos interesados ​​en profundizar en los detalles, diapositivas están disponibles y brindan más información sobre el sistema y los protocolos.

Enrutamiento

Plan del proyecto

Como todos sabemos, la reubicación es buena para la red, facilitando el envejecimiento de los nodos, entre otras cosas. Sin embargo, observamos que en algunas situaciones estábamos reubicando demasiado. Por ejemplo, estábamos reubicando incluso cuando no teníamos suficientes ancianos debido a la rotación, y también reubicando nodos cuando se habían unido recientemente. Para resolverlo, configuramos algunos criterios para evitar la reubicación excesiva con el objetivo de mantener la red estable durante ciertos escenarios.

También se realizó un cambio de API en información de la sección de devolución para el nombre de destino especificado. Esto es principalmente para el uso de sn_node para el próximo trabajo de refactorización.

Realizamos una prueba de esfuerzo para el enrutamiento (PR bajo revisión). Es una pequeña herramienta diseñada para descubrir los límites del enrutamiento en términos de cómo maneja los cambios de membresía (abandono). Genera abandono aleatorio de acuerdo con un programa configurable. Luego, genera periódicamente información útil sobre la red y mide el estado de la red. Esta herramienta será muy útil para el próximo trabajo de integración de la nueva solución de membresía dinámica. Al ejecutarlo en la versión actual de enrutamiento, ya descubrió algunos problemas que tenemos en torno a las reubicaciones y divisiones, que analizaremos pronto. Esto es realmente bueno, porque el primer paso para solucionar un problema es conocer el problema: sonrisa: Aquí hay una pequeña captura de pantalla del resultado de la herramienta:

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.