Saltar al contenido principal

Configuración del nodo BOT Chain: mejores prácticas

Especificaciones de hardware​

Para garantizar un rendimiento y una confiabilidad óptimos, es crucial seleccionar el tipo de nodo apropiado según sus requisitos específicos para el procesamiento de transacciones y la consulta de estado en el BOT Chain.

Archivo y guía de implementación de nodo completo​

  1. Clone el repositorio y acceda al directorio

  2. bash

git clone https://github.com/bl-BOHR/node-deploy.git && cd node-deploy

  1. Otorgar permisos de ejecución (solo se requiere la primera vez en Linux)

  2. bash

chmod +x BOHR_full_node.sh BOHR_archive_node.sh bin/geth*

  1. Inicializar e iniciar el nodo

    • Nodo completo:

    • bash

    ./BOHR_full_node.sh reset

    • Nodo de archivo:

    • bash

    ./BOHR_archive_node.sh reset

  2. Ver registros Los registros de nodo se encuentran en: .local/fullnode/node/BOHR-node.log Para los usuarios que requieren acceso al estado mundial más reciente en un modo liviano, el nodo rápido es la opción ideal. Exige menos de la CPU y del espacio en disco de su sistema.

Configuración recomendada​

Para un acceso completo a todo el estado mundial histórico de la red principal BOT, considere implementar un nodo de archivo. Las instrucciones detalladas están disponibles en el repositorio de GitHub BOT Chain. (Aquí se requiere un enlace externo a nuestro repositorio).

  • Procesador: CPU de 2 núcleos mínimo.

  • Memoria: Al menos 4 GB de RAM.

  • Almacenamiento: Unidad de estado sólido (SSD) con una capacidad mínima de 128 GB.

  • Red: Conexión a Internet estable y de alta velocidad, mínimo 1 MBps.

Nodo de archivo​

Para obtener el último estado mundial y verificar la validez del estado o generar pruebas de datos, un Nodo Completo estándar es adecuado.

  • Procesador: CPU mínima de 4 núcleos.

  • Memoria: Al menos 8 GB de RAM.

  • Almacenamiento: SSD con una capacidad mínima de 1 TB (se recomiendan NVME SSD para un rendimiento óptimo).

  • Red: Conexión a Internet estable y de alta velocidad, mínimo 2 MBps.

Nodo completo​

Los activos más valiosos de un validador son dos claves: una para firmar transacciones y otra para firmar bloques.

  • Procesador: CPU mínima de 4 núcleos.

  • Memoria: Al menos 8 GB de RAM.

  • Almacenamiento: Unidad de estado sólido (SSD) con una capacidad mínima de 1TB.

  • Red: Conexión a Internet estable y de alta velocidad, mínimo 2 MBps.

Configuración de pares​

Red principal​

  • No es necesario especificar nodos estáticos, solo se requieren nodos de arranque para la red principal que ya están configurados en el código. Además, asegúrese de utilizar el archivo config.toml de la última versión.

Red de prueba​

  • Red de prueba aún necesita configurar los StaticNodes manualmente y, por lo tanto, la lista de StaticNodes está contenida en el archivo config.toml de la última versión.

Solución de problemas sin pares en red de prueba​

  • Compruebe si hay problemas de configuración como ID de cadena incorrecta, archivo/directorio de configuración incorrecto.

  • Asegúrese de actualizar el archivo config.toml según la última versión

  • No utilice nodos de arranque en red de prueba, no es necesario.

  • Eliminar el archivo/dir geth/nodes y geth/nodekey puede resultar útil

  • Vuelve a descargar la instantánea e inténtalo de nuevo.

Almacene su BOT con una billetera de hardware​

No exponga sus puntos finales RPC a redes públicas.

Proteger su nodo completo RPC de los piratas informáticos​

Para proteger tu BOT, no compartas tus 24 palabras con nadie. La única persona que debería necesitar conocerlas eres tú. En resumen, los HSM son piezas de hardware portátiles, asequibles y de alto rendimiento que ayudan a generar, almacenar y administrar de forma segura sus claves privadas. Los ataques de malware y la extracción remota de claves privadas son mucho más difíciles cuando un HSM está configurado correctamente.

Claves privadas de la cuenta​

Para proteger tu BOT, solo debes descargar software directamente de fuentes oficiales y asegurarte de usar siempre la versión más reciente y segura.

Vulnerabilidades de software​

Es importante mantener geth funcionando en todo momento. Hay varias formas de lograr esto, y la solución más simple que recomendamos es registrar geth como un servicio systemd para que se inicie automáticamente al reiniciar el sistema y en otros eventos.

