Informe de Estabilidad de la Red: Kusama con Parachains

Por Robert Habermeier, fundador de Polkadot. 16 de agosto de 2021 en Kusama Parachains traducción de Lorena Fabris

Hemos monitoreado la estabilidad de la red de Kusama después de las primeras 5 subastas de parachain. En este momento, hay 6 parachains en la red.

Nuestro interés estuvo puesto en 4 áreas clave:

1. Estabilidad de Producción de la Candidata
2. Estadísticas de Votación de Aprobación
3. Conectividad de Red
4. Carga

Hemos muestreado métricas de validadores opcionales para recopilar la información en Prometheus y Grafana como se muestra en los gráficos a continuación.

Estabilidad de Producción de la Candidata

En circunstancias ideales, en la iteración actual del protocolo, cada parachain produce un bloque por cada 2 bloques de la relay chain. Podemos determinar la tasa de producción de bloques para cada parachain dividiendo la cantidad de bloques de la relay chain producidos durante el tiempo que la parachain ha estado en línea por la cantidad de bloques de la parachain producidos en ese período de tiempo.

La siguiente tabla muestra los valores para las 6 parachains actuales a partir de un número de bloque reciente (#).

Como todas estas parachains están aseguradas por el mismo conjunto de validadores y validadas por validadores aleatorios, no debería haber grandes discrepancias en el servicio proporcionado por los validadores a las parachains.

No vale la pena considerar el efecto del ruido de la red en este momento, ya que en los últimos días las parachains no han tenido tiempo suficiente para estar expuestas repetidamente a todas las combinaciones posibles de validadores de respaldo. Pero el ruido ciertamente no explica la gran discrepancia entre Shiden (y en menor medida, Khala) y el resto de las parachains, que en su mayoría ocupan la banda entre un 5 y un 10% menos que el ideal. Vale la pena señalar que Statemine tuvo un período difícil en las primeras semanas de su lanzamiento, lo que provocó que produjera bloques solo una vez por minuto, y los datos actuales están sesgados por ese problema inicial.

Hay dos posibles explicaciones para la discrepancia. La verdadera razón puede ser una o una combinación de las dos:

1. Ejecución o datos pesados de parachain
2. Mala conectividad del recolector (collator) con los validadores

Por el momento, la ventana de tiempo dada a los recolectores y validadores para producir un bloque de parachain es muy corta, lo que hace que el sistema sea frágil y experimente breves retrasos en la comunicación. Para ambas cuestiones, la solución a largo plazo es mejorar el protocolo de parachains para permitir una ventana más larga para la creación del siguiente bloque de parachain. Una solución a corto plazo sería colocar los recolectores geográficamente más cerca de la mayor parte de los nodos del validador. Sin embargo, esto crea un riesgo temporal de centralización regional, uno que sería mitigado por la solución a largo plazo.

Votación de Aprobación

El protocolo de votación de aprobación es responsable de proporcionar la mayor parte de la seguridad de las parachains. Está estrechamente integrado con el protocolo de finalidad GRANDPA. En términos generales, los nodos se seleccionan aleatoriamente para verificar la validez de los bloques de parachain. Se requiere un cierto número de nodos para finalizar el bloque de la relay chain que contiene al candidato, y los “no-shows” que anuncian su intención de verificar pero no hacen seguimiento se reemplazan automáticamente. Las disputas sobre la validez se escalan a todo el conjunto de validadores, lo que resulta en el recorte (slashing) de al menos un validador.

Como guía de referencia, en la votación de aprobación podemos observar lo siguiente:

1. opiniones de retraso de finalidad de GRANDPA por los validadores
2. “Tramo” medio de asignaciones por validadores (idealmente = 0)
3. Número de asignaciones y aprobaciones por validadores

Retraso de la Finalidad

El gráfico de arriba muestra en escala logarítmica, la opinión máxima y promedio sobre cuántos bloques deben quedar atrás de la cabeza de la finalidad de la relay chain. Cada validador tiene su propia opinión, basada en la percepción del validador del estado de aprobación de cada bloque de parachain referenciado por la relay chain.

La mayoría de las veces, esto es entre 2 y 5. Sin embargo, ocasionalmente salta hasta 50. Estos incidentes son algo alarmantes: hay una prueba de fallos en 50 bloques que claramente se salta muy ocasionalmente, una vez cada pocas semanas.

Estos incidentes de retraso de finalidad (finality stall incidents) se están investigando en este momento. Propondremos una solución a la gobernanza, para resolver el problema antes del lanzamiento de las parachains de Polkadot.

Tramo Promedio

Cada validador está técnicamente asignado para verificar cada bloque de parachain. La única pregunta es cuándo, por lo general, solo los validadores del tramo 0 están realmente alistados para verificar, y los tramos posteriores solo entran en escena cuando los validadores del tramo 0 no aparecen.

El gráfico anterior demuestra que fuera de los incidentes de retraso de finalidad, los tramos de las asignaciones de percentiles 50 y 95 son generalmente 0.

Asignaciones y Aprobaciones

Este gráfico demuestra cómo las asignaciones de los validadores en la red se traducen en sus correspondientes votos de aprobación. Podemos ver que todas las asignaciones se traducen en aprobaciones, aunque la mayoría de ellas se informan como obsoletas. Estos datos son inconsistentes con el retraso de la finalidad informado, ya que las aprobaciones “obsoletas” son aquellas que se vuelven irrelevantes después de la finalidad.

Casi por definición, la mayoría de las aprobaciones no deberían quedar obsoletas, ya que en primer lugar se requieren para que sean definitivas. Existe la posibilidad de que el nodo o Grafana denuncie mal o distorsione esta categoría. En Rococó, el gráfico correspondiente muestra un mapeo de asignaciones y aprobaciones exitosas de casi 1: 1.

Conectividad de Red

En Kusama, hay 900 validadores, y en cada sesión, 200 de ellos se seleccionan aleatoriamente para participar en el consenso de parachain. Cada validador actual está destinado a conectarse a los validadores del conjunto de validadores actual, así como a las últimas 6 sesiones.

Hay varios validadores que tienen aproximadamente 200 conexiones, y esto se debe al hecho de que forman parte de un conjunto de validadores más antiguo. Los validadores que forman parte del conjunto de validadores actual deberían experimentar picos de mayor conectividad. Podemos ver que, en gran parte, los validadores que inspeccionamos en la red están sobreconectados y están conectados a la mayoría de los otros 899 validadores en el conjunto de pares de validación. Esto no plantea ningún problema para la corrección, pero presenta una oportunidad para la eficiencia.

Algunos validadores están poco conectados y no están tan conectados a la red de difusión como deberían. A pesar de esto, ninguno de los validadores tiene menos de 100 conexiones y, por lo tanto, la información se debe difundir a los validadores, aunque con más saltos.

Ciertas solicitudes requieren comunicación punto a punto y, por esa razón, todos los validadores deben ser accesibles públicamente a través de una dirección de nodo publicada. El software del nodo realiza automáticamente esta función, pero el operador del nodo es responsable de garantizar que el nodo sea accesible.

Este gráfico muestra la cantidad de solicitudes de fragmentos realizadas por segundo y la cantidad de fallas de diferentes tipos. El tipo de solicitud aquí no es importante, y la conclusión clave es que las fallas por “falla de marcación” (la línea amarilla en el gráfico inferior) representan casi exactamente el 10% del número de solicitudes realizadas. Esto indica que el 10% de los validadores no están disponibles en su dirección publicada.

Carga (CPU y Red)

Este gráfico muestra el uso de CPU en núcleos por parte de los validadores. La mayoría de los validadores se encuentran en la banda de utilización de núcleos 1.5–2. Nuestra recomendación actual es que los validadores se ejecuten con CPU de 4 núcleos, por lo que la utilización de la CPU está dentro de las expectativas.

Este gráfico muestra el uso de CPU desglosado por tarea. Las 3 tareas principales dominan el uso de la CPU, y en orden descendente son las tareas “libp2p-node”, “network-worker” y “grandpa-voter”. Estas tareas están principalmente relacionadas con la red, lo que indica que las optimizaciones en la utilización de la red reducirán sustancialmente la utilización de la CPU del nodo.

La mayoría del tráfico rumoreado que es usado por los nodos ocurre en protocolo de red /polkadot/validation/1. Esto acumula todos los rumores entre los nodos y representa una gran parte del tráfico de la red. Este gráfico muestra que, en general, el ancho de banda de red promedio entre los validadores es muy estable entre 400 y 500 KB / s con un poco más de ancho de banda “dentro” que “fuera”.

La mayor parte del ancho de banda de solicitud / respuesta que utilizan los nodos se encuentra en el protocolo de distribución de fragmentos. Con 200 validadores y un tamaño máximo de PoV de 1 MB, los fragmentos tienen un pico de alrededor de 15 KB. A estas tasas promedio de solicitud / respuesta, esto implica un ancho de banda de alrededor de 307 KB / s de entrada y 138 KB / s de salida. Sin embargo, por el momento, los PoVs son mucho, mucho más pequeños, ya que las parachains no están cerca del volumen máximo de transacciones.

Recomendaciones

En general, la red funciona sin problemas. Aunque la cantidad promedio de pares y el ancho de banda de la red parecen consistentes en toda la red, hay nodos atípicos que están sobreconectados y experimentan niveles más altos de ancho de banda de red.

Parece que en el entorno actual, la recomendación permanente de una CPU sólida de 4 núcleos y una memoria de 64 GB es más que suficiente junto con una conexión rápida a Internet. El uso actual de ancho de banda parece estar en el rango de 8–16 Mbps, por lo que una conexión típica de centro de datos de 100 Mbps será suficiente para mantener los últimos 5.

El único problema importante son los retrasos infrecuentes de la finalización que experimenta la red. Estos retrasos están siendo capturados por un dispositivo de seguridad y, por lo tanto, no han causado mucho daño, pero se está investigando la causa subyacente y se propondrá una solución para remediar esto antes del lanzamiento de parachains en Polkadot.

DdZD8ArevK5LoaVNZNVyoit1hGUBFvudpgtnRvJVmUWfWne