diff --git a/docs/analysis/block-rate-devnet2.md b/docs/analysis/block-rate-devnet2.md index b8b5e7cd..3c0524d9 100644 --- a/docs/analysis/block-rate-devnet2.md +++ b/docs/analysis/block-rate-devnet2.md @@ -14,6 +14,7 @@ below as they are measured; every figure carries its source file under `~/Deskto |---|---|---|---|---| | 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 @@ -53,12 +54,59 @@ true mesh was also not possible tonight: no provider gave a pod with an inbound 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 +### 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 -TIER_TABLE +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 -RECOMMENDATION +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. diff --git a/docs/bench-log.md b/docs/bench-log.md index 533677be..2b37eab1 100644 --- a/docs/bench-log.md +++ b/docs/bench-log.md @@ -2014,3 +2014,15 @@ USD 20 an hour on community pods, against a devnet of 1.16 GH/s. Consequence: the devnet's hash is rentable for the price of a dinner, so nothing on it is a security result; the counter-ASIC and finality work is tested there for correctness, not for cost. The cost argument only starts at the TH/s scale, where the rental market's supply (not its price) is the limit, and that number belongs in the litepaper with this caveat. + +## Block rate on Devnet 2, 6 October 2026 (branch gpu-fleet): 10 blocks per second against 1 on 42 rented cards + +Run A (10 blocks/s profile, star topology, 65 min): 4.87 DAG blocks/s, 1.09 blue blocks/s, 77.6 percent red, tips 250 to 660, +max reorg 55, difficulty easing all hour (6,719 to 1,307), the exec follower at 0.05 blocks/s (lag 18,901 at the end). Run B +(1 block/s, same boxes, 30 min): 1.41 blocks/s over the window with the join burst, 1.0 blocks/s and under 2 percent red from +minute six, tips 1 to 3, difficulty settled in six minutes (453 to 482 M), the exec follower at 0.46 blocks/s. The network +lane's read: run A's reds came from node throughput (61 to 345 ms CPU per accepted block at mergeset 8 to 200), not from the +star. Per tier the blue rate decides the payout interval (1.09 against 1.19 blue/s: a 4070 at 10 TH/s waits about three days +for a paying block either way), so the higher rate buys the solo miner nothing until the node processes a block in under 50 ms +at mergeset 248. Recommendation (the lane's): 1 block/s for the testnet and the launch, 10 behind three measured gates. +Full tables and sources: `docs/analysis/block-rate-devnet2.md`, rows in `~/Desktop/fleet/bps/{A,B}.jsonl`.