Asegurar un Validador

Se recomienda a cada candidato a validador ejecutar sus operaciones de forma independiente, ya que las configuraciones diversas aumentan la resistencia de la red. Los candidatos a validador deben comenzar su fase de configuración ahora para estar a tiempo para el lanzamiento.

Gestión de Claves - Carteras de Hardware y HSM

Es de misión crítica que un atacante no pueda robar la clave de un validador. Si esto es posible, pone en riesgo toda la participación delegada al validador comprometido. Los módulos de seguridad de hardware y las carteras de hardware son estrategias importantes para mitigar este riesgo.

Requisitos de Cartera de Hardware

Las carteras de hardware (como los dispositivos Ledger) proporcionan almacenamiento seguro de claves donde:

• Las claves privadas se generan y almacenan en hardware cifrado
• La firma de transacciones ocurre dentro del dispositivo
• Las claves privadas nunca salen de la cartera de hardware
• Una frase mnemónica de 24 palabras controla el acceso a todas las claves

Limitaciones Importantes

• No se pueden migrar validadores existentes: La integración de cartera de hardware solo es posible al crear nuevos validadores
• El respaldo es crítico: La pérdida de la frase mnemónica resulta en la pérdida permanente del control del validador
• Almacenamiento offline requerido: Almacene las frases mnemónicas de forma segura offline en múltiples ubicaciones

Soporte HSM

Los módulos HSM deben soportar firmas ed25519 para CrossFi Chain. El YubiHSM2 soporta ed25519 y esta biblioteca yubikey está disponible. El YubiHSM puede proteger una clave privada pero no puede asegurar en un entorno seguro que no firmará el mismo bloque dos veces.

Integración con Ledger

Los dispositivos Ledger soportan operaciones de validador de CrossFi a través de la aplicación Cosmos. La aplicación Ledger puede almacenar bloques recientes y ayuda a mitigar ataques de doble firma.

Operaciones Soportadas:

• Gestión de claves de cuenta (operaciones de validador, recompensas, delegación)
• Firma de transacciones con confirmación de hardware
• Verificación de direcciones en el dispositivo

Para instrucciones detalladas de configuración, consulte la Guía de Configuración de Cartera de Hardware a continuación.

Tipos de Claves

Los validadores de CrossFi utilizan dos tipos distintos de claves privadas, cada una sirviendo diferentes propósitos:

Clave de Cuenta (Clave de Operador del Validador)

• Propósito: Controla la cuenta del validador para tareas operativas
• Uso:
  • Recibir recompensas de staking y comisiones
  • Actualizar información del validador (descripción, tasa de comisión)
  • Operaciones de auto-delegación y des-delegación
  • Votación de gobernanza del validador
• Almacenamiento: Puede almacenarse en carteras de hardware (Ledger) para mayor seguridad
• Prefijo: Usa prefijos mpvaloper y mpvaloperpub
• Creación: Generada con crossfid keys add <nombre> --ledger para integración de cartera de hardware

Clave de Consenso (Clave Tendermint)

• Propósito: Utilizada por Tendermint/CometBFT para firmar bloques y votos de consenso
• Uso:
  • Firma de propuestas de bloque
  • Firma de prevote y precommit en rondas de consenso
  • Debe estar disponible 24/7 para la producción continua de bloques
• Almacenamiento: Almacenada en el archivo priv_validator.json por defecto
• Prefijo: Asociada con la clave pública mpvalconspub
• Seguridad: Puede aislarse usando Tendermint KMS para mayor protección
• Creación: Generada automáticamente cuando el nodo se inicializa con crossfid init

Advertencia Crítica de Seguridad

• Nunca copie priv_validator.json entre múltiples nodos - esto causará doble firma y resultará en slashing
• No se pueden migrar claves existentes a carteras de hardware - solo es posible para nuevos validadores
• Respalde ambos tipos de claves de forma segura y por separado

Relación de Claves: Ambas claves son esenciales para las operaciones del validador pero sirven funciones completamente diferentes. La clave de cuenta gestiona la entidad del validador, mientras que la clave de consenso maneja el proceso real de firma de bloques.

