docs: update consensus-node page

.vitepress/config.ts

@@ -414,7 +414,7 @@ function sidebarHome() {
               text: "Consensus",
               collapsed: true,
               items: [
-                { text: "Full consensus node", link: "/nodes/full-consensus-node" },
+                { text: "Consensus node", link: "/nodes/consensus-node" },
                 { text: "Validator node", link: "/nodes/validator-node" },
               ],
             },

developers/arbitrum-integration.md

@@ -41,7 +41,7 @@ The core logic behind posting and retrieving data happens in [celestia.go](https
 Then the `Read` logic takes care of taking the deserialized Blob Pointer struct and consuming it in order to fetch the data from Celestia and additionally inform the fetcher about the position of the data on Celestia (we'll get back to this in the next section).
 
 The following represents a non-exhaustive list of considerations when running a Batch Poster node for a chain with Celestia underneath:
-- You will need to use a consensus full node RPC endpoint, you can
+- You will need to use a consensus node RPC endpoint, you can
 [find a list of them for Mocha](../nodes/mocha-testnet#community-rpc-endpoints)
 - The Batch Poster will only post a Celestia batch to the underlying chain if the height for which it posted is in a recent range in BlobstreamX and if the verification succeeds, otherwise it will discard the batch. Since it will wait until a range is relayed, it can take several minutes for a batch to be posted, but one can always make an on-chain request for the BlobstreamX contract to relay a header promptly.
 

developers/blobstream-proof-queries.md

@@ -11,7 +11,7 @@ next:
 
 ## Prerequisites
 
-- Access to a Celestia [full consensus node](../nodes/full-consensus-node.md)
+- Access to a Celestia [consensus node](../nodes/consensus-node.md)
   RPC endpoint (or full node). The node doesn't need to be a
   validating node in order for the proofs to be queried. A full node is enough.
 

nodes/arabica-devnet.md

@@ -138,7 +138,7 @@ celestia light start --p2p.network arabica \
 :::tip Bridge node runners
 Not all of the RPC endpoints do not guarantee the full block history.
 Find [an archive endpoint on the community dashboard](https://celestia-tools.brightlystake.com/)
-or run your own full consensus node with no pruning for
+or run your own consensus node with no pruning for
 your bridge node.
 :::
 

nodes/celestia-app-vesting.md

@@ -308,7 +308,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 full consensus node and set up a vesting account on
+to set up a consensus node and set up a vesting account on
 [Mocha testnet](../nodes/mocha-testnet.md).
 
 First, be sure that you have
@@ -376,13 +376,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 full consensus node or validator
+### Optional: Set up a consensus node or validator
 
-Running a full consensus node or validator will prevent you from needing
+Running a consensus node or validator will prevent you from needing
 to use an RPC.
 
 You can set up a [validator](../nodes/validator-node.md)
-or [full consensus node](../nodes/full-consensus-node.md)
+or [consensus node](../nodes/consensus-node.md)
 for the previous portion of the tutorial.
 
 Note: this may take some time depending on how you choose to sync the

nodes/full-consensus-node.md → nodes/consensus-node.md

@@ -1,41 +1,32 @@
 ---
-description: Learn how to set up a Celestia full consensus node.
+description: Learn how to set up a Celestia consensus node.
 outline: deep
 ---
 
-# Setting up a Celestia full consensus node
+# Consensus node
 
 <!-- markdownlint-disable MD033 -->
 <!-- markdownlint-disable MD013 -->
 <script setup>
 import constants from '/.vitepress/constants/constants.js'
 </script>
 
-This guide covers how to set up a full consensus node on Celestia.
-Full consensus nodes allow you to sync blockchain history in the Celestia
+This guide covers how to set up a consensus node on Celestia.
+Cconsensus nodes allow you to sync the entire blockchain history in the Celestia
 consensus layer.
 
-![full consensus node](/img/nodes/full-consensus-node.png)
+![consensus node](/img/nodes/full-consensus-node.png)
 
-## Hardware requirements
+## Minimum hardware requirements
 
-The following hardware minimum requirements are recommended for running a
-full consensus node:
+The following minimum hardware requirements are recommended for running a consensus node:
 
-- Memory: **8 GB RAM**
+- Memory: **16 GB RAM**
 - CPU: **Quad-Core**
-- Disk: **250 GB SSD Storage**
+- Disk: **2 TB SSD Storage**
 - Bandwidth: **1 Gbps for Download/1 Gbps for Upload**
 
-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
+## Set up a consensus node
 
 The following tutorial is done on an Ubuntu Linux 20.04 (LTS) x64
 instance machine.
@@ -112,16 +103,23 @@ seeds = ""
 
 :::
 
-**Optionally**, you can set persistent peers in your `config.toml` file.
-You can get the persistent peers from the networks repository with
-the following commands:
+<details>
+  <summary>Optional: Set persistent peers</summary>
+
+Optionally, you can set persistent peers in your `config.toml` file.
+If you set persistent peers, your node will **always** try to connect
+to these peers. This is useful when running a local devnet, for example,
+when you would always want to connect to the same local nodes in your
+devnet. In production, setting persistent peers is advised only if you are running a [sentry node](https://hub.cosmos.network/main/validators/security.html#sentry-nodes-ddos-protection).
 
-Setting persistent peers is advised only if you are running a sentry node.
+You can get the persistent peers from the
+[@cosmos/chain-registry](/~https://github.com/cosmos/chain-registry)
+repository (for Mainnet Beta) or [@celestiaorg/networks repository](/~https://github.com/celestiaorg/networks) repo (for Mocha and Arabica) with the following commands:
 
 ::: code-group
 
 ```bash-vue [Mainnet Beta]
-PERSISTENT_PEERS=$(curl -sL https://raw.githubusercontent.com/celestiaorg/networks/master/{{constants.mainnetChainId}}/peers.txt | tr '\n' ',')
+PERSISTENT_PEERS=$(curl -s https://raw.githubusercontent.com/cosmos/chain-registry/master/{{constants.mainnetChainId}}/chain.json | jq -r '.peers.persistent_peers[].address' | tr '\n' ',' | sed 's/,$/\n/')
 echo $PERSISTENT_PEERS
 sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"/" $HOME/.celestia-app/config/config.toml
 ```
@@ -139,10 +137,11 @@ sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"
 ```
 
 :::
+</details>
 
 ## Storage and pruning configurations
 
-### Connecting a consensus node to a bridge node
+### Optional: Connect a consensus node to a bridge node
 
 If your consensus node is being connected to a celestia-node bridge node,
 you will need to enable transaction indexing and retain all block
@@ -163,7 +162,7 @@ setting of `0`:
 min-retain-blocks = 0 # retain all block data, this is default setting
 ```
 
-### Querying transactions by hash
+### Query transactions by hash
 
 To query transactions using their hash, transaction
 indexing must be turned on. Set the `indexer` to `"kv"` in your `config.toml`:
@@ -172,7 +171,7 @@ indexing must be turned on. Set the `indexer` to `"kv"` in your `config.toml`:
 indexer = "kv"
 ```
 
-### Accessing historical state
+### Optional: Access historical state
 
 If you want to query the historical state — for example, you might want
 to know the balance of a Celestia wallet at a given height in the past —
@@ -184,7 +183,7 @@ significant storage:
 pruning = "nothing"
 ```
 
-### Saving on storage requirements
+### Save on storage requirements
 
 If you want to save on storage requirements, consider using
 `pruning = "everything"` in your `app.toml` to prune everything. If you
@@ -199,15 +198,22 @@ pruning = "everything"
 min-retain-blocks = 0 # this is the default setting
 ```
 
-## Syncing
+## Sync types
+
+| Mode              | Block sync  | State sync      | Quick sync |
+|-------------------|-------------|-----------------|------------|
+| Time              | ~3 weeks    | TBD             | TBD        |
+| Trust assumptions | Most secure | Trusts snapshot | TBD        |
+
+### Option 1: Block sync
 
 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
+### Option 2: 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
@@ -240,7 +246,7 @@ Once setup, you should be ready to start the node as normal. In the logs, you sh
 see: `Discovering snapshots`. This may take a few minutes before snapshots are found
 depending on the network topology.
 
-### Quick sync
+### Option 3: 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
@@ -310,12 +316,6 @@ celestia-appd start --v2-upgrade-height <height>
 
 Optional: If you would like celestia-app to run as a background process, you can follow the [SystemD tutorial](./systemd.md).
 
-:::tip
-Refer to
-[the ports section of the celestia-node troubleshooting page](../nodes/celestia-node-troubleshooting.md#ports)
-for information on which ports are required to be open on your machine.
-:::
-
 ## Extra resources for consensus nodes
 
 ### Optional: Reset network
@@ -326,9 +326,9 @@ This will delete all data folders so we can start fresh:
 celestia-appd tendermint unsafe-reset-all --home $HOME/.celestia-app
 ```
 
-### Optional: Configuring an RPC endpoint
+### Optional: Configure an RPC endpoint
 
-You can configure your full consensus node to be a public RPC endpoint.
+You can configure your 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.
 

nodes/full-storage-node.md

@@ -6,7 +6,7 @@ description: Set up a Celestia full storage node.
 
 This tutorial will guide you through setting up a Celestia full storage
 node, which is a celestia-node that doesn't connect to celestia-app
-(hence not a full consensus node), but stores all the data.
+(hence not a consensus node), but stores all the data.
 
 ## Overview of full storage nodes
 

nodes/hardfork-process.md

@@ -40,5 +40,5 @@ The two testnets where hardforks are deployed are:
 
 The Lemongrass hardfork is the first consensus layer breaking change since Celestia's Mainnet Beta genesis block. The Lemongrass hardfork includes all of the CIPs listed in [CIP-17](/~https://github.com/celestiaorg/CIPs/blob/main/cips/cip-17.md). The Lemongrass hardfork will be executed on Arabica, then Mocha, then Mainnet Beta. The hardfork will take place at an "upgrade height" that will be coordinated offline on a per-network basis. The upgrade heights will be announced in advance (see [Network upgrades](./participate#network-upgrades)) to give node operators time to download and start a compatible binary prior to the upgrade height.
 
-- If you are a full consensus node or validator operator: you will need to download and run a celestia-app v2.x.x binary prior to the `--v2-upgrade-height` to remain on the canonical chain. You do not need to use a tool like [cosmovisor](https://docs.cosmos.network/main/build/tooling/cosmovisor) to upgrade the binary at the upgrade height.
+- If you are a consensus node or validator operator: you will need to download and run a celestia-app v2.x.x binary prior to the `--v2-upgrade-height` to remain on the canonical chain. You do not need to use a tool like [cosmovisor](https://docs.cosmos.network/main/build/tooling/cosmovisor) to upgrade the binary at the upgrade height.
 - If you are a DA node operator, you will need to download and run a compatible celestia-node binary (likely v0.16.0) prior to the upgrade height.

nodes/mainnet.md

@@ -121,7 +121,7 @@ your own node.
 
 ### Consensus nodes
 
-- [Full consensus node](./full-consensus-node)
+- [Consensus node](./consensus-node)
 - [Validator node](./validator-node)
 
 #### Community consensus RPC endpoints
@@ -254,7 +254,7 @@ celestia <da_type> start --core.ip <url> -–core.grpc.port <port>
 :::tip Bridge nodes
 Not all RPC endpoints guarantee the full block history.
 Find [an archive endpoint on the community dashboard](https://celestia-tools.brightlystake.com/)
-or run your own full consensus node with no pruning for your bridge node.
+or run your own consensus node with no pruning for your bridge node.
 :::
 
 RPCs for DA nodes to initialise or start your celestia-node to Mainnet Beta with:

nodes/mocha-testnet.md

@@ -24,7 +24,7 @@ participate in Mocha:
 
 Consensus:
 
-- [Full consensus node](./full-consensus-node)
+- [Consensus node](./full-consensus-node)
 - [Validator node](./validator-node)
 
 Data Availability:
@@ -93,7 +93,7 @@ to their respective DA node.
 :::tip Bridge nodes
 Mentioned below RPC endpoints do not guarantee you the download of 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.md) in order to download
+run a local [consensus node](./consensus-node.md) in order to download
 full blocks from it.
 :::
 

nodes/overview.md

@@ -14,7 +14,7 @@ Consensus:
 - [Validator node](./validator-node):
   This type of node participates
   in consensus by producing and voting on blocks.
-- [Full consensus node](./full-consensus-node): A celestia-app Full node
+- [Consensus node](./consensus-node): A celestia-app full node
   to sync blockchain history.
 
 Data Availability:

nodes/systemd.md

@@ -9,7 +9,7 @@ processes.
 
 ## Consensus nodes
 
-If you are running a validator or full consensus node, here are
+If you are running a validator or consensus node, here are
 the steps to setting up `celestia-appd` as a background process.
 
 ### Start the celestia-app with SystemD

nodes/validator-node.md

@@ -19,9 +19,9 @@ Validator nodes allow you to participate in consensus in the Celestia network.
 The following hardware minimum requirements are recommended for running a
 validator node:
 
-- Memory: **8 GB RAM**
-- CPU: **6 cores**
-- Disk: **500 GB SSD Storage**
+- Memory: **16 GB RAM**
+- CPU: **8 cores**
+- Disk: **2 TB SSD Storage**
 - Bandwidth: **1 Gbps for Download/1 Gbps for Upload**
 
 ## Setting up a validator node
@@ -30,7 +30,7 @@ The following tutorial is done on an Ubuntu Linux 20.04 (LTS) x64
 instance machine.
 
 First, follow the instructions on
-[setting up a full consensus node](/nodes/full-consensus-node#setting-up-a-full-consensus-node).
+[setting up a consensus node](/nodes/full-consensus-node#set-up-a-full-consensus-node).
 
 ### Wallet
 
@@ -241,7 +241,7 @@ to configure your `config.toml` file to select which transactions to index.
 ## Additional resources
 
 For additional resources, refer to
-[the extra resources for consensus nodessection of the full consensus node page](./full-consensus-node.md#extra-resources-for-consensus-nodes).
+[the extra resources for consensus nodessection of the consensus node page](./consensus-node.md#extra-resources-for-consensus-nodes).
 
 ## FAQ