CELESTIA / EXPERIMENTS WITH EVIDENCE
Analytics Lab.
Explore the network’s dependencies before they become incidents.
Loading chain data. Scenarios are hypothetical; no nodes will be changed.
Observe → rehearse → decide.
Use live voting-power data, test a failure or growth scenario, then export the assumptions and next checks.
RECORDED COMMITS, NOT AN UPTIME SCORE
Who made it into the commit?
Green: block signature included. Amber: absent. Violet: nil vote. Each strip shows the last 60 observed eligible commits.
COMPARE OBSERVED PARTICIPATION
Two identities. The same evidence window.
Each denominator counts that identity’s eligible observed heights. Changes to the active set can produce different denominators. This comparison is not an uptime or slashing verdict.
| Validator | Commit inclusion | Absent / nil | Longest absence run | Recent observed commits | Proposals |
|---|
A commit may omit a valid signature that arrived later. Absence here does not establish downtime, misconduct, jailing or slashing. Rates use only observed eligible heights. Gaps break absence streaks; current monikers label historical observations.
INTERACTIVE VOTING-POWER SCENARIOS
What if these identities went offline?
Select validator identities below. This models unavailable voting power, not an actual outage or an attack recommendation.
VOTING-POWER CONCENTRATION
How evenly is power distributed?
Identity-level concentration, not a count of independent operators.
Cumulative power, ranked largest first. Dashed line: equal-power distribution. Effective identity count = 1 / sum of squared voting-power shares.
Each segment represents one consensus identity, sized by voting power. Selected segments are amber. Identity counts do not establish independent operator counts.
SCENARIO RESULT
0%of voting power selectedNo scenario selected
Committing a block requires more than two-thirds of voting power. This simplified unavailable-power model excludes network topology, recovery and Byzantine behavior.
| Scenario | Validator | Voting power | Registered Fibre host | Last TLS probe |
|---|
A shared literal hostname is an observable dependency, not evidence of common ownership, datacenter or provider. Missing registry entries mean no match was observed. Fibre transport availability and consensus signing are separate measurements.
PLAN WITH EXPLICIT ASSUMPTIONS
Turn growth into a resource budget.
A local-ingress model and documented receive-buffer calculation. This is not the Foundation’s stake-to-shard sizing calculator.
Traffic & retention scenario
Example values only. Enter measured ingress to this Fibre server, including its shard overhead—not total chain throughput. Disk must be available to Fibre; existing workloads and raw devices are excluded.
Receive-buffer budget
Worst-case buffers ≈ connections × streams × 132 MiB. With 16 connections and 13 streams: 26.81 GiB, before other work. Separate Fibre and consensus disks are required by the documentation.
Celestia capacity documentation ↗Your operating envelope
Pin a baseline, change the inputs, and compare the resource delta before choosing an upgrade.
Growth sensitivity
Extend your plan with the fleet resource model ↗ or node setup workbench ↗.
Steady-state estimates exclude pruning delays, temporary files, database overhead, download traffic, disk endurance and burst behavior. No benchmark or capacity certification is implied. No server configuration is changed.
CHANGES SINCE OBSERVATION BEGAN
A journal, without invented history.
Active-set entries/exits and changes in TLS probe results. One observation region; events can reflect network path failures.
Registry host changes and voting-power movements are recorded as well. A host change is a configuration observation, not proof that the server migrated. Voting-power changes alone do not establish delegation activity or slashing.