# Setting up a Celestia bridge node This tutorial will go over the steps to set up your Celestia bridge node. Bridge nodes connect the data availability layer and the consensus layer. ## Overview of bridge nodes A Celestia bridge node has the following properties: 1. Import and process “raw” headers & blocks from a trusted core process (meaning a trusted RPC connection to a consensus node) in the Consensus network. Bridge nodes can run this core process internally (embedded) or simply connect to a remote endpoint. Bridge nodes also have the option of being an active validator in the consensus network. 2. Validate and erasure code the “raw” blocks 3. Supply block shares with data availability headers to light nodes in the DA network. ![bridge-node-diagram](/img/nodes/BridgeNodes.png) From an implementation perspective, Bridge nodes run two separate processes: 1. celestia-app with celestia-core ([see repo](https://github.com/celestiaorg/celestia-app)) - **celestia-app** is the state machine where the application and the proof-of-stake logic is run. celestia-app is built on [Cosmos SDK](https://docs.cosmos.network) and also encompasses **celestia-core**. - **celestia-core** is the state interaction, consensus and block production layer. celestia-core is built on [Tendermint Core](https://docs.tendermint.com), modified to store data roots of erasure coded blocks among other changes ([see ADRs](https://github.com/celestiaorg/celestia-core/tree/master/docs/celestia-architecture)). 2. celestia-node ([see repo](https://github.com/celestiaorg/celestia-node)) - **celestia-node** augments the above with a separate libp2p network that serves data availability sampling requests. The team sometimes refers to this as the “halo” network. ## Pruned and archival modes Bridge nodes run in pruned mode by default. They retain recent headers and data within the storage window and can begin syncing from a recent point instead of from genesis. To retain historical headers and data, pass `--archival` every time you start the bridge node. A new archival node syncs from genesis, so it needs more storage and access to peers that still hold the historical headers and data. Archival nodes can still log pruning activity: they remove redundant erasure-coded data while keeping the original data and headers. > **Warning:** Choose archival mode before the node's first start and include > `--archival` every time it starts, including in a systemd service or another > process manager. A store previously started in pruned mode cannot switch to > archival mode; initialise a fresh store to sync from genesis. Omitting > `--archival` on a later start converts an archival store to pruned mode > without refusing startup. It deletes historical headers and original data > outside the storage window, not just redundant erasure-coded data. Adding > `--archival` again does not restore the deleted history or reverse the conversion. Both modes can use a non-archival consensus endpoint. Provision it to retain blocks within the storage window (`169h`) so the bridge node can fetch recent blocks from consensus. The live block listener still fetches newly announced blocks from that endpoint. During header sync, the bridge node routes recent ranges to the consensus endpoint and older ranges to the header peer exchange. Header fetches can also fall back to peers when the consensus endpoint lacks a requested height. The data availability sampler (DASer) retrieves the corresponding share data separately from DA peers. This fallback does not guarantee that peers retain the full history. ## Hardware requirements See [hardware requirements](/operate/getting-started/hardware-requirements). ## Setting up your bridge node The following tutorial is done on an Ubuntu Linux 20.04 (LTS) x64 instance machine. Deploy the Celestia bridge node with the following steps. ### Setup the dependencies Follow the tutorial for [installing the dependencies](/operate/getting-started/environment-setup). ### Install Celestia Node Install the `celestia-node` binary, which will be used to run the bridge node. Follow the tutorial for [installing `celestia-node`](/operate/data-availability/install-celestia-node). ### Initialize the bridge node Run the following: ```sh celestia bridge init --core.ip --core.port ``` After v0.21.5, the `--core.port` must be specified. In most cases, it is port 9090 by default. > **Warning:** Make sure port 2121 TCP/UDP is open and publicly accessible on your bridge node so it can be discovered by other peers in the DHT network. This port is essential for P2P connectivity and if not properly configured, your node won't be able to participate in the network effectively. Refer to [the ports section of the celestia-node troubleshooting page](/operate/maintenance/troubleshooting#ports) for information on which ports are required to be open on your machine. Using an RPC of your own, or one from the [list on the Mocha testnet page](/operate/networks/mocha-testnet#community-rpc-endpoints), start your node. Connecting to a consensus node endpoint (flag: `--core.ip string`) provides the light node with access to state queries (reading balances, submitting transactions, and other state-related queries). Here is an example of initializing the bridge node: **Mainnet Beta** ```sh celestia bridge init --core.ip --core.port ``` **Mocha** ```sh celestia bridge init --core.ip --core.port \ --p2p.network mocha ``` ### Run the bridge node Start the bridge node with a connection to a consensus node's gRPC endpoint, which is usually exposed on port 9090: **Pruned (default)** ```sh celestia bridge start --core.ip --core.port ``` **Archival** ```sh celestia bridge start --core.ip --core.port --archival ``` Here is an example of starting the bridge node on Mocha: ```sh celestia bridge start --core.ip --core.port 9090 --p2p.network mocha ``` Add `--archival` to this command if you need to retain historical headers and data. If you're connecting your bridge node to a localhost consensus node (`--core.ip localhost` or `--core.ip 127.0.0.1`), ensure that gRPC is enabled in your consensus node's `app.toml` configuration file. Look for the `[grpc]` section and verify that `enable = true` is set: ```toml [grpc] # Enable defines if the gRPC server should be enabled. enable = true # Address defines the gRPC server address to bind to. address = "localhost:9090" ``` Without proper gRPC configuration, the bridge node will not be able to connect to the consensus node. You can create your key for your node by [following the `cel-key` instructions](/operate/keys-wallets/celestia-node-key). Once you start the bridge node, a wallet key will be generated for you. You will need to fund that address with Testnet tokens to pay for `PayForBlob` transactions. You can find the address by running the following command: ```sh ./cel-key list --node.type bridge --keyring-backend test --p2p.network ``` You do not need to declare a network for Mainnet Beta. Refer to [the chain ID section on the troubleshooting page for more information](/operate/maintenance/troubleshooting). You can get testnet tokens from: - [Mocha](/operate/networks/mocha-testnet) > **Note:** If you are running a bridge node for your validator, it is highly recommended to request Mocha testnet tokens as this is the testnet used to test out validator operations. #### Optional: run the bridge node with a custom key For an archival bridge node, append `--archival` to either start command below to preserve archival mode. In order to run a bridge node using a custom key: 1. The custom key must exist inside the celestia bridge node directory at the correct path (default: `~/.celestia-bridge/keys/keyring-test`) 2. The name of the custom key must be passed upon `start`, like so: **Mainnet Beta** ```sh celestia bridge start --core.ip --keyring.keyname \ --core.port ``` **Mocha** ```sh celestia bridge start --core.ip --keyring.keyname \ --p2p.network mocha --core.port ``` #### Optional: Migrate node id to another server To migrate a bridge node ID: 1. You need to back up two files located in the celestia-bridge node directory at the correct path (default: `~/.celestia-bridge/keys`). 2. Upload the files to the new server and start the node. ### Optional: start the bridge node with SystemD Follow the [tutorial on setting up the bridge node as a background process with SystemD](/operate/maintenance/systemd). For an archival bridge node, use the archival `ExecStart` from that tutorial before starting the service, and keep `--archival` on every restart. You have successfully set up a bridge node that is syncing with the network. ### Optional: enable on-fly compression with ZFS Follow the [tutorial on how to set up your DA node to use on-fly compression with ZFS](/operate/data-availability/storage-optimization).