Skip to main content

Asegurando un Validador

Se anima a cada candidato a validador a operar de manera independiente, ya que configuraciones diversas aumentan la resistencia de la red. Los candidatos a validadores deben comenzar su fase de configuración ahora para estar a tiempo para el lanzamiento.

Gestión de Claves - HSM​

Es esencial que un atacante no pueda robar la clave de un validador. Si esto es posible, todo el stake delegado al validador comprometido estará en riesgo. Los módulos de seguridad de hardware son una estrategia importante para mitigar este riesgo.

Los módulos HSM deben soportar firmas ed25519 para el hub. El YubiHSM2 soporta ed25519 y esta librería 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.

El equipo de Tendermint también está trabajando en extender nuestra aplicación Ledger Nano S para soportar firmas de validadores. Esta aplicación puede almacenar bloques recientes y mitigar ataques de firmas dobles.

Actualizaremos esta página cuando haya más soluciones de almacenamiento de claves disponibles.

Tipos de Claves​

Hay dos tipos de claves:

  • Clave de Tendermint: Una clave única que se usa para firmar votos de consenso.
    • Está asociada con una clave pública mpvalconspub (Para obtener este valor, ejecute crossfid tendermint show-validator)
    • Se genera cuando el nodo se crea con crossfid init.
  • Clave de Aplicación: Esta clave se crea desde el binario crossfid y se usa para firmar transacciones. Las claves de aplicación están asociadas con una clave pública que tiene el prefijo cosmospub y una dirección que tiene el prefijo cosmos.

La clave de Tendermint y la clave de aplicación se derivan de las claves de cuenta generadas por el comando crossfid keys add.

Nota: La clave de operador de un validador está directamente ligada a una clave de aplicación y utiliza los prefijos mpvaloper y mpvaloperpub que están reservados exclusivamente para este propósito.

Nodos Centinela (Protección DDOS)​

Los validadores son responsables de garantizar que la red pueda soportar 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 de nodos centinela.

Los nodos de validación deben conectarse solo a nodos completos en los que confían porque los operan ellos mismos o son ejecutados por otros validadores que conocen socialmente. Un nodo de validación normalmente 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 la nube. El validador puede usar esos enlaces para conectarse a los nodos centinela en la nube. Esto transfiere la carga de la denegación de servicio directamente del nodo del validador a sus nodos centinela y puede requerir que se generen o activen nuevos nodos centinela para mitigar ataques en los existentes.

Los nodos centinela se pueden generar rápidamente o cambiar sus direcciones IP. Dado que los enlaces a los nodos centinela están en espacio IP privado, un ataque basado en Internet no puede perturbarlos directamente. Esto asegurará que las propuestas y votaciones de bloques del validador siempre lleguen al resto de la red.

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

Los nodos del validador deben editar su config.toml:


# Lista separada por comas de nodos para mantener conexiones persistentes

# No agregue peers privados a esta lista si no desea anunciarlos
persistent_peers =[lista de nodos centinelas]

# Establece en true para habilitar el reactor de intercambio de peers
pex = false

Los Nodos Centinelas deben editar su config.toml:


# Lista separada por comas de IDs de peers para mantener privados (no serán anunciados a otros peers)

# ID de ejemplo: 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 evitar que el servidor en la dirección IP se conecte a internet.

Un atacante escanea la red, intenta aprender la dirección IP de varios nodos de validación 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 nodos centinela.

Se espera que los nodos de validación se conecten solo a nodos completos en los que confían porque operan los nodos completos ellos mismos o los nodos completos de confianza son ejecutados por otros validadores que conocen socialmente. Un nodo de validación normalmente 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 la nube. El validador puede usar esos enlaces para conectarse a nodos centinela en la nube. Esta mitigación transfiere la carga de la denegación de servicio directamente del nodo del validador a sus nodos centinela y puede requerir que se generen o activen nuevos nodos centinela para mitigar ataques en los existentes.

Los nodos centinela se pueden generar 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 y votaciones de bloques del validador tengan una mayor probabilidad de llegar al resto de la red.

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