c8d6acbbc2
- docs/analysis/horizon-2026-10.md section 1 rewritten as a standalone page: the project lead's three lines verbatim (fees cannot fund security for a decade; miners need to be the security; wrong constants and claims in our own text) with the recorded meaning (miners are the security always, no time bound, no stake, no outside checkpoints or committee; emission plus fees pay the miners, nobody pays upkeep; emission never decays on a schedule that assumes fees take over); the nine items with what landed tonight (proof verification in consensus da2d17ec with the switch off by default; the leave item 766e70ca; seven-window signalling 0760b844; the peer-driven unwrap class 8e2f5cbe; the receive-side version gate f1ea7a38; Ember's pause wording and activation guardb43d329,e5e1e92, e54a87b; the export-disk cap f9ad70e; the nine ledger rows plus X31 to X33); lane 8's measured verdicts (B never as class content, C the class v5 candidate); lane 5's 1 block/s verdict with the three gates for 10; the four decisions still owed - lanes table, section 4 (lanes 5, 6, 8) and section 5 (A2 dropped) brought current - docs/plans/ledger-decisions.md: the fud-close file (c6b0bad) now on master, since docs/fud-ledger.md already points at it, with the standing decisions section appended - docs/analysis/block-rate-devnet2.md: lane 5's experiment from gpu-fleetb965b64, unchanged Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
112 lines
9.3 KiB
Markdown
112 lines
9.3 KiB
Markdown
# Block rate on Devnet 2: 10 blocks per second against 1, on the rented fleet
|
|
|
|
6 October 2026, the project lead's experiment (through the coordinator, 17:5xZ): "Devnet 2 at a higher block rate for solo miners
|
|
(Kaspa's answer)". Branch `gpu-fleet`; the node profile on the fork branch `devnet2-bps` (1279a1d6 on release-0.3.14-node
|
|
4c6b129d): a suffixed devnet started with `IGNEUMD_DEVNET_BPS=10` (or 5) runs `BlockrateParams::new::<10>()` with the
|
|
TenBps subsidy and target time, Kaspa's Crescendo-style constants for that rate (k 124, merge depth, sample rates,
|
|
mergeset limit, parents, coinbase maturity from `consensus/core/src/config/bps.rs`); the shared devnet never reads the
|
|
variable, so the live digest and rules are untouched. Built on igneum-build-1 (`tools/build-remote.sh`). Numbers land
|
|
below as they are measured; every figure carries its source file under `~/Desktop/fleet/bps/`.
|
|
|
|
## The runs
|
|
|
|
| Run | Chain | Miners | Length | What is read |
|
|
|---|---|---|---|---|
|
|
| A | igneum-devnet-2, fresh genesis, 10 bps | the 38 wave pods plus the 4 Devnet 2 boxes (42 cards, about 2.0 GH/s) | 60 min | blocks per second achieved, blue and red blocks per minute (orphan rate), blue score growth, max reorg depth, checkpoint lock delay and weight at this voter count, p2p bytes per node per minute, node CPU and RSS, exec lag (height minus executed tip), payout intervals per miner from the coinbase records |
|
|
| B | the same boxes, fresh genesis, 1 bps | the same | 30 min | the same (the control) |
|
|
| A2 | three relays, 10 bps | the same | dropped: the network lane's read of run A (reds from node throughput, not topology) made a topology run uninformative without per-block CPU profiling on a pod; no provider gave inbound ports for a mesh | |
|
|
|
|
Payout interval per tier, from each run's measured block rate and the chain's hash: a 4070 at 28 MH/s, a 5090 at
|
|
128 MH/s, an 8x 4090 rig at 459 MH/s, at tonight's network hash and extrapolated to 1, 10 and 100 TH/s networks
|
|
(interval = blocks per second x miner share, the arithmetic in `tools/fleet/bps-collect.py`).
|
|
|
|
## Measured
|
|
|
|
### Run A: 10 blocks per second, star topology (19:17Z to 20:25Z)
|
|
|
|
Seed: the fork's igneumd (83702a35, `IGNEUMD_DEVNET_BPS=10`) on igneum-build-1 (188.40.146.49:26611, a public port), genesis
|
|
f682b78a4e64f0d2, digest 436d62a5b962e1c2, mining from 19:17:26Z. Miners: dn2-1/2/3 from 19:25Z, the 38 wave pods from 19:26Z
|
|
(each node beside the pod's live-devnet node on other ports, each dialling the seed only: no pod has an inbound port), 41 peers
|
|
on the seed. Collector rows every minute in `~/Desktop/fleet/bps/A.jsonl` (the first 20 minutes carry the seed's log counts only;
|
|
the watch line from 19:37Z after the seed's miner binary was staged).
|
|
|
|
| Read | Value | Source |
|
|
|---|---|---|
|
|
| Blocks at 10 min (19:36Z) | 5,733 (12.4 blocks/s over the last 159 s) | seed watch line |
|
|
| Blue score at 10 min | 1,307 (77 percent of blocks red) | the same |
|
|
| Blocks 19:37Z to 20:24Z (47 min) | 7,204 to 19,153: 4.25 blocks/s; blue +2,926: 1.09 blue/s; red share 77.6 percent | A.jsonl |
|
|
| Rate by six-minute interval | 7.7, 1.9, 2.9, 2.8, 5.9, 4.2, 3.2, 5.1 blocks/s; blue 0.6 to 1.6/s | A.jsonl |
|
|
| Tips | 246 at 10 min, 295 to 662 through the hour, rising | A.jsonl |
|
|
| Difficulty | 6,719 at 19:33Z, 3,551 at 19:36Z, 1,307 at 19:42Z, falling the whole hour (the rule reads the blue rate under target and eases) | seed watch, by hand |
|
|
| Max selected-chain reorg | 55 blocks (a late pod unwinding its genesis-only view at join) | seed log |
|
|
| Exec follower | tip 84 at 19:30Z, 240 at 20:19Z: 0.05 blocks/s against 1.1 blue/s; lag 18,901 blocks at the end | igneum_getExecStatus on the seed |
|
|
| Finality | 18 locks over the run (the voters are the 42 miners' keys) | seed log |
|
|
|
|
What it says: with 42 cards on a 10 blocks/s profile the DAG ran at 4 to 12 blocks a second but the selected chain at about
|
|
1.1 blue blocks a second, three in four blocks red, tips in the hundreds, and the difficulty rule eased all hour because it
|
|
measures the blue rate. The Horizon network lane's read of the same rows (`docs/analysis/horizon/network.md`): the reds came
|
|
from node throughput, not the star: the seed spent 61 to 345 ms of CPU per accepted block (mergeset 8 to 200), a 100 ms-per-block
|
|
knee at 10 blocks/s, RSS 5.4 GB at 12,000 blocks, and the propagation model gives 0.0 percent red for both star and mesh at
|
|
the measured latencies. So a topology run (A2) proves nothing without per-block CPU profiling on a pod, and was dropped. A
|
|
true mesh was also not possible tonight: no provider gave a pod with an inbound p2p port, the live devnet has the same star
|
|
(every rented node dials the two hands and the hub), and the standing-fleet ports rule in `docs/plans/gpu-fleet.md` is the fix.
|
|
|
|
The exec follower is the second finding: at 1.1 blue blocks a second it executed 0.05 blocks a second, so a 10 blocks/s chain
|
|
with payload would leave every wallet and prover reading state hours behind the tip within the first hour.
|
|
|
|
### Run B: 1 block per second, the control, same boxes (20:25Z to 20:58Z)
|
|
|
|
Seed restarted on a fresh genesis without the profile variable (1 block/s, the devnet's rule), the same 42 boxes, each wiped
|
|
and rejoined (`FRESH=1`), rows in `~/Desktop/fleet/bps/B.jsonl` from 20:28Z.
|
|
|
|
| Read | Value | Source |
|
|
|---|---|---|
|
|
| Blocks 20:28Z to 20:58Z (29.5 min) | 2,679 to 5,171: 1.41 blocks/s; blue +2,099: 1.19 blue/s; red share 15.8 percent over the window | B.jsonl |
|
|
| The first six minutes | 3.05 blocks/s against 1.93 blue/s: the join burst (42 nodes arriving on a chain minutes old, the late ones unwinding genesis-only views; max reorg 16) | B.jsonl |
|
|
| From 20:34Z on, by six-minute interval | 1.01, 0.99, 0.94, 1.05 blocks/s and 1.01, 0.99, 0.95, 1.05 blue/s: red share under 2 percent | B.jsonl |
|
|
| Tips | 21 at 20:28Z, 1 to 3 from 20:34Z | B.jsonl |
|
|
| Difficulty | 19.9 M at 20:28Z, 477 M by 20:34Z, 453 to 482 M after: settled in six minutes and flat | B.jsonl |
|
|
| Max selected-chain reorg | 16 (the join) | seed log |
|
|
| Exec follower | tip 188 at 20:28Z, 1,003 at 20:58Z: 0.46 blocks/s against 1.0 blue/s, lag 4,168 at the end and growing | igneum_getExecStatus |
|
|
| Finality | 0 locks in 30 minutes (the chain was 30 minutes old; the window had not filled) | seed log |
|
|
|
|
What it says: the same 42 cards that made a 77 percent red DAG at the 10 blocks/s profile made a chain with one to three tips
|
|
and under 2 percent red at 1 block/s, with the difficulty settled in six minutes. The exec follower still ran under the chain
|
|
(0.46 against 1.0), which is the follower's own ceiling on these pods and a finding for the proving lane, not for the rate.
|
|
|
|
## Per tier
|
|
|
|
From the collector's arithmetic (interval = 1 / (blocks per second x miner hash / network hash)); run A's "blocks" are
|
|
DAG blocks of which three in four were red, so its payout column is read at a quarter.
|
|
|
|
| Network hash | Miner | Run A (4.87 DAG blocks/s, 1.09 blue/s) | Run B (1.19 blue blocks/s) |
|
|
|---|---|---|---|
|
|
| tonight, 2.0 GH/s | 4070, 28 MH/s | a block every 0.2 min, of which 1 in 4 pays | a block every 0.8 min, nearly all pay |
|
|
| tonight, 2.0 GH/s | 5090, 128 MH/s | every 0.1 min | every 0.2 min |
|
|
| tonight, 2.0 GH/s | 8x 4090 rig, 459 MH/s | continuous | every 0.1 min |
|
|
| 1 TH/s | 4070 | every 2.0 h (DAG), about 8 h in blue blocks | every 7.0 h |
|
|
| 1 TH/s | 5090 | every 27 min (DAG), about 1.8 h blue | every 1.5 h |
|
|
| 1 TH/s | 8x 4090 rig | every 7.4 min (DAG), about 30 min blue | every 26 min |
|
|
| 10 TH/s | 4070 | every 20 h (DAG), about 3.4 days blue | every 2.9 days |
|
|
| 10 TH/s | 5090 | every 4.5 h (DAG), about 18 h blue | every 15 h |
|
|
| 10 TH/s | 8x 4090 rig | every 1.2 h (DAG), about 5 h blue | every 4.3 h |
|
|
| 100 TH/s | 4070 | every 8.5 days (DAG), about a month blue | every 29 days |
|
|
| 100 TH/s | 5090 | every 1.9 days (DAG), about a week blue | every 6.4 days |
|
|
| 100 TH/s | 8x 4090 rig | every 12 h (DAG), about 2 days blue | every 1.8 days |
|
|
|
|
Consequence per tier: a home 4070 at a 10 TH/s network waits about three days for a paying block either way (the 10 blocks/s
|
|
profile's extra DAG blocks are red, so the solo miner's variance does not fall by 10x, only by the blue-rate ratio of 1.09 to
|
|
1.19, which is nothing); the rig and the 5090 see the same. The way to a shorter wait for the small card is the pool, not
|
|
the block rate. GHOSTDAG pays red blocks nothing under this rule set, so a higher rate is only worth having where the blue
|
|
rate rises with it, which needs the node to process a block in well under 100 ms at mergeset 248.
|
|
|
|
## The recommendation for mainnet's rate
|
|
|
|
From the Horizon network lane (`docs/analysis/horizon/network.md`), carried here as the experiment's recommendation: 1 block
|
|
per second for the public testnet and the launch; 10 blocks per second behind three gates, each measured before the rate moves:
|
|
(1) per-block node CPU under 50 ms at mergeset 248 on a laptop core (tonight's seed: 61 to 345 ms, a knee at 100 ms per block
|
|
at 10 blocks/s, RSS 5.4 GB at 12,000 blocks); (2) finality constants and the clock cap expressed in DAA seconds, so a rate
|
|
change moves no human-time guarantee; (3) vote aggregation, so 100 voters at 10 blocks/s do not multiply the certificate
|
|
traffic by ten. Two fleet rules from the runs: a box never mines from a genesis-only view, it syncs first (the 55-block reorg
|
|
of run A and the 16-block one of run B were late pods unwinding); and the exec follower's rate (0.05 and 0.46 blocks/s on
|
|
these pods) is the state layer's ceiling and must be measured beside any block-rate change.
|