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

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

Resumen

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

  • Después de trabajar en algunas correcciones y refactores menores, ahora estamos en condiciones de actualizar todas nuestras cajas de Rust a Tokio v1.
  • Hemos revisado “sn_routing” esta semana para cambiar la forma en que se llega a un acuerdo para que ahora se requiera una supermayoría (más de 2/3) en lugar de una mayoría simple (más de 1/2). Creemos que esto era necesario para que la red fuera resistente a ciertos tipos de ataques.
  • Hemos decidido implementar Lazy Messaging en sn_node, con el trabajo ya en marcha. Esto fue planeado originalmente para post-testnet, pero hemos considerado que vale la pena adelantarlo.
  • @jimcollinson lanzó un AMA en Reddit, y justo aquí en el foro, la semana pasada, ¡todavía hay tiempo para responder sus preguntas!
  • @jimcollinson ha creado el primero de lo que creemos que será una serie de respuestas en video de YouTube a las preguntas más importantes recibidas en la AMA. Puede verlo aquí. :movie_camera:
  • @dimitar ha estado trabajando entre bastidores para ayudar a aumentar el conocimiento de Safe Network en India con una campaña publicitaria de Facebook y Twitter. :heart:
  • 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:

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

La semana pasada, un lanzamiento tan esperado de Quinn finalmente llegó con una actualización importante: Tokio v1. Hasta ahora, el uso de una versión anterior de Tokio en Quinn nos impedía actualizar todas nuestras cajas a Tokio v1 debido a versiones de tiempo de ejecución incompatibles, por lo que estamos en el proceso de actualizar todas nuestras cajas a Tokio v1. Con algunas correcciones y refactores menores, hemos podido hacer que todas las pruebas pasen con la nueva versión de Tokio. Esta actualización también nos ayudó a identificar un problema que dejaba las transmisiones abiertas no descubierto anteriormente y que, en última instancia, detenía las comunicaciones de red una vez que se alcanzaba el límite superior. El equipo de Quinn nos ayudó rápidamente y el problema ahora está solucionado en qp2p. ¡Las comunicaciones de sn_routing están funcionando perfectamente de nuevo! Esperamos que todas nuestras cajas se actualicen en los próximos días.

Esta semana también agregamos más ejemplos a la caja qp2p para demostrar mejor el uso de la API y para las pruebas de estrés de qp2p tanto a nivel local y en Digital Ocean.

En sn_routing esta semana decidimos cambiar la forma en que se llega al acuerdo para que ahora se requiera una supermayoría (más de 2/3) en lugar de una mayoría simple (más de 1/2). Esto era necesario para que la red fuera resistente a ciertos tipos de ataques. También aumentamos el número de ancianos en una sección de 5 a 7, lo que significa que una sección aún puede perder hasta dos ancianos y seguir funcionando. Estos cambios se están revisando y probando actualmente, y esperamos que se fusionen pronto.

Con la necesidad de habilitar la mensajería perezosa (vea la subsección a continuación), hemos estado buscando la mejor manera de lograr esto en sn_node. Es posible que podamos ajustar algunas partes pequeñas de esto, pero también estamos analizando un refactor más grande aquí para simplificar las cosas. Parece que con parte del código sn_node desaparecido (esencialmente eliminando Deberes) y analizando directamente los mensajes, terminaremos con algo en lo que podemos equivocarnos con bastante facilidad, mientras que probablemente también eliminemos mucho de sn_node la complejidad. Los esfuerzos iniciales en esta área han sido bastante positivos. Esperamos que esta no sea una tarea tan grande, ya que la lógica subyacente debería seguir siendo la misma, pero independientemente de que nos acerquemos a esto en paralelo a soluciones más ligeras, es de esperar que no bloqueemos nada.

sn_node Lazy Messaging

La mensajería perezosa en sn_node funcionaría aumentando ligeramente el tamaño de los mensajes enviados entre los nodos para que incluyan información adicional sobre el estado actual de la red según lo visto por diferentes observadores en el espacio y el tiempo. La alternativa a este enfoque sería sondear continuamente los cambios; creemos firmementee que el costo de datos adicionales por mensaje está más que compensado con la reducción en el tráfico general en comparación con el sondeo constante. Con las encuestas, incluso cuando la Red está atravesando un período de silencio, las encuestas deberían continuar furiosamente en un segundo plano. Otros enfoques para detener / pausar partes de la red para llegar a un acuerdo están plagados de muchos efectos secundarios y código complejo, por lo tanto, esos están fuera de la mesa.