Nodos Centinela (Protección DDOS)

Los validadores son responsables de asegurar que la red pueda sostener ataques de denegación de servicio.

Una forma recomendada de mitigar estos riesgos es que los validadores estructuren cuidadosamente su topología de red en una arquitectura llamada de nodo centinela.

Los nodos validadores deben conectarse solo a nodos completos de confianza porque los operan ellos mismos o son ejecutados por otros validadores que conocen socialmente. Un nodo validador típicamente se ejecuta en un centro de datos. La mayoría de los centros de datos proporcionan enlaces directos a las redes de los principales proveedores de nube. El validador puede usar esos enlaces para conectarse a nodos centinela en la nube. Esto desplaza la carga de denegación de servicio del nodo del validador directamente a sus nodos centinela, y puede requerir que se activen nuevos nodos centinela o se activen para mitigar ataques en los existentes.

Los nodos centinela pueden activarse rápidamente o cambiar sus direcciones IP. Debido a que los enlaces a los nodos centinela están en espacio IP privado, un atacante basado en internet no puede perturbarlos directamente. Esto asegurará que las propuestas de bloque y votos del validador siempre lleguen al resto de la red.

Para configurar su arquitectura de nodo centinela puede seguir las instrucciones a continuación:

Los nodos validadores deben editar su config.toml:

# Lista separada por comas de nodos para mantener conexiones persistentes

# No agregue pares privados a esta lista si no quiere que se anuncien
persistent_peers =[lista de nodos centinela]

# Establecer en true para habilitar el reactor de intercambio de pares
pex = false

Los Nodos Centinela deben editar su config.toml:

# Lista separada por comas de IDs de pares para mantener privados (no se compartirán con otros pares)

# Ejemplo de ID: 3e16af0cead27979e1fc3dac57d03df3c7a77acc@3.87.179.235:26656

private_peer_ids = "node_ids_of_private_peers"

¿Cómo pueden los validadores protegerse de ataques de denegación de servicio?

Los ataques de denegación de servicio ocurren cuando un atacante envía una avalancha de tráfico de internet a una dirección IP para prevenir que el servidor en esa dirección IP se conecte a internet.

Un atacante escanea la red, trata de aprender la dirección IP de varios nodos validadores, y los desconecta de la comunicación inundándolos con tráfico.

Una forma recomendada de mitigar estos riesgos es que los validadores estructuren cuidadosamente su topología de red usando una arquitectura de nodo centinela.

Se espera que los nodos validadores se conecten solo a nodos completos de confianza porque operan los nodos completos ellos mismos o los nodos completos de confianza son ejecutados por otros validadores que conocen socialmente. Un nodo validador típicamente se ejecuta en un centro de datos. La mayoría de los centros de datos proporcionan enlaces directos a las redes de los principales proveedores de nube. El validador puede usar esos enlaces para conectarse a nodos centinela en la nube. Esta mitigación desplaza la carga de denegación de servicio del nodo del validador directamente a sus nodos centinela, y puede requerir que se activen nuevos nodos centinela o se activen para mitigar ataques en los existentes.

Los nodos centinela pueden activarse rápidamente o cambiar sus direcciones IP. Debido a que los enlaces a los nodos centinela están en espacio IP privado, un ataque basado en internet no puede perturbarlos directamente. Esta estrategia asegura que las propuestas de bloque y votos del validador tengan una posibilidad mucho mayor de llegar al resto de la red.

Para más detalles sobre nodos centinela, consulte la Documentación de Tendermint o la Descripción General de la Arquitectura de Nodo Centinela en el foro.

Guía de Configuración de Cartera de Hardware

Configuración de Cartera de Hardware Ledger

Esta sección proporciona instrucciones paso a paso para configurar un dispositivo Ledger para operaciones de validador de CrossFi.

Requisitos Previos

