Actualización de Safe Network Dev 🇪🇸 6 julio 2023

Software
1

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

4503811aa441a5250da8b2b07641a9cc1f540734
4503811aa441a5250da8b2b07641a9cc1f540734830×430 42.7 KB

Uno de los cambios en los que estamos trabajando esta semana se refiere a la versión actualizada de libp2p, que trae algunas mejoras bienvenidas a AutoNAT: detecta y permite que se unan los nodos que están detrás de un firewall o enrutador. Pronto podremos distinguir entre direcciones IP globales y privadas, lo que antes era un problema.

Sin embargo, inevitablemente, también trae algunos errores nuevos para mantenernos alerta. Así que la mayor parte de nuestro trabajo esta semana ha estado bajo el capó, retocando los taqués en lugar de pulir la parte delantera.

Dicho esto, @ChrisO ahora ha actualizado la interfaz de registro, brindando opciones de almacenamiento y formateo a las personas que ejecutan un nodo. Los usuarios pueden especificar el directorio de salida del registro o la salida estándar si lo desean, pero por defecto ahora son:

       Linux: $HOME/.local/share/safe/node/<peer-id>/logs
       macOS: $HOME/Library/Application Support/safe/node/<peer-id>/logs
       Windows: C:\Users\<nombre de usuario>\AppData\Roaming\safe\node\<peer-id>\logs

Los registros de clientes se almacenan de forma predeterminada en los directorios equivalentes ...client/logs.

También hay una selección de formatos. JSON se puede especificar a través de la CLI si se desea.

Como sabrá, hay tres máximas que seguimos cuando integramos nuestro trabajo con libp2p. Uno es dejarlo en manos de Kad siempre que sea posible, porque hay muchos más ojos en el código libp2p y queremos estandarizar eso siempre que sea posible. El segundo es dejarlo en manos del cliente: cuanto menos tengan que hacer los nodos, mejor. El tercero es maximizar la seguridad: todo debe estar firmado y los datos deben estar encriptados. Encontramos que estos son actualmente contradictorios. @Anselme ha estado analizando los registros que no están protegidos de forma predeterminada en la creación de Kademlia Records, lo que los hace vulnerables a los nodos defectuosos. Los nuevos récords tampoco son CRDT en Kad, por lo que las condiciones de carrera son posibles. Las escrituras posteriores son CRDT, por lo que no hay problema. Anselme cree haber encontrado una solución para ambos problemas.

@Qi_ma y @joshuef están trabajando en otro problema sobre cómo, cuando un cliente almacena fragmentos, encuentra los nodos más cercanos y enruta sus datos. Sentimos que el cliente debería estar haciendo más del trabajo. Queremos que soliciten repetidamente a la red los nodos más cercanos y cuando obtengan un parche, coloquen el fragmento, en lugar de un proceso de descubrimiento completo.

Nuestro enfoque preferido actual es este feat: Using put record for upload by maqi · Pull Request #482 · maidsafe/safe_network · GitHub , que nos hace volver a usar la implementación put de Kademlia, aunque ahora la hemos verificado en el momento de la puesta. Esto elimina las vías para que los nodos defectuosos hagan cosas furtivas y también simplifica un poco el código en torno a PUT.

Las cargas hasta ahora son un poco más lentas, pero estamos seguros de que se pueden optimizar más adelante si es necesario.

El procesamiento de pagos es otro problema que estamos analizando, incluido a través de DBC propiedad de la red, lo que significaría que no tenemos que verificar que los pagos se dirigieron a nodos válidos. en ese momento (ya que ya no tenemos la sección-árbol + historial allí) esto simplifica mucho las cosas. Y más adelante podremos desembolsar recompensas desde la propia red.

Y hemos estado analizando la cuestión de los reinicios y las actualizaciones. Un nodo fallido no debe mantener la misma clave, pero un nodo válido que falla durante una actualización, por ejemplo, debería poder recrear una ID y claves válidas a partir de una clave anterior.

Progreso general

@Bochaco está trabajando a través de la lógica de DBC y pagos a la red.

@aed900 está trabajando en una opción de contenedor personalizado para la herramienta de red de prueba GitHub Actions (CI), y @roland trabajó en la implementación de una red simulada que nos permite probar las características de los nodos más a fondo.

Con la actualización de Libp2p, @Benno busca errores y prueba las capacidades de AutoNat.

Además de arreglar la seguridad del registro, @anselme ha actualizado la funcionalidad del grifo.

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.