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

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

Resumen

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

  • ¡La convocatoria para miembros del comité de voluntarios para el Fondo BambooGarden ya ha cerrado! Contamos con 8 miembros del comité respetados y experimentados de la comunidad.
  • Con el comité del Fondo BambooGarden ahora confirmado, pasaremos a establecer canales de comunicación y poder invitar a las primeras solicitudes de fondos.
  • Hemos realizado varios cambios relativamente pequeños en la base de código del cliente durante la última semana, lo que ha dado como resultado que ahora veamos que la mayoría de las pruebas del cliente pasan consistentemente en una red de varias secciones.
  • Con el cliente estabilizándose, pudimos volver a habilitar los pagos de recompensas y ahora estamos trabajando en problemas y optimizaciones.
  • La implementación de la mensajería diferida continúa en todos los ámbitos.
  • Más preguntas llegan a la AMA, y otra respuesta también vea el último video de @jimcollinson aquí
  • Publicamos un resumen de funciones para la próxima red de pruebas a principios de semana.
  • Esté atento al hilo Me gusta este Tweet en el foro para obtener una excelente orientación sobre cómo ayudar a promover la Red segura, y componentes circundantes, con un simple clic de botón! :bird:

Actualización del Fondo BambooGarden

Un gran agradecimiento a cada uno de los voluntarios del comité del Fondo BambooGarden. Hemos tenido 8 voluntarios que ofrecieron su tiempo y, por lo tanto, creemos que este es un buen momento para cerrar el comité, por ahora, y mantenerlo en un número manejable.

Inicialmente teníamos la intención de tener 3 miembros del comité comunitario a la vez, pero decidimos cambiar esto para tener a los 8 voluntarios en el comité. Este cambio tiene varios beneficios, como permitirnos aprovechar al máximo la variada experiencia y conocimientos que ofrecen. También es inevitable que habrá ocasiones en las que algunos miembros del comité tengan otros compromisos, por lo que este número mayor significa que podemos continuar sin problemas independientemente. Los miembros podrán abstenerse cuando no puedan asistir, o incluso si creen que no están calificados para juzgar una solicitud, sin tener que preocuparse de que se quedarán cortos en el comité.

El personal de MaidSafe seguirá formando alrededor de 3 miembros del comité. También hemos agregado una condición de que MaidSafe tendrá derecho a un “veto” sobre cualquier solicitud de financiación, es decir, el derecho a rechazar propuestas que consideremos que no cumplen con los objetivos, fundamentos y valores de MaidSafe, o que no lo hacen. • Cumplir con el propósito y los objetivos originales para los que se creó este fondo, y de los cuales se le ha pedido a MaidSafe que actúe como garante. Tenga en cuenta que un veto es solo para rechazar solicitudes, no para forzarlas cuando el comité más amplio las ha rechazado.

Todo esto se ha comunicado a los voluntarios del comité durante los últimos días, junto con algunas otras decisiones importantes. Por ejemplo, el comité será todos miembros de un foro de discurso separado, donde podremos discutir y votar las solicitudes. MaidSafe también ha propuesto algunas áreas inmediatas que hemos identificado como urgentes en la toma de medidas para cumplir con el propósito número uno de este fondo, que es “mejorar el ritmo de despliegue de la Red Segura”. Estas áreas son:

  • Documentación formal: creemos que el proyecto se beneficiaría enormemente de tener nuestros algoritmos documentados formalmente. Quizás un escritor técnico o similar que tenga experiencia en la redacción de algoritmos formales y artículos pueda ofrecer valor aquí. Tener estos documentos formales en su lugar ayuda a los desarrolladores a bordo que se están involucrando, al mismo tiempo que ayuda a los auditores externos a quienes en algún momento les pediríamos que verifiquen nuestro código en busca de fallas de seguridad, errores, etc.
  • Experiencia adicional en CRDT para ayudar a llevar esto al siguiente nivel.
  • Experiencia de consenso adicional.
  • Experiencia adicional en redes.

Si tiene ideas para solicitudes de fondos en estas áreas, no las envíe todavía, pero puede comenzar a pensarlas un poco más en preparación para la apertura del proceso de solicitud.

También proponemos que, una vez que la red de prueba esté activa, solicitemos aplicaciones para aumentar en general el tamaño de nuestro equipo de ingeniería para que podamos avanzar a un ritmo más rápido. La razón por la que decimos después de testnet aquí es que la incorporación de nuevos ingenieros de antemano sería una distracción del trabajo de testnet.

Durante los próximos días, se invitará a todos los voluntarios del comité a unirse a un foro de debate separado en el que formalizaremos juntos algunas de las pautas del comité. Luego, anunciaremos que estamos listos para aceptar nuestras primeras solicitudes de financiamiento, con todos los detalles de las áreas iniciales específicas, tales como las outlimencionado anteriormente, queremos que el primer lote de aplicaciones esté restringido. También proporcionaremos detalles completos sobre cómo enviar solicitudes y en qué esperamos que consistan.

Cliente seguro, nodos, enrutamiento y qp2p

Plan del proyecto Safe Network Transfers
Plan de proyecto de cliente seguro
Plan de proyecto de nodo de red segura
Plan de proyecto de enrutamiento seguro

Mejoras en el código del cliente

Después de que los cambios de división de billetera de la nueva sección se fusionaron en los repositorios al comienzo de la semana, hemos estado realizando varias mejoras en el código del cliente. Ha habido algunos pequeños refactores para simplificar las cosas, así como actualizaciones para permitir una mayor flexibilidad con los números mayores (ya que aumentan con los cambios de supermayoría), pero también para usar este mismo cálculo de supermayoría para el manejo de respuestas (es decir, obtenemos el misma respuesta a una consulta de X Elders y, por lo tanto, puede confiar en él). También hemos agregado algunas correcciones para problemas que impedían que el cliente se iniciara en la sección correcta en una red de varias secciones. Con esto en su lugar, pudimos ver que la mayoría de las pruebas de los clientes pasaban consistentemente en una red de múltiples secciones.