• Dispositivo Ledger Nano S, Nano S Plus, o Nano X
• Computadora con conexión USB
• Última versión de la aplicación Ledger Live
• Daemon de CrossFi (crossfid) compilado con soporte Ledger

Paso 1: Preparar su Dispositivo Ledger

Instalar Ledger Live

• Descargue e instale Ledger Live desde el sitio web oficial: https://www.ledger.com/ledger-live
• Conecte su dispositivo Ledger y actualice el firmware a través de Ledger Live a la última versión.

Instalar Aplicación Cosmos

• En Ledger Live:
  • Navegue a la sección Manager
  • Conecte y desbloquee su dispositivo Ledger
  • Busque la aplicación "Cosmos"
  • Haga clic en Install para agregar la aplicación Cosmos a su dispositivo
  • Nota: Es posible que necesite habilitar el Modo Desarrollador en la configuración de Ledger Live si la aplicación Cosmos no es visible.

Inicializar o Restaurar Frase Semilla

• Para dispositivos nuevos:
  • Siga la configuración del dispositivo para generar una nueva frase de recuperación de 24 palabras
  • Escriba todas las 24 palabras en el orden exacto mostrado
  • Verifique la frase ingresando las palabras solicitadas
• Para dispositivos existentes:
  • Use su frase de recuperación existente si ya tiene una
  • Asegúrese de tener respaldos seguros offline de la frase
• ⚠️ Crítico: ¡Almacene su frase de recuperación en múltiples ubicaciones seguras offline. La pérdida de esta frase significa la pérdida permanente de su validador!

Paso 2: Crear Cuenta de Validador con Ledger

Verificar Configuración del Daemon CrossFi

• Asegúrese de que su binario crossfid esté compilado con soporte Ledger:

  crossfid version --long
• La salida debe incluir soporte Ledger en las etiquetas de compilación.

Conectar y Desbloquear Ledger

• Conecte su dispositivo Ledger a su computadora y:
  • Ingrese su PIN para desbloquear el dispositivo
  • Navegue y abra la aplicación Cosmos
  • La pantalla debe mostrar "Cosmos ready"

Crear Clave de Validador

• Cree una nueva clave usando el dispositivo Ledger:

  crossfid keys add <nombre-validador> --ledger
• Reemplace <nombre-validador> con su identificador de validador elegido.
• El comando:
  • Le pedirá confirmar la operación en su dispositivo Ledger
  • Mostrará la dirección del validador y la clave pública
  • Almacenará la referencia de la clave en su llavero local

Verificar Dirección en Dispositivo

• Siempre verifique que la dirección coincida con lo que se muestra en su Ledger:

  crossfid keys show <nombre-validador> -d
• Este comando:
  • Mostrará la dirección en su terminal
  • Pedirá verificación de dirección en su dispositivo Ledger
  • Requerirá que confirme la dirección en la pantalla del dispositivo
• Siempre verifique que las direcciones coincidan antes de proceder con cualquier transacción.

Paso 3: Mejores Prácticas de Seguridad

🔐 Seguridad Mnemónica

• Almacenar frases de recuperación solo offline
• Usar múltiples ubicaciones seguras
• Nunca compartir con nadie
• Considerar soluciones de respaldo en metal
• Probar proceso de recuperación en dispositivo de repuesto

🔄 Seguridad Operativa

• Siempre verificar direcciones en dispositivo
• Mantener firmware de Ledger actualizado
• Usar PIN único del dispositivo
• Habilitar tiempo de espera de auto-bloqueo
• Monitorear actualizaciones de firmware

Integración con Tendermint KMS

Para mayor seguridad de su clave de consenso (la clave utilizada para firma de bloques), considere usar el Sistema de Gestión de Claves de Tendermint (KMS).

¿Qué es Tendermint KMS?

Tendermint KMS (tmkms) es un servicio de gestión de claves que:

• Aísla las claves de consenso de los nodos validadores
• Previene la doble firma a través del seguimiento de estado
• Soporta módulos de seguridad de hardware (HSM)
• Proporciona alta disponibilidad a través de redundancia
• Se ejecuta en un servidor separado para mayor seguridad

