Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3173
Found by: #401 (the census wiring, #400)
The measurement
A node starting with an empty state directory censuses every epoch from 2 to the current one, in a
single pass, before it can report a requirement. Measured on mainnet from PR #401's branch:
- 103 epochs walked, ~11 minutes of continuous chain reads to reach epoch 104.
- Each epoch costs a timestamp binary search for its start block plus a full puzzle-hash coin
read at that height.
- Epoch 2 resolved at height 5,906,783; epoch 104 at 9,196,171.
It grows without bound, by one epoch per week, forever. A node joining in year three faces ~150
epochs; in year five, ~250. Nothing in the design caps it.
Why this is worth fixing rather than tolerating
- A new node cannot answer
dign collateral requirement for its first ~11 minutes — and correctly
says unknown throughout, which is honest but is also a cold-start window that lengthens every week.
- The cost is per fresh state dir, not per install. A reset, a container, a CI run, or a
reprovisioned host pays it again.
- The work is entirely redundant across nodes: every node computes the identical historical record
set, because the model is deterministic and the inputs are on chain. That is the definition of work
that wants a checkpoint.
Two shapes worth considering, not a decision
A bounded catch-up. A node does not need every historical epoch to operate — it needs the current
one, and enough history to serve peers and to satisfy the advancing-height check. Walking back N epochs
and marking the rest absent would bound the cold start, at the cost of a node that cannot answer
dig.getCollateralEpoch for older epochs. That trade needs stating, because sampled sync exists
precisely so peers can serve history to each other.
A checkpoint. The historical record set is deterministic and identical on every node, so a signed
checkpoint at a known epoch would let a node start from there and census forward. That reintroduces a
trust anchor — and the whole point of §24.10's verification design is that a record is believed because
it is recomputable, not because of who sent it. A checkpoint would need to be recomputable too, or
it is a different trust model wearing a performance hat.
Do not assume sampled sync solves this. It cannot, today: adopt returns Advisory whenever the
population is unknown, and there is no collection site at all
(#401 states this). Even once wired, adopting history from
peers is a different trust posture from computing it, and §24.10 deliberately prefers a node's own
census.
Acceptance
A node with an empty state directory reports a current-epoch requirement in a bounded time that does
not grow with chain age, with the trade-off it accepts written into SPEC.md — whether that is
history it declines to serve, or a checkpoint whose recomputability is stated.
Not urgent: ~11 minutes is tolerable today and the node is honest about unknown throughout. It is
filed now because the cost is invisible until it is large, and because the design decision is cheaper to
make before anything depends on the current behaviour.
Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3173
Found by: #401 (the census wiring, #400)
The measurement
A node starting with an empty state directory censuses every epoch from 2 to the current one, in a
single pass, before it can report a requirement. Measured on mainnet from PR #401's branch:
read at that height.
It grows without bound, by one epoch per week, forever. A node joining in year three faces ~150
epochs; in year five, ~250. Nothing in the design caps it.
Why this is worth fixing rather than tolerating
dign collateral requirementfor its first ~11 minutes — and correctlysays
unknownthroughout, which is honest but is also a cold-start window that lengthens every week.reprovisioned host pays it again.
set, because the model is deterministic and the inputs are on chain. That is the definition of work
that wants a checkpoint.
Two shapes worth considering, not a decision
A bounded catch-up. A node does not need every historical epoch to operate — it needs the current
one, and enough history to serve peers and to satisfy the advancing-height check. Walking back N epochs
and marking the rest absent would bound the cold start, at the cost of a node that cannot answer
dig.getCollateralEpochfor older epochs. That trade needs stating, because sampled sync existsprecisely so peers can serve history to each other.
A checkpoint. The historical record set is deterministic and identical on every node, so a signed
checkpoint at a known epoch would let a node start from there and census forward. That reintroduces a
trust anchor — and the whole point of §24.10's verification design is that a record is believed because
it is recomputable, not because of who sent it. A checkpoint would need to be recomputable too, or
it is a different trust model wearing a performance hat.
Do not assume sampled sync solves this. It cannot, today:
adoptreturnsAdvisorywhenever thepopulation is unknown, and there is no collection site at all
(#401 states this). Even once wired, adopting history from
peers is a different trust posture from computing it, and §24.10 deliberately prefers a node's own
census.
Acceptance
A node with an empty state directory reports a current-epoch requirement in a bounded time that does
not grow with chain age, with the trade-off it accepts written into
SPEC.md— whether that ishistory it declines to serve, or a checkpoint whose recomputability is stated.
Not urgent: ~11 minutes is tolerable today and the node is honest about
unknownthroughout. It isfiled now because the cost is invisible until it is large, and because the design decision is cheaper to
make before anything depends on the current behaviour.