diff --git a/docs/developers/celestia-app-vesting.md b/docs/developers/celestia-app-vesting.md index fc11986a047..506cdb4678f 100644 --- a/docs/developers/celestia-app-vesting.md +++ b/docs/developers/celestia-app-vesting.md @@ -309,7 +309,7 @@ Next, you can learn how to create a vesting account on Mocha testnet. In the previous section of this tutorial, we learned how to create a vesting account on a local devnet. In this portion of the tutorial, we'll cover how -to set up a consensus full node and set up a vesting account on +to set up a full consensus node and set up a vesting account on [Mocha testnet](../../nodes/mocha-testnet). First, be sure that you have @@ -377,13 +377,13 @@ Here's an example command to set up the vesting account: celestia-appd tx vesting create-vesting-account $TO_ADDRESS 100000utia 1686748051 --from $FROM_ADDRESS --gas 100000 --fees 100000utia --node $RPC_URL --chain-id mocha --delayed ``` -### Optional: Set up a consensus full node or validator +### Optional: Set up a full consensus node or validator -Running a consensus full node or validator will prevent you from needing +Running a full consensus node or validator will prevent you from needing to use an RPC. -You can [set up a validator](../../nodes/full-consensus-node) or [full node](../../nodes/validator-node) for the previous portion -of the tutorial. +You can [set up a validator or full consensus node](../../nodes/consensus-node) +for the previous portion of the tutorial. Note: this may take some time depending on how you choose to sync the state of the chain. diff --git a/docs/nodes/arabica-devnet.mdx b/docs/nodes/arabica-devnet.mdx index 0b622cb17ed..88b7f305567 100644 --- a/docs/nodes/arabica-devnet.mdx +++ b/docs/nodes/arabica-devnet.mdx @@ -76,7 +76,7 @@ Below is a list of RPC endpoints you can use to connect to Arabica devnet: These RPC endpoints do not allow you to download full blocks from them. We advise that if you are running a bridge node, that you also -run a local [full consensus node](../full-consensus-node) in order to download full blocks from +run a local [full consensus node](../consensus-node) in order to download full blocks from it. - `rpc.consensus.celestia-arabica-10.com` diff --git a/docs/nodes/validator-node.mdx b/docs/nodes/consensus-node.mdx similarity index 56% rename from docs/nodes/validator-node.mdx rename to docs/nodes/consensus-node.mdx index 3f90cdfbefd..9412d09d43c 100644 --- a/docs/nodes/validator-node.mdx +++ b/docs/nodes/consensus-node.mdx @@ -1,94 +1,159 @@ --- -sidebar_label: Validator node -description: A tutorial for setting up a Celestia validator node. +sidebar_label: Consensus nodes +description: Learn how to set up a Celestia consensus node. --- -# Setting up a Celestia validator node +# Setting up a Celestia full consensus node import constants from "../constants/constants.js"; import InlineText from "@site/src/components/InlineText.js"; -import PeersLink from "@site/src/components/PeersLink.js"; +import SeedsLink from "@site/src/components/SeedsLink.js"; -Validator nodes allow you to participate in consensus in the Celestia network. +Full consensus nodes allow you to sync blockchain history in the Celestia +consensus layer. -![validator node](../img/nodes/validator.png) +![full consensus node](../img/nodes/full-consensus-node.png) ## Hardware requirements -The following hardware minimum requirements are recommended for running the -validator node: +The following hardware minimum requirements are recommended for running a +full consensus node: - Memory: **8 GB RAM** -- CPU: **6 cores** -- Disk: **500 GB SSD Storage** +- CPU: **Quad-Core** +- Disk: **250 GB SSD Storage** - Bandwidth: **1 Gbps for Download/1 Gbps for Upload** -## Setting up your validator node +:::tip +Running a full consensus node requires significant storage capacity to store the entire blockchain history. As of the latest recommendation, it is advisable to have at least 250 GB of SSD storage for a Celestia full consensus node if you are using pruning. If you are not using pruning, you are running an archive node, and it is recommended to have 500 GB of SSD storage. Please ensure that your storage meets this requirement to ensure smooth syncing and operation of the node. +::: + +## Setting up a full consensus node The following tutorial is done on an Ubuntu Linux 20.04 (LTS) x64 instance machine. ### Setup the dependencies -Follow [the instructions on installing the dependencies](./environment.mdx). +Follow the instructions on [installing the dependencies](./environment.mdx). ### Install celestia-app -Follow [the tutorial on installing `celestia-app`](./celestia-app.mdx). +Follow the tutorial on [installing `celestia-app`](./celestia-app.mdx). ### Setup the P2P networks Now we will setup the P2P Networks by cloning the networks repository: -```bash +```sh cd $HOME rm -rf networks git clone https://github.com/celestiaorg/networks.git ``` +```mdx-code-block +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + + + + To initialize the network pick a "node-name" that describes your -node. The `--chain-id` parameter we are using here is ****. Keep in -mind that this might change if a new testnet is deployed. +node. The `--chain-id` parameter we are using here is . Keep in mind that this might change if a new testnet is deployed. -```mdx-code-block 

 celestia-appd init "node-name" --chain-id {constants.mochaChainId}
