Files
observer/crates/blackbeard-data/migrations/0002_block_at_tip.sql
rob thijssen 7e5c2de936
All checks were successful
deploy / build (push) Successful in 6m36s
deploy / deploy-web (push) Successful in 6s
deploy / deploy-api (push) Successful in 16s
feat: sparkline history under the headline tiles
Adds `GET /v1/chains/{chain}/series` and a sparkline under network hashrate,
difficulty, block time and miners. Height gets none — it only goes up, and a
straight diagonal reports nothing.

The chart is bucketed by height, not by time: every point is the same number of
blocks, so every point carries equal statistical weight and a stretch nobody
recorded stays the same width on the axis as one that was. A bucket is the
window over fifty, which makes a full window exactly fifty buckets — that is
what lets the rolling miner count at the last point be the same number printed
in the tile above it, rather than a per-bucket count that would sit well below
it. Buckets are anchored to absolute height for the same reason `miner_series`
bins from the epoch: anchored to the tip instead, every boundary slides by one
on every block and the chart shifts under a reader watching it.

Interval comes from `authored_at`, never `observed_at`. A gap fill writes a
whole batch of observation times within the same second, so deltas taken from
it read as a chain producing hundreds of blocks a second — the trap
`RollingWindow`'s `at_tip` flag exists to avoid, which until now lived only in
memory. It is a column as of `0002`, so the distinction survives a restart and
`observed_at` is interpretable at all.

Each point's interval is a three-bucket moving average. The mean of one
bucket's gaps still carries real Poisson error — 72 blocks of a 15 s interval
lands at ±1.8 s — and across fifty points that draws a chain that appears to
change size every few minutes and does not.

Fixes a wrong number found on the way in: `pallet_qpow` retargets in
`on_finalize`, so `QPoWApi_get_difficulty` at the latest state is the
difficulty for the *next* block, not the one just seen. Every stored difficulty
was off by one block — invisible, because a gradual retarget still looks
plausible. It is now asked at `header.parent_hash`, the same call the miner
made when it built the block. A node that has pruned that state gets `None`
rather than the current value: substituting it is exactly how a gap fill would
stamp today's difficulty across a stretch of old heights. The CLI backfill had
the same bug at greater scale, copying one reading across an entire range.

Unknowns are drawn as breaks in the line, never interpolated: an outage, a
difficulty a pruned node cannot supply, a point without a full window of
authors behind it. A chart that guesses across what was never recorded is the
same class of lie as a hashrate divided by a sync speed, and just as hard to
catch afterwards.

Read against the dataviz skill first, per CLAUDE.md. Single series, one hue;
emphasis on the newest point is `--data-bright`, a lighter step of the same
bronze, because the usual "current period in the accent" convention is the one
change that would break this palette. The hover readout borrows each tile's
note line — five floating tooltips across a row of 180px tiles is a pile, not a
hover layer — and the same readout is on keyboard focus and in the aria-label,
since the line does not start at zero and its height is not a quantity anyone
should be estimating.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jp6a8EDar9ueEhAxzep4V5
2026-09-08 14:39:27 +03:00

23 lines
1.4 KiB
SQL

-- Record whether a block's `observed_at` is a tip observation.
--
-- `RollingWindow::push` has always taken an `at_tip` flag, because the elapsed
-- time between importing two *historical* blocks measures the observer catching
-- up rather than the network producing — divide difficulty by that and the
-- hashrate is wrong by orders of magnitude while still rendering as a number.
-- That flag lived only in memory, so nothing in the database distinguished a
-- block seen as it was mined from one fetched minutes later by a gap fill, and
-- every row in a backfilled batch carries very nearly the same `observed_at`.
--
-- Any query that treats `observed_at` as timing data therefore needs this
-- column. The chain series does not — it derives block interval from
-- `authored_at`, the chain's own clock, which is immune to when we looked — but
-- the propagation and withholding signal documented on `BlockObservation` is
-- precisely `authored_at` minus `observed_at`, and that difference means
-- nothing at all unless the observation was made at the tip.
--
-- Existing rows default to false: most of them *were* tip observations, but
-- which ones is not recoverable, and false reads as "not known to be" — the
-- conservative direction for a flag whose whole job is to stop untrustworthy
-- timings being used as if they were measurements.
alter table block add column at_tip boolean not null default false;