Actualización de Safe Network Dev 🇪🇸 19 mayo 2022

Esta es una traducción automática. El original en inglés está aquí: 19 May 2022

Una red en buen estado se compone de nodos en buen estado, dispositivos que hacen lo que se requiere de ellos según lo esperado, dentro de un rango de rendimiento aceptado. Es el trabajo de los ancianos asegurarse de que los adultos de su sección estén a la altura y tomar medidas votando si detectan algún problema. El seguimiento de la disfunción es una gran parte de lo que el equipo está trabajando ahora.

Progreso general

Esta semana nos dimos cuenta de que estábamos perdiendo nodos potencialmente durante un alto índice de abandono y divisiones, con el nodo pensando que se había unido, pero con el abandono la clave de sección válida se había movido. El nodo, pensando que todo estaba bien, no intentaría volver a conectarse. Entonces, @anselme ha estado trabajando para verificar nuestro conocimiento de la red y, después de actualizarlo, volver a intentar el proceso de unión para estos nodos perdidos.

El trabajo de DBC continúa, con los pasos iniciales para almacenar el SpentBook en su lugar.

Al ejecutar testnets para depurar la inestabilidad de los datos, hemos descubierto un par de puntos muertos potenciales. En un caso, vimos que las lecturas de DataStorage se bloqueaban durante la replicación. Entonces, comenzamos a crear algunos puntos de referencia para probar ChunkStorage, y con esto descubrimos un punto muerto en el código de almacenamiento subyacente.

Otro bloqueo (no confirmado) se produjo durante el proceso de limpieza de PeerLink. Es difícil decir si esto definitivamente estaba sucediendo, pero habíamos visto nodos bloqueados y nuestro código de limpieza había sido llamado con frecuencia alrededor de los bloqueos. Profundizando, había mucho potencial para la simplificación, así que hicimos precisamente eso.

Otro posible bloqueo estaba ocurriendo en la disfunción, con la estructura de datos anidados que se leía incorrectamente sin un bloqueo mut. :boca_abierta: :man_facepalming:

Es difícil decir si todo esto estaba sucediendo con certeza (lo que requería que surgieran condiciones específicas), pero ciertamente estos cambios deberían ser pasos en la dirección correcta.

Con todo eso adentro, también tenemos el trabajo DKG-Handover with Generation integrado por fin (que fue mucho más estable sobre otros cambios recientes). Estamos eliminando la estabilidad, con más pruebas/puntos de referencia por venir para DataStorage, y algunos otros ajustes a los flujos de replicación de datos que se están probando (necesitamos expandir el grupo de nodos que solicitamos datos, ya que con una gran rotación, las probabilidades de golpear otro aumento de nodo recién unido y parece que empezamos a perder la retención de datos!).

Seguimiento de disfunción

El seguimiento de la disfunción es un proceso continuo. Siempre hay nuevos comportamientos para probar y modelar, por lo que es un proceso iterativo que permite mejoras en el rendimiento y la estabilidad a medida que avanzamos.

El seguimiento de la disfunción es diferente del manejo de la malicia. La malicia es una mala acción demostrable objetivamente, como firmar un mensaje de red no válido, y es el trabajo de todos los nodos identificar dichos nodos y castigarlos. Disfunción, por otro lado, significa ‘comportamiento deficiente’ y es el deber de los ancianos averiguar lo que eso significa.

Un nodo puede tener un rendimiento deficiente debido a factores ambientales, como la lentitud temporal de Internet local o condiciones que se acumulan con el tiempo, como almacenamiento o memoria insuficientes. O la disfunción puede ser repentina, como una falla de energía o un reinicio forzado.

La disfunción también cubre factores operativos, incluida la calidad y la cantidad de mensajes, y el almacenamiento y la liberación de datos a pedido.

Algunos tipos de disfunción (pérdida de datos, pérdida de conectividad prolongada) son más graves que otros y, por lo tanto, deben tratarse de manera diferente.

Podemos probar el rendimiento de un nodo en relación con otros nodos en la sección, pero ¿qué sucede si toda la sección está por debajo del estándar en relación con otras secciones? ¿Entonces que?

Como puede ver, el seguimiento de la disfunción es un tema complejo con muchas variables.

Objetivos del seguimiento de la disfunción

