Consenso

Establecer un nodo de consenso completo de Celestia​

Esta guía cubre cómo configurar un nodo de consenso completo o un nodo validador en Celestia. Los nodos de consenso completos le permiten sincronizar el historial de blockchain en la capa de consenso de Celestia.

nodo de consenso completo

• Requisitos de hardware
• Configuración de un nodo de consenso completo

  • Configurar las dependencias
  • Instalar celestia-app
  • Configurar las redes P2P
• Configuraciones de almacenamiento y poda

  • Conectar un nodo de consenso a un nodo puente
  • Consulta de transacciones por hash
  • Acceso al estado histórico
  • Ahorro en los requisitos de almacenamiento
• Sincronización

  • Sincronización de estado
  • Sincronización rápida
• Inicie el nodo de consenso
• Opcional: Configuración de un validador

  • Configuración de un nodo validador Celestia
  • Opcional: Implementar el nodo celestia
  • Ejecute el nodo validador
  • Envíe su información de validador
• Recursos adicionales para nodos de consenso

  • Opcional: Restablecer red
  • Opcional: Configuración de un punto final RPC
  • Opcional: Opciones de configuración del indexador de transacciones
  • Opcional: Descarte la configuración de respuestas ABCI

Requisitos de hardware​

Se recomiendan los siguientes requisitos mínimos de hardware para ejecutar un nodo de consenso completo:

• Memoria: 8 GB RAM

• CPU: Quad-Core

• Disco: Almacenamiento SSD de 250 GB

• Ancho de banda: 1 Gbps para Descargar/1 Gbps para Cargar

Ejecutar un nodo de consenso completo requiere una capacidad de almacenamiento significativa para almacenar todo el historial de blockchain. A partir de la última recomendación, es aconsejable tener al menos 250 GB de almacenamiento SSD para un nodo de consenso completo de Celestia si está utilizando la poda. Si no está utilizando la poda, está ejecutando un nodo de archivo y se recomienda tener 500 GB de almacenamiento SSD. Asegúrese de que su almacenamiento cumpla con este requisito para garantizar una sincronización y operación sin problemas del nodo.

Configuración de un nodo de consenso completo​

El siguiente tutorial se realiza en una máquina de instancia Ubuntu Linux 20.04 (LTS) x64.

Configurar las dependencias​

Siga las instrucciones en instalación de dependencias.

Instalar celestia-app​

Sigue el tutorial sobre instalación celestia-app.

Configurar las redes P2P​

Ahora configuraremos las redes P2P clonando el repositorio de redes:

sh

cd $HOME
rm -rf networks
git clone https://github.com/celestiaorg/networks.git

Para inicializar la red, elija un "nombre de nodo" que describa su nodo. Tenga en cuenta que esto podría cambiar si se implementa una nueva red de prueba.

Mainnet BetaMochaArábicabash

celestia-appd init "node-name" --chain-id celestia

Descargar el genesis.json archivo:

Mainnet BetaMochaArábicabash

celestia-appd download-genesis celestia

Pon semillas en el $HOME/.celestia-app/config/config.toml archivo:

Mainnet BetaMochaArábicabash

