HostNexFlow › Library › Run a Celestia light node
Run a Celestia light node — what it verifies and how DAS works
Celestia's light node is the most radical piece of commodity hardware in crypto: a machine on a laptop's budget that can verify a network's data was published without downloading it. Here is the mechanism — data availability sampling — and what running one actually takes.
Celestia is a modular blockchain: it does one job — ordering data and proving the data was published — and leaves execution to the rollups and chains that post to it. The job has a name: data availability. A blob posted to Celestia is only useful if everyone can retrieve it, so the network's core promise is "this data exists and anyone can get it." The light node is how that promise gets checked: the most common way to interact with the network, per Celestia's own quickstart, and the reason the design works at all.
What a light node actually verifies
A Celestia light node doesn't store blocks and doesn't execute transactions. Per the docs, it does exactly two things with each new block: it listens for the ExtendedHeader — the block header plus the data availability metadata — and it performs data availability sampling (DAS) against it. The ExtendedHeader carries a data availability header: a compact set of Merkle roots committing to the block's contents, arranged so any piece of the data can be proven against it.
The node then picks random positions in the block's data square and asks the peer network for those shares with their proofs. Every share that returns correctly is evidence the block was published in full — because of how the data is encoded (next section), a producer that withheld data can't answer random samples for long. Enough successful samples, and the light node accepts the block's data as available with high statistical confidence — having downloaded maybe a few kilobytes of a multi-megabyte block.
Light nodes aren't passive observers, either. They can post and retrieve blobs themselves — celestia blob submit and celestia blob get — which is why a light node is the standard interface for applications writing to Celestia, not just an auditor bolted on the side.
How data availability sampling works
The mechanism behind DAS is worth understanding because it's the entire product. Celestia arranges a block's data into a square of fixed-size shares, then applies 2D Reed-Solomon erasure coding — extending the square with redundant shares so the full block can be reconstructed from any sufficient subset. Rows and columns are committed in Namespaced Merkle Trees, which produce both the data root in the header and the proofs that let a sampler verify each returned share sits in the committed square.
The consequence for an attacker is brutal: withholding even a modest fraction of the block forces withholding a large share of the extended square — erasure coding means partial withholding is detectable, and hiding data entirely requires suppressing most of it, which sampling catches almost immediately. Each random share a light node successfully samples is an independent check; stack enough of them and the probability that data was withheld while every sample passed collapses toward zero. That's the asymmetry the network is built on: verification cost stays flat while block size grows — the whole point of a DA layer that can scale without asking verifiers to buy servers.
Equally important is what sampling does not prove — covered honestly in the FAQ below, because the boundary is the most misunderstood part of the design.
What it costs to run
Celestia's hardware requirements doc (numbers as of September 2026 — check the live page before provisioning) draws the contrast cleanly:
| Node type | Memory | CPU | Disk | Bandwidth |
|---|---|---|---|---|
| Light node | 500 MB RAM | Single core | 20 GB SSD | 56 Kbps |
| Bridge node | 64 GB RAM | 32 cores | 25 TiB NVMe | 1 Gbps |
| Light node, unpruned headers | 500 MB RAM | Single core | 7 TiB NVMe | 56 Kbps |
| Consensus validator | 32 GB RAM | 32 cores | 12 TiB NVMe | 1 Gbps |
A light node runs on basically anything — an old laptop, a Raspberry Pi-class box, the free tier of a VPS. The disk figure assumes pruning; keeping unpruned headers long-term is the archival row. There's also a zero-install variant: Lumina, a light node that runs in your browser, live on the Celenium explorer — DAS as a web page, which tells you how cheap the verifier role was designed to be.
Running one, for real
The actual sequence from the quickstart (paraphrased — run the doc's version when you do this):
Light node on the Mocha testnet
Install celestia-node per the docs, then:
celestia light init --p2p.network mocha # create the node store + key celestia light start \ --core.ip public-endpoint.celestia-mocha.quiknode.pro \ --core.port 9090 --core.tls \ --p2p.network mocha # samples start flowing celestia state account-address # your node's address (fund via the Mocha faucet) celestia blob submit 0x676d 0x676d # post your first blob — "gm", the ritual celestia blob get <height> 0x676d <commitment> # retrieve it back
Three networks share the same binary: celestia (Mainnet Beta — real TIA, real blobspace fees), mocha (the consensus testnet), and arabica (the devnet where node-side features land first). The --p2p.network flag selects it; the --core.* flags point at a consensus gRPC endpoint the node uses for state access like balances and blob submission. Start on mocha or arabica — faucet TIA is free — and treat mainnet as the graduation, not the rehearsal.
What a light node does not do
Honesty section, because the usual description oversells it. A light node proves availability, not validity: it guarantees the data was published, not that the transactions inside it are correct or that a rollup's state transition was right. Execution and validity live with the rollup that posted the blob — Celestia's job ends at "the data exists and is retrievable." It also doesn't validate consensus in the full-node sense, and it stores samples, not blocks — it's a verifier and an interface, not an archive. Those limits are the design working as intended: Celestia deliberately separated data availability from execution so each could scale independently, and the light node is what makes the DA half of that separation checkable by anyone.
Where we stand on Celestia
We run Celestia infrastructure, and it's verifiable rather than asserted: two validators on the mocha-4 testnet (celestiavaloper1ptg3… and celestiavaloper1ylu7…, bonded state read live from the staking LCD on every page view) plus a DA light node on arabica-11 — the same node type this page describes, doing production-shape sampling on the devnet where the client ships first. /networks/celestia/ carries the live read and the explorer links; /networks/ is the full list of chains we operate on; /validators/ is the on-chain footprint. The house rule applies to us exactly as it applies to anyone else: don't trust the copy, check the chain.
Frequently asked
What does a Celestia light node do?
A Celestia light node listens for ExtendedHeaders — block headers carrying the data availability metadata — and performs data availability sampling on each one: it requests small random shares of the block's erasure-coded data and checks the returned proofs against the data root. Enough successful samples means the block's data was published. Light nodes can also post and retrieve blobs, which makes them the standard way applications talk to Celestia.
How much data does a Celestia light node download?
A tiny fraction of each block — the header plus a small set of randomly sampled shares — rather than the block itself. That asymmetry is the entire design: Celestia's hardware guide lists a light node at roughly 500 MB RAM, a single core, 20 GB of SSD and 56 Kbps of bandwidth, against a bridge node's 64 GB RAM, 32 cores and 25 TiB. Verification was made cheap on purpose so the verifier set can be large.
Does a Celestia light node verify that transactions are valid?
No — and that boundary is the point of the architecture. Celestia orders data and proves it was published; whether a transaction inside a blob is valid is the execution layer's problem (the rollup that posted it). A light node's guarantee is narrower and extremely strong: if its samples succeed, the data exists and can be retrieved by anyone who needs to check it.
What is the difference between a Celestia light node and a bridge node?
A light node samples — it verifies availability without storing blocks. A bridge node does the heavy work: it connects the data-availability network to consensus, downloads full blocks, and serves the data the light nodes sample against. Per Celestia's hardware guide, a bridge node wants 64 GB RAM, 32 cores and around 25 TiB of NVMe — a light node runs on hardware a laptop laughs at, which is exactly the trade-off that makes broad verification possible.
Which Celestia network should a light node run against?
Three networks share the same node software: celestia (Mainnet Beta, real TIA and real blobspace), mocha (the consensus testnet — our two validators live there), and arabica (the devnet where new node features land first — our light node runs on arabica-11). The --p2p.network flag selects the network; start on mocha or arabica with faucet TIA before pointing anything at mainnet.