Al monitorear los nodos a medida que cumplen con sus funciones, queremos cortar cualquier problema de raíz antes de que crezcan. Expulsar un nodo debe ser el último recurso; en su lugar, queremos tomar medidas, o hacer que el propietario del nodo, el agricultor, tome medidas para corregir el problema.

Este proceso de corrección progresiva del comportamiento de los nodos debe ser automatizado y flexible, capaz de reaccionar a las condiciones cambiantes en lugar de basarse en parámetros arbitrarios codificados.

El seguimiento de disfunciones tiene que ver con la optimización, pero no se trata solo de optimizar el rendimiento, eso conduciría a la centralización. Los usuarios domésticos no podrían competir con las instancias de los centros de datos; siempre serían relativamente disfuncionales.

Donde estamos

Actualmente tenemos una versión simplificada de disfunción en su lugar.

Prueba de vida verifica que los nodos estén en línea, lo que permite a los ancianos tomar medidas si no lo están. Esto se ha ampliado para penalizar a los nodos no solo por descartar fragmentos, sino también por descartar conexiones y atrasarse en términos de conocimiento de la red.

vivacidad tuna vez ajustado para garantizar que no seamos demasiado duros (como lo hemos sido hasta ahora) o demasiado blandos con los nodos que se comportan mal es un buen primer paso para garantizar una red estable, pero con el seguimiento de disfunciones queremos ir más allá y construir un modelo que optimiza para otros factores también.

Penalizar nodos actualmente significa eliminarlos, pero pronto incorporará otras medidas como reducir a la mitad la antigüedad de los nodos. Las decisiones sobre qué curso de acción tomar serán tomadas por los ancianos por consenso.

Como se mencionó, cierto grado de “comportamiento disfuncional” es inevitable, y en este momento estamos experimentando con la clasificación de los nodos como buenos (más del 95 % de índice de éxito para una operación determinada), mediocres (75 %) o malos (30 %), por lo que podemos puede tratar cada clase de manera diferente según su gravedad, sin codificar ningún valor ‘esperado’ (PR #1179). También queremos saber cuántos nodos de cada clase hay en nuestra sección.

La caja sn_dysfunction está aquí.

A donde vamos

Queremos expandir la cantidad de pruebas que hacemos y los parámetros que verificamos para asegurarnos de que estamos modelando la red de manera significativa.

Las ideas incluyen encuestas periódicas a adultos para darles una pequeña prueba de trabajo que también podría verificar si tienen una versión actualizada de algunos datos mutables. Los datos mutables son un CRDT y eventualmente convergerán, pero la conectividad intermitente puede significar que una réplica devuelve una versión desactualizada. Lo obsoleto que esté influiría en su puntuación de disfunción, una cuenta acumulativa otorgada a cada nodo. Si esto excede un valor de umbral, ese nodo puede ser reclasificado como ‘mediocre’ o ‘malo’ y ser tratado en consecuencia. Durante el período de tiempo que seguimos agregando a la puntuación será necesario probar.

No todos los problemas se pueden rastrear comparando el rendimiento entre pares (si todos los nodos son malos, eso significa una sección mala; si demasiadas secciones son malas, eso significa una red mala), por lo que buscaremos parámetros globales adecuados.

También debemos considerar cómo podemos usar el seguimiento de disfunciones para fomentar la diversidad de nodos y evitar la centralización, de modo que tanto una instancia de AWS como una Raspberry Pi puedan desempeñar un papel.

Y queremos considerar cómo presentamos la información de disfunción al usuario final, el agricultor, posiblemente como un conjunto de parámetros predeterminados que se pueden modificar a través de un archivo de configuración y luego a través de una GUI.

En última instancia, Safe es como una computadora global, con los mayores como una CPU multiproceso y los adultos como un disco duro gigante. Queremos que este disco duro se autorrepare y que la CPU pueda adaptarse a los cambios.

Todo esto nos lleva al ámbito de la ingeniería del caos, tal como la utilizan empresas como Netflix y Google en sus plataformas en la nube, para garantizar que no se produzcan fallas en los servidores individuales. No derribará todo el sistema.

Es probable que también podamos aprender algo aquí mientras trabajamos para hacer que Safe Network sea sólida y confiable.


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.