dan-jan/celestia-networks

Celestia Devnet

• Celestia Devnet
  • Quickstart
  • Overview
    • Celestia (Validator) Bridge Nodes
    • Celestia Light Nodes
  • Run a Light Node
  • Run a Bridge Node
  • Run a Validator Bridge Node
  • Troubleshoot

Note: This guideline is only relevant for the current devnet. As we approach to testnet, there will be a new guide

Quickstart

Devnet participants have the option of running:

1. Light Nodes (low CPU, 5GB+ disk): get started
2. Bridge Nodes (low CPU, 100GB+ disk): get started
3. Bridge Validator Nodes (same node as 2): get started
4. Full DA Nodes are under development

You can view chain activity at the current devnet-2 explorer: https://celestia.observer/

Overview

Devnet demonstrates Celestia’s data availability capabilities by running two individual but connected networks:

1. A libp2p DA network with Bridge Nodes which relay and process blocks from the celestia-core network and Light Nodes, which do data availability sampling those blocks.
2. A p2p Consensus network ("celestia-core network) with Validator Nodes that handles the underlying consensus and block production.

Note that mainnet may look very different from this devnet implementation, as the architecture continues to be improved. You can read more about devnet decisions here (see ADR).

Celestia (Validator) Bridge Nodes

Specifically, Bridge Nodes:

1. Import and process “raw” headers & blocks from a trusted Core process (meaning a trusted RPC connection to a celestia-core 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.

From an implementation perspective, Bridge Nodes run two separate processes:

1. Celestia App with Celestia Core (see repo)
   • Celestia App is the state machine where the application and the proof-of-stake logic is run. Celestia App is built on Cosmos SDK and also encompasses Celestia Core.
   • Celestia Core is the state interaction, consensus and block production layer. Celestia Core is built on Tendermint Core, modified to store data roots of erasure coded blocks among other changes (see ADRs).
2. Celestia Node (see repo)
   • Celestia Node augments the above with a separate libp2p network that serves data availability sampling requests. The team sometimes refer to this as the "halo" network.

Celestia Light Nodes

In the Devnet, Light Nodes:

1. Connect to a Celestia Bridge Node in the DA network. Note: Light Nodes do not communicate with each other, but only with Bridge Nodes.
2. Listen for ExtendedHeaders, i.e. wrapped “raw” headers, that notify Celestia Nodes of new block headers and relevant DA metadata.
3. Perform data availability sampling (DAS) on the received headers

Run a Light Node

Light nodes (CLN) ensure data availability. This is the most common way to interact with the Celestia network.

Note: In future implementations, Light Nodes can also publish transactions (see ADR), though in Devnet, transactions are left to Bridge Nodes.

Installation

• Light Node Setup Guide
• Source code repository(s):
  • celestia-node

Run a Bridge Node

Bridge Nodes connect the aforementioned Consensus and DA networks.

Installation

• Bridge Node Setup Guide
• Repositories:
  • celestia-app
  • celestia-node

Run a Validator Bridge Node

Bridge Nodes have the option of validating the P2P network using its Celestia App component. However, running validator nodes is not a requirement to learn about Celestia’s main value proposition.

Only the top 100 validators make it into the active validator set. The team is not looking for additional validators at the moment and recommend running light or bridge nodes instead.

Installation

• Validator Setup Guide
• Repositories:
  • celestia-app

Troubleshoot

Please navigate to this link to find more details