Descripción General de Configuración KMS

Instalar Dependencias

• Instale las dependencias requeridas para la compilación de KMS:

  # Ubuntu/Debian
  sudo apt update
  sudo apt install -y gcc clang pkg-config libusb-1.0-0-dev
  
  # Instalar Rust
  curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
  source ~/.cargo/env

Instalar Tendermint KMS

• Instale KMS con soporte Ledger:

  # Para soporte Ledger
  cargo install tmkms --features=ledger
  
  # Para soporte YubiHSM2
  cargo install tmkms --features=yubihsm
  
  # Verificar instalación
  tmkms --help

Inicializar Configuración KMS

• Cree directorio de configuración KMS y archivos:

  tmkms init /path/to/kms/home
• Esto crea:
  • tmkms.toml - Archivo de configuración principal
  • kms-identity.key - Clave de identidad KMS
  • secrets/ - Directorio para almacenamiento de claves
  • state/ - Directorio para estado de consenso

Configurar e Iniciar KMS

• Edite el archivo de configuración tmkms.toml para:
  • Especificar su dispositivo de hardware (Ledger/YubiHSM)
  • Configurar ajustes de conexión del validador
  • Establecer rutas de derivación de claves
• Iniciar el servicio KMS:

  tmkms start -c /path/to/kms/home/tmkms.toml

Configuración de Nodo para KMS

Para usar KMS con su nodo validador de CrossFi, actualice su config.toml:

# En ~/.crossfi/config/config.toml
[priv_validator]
# Dirección de socket TCP o UNIX para que Tendermint escuche
# conexiones de un proceso externo PrivValidator
laddr = "tcp://127.0.0.1:26658"

# Ruta al archivo JSON que contiene la clave privada para usar como validador
key_file = ""

# Ruta al archivo JSON que contiene el último estado de firma de un validador
state_file = ""

Recursos Adicionales

Para ejemplos detallados de configuración KMS y configuraciones avanzadas, consulte:

• Documentación de Tendermint KMS
• Guía KMS de Cosmos Hub

Crear un Nuevo Validador con Cartera de Hardware

Una vez que haya configurado su cartera de hardware y opcionalmente configurado KMS, siga estos pasos para crear su validador:

Financiar su Cuenta de Validador

• Envíe tokens XFI a su dirección de cartera de hardware:

  # Obtener su dirección de validador
  crossfid keys show <nombre-validador> --address
  
  # Necesitará suficiente XFI para:
  # - Auto-delegación mínima (verificar requisitos actuales)
  # - Tasas de transacción para creación de validador
  # - Costos operativos continuos

Sincronizar su Nodo

• Asegúrese de que su nodo validador esté completamente sincronizado antes de crear el validador:

  # Verificar estado de sincronización
  crossfid status | jq .SyncInfo.catching_up
  
  # Esperar hasta que catching_up muestre "false"

Crear Transacción de Validador

• Cree su validador usando la cartera de hardware:

  crossfid tx staking create-validator \
    --amount=<cantidad-stake>xfi \
    --pubkey=$(crossfid tendermint show-validator) \
    --moniker="<nombre-validador>" \
    --chain-id=<chain-id> \
    --commission-rate="0.05" \
    --commission-max-rate="0.20" \
    --commission-max-change-rate="0.01" \
    --min-self-delegation="1000000" \
    --gas="auto" \
    --gas-prices="0.025xfi" \
    --from=<nombre-validador>
• ⚠️ Importante: Necesitará confirmar esta transacción en su dispositivo Ledger.

Verificar Creación de Validador

• Verifique que su validador fue creado exitosamente:

  # Encontrar su validador
  crossfid query staking validators | grep -A 10 -B 10 "<nombre-validador>"
  
  # Verificar estado de su validador
  crossfid query staking validator $(crossfid keys show <nombre-validador> --bech val -a)

Consejo Profesional

Para mayor seguridad y operaciones automatizadas, considere configurar Cosmovisor con systemd para gestión automática de nodos y actualizaciones.