Informe Post-Mortem del Update del 7 de Julio 2023 de la Blockchain

Traducción del Original por soranews.io

El 7 de julio a las 13:33, la red SORA experimentó una interrupción mientras se actualizaba el tiempo de ejecución (runtime) de la cadena de bloques. Este informe describe el cronograma y las causas de la interrupción, las acciones tomadas para mitigar y los siguientes pasos para evitar que vuelva a ocurrir una situación similar.

Cronología del incidente:

• El 7/7/23 a las 13:30, la gobernanza de SORA envió la actualización de tiempo de ejecución 1.11.0.
• 13:33: se descubrió una falla de migración (pánico) y el equipo comenzó a trabajar en una solución
• 14:25 — Los usuarios comenzaron a notar que la producción de bloques no se había reanudado y reportaron el problema
• 23:29 — El puente Hashi fue inhabilitado como medida de seguridad
• El 7/8/23 a la 01:00: los nodos MOF (Ministerio de Finanzas) se recuperaron y la producción de bloques comenzó a estabilizarse
• 09:10 — Recuperación completa de la red y reanudación de la producción normal de bloques
• 10:08 — Se habilitó el puente Hashi.

Descripción detallada:

• La migración del pallet de la versión de tiempo de ejecución 1.11.0 falló debido a un problema con el manejo de campos de cadena dentro de la plataforma Hermes. Este problema no se detectó durante la prueba, ya que no había encuestas en la plataforma Hermes que excedieran el límite de cadena de 64 bytes.
• En la red principal, la presencia de encuestas con descripciones por encima del límite de 64 bytes hizo que la migración fallara (pánico). Esta falla hizo imposible inicializar el siguiente bloque, lo que detuvo la producción de bloques por completo.
• Los desarrolladores de SORA proporcionaron en el chat de SORA Devs Telegram un WASM de tiempo de ejecución actualizado junto con una guía para que los validadores pudieran implementar la corrección . A medida que los validadores que implementaron la solución comenzaron a producir bloques nuevamente, aquellos que aún no podían producir bloques fueron considerados infractores y posteriormente fueron penalizados (slashed).

Acciones tomadas para resolver el fallo:

1 Se preparó un WASM en tiempo de ejecución sin la migración de palets fallida
2 La actualización WASM en tiempo de ejecución fue aplicada por 2 validadores
3 Los desarrolladores de SORA prepararon una guía para que los validadores de la comunidad implementen la actualización WASM en tiempo de ejecución, después de lo cual se reanudó gradualmente la producción de bloques. Los validadores que no implementaron la solución y reanudaron la producción de bloques de inmediato fueron recortados porque los validadores que reanudaron la producción de bloques los consideraron infractores.
4 Se configuró un nodo de archivo para monitorear la red durante el tiempo de inactividad del nodo público
5 Se descubrieron problemas con las penalizaciones y el proveedor de elecciones del validador
6 Se intentó cancelar los slashes, sin embargo, hubo dificultades, ya que Polkadot.js no tenía la opción de modificar el umbral extrínseco de CancelSlashes.
7 Se contactó al Consejo de SORA para crear una propuesta interna para cancelar los slashes.
8 El puente Hashi se deshabilitó temporalmente para mitigar cualquier problema potencial.
9 Una vez que se cancelaron los slashes, se plantearon propuestas para reiniciar el proveedor de elecciones del validador.
10 Se realizaron pruebas locales para anticipar y abordar cualquier problema adicional.
11 Los miembros del Consejo de SORA votaron para cancelar los slashes y elegir nuevos validadores.
12 El puente Hashi se volvió a habilitar después de las pruebas de aceptación exitosas y la estabilidad de la red.

Acciones tomadas para evitar que este problema se repita

Se implementaron pruebas de migración de producción en la canalización de CI, y se probarán otros hooks para escenarios de pánico.

Se ha establecido un canal de comunicación simplificado con otros equipos de desarrollo involucrados y los equipos están colaborando para establecer políticas y procesos de desarrollo comunes para SORA.

Se ha incluido un nodo de archivo confiable mantenido las 24 horas, los 7 días de la semana, en las aplicaciones de los clientes y se han otorgado permisos restringidos al Comité Técnico para casos de emergencia.

Lecciones Aprendidas

Situaciones como esta a menudo son difíciles de predecir cuando las pruebas se realizan sin problemas. La primera lección es evitar los lanzamientos en viernes. Aunque el espacio de la cadena de bloques nunca duerme, por lo general las personas tienen dificultades para responder tan rápido como se requiere en una situación de este tipo.

Otra forma de mitigar los retrasos es que el Consejo otorgue los permisos necesarios para resolver problemas técnicos al Comité Técnico, ya que están constantemente en línea para garantizar que toda la red funcione sin problemas.

Se debe implementar más cobertura de prueba antes de los lanzamientos para garantizar que no se deje piedra sin remover antes de implementar cualquier actualización importante. Además, la automatización de pruebas ayudará a que los procesos sean más sólidos y a reducir el riesgo de error humano.

Próximos pasos

La versión 1.11.1 se enviará a producción para corregir la migración de pallets y el WASM en tiempo de ejecución estará disponible para los validadores para que puedan actualizar sus nodos y dejar de usar la actualización WASM en tiempo de ejecución adicional.

Actualización

En el momento de la publicación (19 de julio), la corrección 1.11.1 se implementó con éxito y se recomienda a los nuevos ejecutores de nodos que configuren su nodo con la imagen de Docker 1.11.1.

Gracias por su apoyo para resolver este problema.