Actualizaci贸n de Safe Network Dev 馃嚜馃嚫 11 de febrero de 2021

Esta es una traducci贸n autom谩tica. El original en ingl茅s est谩 aqu铆: Safe Network Dev Update - February 11, 2021

Resumen

  • La versi贸n de testnet todav铆a est谩 en espera mientras trabajamos para completar la refactorizaci贸n del flujo de mensajes, que est谩 bloqueando el progreso de las recompensas.
  • El trabajo de refactorizaci贸n del flujo de mensajes avanza a buen ritmo, con un borrador de PR en su lugar. Esto resultar谩 en un flujo de mensajes m谩s limpio, simple y eficiente.
  • Hemos migrado nuestros scripts de implementaci贸n / eliminaci贸n de testnet para usar terraform, lo que result贸 en una mejora dr谩stica en el tiempo necesario para crear redes de prueba de cualquier tama帽o para pruebas internas / externas despliegue.
  • Pasar alg煤n tiempo trabajando con una configuraci贸n 鈥渟in recompensas鈥 nos ha permitido detectar y eliminar algunos errores que de otro modo habr铆an permanecido ocultos hasta que las recompensas se implementaran por completo.
  • Se est谩 implementando un nuevo subcomando $ safe networks set en la CLI que permitir谩 a los usuarios conectarse m谩s f谩cilmente a las redes simplemente usando su IP: direcci贸n de puerto de arranque, con el PR correspondiente en proceso de revisi贸n ahora.
  • Creemos que hemos encontrado una soluci贸n para la bifurcaci贸n de la cadena de secci贸n en sn_routing. Esta soluci贸n se est谩 implementando actualmente y creemos que ayudar谩 a que las redes de prueba sean lo suficientemente estables para hacer frente al sondeo de la comunidad.
  • 隆Las contribuciones del c贸digo de la comunidad siguen llegando! :heartbeat:

Estado de la red de prueba: en espera

Una vez m谩s, ten铆amos como objetivo incluir recompensas en una red de prueba p煤blica esta semana, pero algunos trabajos relacionados para ajustar los flujos de mensajes despu茅s de que hicimos el cambio para hacer solo la acumulaci贸n de mensajes en sn_routing, que afecta a todas las partes de sn_node, ha cambiado result贸 ser m谩s lento de lo que anticipamos. Este trabajo actualmente bloquea el progreso de las recompensas.

A principios de la semana, decidimos concentrar un poco de energ铆a en la alternativa de tener una red de prueba sin recompensas, es decir, eliminar parte del flujo de recompensas, algo en lo que comenzamos la semana pasada. Hicimos un buen progreso aqu铆, pero encontramos varios problemas de bloqueo en el camino, que tuvimos que aplicar varios 鈥渢rucos鈥 para resolver temporalmente hasta que las recompensas y la funcionalidad relacionada est茅n en su lugar. Las redes resultantes 鈥渟in recompensas鈥 que hemos estado desarrollando han carecido de estabilidad, confiabilidad y consistencia, por lo que, tal como est谩n las cosas, no creemos que tenga valor poner una red de prueba sin recompensas. Este enfoque alternativo tuvo algunos beneficios esta semana, ya que nos permiti贸 avanzar un poco con las pruebas de m煤ltiples secciones, lo que nos llev贸 a identificar y solucionar algunos problemas que de otro modo no habr铆amos visto hasta que las recompensas y la funcionalidad relacionada estuvieran implementadas.

Todav铆a esperamos albergar una red de prueba lo antes posible, con el enfoque cambiando hacia atr谩s para avanzar con recompensas nuevamente y lanzar una red de prueba confiable con eso en su lugar. Potencialmente, haremos un poco m谩s de pruebas utilizando el trabajo 鈥渟in recompensas鈥 para ver si podemos descubrir algo m谩s acechando en el futuro.

Preparaci贸n y prueba de Testnet

Hacia el final de la semana pasada, est谩bamos intentando publicar redes de prueba grandes, y r谩pidamente se hizo evidente que nuestro script bash para esto no estaba a la altura del trabajo: tardaba 30 minutos en iniciar 20 nodos aproximadamente y mucho m谩s. para lanzar 100 nodos! Como tal, hemos estado migrando a terraform para administrar la implementaci贸n / destrucci贸n de gotas y nodos, y eso es muuuch mejor. Ahora podemos lanzar 40 nodos impares en unos minutos. Hemos estado usando esto bastante para iterar y lo hemos configurado ahora para permitirnos implementar compilaciones de nodos personalizados tambi茅n. Lo que ha resultado muy 煤til en el frente de la iteraci贸n. El PR para este cambio a terraform est谩 en su lugar y se prob贸 bastante a fondo ahora, con un trabajo ordenado antes de la fusi贸n.

