Esta es una traducción automática. El original en inglés está aquí: Update 27 July, 2023
Como habrá notado, una nueva red de prueba está entre nosotros. ¡Es hora de subirse a bordo si aún no lo ha hecho! Descargue de forma segura y cargue algunos archivos, y vea cómo el pago por cada carga se resta automáticamente de su billetera. Todo el dinero de Monopoly por ahora, por supuesto, pero es genial verlo en acción. Háganos saber cualquier error que pueda ver en el hilo.
El pago de datos es un gran paso adelante, gracias al hecho de que la red ahora se comporta bastante bien y es estable (toca madera). La memoria por nodo ronda el rango de 50 a 60 MB, mientras que antes era de cientos de MB. Pero todavía hay cosas que resolver. Gracias por los comentarios hasta ahora, y sigan llegando. La siguiente etapa será probar el flujo de pago básico a los nodos y algún tipo de mecanismo de fijación de precios simple.
Desafortunadamente, todavía no hay un NAT transversal sólido, pero aquellos con nodos en la nube o que estén contentos con el reenvío de puertos pueden intentar ejecutar uno o dos nodos. Háganos saber cómo va.
Ahora que estamos en un lugar estable, también vamos a empezar a desmontar el funcionamiento de la red. Esta semana, @roland explicará qué sucede durante la replicación de datos.
Progreso general
@Chriso está trabajando en el registro centralizado para facilitar el análisis de errores en conjunto después de las redes de prueba. En última instancia, esperamos permitir que los miembros de la comunidad hagan esto en tiempo real, pero por ahora lo mantendremos simple.
Thomas Eizinger y Max Inden del equipo rust-libp2p han combinado una solución de @bzee, que estaba viendo nuevos nodos continuar marcando (mensaje ) otros nodos incluso después de que estén conectados a la red. @bzee está en contacto regular con ese equipo, quienes dicen que AutoNAT y perforaciones deberían estar funcionando ‘pronto’. Uno de los mantenedores tiene una solución tentativa que solucionaría el problema de la reutilización de puertos: AutoNAT no necesita reutilizar puertos en sondas salientes. Crucemos los dedos por algún progreso inicial en eso.
@aed900 busca mejorar la UX en torno a los nodos no conectados tiempos de espera de manejo.
@bochaco está avanzando en una función para obtener todos los gastos para un comprobante de pago al mismo tiempo para acelerar el proceso de verificación de DBC, y también un enfoque para hacer registros direccionable por contenido.
@qi_ma solucionó un error sutil con los DBC. Cuando un cliente quiere gastar un DBC para cargar datos, los nodos verifican si existe una prueba de gasto existente en la dirección relevante (para detener el doble gasto). El nodo que tiene esa dirección también responderá activamente a las solicitudes GET, lo que puede retrasar su respuesta a los nodos que preguntan, haciéndoles pensar que no hay una prueba gastada allí. Este es un evento extremadamente raro, pero lo hemos visto en la naturaleza y permitiría el doble gasto. Lo estamos parcheando al requerir 5 nodos para ver un GET antes de que se actúe en consecuencia.
Y @joshuef está buscando pagos y precios dinámicos, incluido el cliente que pregunta a los nodos cerca de la ubicación de pago cuál es su costo de almacenamiento, y con eso actualiza el pago por subidas. Y también un cálculo del costo de la tienda básico basado en la capacidad de la tienda de discos.
Replicación de datos
La replicación de datos es un mecanismo que permite que los nodos distribuyan datos a nuevos pares a medida que se unen y transfieren datos de un “par muerto” a los otros nodos. Esto garantiza que los datos permanezcan disponibles en la red, incluso cuando los nodos se unen o se van. Sin embargo, el enfoque utilizado por Libp2p se basaba en que un nodo inundaba periódicamente la red con todos sus datos. Esto vino con algunas desventajas, incluido un tráfico de red pesado y un uso elevado de memoria entre los nodos. Además, los nuevos nodos no recibieron los datos de los que eran responsables y los datos que tenían los nodos inactivos no se replicaron a tiempo. Para abordar estos problemas, implementamos un proceso de replicación personalizado que se activa cada vez que hay un cambio en el grupo cercano de un nodo.
Antes de profundizar en el proceso de replicación, analicemos brevemente cómo se almacenan los datos en la red. La red funciona como una tabla hash distribuida (DHT), lo que permite la recuperación de datos mediante claves únicas. Cuando alguien quiere almacenar un archivo en la red, primero usa su DBC para pagar el archivo y luego lo carga en la red. Estos datos (DBC, Chunk o Registro) se transforman en una serie de 0 y 1 y se colocan dentro de algo denominado “Registro”. Aunque los registros pueden ser infinitamente grandes, los nodos están restringidos para manejar registros de 1 mb de tamaño. Cada Registro tiene su propia Clave, que es el XorName de los datos que está almacenando.
Para almacenar el Record que contiene tanto los datos como la Clave en la red, el cliente calcula la Distancia Xor entre la Record Key y sus nodos en su RT (Routing Table), ordenando los pares por su cercanía a la Clave. Posteriormente, el cliente solicita a estos nodos que “calculen y compartan los pares que creen que están más cerca de la Clave”. Luego, el cliente ordena las respuestas e identifica los nodos que están aún más cerca de la Clave. Este proceso continúa hasta que se encuentran los ocho nodos responsables del registro y el registro se almacena con ellos. Libp2p abstrae este complejo proceso, permitiéndonos construir nuestra red sobre él.
Una vez que se ha almacenado un ‘Registro’ entre los pares más cercanos de la red, queremos mantener al menos ocho copias del registro, incluso si los nodos que los contienen se desconectan. Nuestro proceso de replicación actual funciona de la siguiente manera: cada nodo realiza un seguimiento de los pares cercanos a él, es decir, su grupo cercano. Cada vez que se agrega o elimina un compañero del RT, verificamos si esto afecta a nuestro grupo cercano. Si hay un cambio, enviamos las “Claves de registro” a nuestros compañeros de grupo cercanos que creemos que deberían tener este registro. Al recibir la lista de claves, si un par no tiene el registro correspondiente, lo solicita al nodo que envió inicialmente la Clave. En caso de que no pueda recibir el registro del nodo que inicialmente envió la clave, solicita los datos a la red.
Aunque es posible realizar más optimizaciones, el enfoque de replicación actual requiere muchos menos recursos que el de Libp2p y evita de forma eficaz la pérdida de datos.
Enlaces útiles
- Sitio web de red segura
- Introducción a la red segura
- Aspectos básicos de la red
- Hoja de ruta
- Glosario
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.