Recompensas

Después de las fusiones mencionadas anteriormente, volvimos a habilitar los pagos de recompensas y hemos estado inspeccionando el comportamiento durante varias divisiones. Se encontraron y solucionaron un par de pequeños problemas, y todavía se está trabajando en un par de otros donde hay un consumo excesivo de CPU y memoria después de algunas divisiones.

Aunque los pagos de recompensas funcionan ahora, parece que podríamos simplificarlos aún más, por lo que intentaremos eliminar una gran parte de la lógica que maneja el pago en la reubicación del nodo y, en su lugar, incluir los pagos de recompensas en la sección billetera. separar.

Mensajes perezosos

Junto a esto, hemos actualizado las implementaciones de mensajería perezosa en las bibliotecas y hemos adaptado sn_node al código de mensajería actualizado. Actualizar sn_routing para estos cambios ha sido una gran tarea, ya que cada mensaje de enrutamiento ahora requerirá un encabezado propio que proporcione los detalles del destino, que el receptor verificará para verificar su exactitud y se usará para actualizar al remitente o receptor con el actual. Estado de la red, si están rezagados. Las implementaciones principales están en su lugar y estamos actualizando las últimas pruebas allí. Una vez que tengamos esto, seremos libres de crear el patrón de mensajería perezosa en sn_node para permitir un fácil manejo de la velocidad de los nodos.

Vecinos de enrutamiento

En el enrutamiento eliminamos el concepto de vecinos. Para recordar, los nodos necesitan mantener información sobre otras secciones de la red para saber (entre otras cosas) cómo enviarles mensajes, etc. Solíamos mantener solo aquellas secciones que eran “vecinas” de nuestra sección. Esto se definió arbitrariamente como aquellas secciones cuyo prefijo difiere de nuestro prefijo en exactamente un bit. Esto significaba que si queríamos enviar un mensaje a una sección que no era nuestra vecina, teníamos que transmitirlo a través de nuestros vecinos. Hace mucho tiempo que nos dimos cuenta de que se trataba de una complejidad innecesaria y decidimos eliminarla y esta semana finalmente lo hemos conseguido. Entonces, ahora los nodos mantienen información sobre todas las secciones de la red, lo que significa que no hay necesidad de transmitir nada, ya que siempre conocen a los destinatarios finales. Esto simplifica el diseño y mejora el rendimiento. Uno podría preocuparse si esto requiere una gran cantidad de memoria, pero resulta que no es así. Calculamos que podemos admitir varios cientos de miles de secciones antes de que la memoria se convierta en un problema. Nos ocuparemos de ese problema cuando lleguemos. Como parte de este cambio, también refactorizamos la lógica de mensajería perezosa y la extrajimos en un módulo separado, lo que nos permitió agregarle más pruebas unitarias, aumentando la confianza en el código.

API y CLI

Después de finalizar los cambios requeridos para el nuevo tipo de datos CRDT Register en las cajas sn_node y sn_client, comenzamos a adaptar el código base sn_api y su API para admitirlo.

El aspecto principal de estos cambios está relacionado con el hecho de que ahora estaríamos exponiendo al usuario de la API la posibilidad de encontrar ramificaciones en los datos. Estas ramas podrían haber sido causadas involuntariamente por la aplicación cuando varias instancias están escribiendo valores al mismo tiempo en el mismo “Registro”, pero podrían ser creadas intencionalmente por la aplicación, por ejemplo, una aplicación de cadena de bloques donde las bifurcaciones simplemente ocurren y también se resuelven.

También comenzamos adaptando todas nuestras abstracciones (NRS, FilesContainers y Wallets) para hacer uso de este tipo de datos. Aquí es donde vemos un desafío mayor en términos de UX, dado que leer un FilesContainer podría resultar en ver más de un estado como se explicó anteriormente. Por lo tanto, ahora estamos buscando la mejor manera de exponer esto en nuestra API para que el usuario y / o desarrollador de una aplicaciónpuede decidir qué hacer en esas situaciones. Por ejemplo, se le puede pedir al usuario final que decida no solo qué rama leer, sino también quizás cómo fusionarlos en una sola rama nuevamente. Como ya puede ver, puede haber varias formas en que el usuario o desarrollador desearía resolver la aparición de ramas en los datos, y este es el principal impulsor ahora para el nuevo diseño de estas API.

Cuando se trata de la CLI segura, tendremos que tomar algunas decisiones sobre qué opciones ofrecer al usuario final para resolver las ramas de datos. Un ejemplo aquí es cuando se obtiene un contenedor de archivos con dos estados no resueltos, la CLI probablemente puede presentar información detallada sobre ellos y permitir que el usuario decida cuál buscar.

CRDT

Continuamos investigando sobre el trabajo del Contador limitado y esta semana hemos estado trabajando para que sean tolerantes a fallas bizantinas y para implementar una PoC. Con suerte, en la próxima semana tendremos algo concreto que compartir en este frente.

También hemos desarrollado el diseño de un nuevo MultiMap CRDT basado en MerkleReg. Esta será probablemente la base para los tipos de datos del subdominio NRS, así como una estructura flexible para otras aplicaciones que necesitan un mapa como el tipo de datos.

Comunidad y marketing

Más preguntas llegan a la AMA y otra respuesta también. Esta vez @jimcollinson aborda uno de @dimitar: _ ¿Es demasiado tarde para la privacidad en línea? ¿No tienen ya toda nuestra información? _

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.