En un momento de la semana, vimos con bastante regularidad redes de prueba internas que quer铆an dividirse, pero no lo hac铆an. Comenzamos a intentar depurar con secciones m谩s peque帽as (por ejemplo, 3 mayores, un tama帽o de secci贸n de 5 nodos) para activar m谩s divisiones, pero esto no ayud贸. Result贸 que no est谩bamos viendo divisiones ya que nuestro c贸digo depend铆a de las secciones de los ancianos movi茅ndose, pero esto no es realmente necesario (como est谩n las cosas). Al igual que con todas las cosas de probabilidad, incluso esos eventos improbables parec铆an suceder con una frecuencia razonable 鈥 y as铆 fue como todos nuestros mayores estaban cayendo en la mitad de la secci贸n, formando as铆 una nueva secci贸n para ellos mismos, sin necesidad de cambio de clave , y ninguno de nuestro c贸digo se ve afectado.

Con m谩s correcciones de errores all铆, adem谩s de eliminar algunas funciones de recompensas que se est谩n reelaborando, hemos solucionado un problema que estaba ocurriendo al inicio de la red por el cual en cada rotaci贸n en la secci贸n de g茅nesis, el Anciano reci茅n ascendido volver铆a a proponer una g茅nesis pago una vez m谩s, haciendo que el resto de los Ancianos espere unOtro pago de g茅nesis que se supon铆a que suceder铆a solo una vez inicialmente. Con eso clavado, tambi茅n hemos solucionado otro error relacionado en el que la acumulaci贸n de la prueba de pago de G茅nesis no estaba ocurriendo (est谩bamos almacenando todos los eventos de pago excepto los de validaci贸n); lo que ayud贸 a que las cosas se movieran.

Despu茅s de eso, tambi茅n nos encontramos con algunos bucles en sn_routing, que se observ贸 que causaba un alto uso de memoria, lo que podr铆a causar la muerte de los nodos. Sabemos d贸nde est谩 el problema y hemos implementado una medida temporal para evitar que suceda por ahora. A su debido tiempo, llegar谩 una soluci贸n m谩s permanente.

Con todo lo anterior implementado con la rama 鈥渟in recompensas鈥, finalmente llegamos a la etapa en la que pudimos ver que la mayor铆a de las pruebas de los clientes pasaban, y las fallas resaltaron algunos otros problemas, como el acceso ocasional a alg煤n c贸digo que no deber铆amos. poder alcanzar (se requiere cierto manejo de errores para eso), y ahora tambi茅n estamos reduciendo un problema con las billeteras de los clientes. Hacer que el conjunto de pruebas del cliente sea un poco m谩s ecol贸gico en preparaci贸n para cuando el flujo de recompensas est茅 completamente integrado nuevamente.

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

QP2P

Durante la 煤ltima semana, probamos la nueva API qp2p con todas nuestras cajas. Inicialmente hubo algunos problemas, pero todos est谩n resueltos ahora y estamos en la fase final de revisi贸n y fusi贸n en todos los 谩mbitos. Incluiremos estos cambios durante las pruebas de un extremo a otro y ser谩n parte del pr贸ximo lanzamiento de testnet.

Mensajes

Recientemente pasamos a acumular mensajes solo en sn_routing, ya que anteriormente tambi茅n lo hab铆amos hecho en sn_node. Para finalizar esta refactorizaci贸n, se ha tocado mucho c贸digo, pero tambi茅n se han eliminado unas 1350 l铆neas.
El resultado es un flujo de mensajes m谩s simple, limpio y eficiente.

El trabajo para hacer esto est谩 actualmente en curso, con un borrador de PR que rastrea el progreso. Esto nos ayudar谩 a avanzar con los flujos de mensajes en general, pero lo que es m谩s importante ahora tambi茅n las recompensas, que se han frenado un poco por estas actualizaciones.

API y CLI

Una deuda t茅cnica que ten铆amos en nuestra caja sn_api era hacer que nuestro tipo / s de Error implemente el rasgo std :: error :: Error. Esto es algo que completamos y fusionamos la semana pasada con la ayuda de thiserror caja. Tambi茅n hemos cambiado la base de c贸digo CLI para hacer uso de de todos modos por lo que todas las funciones ahora devuelven de todos modos :: Resultado y el manejo de errores se hace mucho m谩s f谩cil sin perder informaci贸n o contexto sobre la causa ra铆z de cada uno de los errores propagados.

