Generar claves y certificado de operación del Stake Pool

El Stake Pool necesita tres pares de claves, a saber:

  • Node (Cold) Keys: Son las claves del nodo propiamente dicho. A menudo también se les llama Cold Keys por la importancia de ser mantenidas siempre almacenadas en un entorno frío, es decir, fuera del alcance de una conexión a internet, ya que con estas claves se puede obtener el control del Stake Pool. Idealmente, cualquier uso de estas claves debería hacerse en una máquina desconectada de internet, copiando posteriormente los archivos generados al nodo.
  • VRF Keys (Verification Random Function Keys): Son las claves que nos permitirán participar en el procedimiento de Staking.
  • KES Keys (Key Evolving Signature Keys): Claves que van cambiando cada cierto periodo de tiempo para evitar que alguien pueda hacer trampas introduciendo bifurcaciones en la cadena de bloques a partir de bloques anteriores.

Además de estos pares de claves necesitaremos generar un Certificado Operacional

  • Claves del Nodo (Cold)

cardano-cli node key-gen \
    --cold-verification-key-file node.vkey \
    --cold-signing-key-file node.skey \
    --operational-certificate-issue-counter node.counter
  • Claves VRF

cardano-cli node key-gen-VRF \
    --verification-key-file vrf.vkey \
    --signing-key-file vrf.skey
  • Claves KES

cardano-cli node key-gen-KES \
    --verification-key-file kes.vkey \
    --signing-key-file kes.skey

Como vemos, estos tres pares de claves se generan de la nada, es decir, no necesitan ningún archivo previo y su creación no reviste ninguna dificultad. Cada par de claves, como es habitual, consta de una clave de firma (skey) y una clave de verificación (vkey).

  • Certificado operacional

Este certificado es el que nos permitirá ejecutar nuestro nodo de manera que sea candidato para firmar bloques. Para generar este archivo sí que necesitamos contar con algo de información previa, tanto del protocolo como del estado actual de la cadena de bloques. Concretamente, necesitamos saber el nº de periodo KES en el que nos encontramos, y para ello debemos dividir el nº del Slot actual por el nº de slots por periodo

Consultamos el nº de slot por periodo KES a partir de los archivos de información:

cat testnet-shelley-genesis.json | grep KES

"slotsPerKESPeriod": 129600,
"maxKESEvolutions": 62,

De esta salida nos interesa el primer parámetro, en nuestro caso: 129600

Y consultamos el slot actual (con el nodo completamente sincronizado)

 cardano-cli query tip --testnet-magic $MAGIC_NUM
{
    "epoch": 166,
    "hash": "b7331f9a6ec5de5871a74d02807d3fe811cd3f03258cd7542e6002cba592f310",
    "slot": 41772106,
    "block": 3049366,
    "era": "Alonzo",
    "syncProgress": "100.00"
}

Entonces, dividiento slot / slotsPerKESPeriod

expr 41772106 / 129600
322

Que será el nº de periodo KES a partir del cual será válido nuestro certificado. Con este dato ejecutamos:

cardano-cli node issue-op-cert \
    --kes-verification-key-file kes.vkey \
    --cold-signing-key-file node.skey \
    --operational-certificate-issue-counter node.counter \
    --kes-period 322 \
    --out-file node.cert

Y obtenemos el certificado operacional del nodo. Con este archivo ya podemos ejecutar nuestro nodo activamente, es decir, participando en la firma de bloques.

Como medida de seguridad, las claves dejan de ser válidas tras un periodo de 90 días, por lo que tienen que ser regeneradas antes de ese plazo para que el pool siga operando. El proceso es tan sencillo como generar un nuevo par de claves KES y crear otro certificado operacional a partir de la nueva kes.vkey. Despues, basta con reiniciar el productor de bloques y el nodo ya se ejecutará con el nuevo certificado.

Deja una respuesta