Ejecutar el servidor como una Daemon​

Después de ejecutarse (sincronizarse) durante un largo período de tiempo y finalizar abruptamente, se espera que solo los nodos archivados se vuelvan a sincronizar rápidamente al reiniciar.

Configurar un nodo de respaldo​

  • Ejecute el nodo validador en modo archivo

  • Apague los nodos con gracia

  • Utiliza herramientas para monitoreo activo

Pasos para ejecutar un nodo de respaldo​

  1. Instale la última versión de geth

  2. Sincroniza con la última altura usando el modo de sincronización rápida. Puede descargar la última instantánea o iniciar la sincronización rápida una vez que su nodo esté completamente sincronizado.

  3. Cierra tu nodo con gracia y mata -HUP $(pgrep geth)

  4. Reinicia tu nodo.

Why Node will be Offline for a While After Restart? or What will Happen If the Client is Force Killed?​

Pasos para reproducir:

Razones

  • Ejecute el nodo sincronizado durante un período de tiempo.

  • Termina abruptamente el nodo (kill -9 o fallo el sistema).

  • Reinicie el nodo, observe dónde se resincroniza desde la altura del bloque de hace 1 hora.

Si Geth falla (o no se cierra correctamente), el estado reciente mantenido en la memoria se pierde y debe regenerarse. Se necesita Geth mucho tiempo para restaurar los estados.

La razón fundamental es que geth limpia el estado try periódicamente. El período se define como trieTimeout en config.toml.

Puede dejar de minar nuevos bloques enviando comandos a la consola de geth

¿Cómo actualizar un nodo de respaldo a un nodo validador?​

Conéctese a su nodo validador con geth Attach ipc:path/to/geth.ipc

Luego, deje que el nodo de respaldo reanude la validación.

miner.stop()

Se anima a cada candidato a validador a ejecutar sus operaciones de forma independiente, ya que las diversas configuraciones aumentan la resiliencia de la red. Debido a la gran cantidad invertida por los validadores, es muy importante protegerlos contra diferentes ataques DoS y DDoS. En esta sección, analizamos el mecanismo de seguridad adoptado por BOT Chain para sus validadores.

miner.start()

Asegurando la seguridad de los validadores​

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 la denominada arquitectura de nodo centinela. Los nodos centinela se pueden activar rápidamente o cambiar sus direcciones IP. Debido a que los enlaces a los nodos centinela se encuentran en un espacio IP privado, un ataque basado en Internet no puede perturbarlos directamente. Esto garantizará que los validadores bloqueen las propuestas y que los votos siempre lleguen al resto de la red.

Nodos centinela (protección DDOS)​

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

No exponga los puntos finales de su validador de nodo completo RPC a la red pública.

  1. Construya una red privada y configure conexiones privadas confiables entre el nodo validador y su centinela

Instala tu nodo completo

En la consola del nodo centinela, ejecute admin.nodeInfo.enode. Debería obtener algo similar a esto.

  1. Establecer centinela como pares para el nodo validador

!!! Nota: [::] se analizará como localhost (127.0.0.1). Si sus nodos están en una red local, verifique cada máquina host individual y encuentre su IP con ifconfig. Si sus pares no están en la red local, necesita conocer su dirección IP externa (use un servicio) para construir la URL del enodo. Copie este valor y en la consola de la primera ejecución del nodo,

enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[::]:30306?discport=0

Actualizar el archivo config.toml del nodo validador

Esto devolverá verdadero si tiene éxito, pero eso no significa que el nodo se haya agregado correctamente.

# make node invisible
NoDiscovery = true
# connect only to sentry
StaticNodes = ["enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[10.1.1.1]:30306"]

Para confirmar, ejecute admin.peers y debería ver los detalles del nodo que acaba de agregar.

De esa manera, su nodo validador intentará conectarse únicamente con los nodos centinela proporcionados.

Para confirmar, ejecute admin.peers y debería ver los detalles del nodo que acaba de agregar.

  1. Confirma la conexión

geth utiliza varios puertos TCP para diferentes propósitos.

Configuración del cortafuegos​

geth usa un puerto de escucha (TCP) y un puerto de descubrimiento (UDP), ambos en 31000 de forma predeterminada.

Si necesita ejecutar JSON-RPC, también necesitará el puerto TCP 8545. Tenga en cuenta que el puerto JSON-RPC no debe abrirse al mundo exterior, porque desde allí puede realizar operaciones de administración.

If you need to run JSON-RPC, you'll also need TCP port 8545. Note that JSON-RPC port should not be opened to the outside world, because from there you can do admin operations.