Actualización de Safe Network Dev 🇪🇸 9 de febrero de 2023

Esta es una traducción automática. El original en inglés está aquí: Update 9 February, 2023

En la parte posterior de la interesante red de prueba de la semana pasada, que no funcionó durante tanto tiempo como otras pero, sin embargo, se mantuvo activa y produjo algunos hallazgos útiles, hemos decidido hacer una pequeña explicación sobre la unión de nodos. Esto es algo que estamos tratando de hacer más confiable y fácil de probar para la gente. Entonces, si nota algunos sucesos extraños en sus registros, será por eso.

Un gran agradecimiento a @josh por su aplicación Gooey, una GUI amigable para ayudar a superar FCL (miedo a la línea de comandos). Usando Gooey puedes PONER y OBTENER archivos a tu gusto, sin sentir que estás ingresando a Matrix. Iniciativas como esta, la aplicación de monitoreo Vdash de @happybeing y los scripts de @southside son lo que hace de esta una comunidad tan excelente. :aplaude aplaude aplaude:

Progreso general

Primero algunas buenas noticias sobre los aspectos legales: Safe Network Foundation se ha registrado debidamente en el Registro Comercial de Ginebra. @JimCollinson y @andrew.james han estado trabajando en esto durante muchos meses y representa un hito importante superado. También hemos enviado una carta de no acción a FINMA. Esto establece la opinión legal de que SNT es un token de utilidad para la compra de almacenamiento y no un valor, lo que significa que podemos continuar con el lanzamiento. :tada:

Todavía estamos profundizando en la idea del conjunto estable: usar los ancianos y los nodos adultos más antiguos como almacenamiento de datos principal, mientras que los nodos que son pasando por el proceso de edad del nodo se les asignan tareas secundarias de almacenamiento menos importantes para realizar. @davidrusu está realizando experimentos al respecto, mientras que @anselme ha estado trabajando en posibles implicaciones de seguridad.

La idea del conjunto estable trae algunos cambios interesantes:

  • Sin DKG (ya que los nodos más antiguos son instantáneamente mayores). Esto elimina una carga de red significativa en el cambio de personas mayores.
  • No se reubican nodos en el conjunto estable, por lo que este es un conjunto solo para agregar
  • Los nodos en el conjunto estable no tienen marcador de edad, su edad es su ubicación relativa en el conjunto (según lo visto por primera vez)
  • Los nuevos ancianos firman a los ancianos antiguos en el SAP (Proveedor de autoridad de sección), esto nos permite recuperarnos de los nodos de consenso perdidos (manejo de abandono masivo)
  • Es probable que podamos manejar las particiones con bastante facilidad con estos cambios, aunque todavía no tenemos ningún mecanismo para permitir que las redes particionadas se vuelvan a conectar.

@oetyng está profundamente metido en las comunicaciones entre clientes y nodos, limpiando tipos y patrones redundantes e intentando arreglar las cosas.

@anselme continúa refactorizando los DBC. Ayer reemplazó bls_bulletproofs con las pruebas de balas upstream en sn_dbc. ¡Esto no solo hace que el código sea más seguro ya que usamos código auditado, sino que también mejora significativamente el rendimiento!

2096 ms → 234 ms: Benchmarking reedición división 1 a 100
160 s → 40 s: ejecutando todas las pruebas

En el frente del nodo, @joshuef notó que cuando un nodo se vuelve a unir, se le da un nombre diferente, lo que requiere algo de lógica adicional. Eso se solucionó y los nodos ahora se vuelven a unir con el mismo nombre.

@Chriso logró obtener instancias EC2 que participan en una red de prueba configurada para servicios de recopilación de telemetría y preparación de datos, que se necesitan para la distribución de carga y otras tareas. También tiene una red de prueba en funcionamiento en AWS que envía seguimientos a OpenSearch. Debería ser un PR entrante.

@Roland ha estado escribiendo una explicación sobre la telemetría, por qué es necesaria y cómo la estamos usando, que deberíamos poder compartir pronto.

@qi_ma está depurando uniones de nodos y reubicaciones, y @bochacho está eliminando mensajes y qp2p.

Y @bzee ha estado eliminando el código redundante del proceso de unión de nodos.

Unión de nodos

Lo que nos lleva claramente a los nodos desde casa. La última red de prueba fue la primera vez en mucho tiempo que permitimos que los nodos se unieran desde casa (o una VM en la nube), y también la primera prueba ‘oficial’ con nodos más pequeños (después de que una comnet viera éxitos allí). En general, nos complació que muchas personas lograron unirse, aunque los PUT se bloquearon con bastante rapidez. Hemos identificado lo que estaba pasando aquí, con las reubicaciones de nodos más escasas de lo que esperábamos, nuestra red inicial no estaba lo suficientemente “envejecida” para proporcionar una fase de inicio estable.

Idealmente, queremos que todos puedan unirse desde cualquier lugar y en cualquier dispositivo, cuando la red necesite más almacenamiento. Ha habido algunos problemas con los tiempos de espera, cuando un nodo solicita unirse y luego pierde la conexión con el antiguo, que ya hemos solucionado en su mayoría (los nodos recibirán una respuesta que dice que la votación está en curso, en lugar de no responder; los nodos ahora también solo siga intentando con el mismo nombre en lugar de cambiar de nombre, lo que ha confundido el proceso de unión anteriormente).

Pueden ocurrir algunos errores cuando un nodo se une justo después de que la membresía (la composición de la sección) haya sido compartida entre los ancianos después de una sesión de DKG. Cuando esto sucede, el nuevo nodo no se cuenta y hay una vista dividida. Es algo que @qi_ma está corrigiendo ahora.

Las banderas safe node join de --skip-auto-port-forwarding y --public-addr ahora están obsoletas ya que eliminamos el reenvío de puertos UPnP/IGD, que nunca ha sido confiable. Esto se ha eliminado para simplificar qp2p por ahora. Es posible que recuperemos esto en el futuro, pero no es una prioridad en este momento. Debería poder unirse con safe node join --network-name ahora, aunque NAT sin duda será un problema para algunos nodos domésticos.

Esto se debe a que para que los nodos en una red P2P puedan comunicarse, deben poder encontrarse entre sí, pero con NAT, su dirección exacta está oculta por el enrutador que solo muestra la IP pública. NAT se introdujo como un truco para evitar que IPv4 se quedara sin direcciones, pero desafortunadamente se ha mantenido. Diferentes enrutadores e ISP tienen diferentes formas de implementar el reenvío de puertos, que no todos estarán seguros de probar de todos modos. IPv6 soluciona el problema, pero lamentablemente la aceptación sigue siendo bastante baja. Es un problema de todas las redes descentralizadas y seguimos buscando soluciones.

Planeamos eliminar gradualmente el comando nodo seguro a favor de usar el binario sn_node directamente, como sugiere @Chriso en esta publicación. El comando node es esencialmente una envoltura delgada alrededor del binario sn_node y no ofrece muchas ventajas sobre el uso directo del binario del nodo. Además, genera problemas de mantenimiento en términos de mantener los argumentos compatibles sincronizados entre los dos. Lo más probable es que el nodo obtenga su propio script de instalación. El comando safe node run-baby-fleming se mantendrá, pero probablemente se convierta en safe run-baby-fleming.


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.