Como una descripción general muy breve, con la mensajería perezosa, si un nodo recibe un mensaje y se da cuenta de que los detalles del * estado de la red * en el mensaje entrante difieren de lo que creía que era el estado, entonces se comunica más con el nodo remitente para traerlo a sí mismo, ** o el remitente **, actualizado con el * estado de red * correcto, entonces el mensaje original se puede procesar en consecuencia.

La mensajería perezosa se ha implementado en sn_routing desde hace algún tiempo, demostrando ser eficaz y confiable. En sn_node nos hemos enfrentado a algunos desafíos durante las últimas semanas tratando de actualizar los nodos con los últimos * cambios en el estado de la red * (después del abandono, promoción, degradación, etc.). Por ejemplo, cuando una sección se divide, nos enfrentamos a desafíos para que los nuevos Ancianos de las respectivas nuevas secciones de hermanos se pongan al día con la sección principal Ancianos, sin dejar de ser capaces de hacer frente al tráfico esperado típico y los eventos de red.

Hemos tenido mensajes perezosos marcados como el objetivo final por un tiempo, pero hasta ahora lo consideramos como una optimización posterior a la prueba. Sin embargo, se siente como una lucha cuesta arriba con los desafíos que hemos enfrentado en las últimas semanas, y que estamos colocando una cantidad aparentemente interminable de yeso temporal sobre las grietas que sabemos que se resuelven de manera integral mediante mensajes perezosos. Por lo tanto, hemos decidido no perder más tiempo aquí y pasar a usar este patrón en sn_node para actualizar el * estado de la red * en cada nodo a lo largo del tiempo, como y cuando sea necesario.

Como se mencionó, este es un trabajo adicional que no pensamos que fuera necesario antes de la red de prueba, pero no lo consideramos tan grande que retrase una red de prueba de manera demasiado significativa. Y es otro elemento marcado en nuestra lista de * tareas pendientes * en el camino hacia la versión beta y el lanzamiento.

CRDT

Se ha comenzado a trabajar en un tipo de contador acotado que nos permitirá limitar las operaciones a un tipo de datos. Este es un componente valioso que permite que los datos mutables crezcan continuamente, al tiempo que los agrupa en compartimentos. Esto significa que podemos pagar para cargar el tipo de datos, luego agregarlo libremente hasta un punto delimitado, momento en el cual el usuario pagaría nuevamente y obtendría otro conjunto de espacio de operaciones liberado. Dividir los datos que se pueden crecer de esta manera distribuye la carga a través de la red. Esta es una optimización, pero una importante que se requiere para el lanzamiento, pero no para Fleming. Es bueno ver estos pellizcos y pliegues en la tubería ahora.

También hemos estado realizando cambios en el tipo de datos de Secuencia desde que estamos migrando para usar el nuevo CRDT MerkleReg, que nos permitirá mantener todo el historial de anexos, además de permitir bifurcaciones de datos si el usuario final o la aplicación las genera. ya sea a propósito o no. Esto está afectando cómo se presentará nuestra API al usuario final, ya que, según el caso de uso, podría haber bifurcaciones / ramas de anexos que el usuario puede querer no solo atravesar, sino también resolver. Por lo tanto, también estamos trabajando en ajustar nuestra API en el lado del cliente para presentar todas las capacidades al usuario, sin hacerlo más complicado y sin quitar la flexibilidad y la potencia que este nuevo tipo de datos CRDT aporta para aplicaciones y desarrolladores.

Comunidad y marketing

@jimcollinson lanzó un AMA en Reddit, y justo aquí en el foro, la semana pasada.

El objetivo original era reunir un par de preguntas interesantes y responderlas en una sesión de preguntas y respuestas en YouTube. Ha habido una respuesta espléndida, y las respuestas a muchas preguntas resultan ser mucho más detalladas de lo que podría manejar una sola sesión de preguntas y respuestas. Así que aquí está la primera respuesta en video de lo que probablemente se convertirá en una serie:

Por favor haga me gusta, comparta, disperse, distribuya, difunda, discuta y disfrute de la forma que considere conveniente. Y no dude en seguir recibiendo preguntas.

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.