SEEDS=$(curl -sL https://raw.githubusercontent.com/celestiaorg/networks/master/celestia/seeds.txt | tr '\n' ',')
echo $SEEDS
sed -i.bak -e "s/^seeds *=.*/seeds = \"$SEEDS\"/" $HOME/.celestia-app/config/config.toml

Opcionalmente, puede establecer pares persistentes en su config.toml archivo. Puede obtener los pares persistentes del repositorio de redes con los siguientes comandos:

Se recomienda establecer pares persistentes solo si está ejecutando un nodo centinela.

Mainnet BetaMochaArábicabash

PERSISTENT_PEERS=$(curl -sL https://raw.githubusercontent.com/celestiaorg/networks/master/celestia/peers.txt | tr '\n' ',')
echo $PERSISTENT_PEERS
sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"/" $HOME/.celestia-app/config/config.toml

Configuraciones de almacenamiento y poda​

Conectar un nodo de consenso a un nodo puente​

Si su nodo de consenso está conectado a un nodo puente celestia-node, deberá habilitar la indexación de transacciones y retener todos los datos de bloque. Esto se puede lograr con la siguiente configuración en su config.toml.

Habilitar indexación de transacciones​

toml

indexer = "kv"

Conservar todos los datos de bloque​

Y en tu app.toml, min-retain-blocks debe permanecer como la configuración predeterminada de 0:

toml

min-retain-blocks = 0 # retain all block data, this is default setting

Consulta de transacciones por hash​

Si desea consultar transacciones utilizando su hash, la indexación de transacciones debe estar activada. Establecer el indexer a "kv" en tu config.toml:

toml

indexer = "kv"

Acceso al estado histórico​

Si desea consultar el estado histórico — por ejemplo, es posible que desee conocer el saldo de una billetera Celestia a una altura determinada en el pasado — con la que debe ejecutar un nodo de archivo pruning = "nothing" en tu app.toml. Tenga en cuenta que esta configuración requiere muchos recursos y requerirá un almacenamiento significativo:

toml

pruning = "nothing"

Ahorro en los requisitos de almacenamiento​

Si desea ahorrar en los requisitos de almacenamiento, considere usar pruning = "everything" en tu app.toml para podar todo. Si selecciona "everything" o "default", pero aún desea mantener los datos de bloque, puede hacerlo al no cambiar el valor predeterminado de min-retain-blocks = 0 en tu app.toml. Un valor de 0 para min-retain-blocks mantendrá todos los datos de bloque. Esto podará las instantáneas del estado, pero mantendrá los datos de bloque:

toml

pruning = "everything"
min-retain-blocks = 0 # this is the default setting

Sincronización​

De forma predeterminada, un nodo de consenso se sincronizará utilizando la sincronización de bloques; es decir, solicitar, validar y ejecutar cada bloque hasta la cabecera de la cadena de bloques. Este es el mecanismo más seguro hasta ahora el más lento (tomando hasta días dependiendo de la altura de la cadena de bloques).

Hay dos alternativas para una sincronización más rápida.

Sincronización de estado​

La sincronización de estado utiliza la verificación del cliente ligero para verificar las instantáneas de estado de los pares y luego aplicarlas. La sincronización de estado se basa en una subjetividad débil; se debe proporcionar un encabezado confiable (específicamente el hash y la altura). Esto se puede encontrar consultando un punto final de RPC de confianza (/bloque). También se requieren puntos finales RPC para recuperar bloques de luz. Estos se pueden encontrar en los documentos aquí bajo las respectivas redes o desde el registro de la cadena.

En $HOME/.celestia-app/config/config.toml, conjunto

toml

rpc_servers = ""
trust_height = 0
trust_hash = ""

a sus respectivos campos. Se deben proporcionar al menos dos puntos finales de rpc diferentes. Cuanto más, mayor es la posibilidad de detectar cualquier comportamiento fraudulento.

Una vez configurado, debe estar listo para iniciar el nodo de forma normal. En los registros, deberías ver: Discovering snapshots. Esto puede tomar unos minutos antes de que se encuentren instantáneas dependiendo de la topología de la red.

Sincronización rápida​

La sincronización rápida descarga efectivamente todo data directorio de un proveedor externo, lo que significa que el nodo tiene todo el estado de la aplicación y la cadena de bloques como el nodo del que se copió.

Ejecute el siguiente comando para sincronizar rápidamente desde una instantánea:

Mainnet BetaMochaArábicabash

cd $HOME
rm -rf ~/.celestia-app/data
mkdir -p ~/.celestia-app/data
SNAP_NAME=$(curl -s https://snaps.qubelabs.io/celestia/ | \
    egrep -o ">celestia.*tar" | tr -d ">")
aria2c -x 16 -s 16 -o celestia-snap.tar "https://snaps.qubelabs.io/celestia/${SNAP_NAME}"
tar xf celestia-snap.tar -C ~/.celestia-app/data/

Inicie el nodo de consenso​

Para iniciar su nodo de consenso completo, ejecute lo siguiente:

sh

celestia-appd start

Opcional: Si desea que celestia-app se ejecute como un proceso de fondo, puede seguir el SystemD tutorial.

PUNTA

Consulte la sección de puertos de la página de solución de problemas de celestia-node para obtener información sobre qué puertos deben estar abiertos en su máquina.

Opcional: Configuración de un validador​

Configuración de un nodo validador Celestia​

Los nodos validadores le permiten participar en el consenso en la red Celestia.

nodo validador

Requisitos de hardware del validador​

Se recomiendan los siguientes requisitos mínimos de hardware para ejecutar un nodo validador:

• Memoria: 8 GB RAM

• CPU: 6 núcleos

• Disco: Almacenamiento SSD de 500 GB

• Ancho de banda: 1 Gbps para Descargar/1 Gbps para Cargar

El siguiente tutorial se realiza en una máquina de instancia Ubuntu Linux 20.04 (LTS) x64.

Primero, configure su nodo de consenso completo siguiendo las instrucciones en la sección anterior.

Cartera​

Seguir el tutorial sobre cómo crear una billetera.

Delegar la participación en un validador​

Crear una variable de entorno para la dirección:

bash

VALIDATOR_WALLET=<validator-wallet-name>

Si desea delegar más participación en cualquier validador, incluido el suyo, necesitará celesvaloper dirección del validador en cuestión. Puede ejecutar el comando a continuación para obtener el celesvaloper de su cartera de validador local en caso de que desee delegar más en ella:

bash

celestia-appd keys show $VALIDATOR_WALLET --bech val -a

Después de ingresar la frase de contraseña de la billetera, debería ver una salida similar:

bash

Enter keyring passphrase:
celesvaloper1q3v5cugc8cdpud87u4zwy0a74uxkk6u43cv6hd

Para delegar tokens en el celestiavaloper validador, como ejemplo puede ejecutar:

bash

celestia-appd tx staking delegate \
celestiavaloper1q3v5cugc8cdpud87u4zwy0a74uxkk6u4q4gx4p 1000000utia \
--from=$VALIDATOR_WALLET --chain-id=mocha-4 \
--fees=21000utia

Si tiene éxito, debería ver una salida similar a:

consola

code: 0
codespace: ""
data: ""
gas_used: "0"
gas_wanted: "0"
height: "0"
info: ""
logs: []
raw_log: '[]'
timestamp: ""
tx: null
txhash: <tx-hash>

Puede verificar si el hash TX pasó usando el explorador de bloques ingresando el txhash ID que fue devuelto.

Opcional: Implementar el nodo celestia​

Ejecutar un nodo puente es fundamental para la red Celestia, ya que permite que la disponibilidad de datos y los nodos de consenso se comuniquen entre sí. Se recomienda admitir la red de disponibilidad de datos, pero no es necesario para celestia-app.

Si no está ejecutando un nodo de puente, puede saltar a ejecute un nodo validador.

Esta sección describe la parte 2 de la configuración del nodo validador Celestia: ejecutar un demonio de nodo de puente Celestia.

Instalar celestia-node​

Puedes siga el tutorial para instalar celestia-node

Inicializar el nodo puente​

Ejecute lo siguiente:

bash

celestia bridge init --core.ip <URI>

PUNTA

Consulte la sección de puertos de la página de solución de problemas de celestia-node para obtener información sobre qué puertos deben estar abiertos en su máquina.

Si necesita una lista de puntos finales de RPC para conectarse, puede encontrar el lista en la página de testnet de Mocha o lista en la página de arábica devnet.

Ejecute el nodo del puente​

Ejecute lo siguiente:

bash

celestia bridge start

Opcional: inicie el nodo puente con SystemD​

Seguir el tutorial sobre la configuración del nodo puente como un proceso de fondo con SystemD.

Ha configurado correctamente un nodo puente que se está sincronizando con la red.

Ejecute el nodo validador​

Para iniciar su nodo validador, ejecute lo siguiente:

bash

celestia-appd start

¡Después de completar todos los pasos necesarios, ahora está listo para ejecutar un validador! Para crear su validador en la cadena, siga las instrucciones a continuación. Tenga en cuenta que estos pasos son necesarios SOLO si desea participar en el consenso.

Elige un moniker nombre de su elección! Este es el nombre del validador que aparecerá en los paneles públicos y exploradores. VALIDATOR_WALLET debe ser el mismo que definiste anteriormente. Parámetro --min-self-delegation=1000000 define la cantidad de tokens que se autodelegan desde su billetera de validador.

Ahora, conéctese a la red de su elección.

Tiene la siguiente opción de conectarse a la lista de redes que se muestra a continuación:

Continuando con el tutorial del validador, estos son los pasos para conectar su validador a Mocha:

bash

MONIKER="your_moniker"
VALIDATOR_WALLET="validator"

celestia-appd tx staking create-validator \
    --amount=1000000utia \
    --pubkey=$(celestia-appd tendermint show-validator) \
    --moniker=$MONIKER \
    --chain-id=mocha-4 \
    --commission-rate=0.1 \
    --commission-max-rate=0.2 \
    --commission-max-change-rate=0.01 \
    --min-self-delegation=1000000 \
    --from=$VALIDATOR_WALLET \
    --keyring-backend=test \
    --fees=21000utia \
    --gas=220000

Se le pedirá que confirme la transacción:

consola

confirm transaction before signing and broadcasting [y/N]: y

Entrada y debe proporcionar una salida similar a:

consola

code: 0
codespace: ""
data: ""
gas_used: "0"
gas_wanted: "0"
height: "0"
info: ""
logs: []
raw_log: '[]'
timestamp: ""
tx: null
txhash: <tx-hash>

Ahora debería poder ver su validador desde un explorador de bloques

Envíe su información de validador​

Después de iniciar su nodo, envíe su nodo como semilla y mire al repositorio de redes.

Recursos adicionales para nodos de consenso​

Opcional: Restablecer red​

Esto eliminará todas las carpetas de datos para que podamos comenzar de nuevo:

sh

celestia-appd tendermint unsafe-reset-all --home $HOME/.celestia-app

Opcional: Configuración de un punto final RPC​

Puede configurar su nodo de consenso completo para que sea un punto final de RPC público. Esto le permite aceptar conexiones desde nodos de disponibilidad de datos y atender solicitudes para la API de disponibilidad de datos.

Exponer RPC​

De forma predeterminada, el servicio RPC escucha localhost lo que significa que no se puede acceder desde otras máquinas. Para que el servicio RPC esté disponible públicamente, debe vincularlo a una IP pública o 0.0.0.0 (lo que significa escuchar en todas las interfaces de red disponibles).

Puede hacerlo editando el archivo config.toml:

sh

sed -i 's#"tcp://127.0.0.1:26657"#"tcp://0.0.0.0:26657"#g' ~/.celestia-app/config/config.toml

Este comando reemplaza el localhost Dirección IP con 0.0.0.0, haciendo que el servicio RPC escuche en todas las interfaces de red disponibles.

Nota sobre external-address​

El external-address el campo en la configuración se usa cuando su nodo está detrás de un NAT y necesita anunciar una dirección diferente para que los pares marquen. Poblar este campo no es necesario para hacer público el punto final de RPC.

sh

EXTERNAL-ADDRESS=$(wget -qO- eth0.me)
sed -i.bak -e "s/^external-address = ""/external-address = "$EXTERNAL-ADDRESS:26656"/" \
    $HOME/.celestia-app/config/config.toml

Reinicie el nodo​

Después de hacer estos cambios, reinicie celestia-appd para cargar las nuevas configuraciones.

Opcional: Opciones de configuración del indexador de transacciones​

Esta sección le guía sobre cómo configurar su config.toml archivo en celestia-app para seleccionar qué transacciones indexar. Dependiendo de la configuración de la aplicación, un operador de nodo puede decidir qué transacciones indexar.

Las opciones disponibles son:

1. null: Esta opción deshabilita la indexación. Si no necesita consultar transacciones, puede elegir esta opción para ahorrar espacio.

2. kv (predeterminado): Este es el indexador más simple, respaldado por el almacenamiento de valor clave (defaults to levelDB; ver DBBackend). Cuando kv es elegido, tx.height y tx.hash siempre será indexado. Esta opción es adecuada para consultas básicas sobre transacciones.

3. psql: Este indexador está respaldado por PostgreSQL. Cuando se elige psql, tx.height y tx.hash siempre será indexado. Esta opción es adecuada para consultas complejas sobre transacciones.

Un ejemplo para establecer el valor a kv en config.toml es:

toml

indexer = "kv"

Recuerde reiniciar celestia-appd después de realizar cambios en la configuración para cargar la nueva configuración.

Opcional: Descarte la configuración de respuestas ABCI​

Esta sección le guiará sobre cómo configurar su config.toml archivo en celestia-app gestionar el almacenamiento de las respuestas ABCI. Las respuestas de ABCI son los resultados de la ejecución de transacciones y se utilizan para /block_results Consultas RPC y para reindexar eventos en la herramienta de línea de comandos.

El discard_abci_responses la opción le permite controlar si estas respuestas persisten en la tienda estatal:

• false (predeterminado): Las respuestas ABCI se almacenan en la tienda estatal. Esto asegura que las respuestas ABCI estén disponibles para /block_results Consultas RPC y para reindexar eventos. Sin embargo, puede consumir una cantidad significativa de espacio en disco.

• true: Las respuestas de ABCI no se almacenan en la tienda estatal. Esto puede ahorrar una cantidad considerable de espacio en disco, pero /block_results Las consultas de RPC y la reindexación de eventos no estarán disponibles.

Un ejemplo para establecer el valor en false config.toml es:

toml

discard_abci_responses = false

Recuerde reiniciar celestia-appd después de realizar cambios en la configuración para cargar la nueva configuración.