Bridge Nodes Depend on Archival gRPC — Key Findings and How We’re Supporting the Network

Node Operators1 posts508 views11 likesLast activity Nov 2025

validatusinternalOP

Nov 2025♥ 11

Bridge Nodes Depend on Archival gRPC — Our Findings and How We Are Supporting the Network

TL;DR

Only a very small number of gRPC endpoints currently provide true archival history from block 1.
Bridge nodes can sync from pruned endpoints during normal operation — but cannot fully recover from them after crashes or corrupted disks.
This creates a bridge-recovery bottleneck, with most operators relying on a tiny set of archival sources.
We now run multiple archival gRPC nodes and publish bridge snapshots to help strengthen the network.
More community-run archival endpoints would significantly improve overall resilience.

In short: lots of pruned endpoints — almost no real escape paths for rebuilding a broken bridge node.

Hi everyone ,

with the Mainnet Beta upgrade around the corner, we want to share some insights from a technical analysis we conducted on archival infrastructure — and how we are contributing to a more resilient network.

This post is meant to provide transparent value to node operators, regardless of delegation outcomes. We believe shared infrastructure strengthens the entire Celestia ecosystem.

What We Investigated

Over the past weeks, we analyzed the availability and reliability of archival gRPC endpoints by:

Scraping RPC & gRPC endpoints from the Cosmos Chain Registry
Automatically verifying:
- Live RPC endpoints
- Live gRPC endpoints
- Which gRPC endpoints expose full block history starting at block 1
Checking block-height consistency across providers
Identifying nodes suitable for bridge node syncing

Key Finding

Only a very small number of public endpoints currently provide all of the following at the same time:

gRPC enabled
Full archival history (from block 1)
Up-to-date block height

For day-to-day operation, bridge nodes can sync from pruned gRPC endpoints as long as those endpoints stay online and keep enough recent history.

However, this becomes a problem in recovery scenarios – for example:

a bridge node crashes and needs to be rebuilt from scratch
a disk is corrupted
a major upgrade goes wrong and you have to wipe and resync

In these cases, a bridge can only fully recover if there is either:

a recent, trusted snapshot, or
a truly archival gRPC / RPC endpoint that still serves data from block 1.

Our measurements show that the network currently depends on very few such archival gRPC sources that can be used as full recovery paths for bridge nodes.

This concentrates risk: if those few archival providers are unavailable or fall behind, operators may face slow, fragile, or even blocked recovery options for their bridge nodes.

In short:

The network operates with plenty of pruned endpoints but almost no true escape paths for rebuilding a broken bridge node.

Why Archival gRPC Matters for Bridge Nodes

Bridge nodes rely on archival gRPC to:

Reconstruct namespace Merkle trees
Perform Data Availability Sampling (DAS)
Verify historical headers and data-availability proofs back to genesis
Avoid relying on pruned nodes, which cannot serve historical proofs

A lack of reliable archival endpoints means:

Slower recovery (if recovery is even possible)
Higher sync fragility
Increased load on the few existing archival providers

What We Are Doing to Help

Bridge Node Snapshots

We will maintain up-to-date bridge snapshots, enabling operators to:

Start a fully-synced bridge node
Skip long initial sync periods
Recover quickly after upgrades
Reduce load on limited archival gRPC endpoints

Full Archival Consensus Nodes With Open gRPC

We have started to operate several independent full archival nodes, providing:

Public gRPC endpoints
Full block history from block 1
High uptime monitoring
Upgrade-ready infrastructure and continuous monitoring

These nodes are intended as reliable fallback sources for bridge nodes, especially during upgrade windows.

Call for Community Collaboration

We encourage operators and validators with capacity to:

Run at least one archival consensus node
Expose gRPC publicly
Announce availability to the community

Even a small increase in archival providers significantly improves overall network reliability.

If you are running an archival node and want it included in our monitoring set, feel free to reach out.

Technical

We also built a global RPC benchmarking and gRPC archival-detection system [1] that measures endpoints from multiple Cloudflare POPs worldwide and checks:

Latency
HTTP health
Block height
Archival depth (via gRPC Block 1 check)
“Latest height” status (with ±5 block tolerance window)

The screenshot below shows a sample run of our gRPC endpoint check tool against Celestia endpoints. This is CLI output from our probe — the dashboard UI will be shared soon.

[1]: gRPC Endpoint Check (Archival Detection) — sample CLI output from our probe

Operators interested in performance benchmarking or adding their endpoints to our public metrics are welcome to connect.

We’ll share the dashboard URL very soon!

Questions to the Community

We’d love to hear your insights:

Are you running a full archival node with gRPC enabled?

Would you be open to listing it as a sync source for bridge nodes?
Have you experienced bridge-sync issues during previous upgrades?
Would a shared list of vetted archival gRPC nodes be useful to operators?
Should Celestia consider publishing a recommended minimum set of archival nodes?
Is anyone working on tooling for automatic fallback between archival RPC sources?

Thanks for reading — and for helping strengthen the Celestia network.

We welcome collaboration and discussion.

— Validatus Team

← Back to Discussions