Actualización de Safe Network Dev 🇪🇸 6 de enero de 2022

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

¡Feliz Año Nuevo a todos! Estamos de vuelta en la silla de montar otra vez :cowboy_hat_face: y con muchas ganas de ir.

Muchas gracias a @josh por configurar la red de prueba de la comunidad reciente y a todos los que participaron. Algunas de las anomalías informadas que hemos visto reflejadas en nuestros propios resultados de prueba, y también hubo algunas sorpresas, incluidos los picos máximos de CPU que estamos investigando ahora. ¡Animo amigos!

Solo uno rápido esta semana para informarle en qué estamos trabajando en este momento. Feliz de decir que ya hemos atado algunos cabos sueltos y estamos listos para rodar.

Progreso general

Con el tiempo, hemos considerado varias formas diferentes de calcular el espacio libre en la red. Recientemente, hemos estado recorriendo los pocos directorios de db y agregando tamaños de directorio para calcular el espacio utilizado. Dirigido por @anselme, ahora hemos simplificado el almacenamiento de datos al eliminar la base de datos avanzada para reemplazarla con un proceso directo al disco más simple con una estructura de directorio de árbol binario. Esto nos obligó a reemplazar el proceso de recorrido de directorios con uno que cuenta cada byte a medida que se escribe y realiza un seguimiento del espacio total utilizado, que es mucho más rápido y más escalable ahora que tendremos un árbol profundo de directorios en lugar de uno o dos. También simplificará enormemente el proceso de hacer que un nodo con fragmentos se reincorpore a la red porque no necesitamos medirlo cada vez, además de simplificar las divisiones de sección.

Anselme también está analizando cómo se puede calcular fácilmente el espacio de almacenamiento que se libera cuando se eliminan los registros privados (datos mutables).

Hablando de datos mutables, hemos estado considerando qué tipo de cargos deben adjuntarse al tipo de datos de registro. El pago por cambio sería muy complicado, queremos separar las ediciones del proceso DBC. Actualmente, estamos pensando en cobrar un múltiplo del precio de un PUT de fragmento inmutable (blob) por un PUT de registro, y permitir ediciones infinitas por parte del propietario de los datos (y las partes con las que decidan compartir) a partir de entonces.

@bochaco ha seguido perfeccionando el proceso de membresía, es decir, cómo mantenemos la cantidad correcta de ancianos en una sección y cómo agregamos nuevos nodos adultos a la sección cuando es necesario. Cuando un nuevo nodo solicita unirse, inicia un proceso que incluye mensajes AE y la prueba de prueba de recursos, y una vez que los mayores aceptan aceptarlo, se envía un mensaje de vuelta al nodo que se une. Este flujo ahora está integrado con la caja sn_membership, al menos para los adultos que ascienden a adultos mayores y los adultos mayores que se van. Sin embargo, este proceso de “membresía sn” actualmente asume que todos los nodos involucrados son miembros con derecho a voto (es decir, ancianos), por lo que excluye la promoción de un adulto a un anciano. @bochaco y @davidrusu están trabajando en esto ahora. Explicaremos más en una futura actualización.

Mientras tanto, @lionel.faber ha estado buscando acelerar el proceso de CI/CD con corredores de GitHub autoalojados en AWS. Las máquinas virtuales nativas en GitHub Actions pueden ser bastante lentas, especialmente para Windows, lo que ha demostrado ser un cuello de botella en las pruebas. Al alojar nosotros mismos el servicio en AWS, podemos usar máquinas virtuales más potentes para completar nuestros flujos de trabajo más rápidamente. Lionel también está documentando el proceso de generación de claves distribuidas (DKG) que usamos para el acuerdo.

Permaneciendo en las pruebas por un momento, a veces las pruebas pueden ser demasiado rigurosas. ¿Cómo es eso? Las pruebas de pozo están diseñadas para detectar todos los errores cuando ocurren, mientras que una red tolerante a fallas con CRDT puede solucionar estos problemas técnicos y llegar eventualmente a un estado consistente garantizado. Por lo tanto, puede ser un desperdicio crear pruebas que atrapen todo, ¡pero es un acto de equilibrio complicado!

Un ejemplo de ello es un error de datos faltantes, como el que puede haber visto en la red de prueba. ¿Realmente faltan los datos o simplemente no han llegado todavía? Quizás aparezca más tarde, o quizás esté ahí pero ha habido otro error.

En este escenario, los mensajes entre actores también se matizan, y este es otro tema de discusión. Cuando un fragmento se ha PUTADO con éxito, se le debe informar (opcionalmente) al cliente que se ha almacenado y, gracias a los CRDT, esto debería ser 100 % seguro, pero si aparentemente ha “fallado”, esto no es 100 % seguro debido a la asincronía y otros factores, por lo que el cliente necesita opciones sobre cómo proceder.

@Qi_ma ha estado revisando los registros para rastrear el error de datos faltantes, y @yogesh está investigando el motivo de la avalancha de mensajes AE que a veces abruman las comunicaciones entre nodos. ¿Están relacionados? Deberíamos saberlo pronto. Mientras tanto, @joshuef ha estado analizando un error que podría causar problemas en los nodos que están siendo golpeados por los clientes, lo que hace que la memoria del nodo se dispare y, en ocasiones, los bloquee. En este momento, solo estamos limitando eso a un límite arbitrario de mensajes de clientes simultáneos, pero buscaremos hacer que esto sea dinámico en función de la carga del nodo a medida que avanzamos.

cada paso es otror paso más cerca.


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.