Estimados delegantes del pool CAZ:
Como operador responsable del pool, les comunico que he detectado en el transcurso de este epoch un problema con el vencimiento de las llaves KES de nuestro pool, CAZ. Las mismas se encontraban vencidas desde hace dos 2 epochs atrás, lo que afectó a este epoch 218 y al anterior 217.
Cuando nuestro pool con 3M en stake no fué elegido en todo el epoch pasado para crear un bloque, saltaron todas las alarmas porque el protocolo no estaba asignando bloques al pool, tal como lo había hecho en epochs anteriores, cuando por cálculo matemático estaba previsto recibir al menos un bloque entre los 2 epochs.
Explicación del suceso
Las llaves KES permiten al pool estar “habilitado” para firmar bloques. Dicha llave, por cuestiones de seguridad (robo del pool, ataques, etc.), tiene proyectado un tiempo de vida acotado, la cual debe renovarse cada cierto período de tiempo.
El problema se produjo cuando renové las llaves hace 2 semanas. El proceso de registro se había completado con éxito, pero la parte del script que hacía la copia de los archivos entre el servidor que actualiza las llaves y ambos servidores de los pools no ejecutó el procedimiento correctamente, dando como resultado que los archivos no se actualizaron en los servidores de destino.
Esto produjo que los pools se quedaran sin llaves KES habilitadas, porque al registrar las nuevas llaves, pero no ingresarlas al servidor, los pools ya no contaban con ninguna llave habilitada. Fue el peor escenario, porque las llaves originales no estaban vencidas aún, y la renovación la realicé con bastante anticipación.
A su vez, como era la primera vez que corría esta actualización, nunca puse a prueba el script, pero confié en su funcionamiento. Así mismo, el problema se hubiese resuelto si desde el tablero de comandos hubiese recibido el aviso de este error. Pero desde Grafana eso tampoco sucedió, hasta que eliminé los módulos del KES y los creé nuevamente.
Remediación
El problema ha sido resuelto hace un día atrás, el pool ya está activo y habilitado, con un nuevo registro de llaves y con el proceso de copia manual de los archivos. A su vez, tomé varias decisiones.
Nuevo tablero de comandos
Por un lado, rehice completamente desde cero el panel de control de Grafana, en lugar de usar un template de un operador confiable, esta vez controlando cada indicador de manera precisa.
La realidad es que no es aceptable que teniendo tamaña infraestructura al alcance de no muchos operadores en la red, con:
- 2 pool + 5 relays en 3 continentes,
- más servidor de monitorización,
- más servidor para creación de los binarios y registro de los pools,
- más servidor para correr snapshot en frío,
- más backups recurrentes en caliente,
- más un servicio redundante VPS world class de Amazon con una tasa de transferencia súper potente,
al final el hilo se termine cortando por un comando y un indicador de tablero.
Nuevo script, con un mejor control de calidad
Para ello, he realizado un registro de un nuevo pool, uno de prueba, para hacer nuevos tests sobre el script que utilizaré para el registro y transferencia de archivos a futuro.
Situación del pool CAZ
Volviendo a la realidad que nos compete, estamos viendo la pérdida de stake por parte de delegantes, y es comprensible. Voy a tomar dos decisiones al respecto.
Por una lado resarcir a los delegantes distribuyendo el stake que el pool obtuvo como recompensas durante los epochs productivos pasados. Esto no tendrá que ver si el delegante se queda o se retira. Por cuestiones de responsabilidad profesional, llevaré a cabo este procedimiento. Daré cuenta del total de monedas a distribuir en otro comunicado.
Por otro lado, he meditado personalmente si continuar o no con la operatoria de pools, ya que este tipo de errores son difíciles de digerir. Sobre todo cuando llevo más de 9 meses operando pools de Cardano y dando soporte a la comunidad, y este error cuasi infantil me deja tocado. Es mucha la presión por no fallar, y creo que en cierto aspecto no se justifica.
Pero por otra parte, necesito que el pool CAZ siga adelante ya que es fundamental su existencia como fuente de ingresos para sostener el proyecto Cardano A-Z camino a la descentralización.
Está de más aclarar (pero lo aclaro) que este error fue humano, lo asumo como tal, asique nada que reprochar a IOHK con su monumental nodo de Cardano, una bestia sólida como una roca.
Para no extenderme demasiado, me disculpo abiertamente por lo sucedido, he fallado a la confianza de operación que ustedes me delegaron, y eso será difícil de reparar. Estoy enormemente agradecido por todo el apoyo de los que estuvieron, están y estarán.
P.D. para operadores: Querría alertar a los demás operadores que aún no tienen vencida su KES, que tengan enorme cuidado con esto. Y espero que mi error sirva para que ninguno pase por lo mismo. Hay veces que uno por creer que maneja una tecnología, puede tener todo controlado. Pero luego suceden estos imponderables. Ser operador no es una diversión de fin de semana. Ser operador significa no sólo conocer en profundidad sobre la operación de pools y su tecnología (y saberse promocionar, no?), sino que también requiere tomar la debida responsabilidad de procurar que todo funcione porque está en juego los ingresos de otras personas, los delegantes. Ser operador no es un chiste, ni es broma, y es una tarea que debe tomarse muy, pero muy en serio.