Se est谩 implementando un nuevo subcomando 鈥$ safe networks set鈥 en la CLI que permitir谩 a los usuarios conectarse m谩s f谩cilmente a las redes simplemente usando su direcci贸n de puerto IP: bootstrapping. El RP correspondiente incluye una actualizaci贸n de la Gu铆a del usuario, por lo que para cualquier persona interesada en proporcionar algunos comentarios sobre este comando, siga adelante y eche un vistazo a la descripci贸n aqu铆.

Las contribuciones de la comunidad siguieron llegando la semana pasada. Hay un esfuerzo de trabajo en progreso por @bzee para hacer que el paquete nodejs sea compatible con la 煤ltima versi贸n de sn_api, as铆 como una soluci贸n en la CLI para eliminar un nombre de bandera que estaba causando un conflicto entre dos comandos diferentes (https://github.com/maidsafe/sn_api/pull/708). Tambi茅n se gener贸 un PR y se fusion贸 para eliminar la implementaci贸n de registro de sn_client, ya que esto deber铆a dejarse en manos de las aplicaciones o binarios que usan la biblioteca, haciendo Aseg煤rese de que las aplicaciones no obtengan resultados inesperados en stdout o stderr.

Dado que la mayor铆a de las dependencias de nuestras cajas usan tiny-keccak v2.0.2, @mav ha estado enviando PR para actualizar todas nuestras cajas para que dependan de esta misma versi贸n. Todos apreciamos mucho el esfuerzo de todos los que se involucran de cualquier manera que puedan: aplaudir:

BRB - Difusi贸n confiable bizantina

Hicimos un trabajo adicional en brb_node_qp2p para que funcione con flujos bidireccionales y la nueva (pr贸ximamente) API qp2p. Esto permite que cada nodo env铆e y reciba desde el mismo puerto, en lugar de abrir nuevas conexiones a trav茅s de un puerto aleatorio separado para paquetes salientes. En el proceso, contribuimos con un par de peque帽os RP a qp2p. Uno en particular hace que sea m谩s f谩cil compartir un punto final qp2p entre subprocesos, lo que deber铆a ser una ventaja para cualquiera que cree una aplicaci贸n p2p con la biblioteca.

sn_data_types

Tenemos un dise帽o para simplificar la Pol铆tica / PermisoSiendo la l贸gica que rige el acceso a los datos de la red, esto se encuentra actualmente en revisi贸n interna. Tambi茅n tenemos un PoC para un nuevo Chain CRDT que podr铆a resultar un mejor CRDT subyacente para nuestro tipo de datos de secuencia, esto vino fuera del problema planteado por @mav con respecto a nuestro tipo de datos de secuencia.

Enrutamiento

Plan del proyecto

Esta semana est谩bamos explorando un enfoque prometedor para la resoluci贸n de bifurcaciones. Para recapitular: tenemos algo llamado 鈥渃adena de secci贸n鈥 que es una lista de claves de secci贸n vinculadas con firmas. Puede usarse para demostrar que un dato fue firmado por un grupo de nodos que alguna vez fueron miembros v谩lidos de una secci贸n, incluso despu茅s de que esos nodos hayan desaparecido hace mucho tiempo. Actualmente, esta cadena requiere que la secci贸n acuerde qu茅 clave agregarle a continuaci贸n. Si hay un desacuerdo al respecto, la cadena puede bifurcarse en dos (o m谩s) cadenas mutuamente incompatibles que podr铆an romper la secci贸n actualmente. Esto puede suceder, por ejemplo, en momentos de intensa rotaci贸n. Esper谩bamos poder escapar sin abordar esto por un poco m谩s de tiempo, es decir, hasta que la red de prueba estuviera fuera, pero resulta que a veces vemos bifurcaciones incluso en redes de prueba relativamente peque帽as.

As铆 que est谩bamos ocupados discutiendo cu谩l era la mejor manera de abordar este problema y se nos ocurrieron un par de ideas prometedoras. Actualmente se est谩 implementando una de esas ideas y esperamos que ayude a que las redes de prueba sean lo suficientemente estables como para hacer frente al sondeo de la comunidad. A煤n existen algunas preocupaciones potenciales sobre la seguridad y los posibles vectores de ataque, pero se abordar谩n m谩s adelante. Ahora mismo, el foco es la estabilidad. Peque帽os pasos.

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.