Index Planck — it has public endpoints after all #6

New Issue

grenade · 2026-09-10T08:09:34Z

grenade commented

2026-09-10 08:09:34 +00:00

What

a1-planck.quantus.cat and a2-planck.quantus.cat both answer. The config
comment says Planck "publishes no RPC endpoint we can find", which was true when
it was written and is not now.

Planck · 0.6.4-phase-alignment · quantus-runtime v148
height 1,082,462 · PLK, 12 decimals, ss58 189
genesis 0x4901bf5c…e65e72
ZkTree::LeafCount 2,381,571 · System::Account 1000+ keys
ReversibleTransfers::NextTransactionId 0

A million blocks of history and 2.38M zk-tree leaves — a much larger corpus than
either chain currently indexed.

Measured cost, before deciding

Run in a dev instance alongside quantus and heisenberg:

3 chains backfilling      520 blocks/min total (planck 6.5/s)
CPU                       4.8% of one core
Postgres connections      5 held, 1 active     (pool is 8)
API p95                   summary 7ms · leaderboard 6ms · block 13ms · account 49ms

Entirely RPC-latency-bound — not CPU, not database. No new deployable is
needed, and the backfill task only reads in-memory state (tip height,
current runtime) while writing exclusively to Postgres, so it contends with
nothing the API serves.

Restart resilience confirmed by killing the process mid-backfill: event_scan.low
stayed put rather than jumping back to the tip. That matters here because
blackbeard-api-cert.path restarts the service several times a day on cert
rotation.

Decision

Added as-is, no throttle. ~46 hours to reach genesis at ~20 req/s against the
public endpoint. Hammering public decentralised testnet nodes exercises a core
design trait of blockchains, which is the point of their being there.

Follow-up filed separately: multiple endpoints per chain, so one going down
cannot hold the observer hostage.

## What `a1-planck.quantus.cat` and `a2-planck.quantus.cat` both answer. The config comment says Planck "publishes no RPC endpoint we can find", which was true when it was written and is not now. ``` Planck · 0.6.4-phase-alignment · quantus-runtime v148 height 1,082,462 · PLK, 12 decimals, ss58 189 genesis 0x4901bf5c…e65e72 ZkTree::LeafCount 2,381,571 · System::Account 1000+ keys ReversibleTransfers::NextTransactionId 0 ``` A million blocks of history and 2.38M zk-tree leaves — a much larger corpus than either chain currently indexed. ## Measured cost, before deciding Run in a dev instance alongside quantus and heisenberg: ``` 3 chains backfilling 520 blocks/min total (planck 6.5/s) CPU 4.8% of one core Postgres connections 5 held, 1 active (pool is 8) API p95 summary 7ms · leaderboard 6ms · block 13ms · account 49ms ``` Entirely RPC-latency-bound — not CPU, not database. **No new deployable is needed**, and the backfill task only *reads* in-memory state (tip height, current runtime) while writing exclusively to Postgres, so it contends with nothing the API serves. Restart resilience confirmed by killing the process mid-backfill: `event_scan.low` stayed put rather than jumping back to the tip. That matters here because `blackbeard-api-cert.path` restarts the service several times a day on cert rotation. ## Decision Added as-is, no throttle. ~46 hours to reach genesis at ~20 req/s against the public endpoint. Hammering public decentralised testnet nodes exercises a core design trait of blockchains, which is the point of their being there. Follow-up filed separately: multiple endpoints per chain, so one going down cannot hold the observer hostage.

grenade referenced this issue from a commit

2026-09-10 08:10:07 +00:00

feat: index Planck

grenade closed this issue

2026-09-10 08:10:07 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blackbeard/observer#6