Esta es una traducción automática. El original en inglés está aquí: Update 15 June, 2023
Lo primero que hay que decir es que estamos enormemente contentos con el resultado de ReplicationNet. Fue un poco arriesgado arrojar tantos nodos, nuestra red de prueba más grande hasta ahora por cierto margen, y esperábamos algunas oscilaciones importantes, pero tomó todo lo que pudimos lanzar con calma y sin quejas, hasta que los nodos completos dejaron de funcionar. . Lo más alentador de todo es que esta estabilidad se produjo a pesar de algunos errores de mensajería en torno a la replicación de datos que se esperaba que la derribaran. En cambio, los ahuyentó como una mosca. Una vez más, un sincero agradecimiento a todos los que participaron 
, y una mención especial a @shu por su fantástico trabajo en el tablero :trofeo:.
ReplicationNet - hallazgos y acciones
Entonces, después de revisar los registros, tanto los amablemente compartidos por la comunidad como los nuestros, podemos informar lo siguiente.
-
El problema de la memoria que aumenta lentamente se debe casi con certeza a que los nodos alcanzan su capacidad máxima. No vemos este comportamiento hasta que se llenan varios nodos (1024 fragmentos en este caso). Una vez que la red esté operativa, no deberíamos ver esto, ya que se incentivará a los nuevos nodos a unirse.
-
Los problemas de falta de memoria parecen deberse a que se almacenan demasiados datos en la memoria caché a medida que el nodo se acerca a su capacidad. (Y para ese caso, parece que tenemos demasiados nodos en una máquina demasiado pequeña). Eso no es un error per se, libp2p debería dispersar ese caché y los datos se almacenarían a medida que se unieran más nodos.
-
Identificamos y eliminamos un error por el cual la replicación de datos estaba causando cierres de conexión y, en consecuencia, muchos mensajes perdidos sobre la replicación. Es probable que esto signifique la perdición, y es un testimonio de la estabilidad subyacente de la red que tuvo tan poco impacto.
-
Otra corrección de errores tenía que ver con los errores de
Falla de salida. -
La distribución de datos entre nodos es bastante uniforme. Una vez más, buenas noticias porque podemos usar el porcentaje de espacio utilizado como disparador para el precio de recompensa según lo planeado. El problema de que algunos nodos no se llenen es un error, probablemente algo relacionado con los nuevos nodos que no se promocionan a sí mismos en las tablas de enrutamiento de otros con la suficiente fuerza.
-
Hay algunas anomalías en los registros donde las solicitudes de colocación y las métricas almacenadas en fragmentos no parecen coincidir. Tenemos que trabajar para aclararlos.
-
Para brindar más control a los usuarios con un ancho de banda más bajo, agregamos la capacidad para que el cliente establezca la duración del tiempo de espera para solicitudes y respuestas desde la red. . También hemos aumentado la duración del tiempo de espera predeterminado de 10 a 30 segundos.
-
Ahora estamos pensando en los flujos de pago y las recompensas para los diferentes escenarios: nuevos datos, replicación de datos y republicación de datos (cuando se hayan perdido datos válidos por cualquier motivo)
La próxima red de prueba nos ayudará a probar estas suposiciones y correcciones, así como a validar algunos trabajos en torno a la experiencia del usuario.
Progreso general
Ahora todos los ojos están puestos en los DBC, con @bochaco y @Anselme trabajando para asegurar verificar el proceso de pago para almacenar fragmentos, incluida la verificación de los padres de los se gastan los DBC de pago, y asegurando que su “razón”-hash coincida con la información de prueba de pago proporcionada para cada porción. Anselme solucionó una falla por la cual el grifo y la billetera no marcaban los DBC como gastados. Resultó que esto tenía que ver con la actividad síncrona de los nodos de verificación que provocaban un bloqueo de lectura y escritura, mientras que necesitamos que sea asíncrono.
Del mismo modo, @roland está eliminando un punto muerto en las operaciones PUT y GET para garantizar que se puedan realizar y pagar al mismo tiempo. La paralelización es el nombre del juego. También se asegura de que nuestras validaciones de datos se produzcan independientemente de cuándo lleguen los datos a un nodo, lo que evita que se “carguen” algunos datos a través de los protocolos libp2p/kad (que esencialmente habrían permitido datos gratuitos).
@bzee todavía está jugando con las entrañas de libp2p, actualmente ajustando la marcación inicial de los compañeros de arranque.
@Joshuef y @qi_ma han estado trabajando principalmente en los hallazgos de la última red de prueba y corrigiendo sobre la marcha.
@chriso ha estado trabajando arduamente para actualizar safeup, más sobre eso pronto.
Y @aed900 compitió con una herramienta de lanzamiento de redes de prueba para automatizar la creación de redes de prueba en AWS y Digital Ocean.
¡Adelante!
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.