-Copy the `genesis.json` file. For mocha we are using: +Copy the `genesis.json` file. For Mocha we are using: 

 cp $HOME/networks/{constants.mochaChainId}/genesis.json $HOME/.celestia-app/config
+ + + +Set seeds manually in the `$HOME/.celestia-app/config/config.toml` file: + +

+# Comma separated list of seed nodes to connect to

+seeds = ""
+
+ +Optionally, you can set peers from the networks repository with the following +commands: + +

+PERSISTENT_PEERS=$(curl -sL https://raw.githubusercontent.com/celestiaorg/networks/master/{constants.mochaChainId}/peers.txt | head -c -1 | tr '\n' ',')

+echo $PERSISTENT_PEERS

+sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"/" $HOME/.celestia-app/config/config.toml

+
+ + + + +To initialize the network pick a "node-name" that describes your +node. The `--chain-id` parameter we are using here is . Keep in mind that this might change if a new testnet is deployed. + +

+celestia-appd init "node-name" --chain-id {constants.arabicaChainId}
+
+ +Copy the `genesis.json` file. For Arabica we are using: + +

+cp $HOME/networks/{constants.arabicaChainId}/genesis.json $HOME/.celestia-app/config
+
+ + + +Set seeds manually in the `$HOME/.celestia-app/config/config.toml` file: + +

+# Comma separated list of seed nodes to connect to

+seeds = ""
+
+ +Optionally, you can set peers from the networks repository with the following +commands: + +

+PERSISTENT_PEERS=$(curl -sL https://raw.githubusercontent.com/celestiaorg/networks/master/{constants.arabicaChainId}/peers.txt | head -c -1 | tr '\n' ',')

+echo $PERSISTENT_PEERS

+sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"/" $HOME/.celestia-app/config/config.toml

+
+ + + ``` -Set seeds and peers: +:::tip +Mac users built-in `head` command does not accept negative numbers for `-c` flag. +Solution is to install `coreutils` package and use `ghead` command from it. ```bash -SEEDS="some seeds" -PEERS="some peers" -sed -i -e 's|^seeds *=.*|seeds = "'$SEEDS'"|; s|^persistent_peers *=.*|persistent_peers = "'$PEERS'"|' $HOME/.celestia-app/config/config.toml -sed -i -e "s/^seed_mode *=.*/seed_mode = \"$SEED_MODE\"/" $HOME/.celestia-app/config/config.toml +brew install coreutils +``` + +and optionally set alias from `head` to `ghead` in shell config (`~/.bashrc`, `~/.zshrc` etc): + +``` +alias head=ghead ``` - +::: ### Configure pruning For lower disk space usage we recommend setting up pruning using the -configurations below. You can change this to your own pruning configurations +configurations below in `$HOME/.celestia-app/config/app.toml`. +You can change this to your own pruning configurations if you want: -```bash -PRUNING="custom" -PRUNING_KEEP_RECENT="100" -PRUNING_INTERVAL="10" - -sed -i -e "s/^pruning *=.*/pruning = \"$PRUNING\"/" $HOME/.celestia-app/config/app.toml -sed -i -e "s/^pruning-keep-recent *=.*/pruning-keep-recent = \ -\"$PRUNING_KEEP_RECENT\"/" $HOME/.celestia-app/config/app.toml -sed -i -e "s/^pruning-interval *=.*/pruning-interval = \ -\"$PRUNING_INTERVAL\"/" $HOME/.celestia-app/config/app.toml +```toml +pruning = "custom" +pruning-keep-recent = "100" +pruning-interval = "10" ``` ### Syncing @@ -106,7 +171,7 @@ and then apply them. State sync relies on weak subjectivity; a trusted header (specifically the hash and height) must be provided. This can be found by querying a trusted RPC endpoint (/block). RPC endpoints are also required for retrieving light blocks. These can be found in the docs here under the respective networks or -from the [chain-registry](https://github.com/cosmos/chain-registry). +from [the chain-registry](https://github.com/cosmos/chain-registry). In `$HOME/.celestia-app/config/config.toml`, set @@ -129,47 +194,50 @@ Quick sync effectively downloads the entire `data` directory from a third-party meaning the node has all the application and blockchain state as the node it was copied from. -````mdx-code-block -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - +```mdx-code-block -Run the following command to quick-sync from a snapshot for `mocha`: +Run the following command to quick-sync from a snapshot for : 

 cd $HOME

 rm -rf ~/.celestia-app/data

 mkdir -p ~/.celestia-app/data

 SNAP_NAME=$(curl -s https://snaps.qubelabs.io/celestia/ | \

-  egrep -o ">{constants.mochaChainId}.*tar" | tr -d ">")

+    egrep -o ">{constants.mochaChainId}.*tar" | tr -d ">")

 wget -O - https://snaps.qubelabs.io/celestia/${SNAP_NAME} | tar xf - \

-  -C ~/.celestia-app/data/

+    -C ~/.celestia-app/data/
- + -Run the following command to quick-sync from a snapshot for `blockspacerace`: +Run the following command to quick-sync from a snapshot for : -```bash -cd $HOME -rm -rf ~/.celestia-app/data -mkdir -p ~/.celestia-app/data -SNAP_NAME=$(curl -s https://snaps.qubelabs.io/celestia/ | \ - egrep -o ">blockspacerace.*tar" | tr -d ">") -wget -O - https://snaps.qubelabs.io/celestia/${SNAP_NAME} | tar xf - \ - -C ~/.celestia-app/data/ -``` +

+cd $HOME

+rm -rf ~/.celestia-app/data

+mkdir -p ~/.celestia-app/data

+SNAP_NAME=$(curl -s https://snaps.qubelabs.io/celestia/ | \

+    egrep -o ">{constants.arabicaChainId}.*tar" | tr -d ">")

+wget -O - https://snaps.qubelabs.io/celestia/${SNAP_NAME} | tar xf - \

+    -C ~/.celestia-app/data/

+
 -```` +``` -### Start the celestia-app +### Start the consensus node -In order to start your validator node, run the following: +In order to start your full consensus node, run the following: + +```sh +celestia-appd start +``` + +Optional: If you would like celestia-app to run as a background process, you can follow the [SystemD tutorial](./systemd.md). :::tip Refer to @@ -177,19 +245,37 @@ Refer to for information on which ports are required to be open on your machine. ::: -```bash -celestia-appd start -``` +## Optional: Setting up a validator -Follow -[the tutorial on setting up `celestia-app` as a background process -with SystemD](../systemd). +### Setting up a Celestia validator node + +Validator nodes allow you to participate in consensus in the Celestia network. + +![validator node](../img/nodes/validator.png) + +#### Validator hardware requirements + +The following hardware minimum requirements are recommended for running a +validator node: + +- Memory: **8 GB RAM** +- CPU: **6 cores** +- Disk: **500 GB SSD Storage** +- Bandwidth: **1 Gbps for Download/1 Gbps for Upload** -### Wallet +#### Setting up your validator node + +The following tutorial is done on an Ubuntu Linux 20.04 (LTS) x64 +instance machine. + +First, set up your full consensus node by following the instructions in +[the previous section](#setting-up-a-full-consensus-node). + +##### Wallet Follow [the tutorial on creating a wallet](../developers/celestia-app-wallet.md). -### Delegate stake to a validator +##### Delegate stake to a validator Create an environment variable for the address: @@ -198,9 +284,8 @@ VALIDATOR_WALLET= ``` If you want to delegate more stake to any validator, including your own you -will need the `celesvaloper` address of the validator in question. You can -either check it using the block explorer mentioned above or you can run the -command below to get the `celesvaloper` of your local validator wallet in +will need the `celesvaloper` address of the validator in question. You can run +the command below to get the `celesvaloper` of your local validator wallet in case you want to delegate more to it: ```bash @@ -221,7 +306,8 @@ example you can run: celestia-appd tx staking delegate \
celestiavaloper1q3v5cugc8cdpud87u4zwy0a74uxkk6u4q4gx4p 1000000utia \
- --from=$VALIDATOR_WALLET --chain-id={constants.mochaChainId} + --from=$VALIDATOR_WALLET --chain-id={constants.mochaChainId} \
+ --fees=21000utia @@ -245,7 +331,7 @@ txhash: You can check if the TX hash went through using the block explorer by inputting the `txhash` ID that was returned. -## Optional: Deploy the Celestia Node +#### Optional: Deploy the celestia-node Running a bridge node is critical to the Celestia network as it enables the data availability and consensus nodes to communicate with one @@ -258,11 +344,11 @@ If you are not running a bridge node, you can skip to This section describes part 2 of Celestia validator node setup: running a Celestia bridge node daemon. -### Install Celestia Node +##### Install celestia-node You can [follow the tutorial for installing `celestia-node`](./celestia-node.mdx) -### Initialize the bridge node +##### Initialize the bridge node Run the following: @@ -279,7 +365,7 @@ for information on which ports are required to be open on your machine. If you need a list of RPC endpoints to connect to, you can find the [list on the Mocha testnet page](../mocha-testnet#rpc-endpoints). -### Run the bridge node +##### Run the bridge node Run the following: @@ -287,14 +373,14 @@ Run the following: celestia bridge start ``` -### Optional: start the bridge node with SystemD +##### Optional: start the bridge node with SystemD Follow [the tutorial on setting up the bridge node as a background process with SystemD](../systemd). You have successfully set up a bridge node that is syncing with the network. -### Setup QGB keys +##### Setup QGB keys ````mdx-code-block @@ -309,6 +395,7 @@ access to. We will use it to register your validator's EVM address + This step helps get you prepared for when the Quantum Gravity Bridge is enabled. You would still need to go through this step before running a validator to configure an extra key. @@ -331,7 +418,21 @@ environment variable before setting it. ```` -## Run a validator node +#### Run a validator node + +##### Start the celestia-app + +In order to start your validator node, run the following: + +:::tip +Refer to +[the ports section of the celestia-node troubleshooting page](../../nodes/celestia-node-troubleshooting/#ports) +for information on which ports are required to be open on your machine. +::: + +```bash +celestia-appd start +``` ````mdx-code-block @@ -368,7 +469,9 @@ celestia-appd tx staking create-validator \
  --commission-max-change-rate=0.01 \
  --min-self-delegation=1000000 \
  --from=$VALIDATOR_WALLET \
-  --keyring-backend=test +  --keyring-backend=test \
+  --fees=21000utia \
+  --gas=220000 You will be prompted to confirm the transaction: @@ -394,7 +497,7 @@ tx: null txhash: ``` -## Register your validator's EVM address +### Register your validator's EVM address This section will cover how to register your validator's EVM address. This is required to run an orchestrator. @@ -403,14 +506,13 @@ To register your EVM address, run the following. Be sure to replace `YOUR_EVM_ADDRESS` with your EVM address: ```bash -VALIDATOR_ADDRESS=$(celestia-appd keys show $VALIDATOR_WALLET --home "${HOME_DIR}" --bech val -a) +VALIDATOR_ADDRESS=$(celestia-appd keys show $VALIDATOR_WALLET --bech val -a) EVM_ADDRESS="YOUR_EVM_ADDRESS" celestia-appd tx qgb register \ - "${VALIDATOR_ADDRESS}" \ - "${EVM_ADDRESS}" \ + $VALIDATOR_ADDRESS \ + $EVM_ADDRESS \ --from $VALIDATOR_WALLET \ - --home "${HOME_DIR}" \ --fees 30000utia \ -b block \ -y & @@ -484,9 +586,74 @@ txhash: You should now be able to see your validator from [a block explorer](../mocha-testnet#explorers) -## Run the QGB Orchestrator +#### Run the QGB Orchestrator -Now that the QGB will be enabled for Blockspace Race (BSR), all validators +Now that the QGB will be enabled for Mocha, all validators will need to run the QGB orchestrator to be able to sign attestations. To run it, please [refer to the documentation](https://docs.celestia.org/nodes/qgb-orchestrator/#how-to-run). + +## Extra resources for consensus nodes + +### Optional: Reset network + +This will delete all data folders so we can start fresh: + +```sh +celestia-appd tendermint unsafe-reset-all --home $HOME/.celestia-app +``` + +### Optional: Configuring an RPC endpoint + +You can configure your full consensus node to be a public RPC endpoint. +This allows it to accept connections from data availability nodes and +serve requests for the data availability API. + +#### Expose RPC + +By default, the RPC service listens on `localhost` which means it can't +be accessed from other machines. To make the RPC service available publicly, +you need to bind it to a public IP or `0.0.0.0` (which means listening on all +available network interfaces). + +You can do this by editing the config.toml file: + +```sh +sed -i 's#"tcp://127.0.0.1:26657"#"tcp://0.0.0.0:26657"#g' ~/.celestia-app/config/config.toml +``` + +This command replaces the `localhost` IP address with `0.0.0.0`, making the +RPC service listen on all available network interfaces. + +#### Note on `external-address` + +The `external-address` field in the configuration is used when your node +is behind a NAT and you need to advertise a different address for peers +to dial. Populating this field is not necessary for making the RPC +endpoint public. + +```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 +``` + +#### Restart the node + +After making these changes, restart `celestia-appd` to load the new +configurations. + +### Optional: Transaction indexer configuration options + +This section will show you how to set your `config.toml` file in `celestia-app` +to chose which transactions to index. In some +cases, a node operator will be able to decide which transactions to index +based on configuration set in the application. + +The options are: + +1. `null` +2. `kv` (default) - the simplest possible indexer backed by key-value storage + (defaults to levelDB; see DBBackend) + 1. when `kv` is chosen `tx.height` and `tx.hash` will always be indexed +3. `psql` - the indexer services backed by PostgreSQL + 1. when `psql` is chosen, `tx.height` and `tx.hash` will always be indexed diff --git a/docs/nodes/decide-node.md b/docs/nodes/decide-node.md index 92db31bbd37..7141e255a0e 100644 --- a/docs/nodes/decide-node.md +++ b/docs/nodes/decide-node.md @@ -22,7 +22,7 @@ in [this tutorial for the light node](../developers/node-tutorial.mdx). ## Advanced If you are looking to run a validator, please follow the -[tutorial for running a validator](./validator-node.mdx). +[tutorial for running a validator](../consensus-node#optional-setting-up-a-validator). Note that running a validator means you must also run a bridge node, which is covered in [this section](./bridge-node.mdx). diff --git a/docs/nodes/full-consensus-node.mdx b/docs/nodes/full-consensus-node.mdx deleted file mode 100644 index 230c6b960c1..00000000000 --- a/docs/nodes/full-consensus-node.mdx +++ /dev/null @@ -1,327 +0,0 @@ ---- -sidebar_label: Full consensus node -description: Learn how to set up a Celestia full consensus node. ---- - -# Setting up a Celestia full consensus node - -import constants from "../constants/constants.js"; - -Full Consensus Nodes allow you to sync blockchain history in the Celestia -Consensus Layer. - -![full consensus node](../img/nodes/full-consensus-node.png) - -## Hardware requirements - -The following hardware minimum requirements are recommended for running the -Full Consensus Nodes: - -- Memory: **8 GB RAM** -- CPU: **Quad-Core** -- Disk: **250 GB SSD Storage** -- Bandwidth: **1 Gbps for Download/1 Gbps for Upload** - -**Note**: Running a full consensus node requires significant storage capacity to store the entire blockchain history. As of the latest recommendation, it is advisable to have at least 250 GB of SSD storage for a Celestia full consensus node if you are using pruning. If you are not using pruning, you are running an archive node, and it is recommended to have 500 GB of SSD storage. Please ensure that your storage meets this requirement to ensure smooth syncing and operation of the node. - -## Setting up a full consensus node - -The following tutorial is done on an Ubuntu Linux 20.04 (LTS) x64 -instance machine. - -### Setup the dependencies - -Follow the instructions on [installing the dependencies](./environment.mdx). - -### Install celestia-app - -Follow the tutorial on [installing `celestia-app`](./celestia-app.mdx). - -### Setup the P2P networks - -Now we will setup the P2P Networks by cloning the networks repository: - -```sh -cd $HOME -rm -rf networks -git clone https://github.com/celestiaorg/networks.git -``` - -```mdx-code-block -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - - - - -To initialize the network pick a "node-name" that describes your -node. The `--chain-id` parameter we are using here is: -
{constants.mochaChainId}
-Keep in mind that this might change if a new testnet is deployed. - -

-celestia-appd init "node-name" --chain-id {constants.mochaChainId}
-
- -Copy the `genesis.json` file. For mocha we are using: - -

-cp $HOME/networks/{constants.mochaChainId}/genesis.json $HOME/.celestia-app/config
-
- -Set seeds and peers: - -

-PERSISTENT_PEERS=$(curl -sL https://raw.githubusercontent.com/celestiaorg/networks/master/{constants.mochaChainId}/peers.txt | head -c -1 | tr '\n' ',')

-echo $PERSISTENT_PEERS

-sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"/" $HOME/.celestia-app/config/config.toml

-
- -:::tip -Mac users built-in `head` command does not accept negative numbers for `-c` flag. -Solution is to install `coreutils` package and use `ghead` command from it. - -

-brew install coreutils
-
- -and optionally set alias from `head` to `ghead` in shell config (`~/.bashrc`, `~/.zshrc` etc): - -

-alias head=ghead
-
-::: - -Note: You can find more peers at: - -

-https://github.com/celestiaorg/networks/blob/master/{constants.mochaChainId}/peers.txt
-
- - - - -To initialize the network pick a "node-name" that describes your -node. The `--chain-id` parameter we are using here is: -
{constants.arabicaChainId}
-Keep in mind that this might change if a new testnet is deployed. - -

-celestia-appd init "node-name" --chain-id {constants.arabicaChainId}
-
- -Copy the `genesis.json` file. For mocha we are using: - -

-cp $HOME/networks/{constants.arabicaChainId}/genesis.json $HOME/.celestia-app/config
-
- -Set seeds and peers: - -

-PERSISTENT_PEERS=$(curl -sL https://raw.githubusercontent.com/celestiaorg/networks/master/{constants.arabicaChainId}/peers.txt | head -c -1 | tr '\n' ',')

-echo $PERSISTENT_PEERS

-sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"/" $HOME/.celestia-app/config/config.toml

-
- -:::tip -Mac users built-in `head` command does not accept negative numbers for `-c` flag. -Solution is to install `coreutils` package and use `ghead` command from it. - -

-brew install coreutils
-
- -and optionally set alias from `head` to `ghead` in shell config (`~/.bashrc`, `~/.zshrc` etc): - -

-alias head=ghead
-
-::: - -Note: You can find more peers at: - -

-https://github.com/celestiaorg/networks/blob/master/{constants.arabicaChainId}/peers.txt
-
- - - -``` - -### Configure pruning - -For lower disk space usage we recommend setting up pruning using the -configurations below. You can change this to your own pruning configurations -if you want: - -```sh -PRUNING="custom" -PRUNING_KEEP_RECENT="100" -PRUNING_INTERVAL="10" - -sed -i -e "s/^pruning *=.*/pruning = \"$PRUNING\"/" $HOME/.celestia-app/config/app.toml -sed -i -e "s/^pruning-keep-recent *=.*/pruning-keep-recent = \ -\"$PRUNING_KEEP_RECENT\"/" $HOME/.celestia-app/config/app.toml -sed -i -e "s/^pruning-interval *=.*/pruning-interval = \ -\"$PRUNING_INTERVAL\"/" $HOME/.celestia-app/config/app.toml -``` - -### Reset network - -This will delete all data folders so we can start fresh: - -```sh -celestia-appd tendermint unsafe-reset-all --home $HOME/.celestia-app -``` - -:::tip -Refer to -[the ports section of the celestia-node troubleshooting page](../../nodes/celestia-node-troubleshooting/#ports) -for information on which ports are required to be open on your machine. -::: - -### Syncing - -By default, a consensus node will sync using block sync; that is request, validate -and execute every block up to the head of the blockchain. This is the most secure -mechanism yet the slowest (taking up to days depending on the height of the blockchain). - -There are two alternatives for quicker syncing. - -#### State sync - -State sync uses light client verification to verify state snapshots from peers -and then apply them. State sync relies on weak subjectivity; a trusted header -(specifically the hash and height) must be provided. This can be found by querying -a trusted RPC endpoint (/block). RPC endpoints are also required for retrieving -light blocks. These can be found in the docs here under the respective networks or -from [the chain-registry](https://github.com/cosmos/chain-registry). - -In `$HOME/.celestia-app/config/config.toml`, set - -```toml -rpc_servers = "" -trust_height = 0 -trust_hash = "" -``` - -to their respective fields. At least two different rpc endpoints should be provided. -The more, the greater the chance of detecting any fraudulent behavior. - -Once setup, you should be ready to start the node as normal. In the logs, you should -see: `Discovering snapshots`. This may take a few minutes before snapshots are found -depending on the network topology. - -#### Quick sync - -Quick sync effectively downloads the entire `data` directory from a third-party provider -meaning the node has all the application and blockchain state as the node it was -copied from. - -```mdx-code-block - - - -Run the following command to quick-sync from a snapshot for `mocha`: - -

-cd $HOME

-rm -rf ~/.celestia-app/data

-mkdir -p ~/.celestia-app/data

-SNAP_NAME=$(curl -s https://snaps.qubelabs.io/celestia/ | \

-    egrep -o ">{constants.mochaChainId}.*tar" | tr -d ">")

-wget -O - https://snaps.qubelabs.io/celestia/${SNAP_NAME} | tar xf - \

-    -C ~/.celestia-app/data/

-
- - - - -Run the following command to quick-sync from a snapshot for `arabica-10`: - -

-cd $HOME

-rm -rf ~/.celestia-app/data

-mkdir -p ~/.celestia-app/data

-SNAP_NAME=$(curl -s https://snaps.qubelabs.io/celestia/ | \

-    egrep -o ">{constants.arabicaChainId}.*tar" | tr -d ">")

-wget -O - https://snaps.qubelabs.io/celestia/${SNAP_NAME} | tar xf - \

-    -C ~/.celestia-app/data/

-
- - - -``` - -### Start the celestia-app - -In order to start your full consensus node, run the following: - -```sh -celestia-appd start -``` - -Follow the tutorial on -[setting up Celestia App as a background process with SystemD](./systemd.md). - -:::tip -Refer to -[the ports section of the celestia-node troubleshooting page](../../nodes/celestia-node-troubleshooting/#ports) -for information on which ports are required to be open on your machine. -::: - -### Optional: Configuring an RPC endpoint - -You can configure your full consensus node to be a public RPC endpoint. -This allows it to accept connections from data availability nodes and -serve requests for the data availability API. - -#### Expose RPC - -By default, the RPC service listens on `localhost` which means it can't -be accessed from other machines. To make the RPC service available publicly, -you need to bind it to a public IP or `0.0.0.0` (which means listening on all -available network interfaces). - -You can do this by editing the config.toml file: - -```sh -sed -i 's#"tcp://127.0.0.1:26657"#"tcp://0.0.0.0:26657"#g' ~/.celestia-app/config/config.toml -``` - -This command replaces the `localhost` IP address with `0.0.0.0`, making the -RPC service listen on all available network interfaces. - -#### Note on `external-address` - -The `external-address` field in the configuration is used when your node -is behind a NAT and you need to advertise a different address for peers -to dial. Populating this field is not necessary for making the RPC -endpoint public. - -```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 -``` - -#### Restart the node - -After making these changes, restart `celestia-appd` to load the new -configurations. - -## Transaction indexer configuration options - -This section will show you how to set your `config.toml` file in `celestia-app` -to chose which transactions to index. In some -cases, a node operator will be able to decide which transactions to index -based on configuration set in the application. - -The options are: - -1. `null` -2. `kv` (default) - the simplest possible indexer backed by key-value storage - (defaults to levelDB; see DBBackend) - 1. when `kv` is chosen `tx.height` and `tx.hash` will always be indexed -3. `psql` - the indexer services backed by PostgreSQL - 1. when `kv` or `psql` is chosen, `tx.height` and `tx.hash` will always be indexed diff --git a/docs/nodes/instantiate-testnet.md b/docs/nodes/instantiate-testnet.md index d321a5f8d2d..0ed46137747 100644 --- a/docs/nodes/instantiate-testnet.md +++ b/docs/nodes/instantiate-testnet.md @@ -13,7 +13,7 @@ to test out new features to build as a core developer. ## Hardware requirements You wil need to -[follow hardware requirements](../nodes/validator-node.mdx#hardware-requirements). +[follow hardware requirements](../consensus-node#validator-hardware-requirements). ## Setup dependencies diff --git a/docs/nodes/mocha-testnet.mdx b/docs/nodes/mocha-testnet.mdx index fd675f26e54..0e830256915 100644 --- a/docs/nodes/mocha-testnet.mdx +++ b/docs/nodes/mocha-testnet.mdx @@ -29,14 +29,14 @@ participate in Mocha: Consensus: -- [Validator node](./validator-node.mdx) -- [Full consensus node](./full-consensus-node.mdx) +- [Validator node](../consensus-node#optional-setting-up-a-validator) +- [Full consensus node](../consensus-node) Data Availability: -- [Bridge node](./bridge-node.mdx) -- [Full storage node](./full-storage-node.mdx) -- [Light node](./light-node.mdx) +- [Bridge node](../bridge-node) +- [Full storage node](../full-storage-node) +- [Light node](../light-node) Select the type of node you would like to run and follow the instructions on each respective page. Whenever you are asked to select the type of network @@ -70,7 +70,7 @@ Below is a list of RPC endpoints you can use to connect to Mocha testnet: These RPC endpoints do not allow you to download full blocks from them. We advise that if you are running a bridge node, that you also -run a local [full consensus node](../full-consensus-node) in order to download full blocks from +run a local [full consensus node](../consensus-node) in order to download full blocks from it. - `rpc.celestia-mocha.com` diff --git a/docs/nodes/overview.md b/docs/nodes/overview.md index bfebac770bb..f0ae047cbeb 100644 --- a/docs/nodes/overview.md +++ b/docs/nodes/overview.md @@ -11,18 +11,19 @@ Celestia node operators can run several options on the network. Consensus: -- [Validator node](./validator-node.mdx): This type of node participates +- [Validator node](../consensus-node#optional-setting-up-a-validator): + This type of node participates in consensus by producing and voting on blocks. -- [Full consensus node](./full-consensus-node.mdx): A `celestia-app` Full node +- [Full consensus node](../consensus-node): A `celestia-app` Full node to sync blockchain history. Data Availability: -- [Bridge node](./bridge-node.mdx): This node bridges blocks between the +- [Bridge node](../bridge-node): This node bridges blocks between the Data-Availability network and the Consensus network. -- [Full storage node](./full-storage-node.mdx): This node stores all +- [Full storage node](../full-storage-node): This node stores all the data but does not connect to Consensus. -- [Light node](./light-node.mdx): Light clients conduct data availability +- [Light node](../light-node): Light clients conduct data availability sampling on the Data Availability network. You can learn more about how to setup each different node by going through diff --git a/docs/nodes/qgb-intro.md b/docs/nodes/qgb-intro.md index b6f84d87785..84c5be5b871 100644 --- a/docs/nodes/qgb-intro.md +++ b/docs/nodes/qgb-intro.md @@ -69,7 +69,8 @@ You can learn more about the mechanics behind the Relayer in The following sections in this category presume you have the following setup: -- A Celestia App [validator node](../validator-node) running +- A Celestia App +[validator node](../consensus-node#optional-setting-up-a-validator) running - A Celestia Node [bridge node](../bridge-node) running ## Next steps diff --git a/docs/nodes/qgb-orchestrator.md b/docs/nodes/qgb-orchestrator.md index dc77774e271..8a78c14caa7 100644 --- a/docs/nodes/qgb-orchestrator.md +++ b/docs/nodes/qgb-orchestrator.md @@ -16,7 +16,7 @@ The orchestrator does the following: 1. Connect to a Celestia-app full node or validator node via RPC and gRPC and wait for new attestations 2. Once an attestation is created inside the QGB state machine, the orchestrator queries it. -3. After getting the attestation, the orchestrator signs it using the provided EVM private key. The private key should correspond to the EVM address provided when creating the validator. More details in [here](https://docs.celestia.org/nodes/validator-node/#setup-qgb-keys). +3. After getting the attestation, the orchestrator signs it using the provided EVM private key. The private key should correspond to the EVM address provided when creating the validator. More details in [here](https://docs.celestia.org/nodes/consensus-node/#setup-qgb-keys). 4. Then, the orchestrator pushes its signature to the P2P network it is connected to, via adding it as a DHT value. 5. Listen for new attestations and go back to step 2. diff --git a/docs/nodes/systemd.md b/docs/nodes/systemd.md index b3b517212f4..0f2ba087da8 100644 --- a/docs/nodes/systemd.md +++ b/docs/nodes/systemd.md @@ -23,12 +23,14 @@ sudo tee </dev/null /etc/systemd/system/celestia-appd.service [Unit] Description=celestia-appd Cosmos daemon After=network-online.target + [Service] User=$USER ExecStart=$(which celestia-appd) start Restart=on-failure RestartSec=3 LimitNOFILE=4096 + [Install] WantedBy=multi-user.target EOF diff --git a/docusaurus.config.js b/docusaurus.config.js index 979fe16eac6..ddf6db1688a 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -78,6 +78,14 @@ const config = { "@docusaurus/plugin-client-redirects", { redirects: [ + { + to: "/nodes/consensus-node", + from: "/nodes/full-consensus-node", + }, + { + to: "/nodes/consensus-node", + from: "/nodes/validator-node", + }, { to: "/nodes/environment", from: "/developers/environment", diff --git a/sidebars.js b/sidebars.js index 5be537a8399..ceebac0e36c 100644 --- a/sidebars.js +++ b/sidebars.js @@ -106,39 +106,14 @@ const sidebars = { ] }, { - type: "category", - label: "Consensus", - link: { - type: 'generated-index' - }, - collapsed: true, - items: [ - { - type: "category", - label: "Validators", - link: { - type: 'generated-index' - }, - collapsed: true, - items: [ - { - type: "doc", - label: "Validator node", - id: "nodes/validator-node", - }, - ] - }, - { - type: "doc", - label: "Full consensus node", - id: "nodes/full-consensus-node" - }, - { - type: "doc", - label: "IBC Relayer", - id: "nodes/ibc-relayer" - } - ] + type: "doc", + label: "Consensus nodes", + id: "nodes/consensus-node", + }, + { + type: "doc", + label: "IBC Relayer", + id: "nodes/ibc-relayer" }, { type: "category", diff --git a/src/components/PeersLink.js b/src/components/PeersLink.js deleted file mode 100644 index 94c0dbf2fc2..00000000000 --- a/src/components/PeersLink.js +++ /dev/null @@ -1,12 +0,0 @@ -import React from 'react'; - -const PeersLink = ({ chainId }) => ( -

- Note: You can find more peers - {" "} - here - . -

-); - -export default PeersLink; \ No newline at end of file diff --git a/src/components/SeedsLink.js b/src/components/SeedsLink.js new file mode 100644 index 00000000000..f2a757ee4f0 --- /dev/null +++ b/src/components/SeedsLink.js @@ -0,0 +1,12 @@ +import React from 'react'; + +const SeedsLink = ({ chainId }) => ( +

+ Find a seed from{" "} + + the list + and pick one. +

+); + +export default SeedsLink; \ No newline at end of file diff --git a/src/pages/arabica-9.mdx b/src/pages/arabica-9.mdx index d7826510e73..a14d1aa6ae8 100644 --- a/src/pages/arabica-9.mdx +++ b/src/pages/arabica-9.mdx @@ -64,7 +64,7 @@ Below is a list of RPC endpoints you can use to connect to arabica-9 Devnet: These RPC endpoints do not allow you to download full blocks from them. We advise that if you are running a bridge node, that you also -run a local [full consensus node](../nodes/full-consensus-node) in order to download full blocks from +run a local [full consensus node](../nodes/consensus-node) in order to download full blocks from it. * `rpc-arabica-9.consensus.celestia-arabica.com`