igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

Class v6 history lane, revision 3: the dataset-floor schedule priced per tier and against the chips (section 4.2a, main's ask of 11:2x UK)

Browse source 
docs/analysis/class-v6/history.md 4.2a: main's 6, 10 and 14 GiB steps checked against every tier's room under the standing 75 percent budget rule (the card-lifetime method, the bench table's 32 measured consumer cards as the population): 6 GiB does not fit the 8 GB tier under the rule (78 to 82 percent of the card; it fits only at a headless-rig reading of about 85 percent), 10 GiB retires the 10, 11 and 12 GB tiers and the Apple 16 GB laptop at year 2, 14 GiB retires the 16 GB tier at year 4, leaving 24 GB and above; beside it the schedule that drops the tiers in the order main named (5.5 GiB at the v6 epoch, 8 GiB at two years, 11 GiB at four) with the year each tier falls and its share of the measured cards (6 GB 3 percent at day one; 8 GB plus the 10 GB RTX 3080 plus Apple 16 GB 25 percent at year 2; 12 GB 22 percent at year 4; 16 GB 28 percent at the 16 GiB step; 24 GB and above hold). Against the chips: the hybrid-bonded or soldered chip sized at launch dies at the first step it cannot carry (the E3's shape, 20 to 27 months) but a maker reading a public consensus field sizes to the step it wants (USD 160 more of GDDR7 on a USD 470 part; about 3x the memory die area for the Jasminer shape); the f = 1 GDDR7 chip's 32 GB board pays USD 0 through 16 GiB and keeps 5.1x; the SRAM store pays capex only at the cache doubling (USD 46 to 111 per die) and keeps 0.92x and 1.86x. The fleet's hashrate-weighted card census is owed. The arithmetic is checked by script against the card-lifetime working sets.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-08 10:38:53 +00:00
parent d5c4b90d23
commit fd32fdc5ce
1 changed files with 33 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
docs/analysis/class-v6/history.md
View file

@ -234,6 +234,39 @@ The arithmetic that binds. A chip's memory is bought by the board, and today's p
So layer 2 as a rate "tracking chain state" ages out fixed-memory silicon only if the dataset grows faster than a chip generation's memory headroom, and every rate that does that retires the honest small cards first by the same table. The E3 is the only case in the record where a growth rule beat a chip, and it beat a chip that had under-provisioned memory by a factor the card fleet also hit (4 GB). The rule that would hurt the f = 1 chip is one that keeps the dataset above what one board of commodity DRAM holds at the chip's price point, and that rule is unaffordable for the honest fleet. The honest reading: layer 2 is the right lever class (the memory is the one parameter a stored-dataset chip cannot read as firmware), and its value is set by the floor and the ceiling, not by the tracking: a floor keeps the dataset above every SRAM die (class B stays closed: 2 GiB is 1,000 mm^2 of SRAM even at N5), and a ceiling keeps it under the honest tiers' memory. Between those two lines the chip's board holds whatever the card holds, and the growth rate changes nothing for it. What "tracking chain state" adds over the fixed schedule is governance (no release decides the size) and the class v5 link (the dataset is built from the state, so the size follows the state's record count naturally); it is not an anti-chip rate. Resolved by the synthesis lane (11:2x UK, `docs/design/class-v6-rotating-family.md` section 7b on `counter-asic-4`): layer 2's rule carries a per-year ceiling as its first constant, the fixed schedule's power-of-two step for that year, so the chain's state can bring a step forward and never add one; "retires cards before chips" is recorded as the reason the ceiling exists. Under that rule the table above is the ceiling's own schedule, and the honest 8 GB tier's year-12 line stands whatever the state does. What this file adds for the record: if the chain's state grew the way Ethereum's did (approximate, from memory: the account and storage state passed 100 GB in its eighth year), a dataset tracking it with no ceiling would have outgrown every consumer card inside the first decade; the ceiling is what makes layer 2 a governance rule and not a fleet-retirement rule. So layer 2 as a rate "tracking chain state" ages out fixed-memory silicon only if the dataset grows faster than a chip generation's memory headroom, and every rate that does that retires the honest small cards first by the same table. The E3 is the only case in the record where a growth rule beat a chip, and it beat a chip that had under-provisioned memory by a factor the card fleet also hit (4 GB). The rule that would hurt the f = 1 chip is one that keeps the dataset above what one board of commodity DRAM holds at the chip's price point, and that rule is unaffordable for the honest fleet. The honest reading: layer 2 is the right lever class (the memory is the one parameter a stored-dataset chip cannot read as firmware), and its value is set by the floor and the ceiling, not by the tracking: a floor keeps the dataset above every SRAM die (class B stays closed: 2 GiB is 1,000 mm^2 of SRAM even at N5), and a ceiling keeps it under the honest tiers' memory. Between those two lines the chip's board holds whatever the card holds, and the growth rate changes nothing for it. What "tracking chain state" adds over the fixed schedule is governance (no release decides the size) and the class v5 link (the dataset is built from the state, so the size follows the state's record count naturally); it is not an anti-chip rate. Resolved by the synthesis lane (11:2x UK, `docs/design/class-v6-rotating-family.md` section 7b on `counter-asic-4`): layer 2's rule carries a per-year ceiling as its first constant, the fixed schedule's power-of-two step for that year, so the chain's state can bring a step forward and never add one; "retires cards before chips" is recorded as the reason the ceiling exists. Under that rule the table above is the ceiling's own schedule, and the honest 8 GB tier's year-12 line stands whatever the state does. What this file adds for the record: if the chain's state grew the way Ethereum's did (approximate, from memory: the account and storage state passed 100 GB in its eighth year), a dataset tracking it with no ceiling would have outgrown every consumer card inside the first decade; the ceiling is what makes layer 2 a governance rule and not a fleet-retirement rule.
### 4.2a One schedule, priced (main's ask of 11:2x UK, for the 20:00 reading)
Main asked for one dataset-floor schedule priced per tier and against the chips, so the 20:00 reading carries a decision: 6 GiB at the v6 epoch, 10 GiB two years on, 14 GiB at four years, each step by height like a class epoch, the schedule a consensus field. The method is `card-lifetime-2026-10-05.md`'s: a card's room for the dataset is its usable memory (75 percent of card memory, the standing rule "the whole working set under 6 GB on an 8 GB card"; 50 percent of Apple unified memory) less the non-dataset working set (best: 32 KiB scratch, the cache freed after the build, 254 to 479 MiB by tier; worst: 128 KiB scratch, the cache resident, 600 to 1,500 MiB). The population is the bench table's measured cards (`site/miner-bench.json`, 8 October 2026: 32 distinct consumer cards, one Apple part, eight datacentre parts); the fleet's own card census is not a file this lane could find and is owed, so the shares below are by count of distinct measured cards, not by hashrate.
**What the memory arithmetic says about main's three steps.** A step fits a tier when the dataset plus the working set is under the tier's usable memory.
| Step | 8 GB (usable 6,144 MiB) | 10 GB (7,680) | 11 GB (8,448) | 12 GB (9,216) | 16 GB (12,288) | Apple 16 GB unified (8,192) | 24 GB (18,432) | 32 GB (24,576) |
|---|---|---|---|---|---|---|---|---|
| 6 GiB (6,144 MiB) | **does not fit the rule**: 6,398 best, 6,744 worst, 78 to 82 percent of the card; fits only if the budget rule moves to about 85 percent (a headless rig with no display) | fits (6,404 best, 63 percent) | fits | fits | fits | fits (6,432 MiB, 79 percent of its usable half) | fits | fits |
| 10 GiB (10,240 MiB) | out | out | out | **out**: 10,506 best, 10,888 worst, 86 to 89 percent | fits (10,518, 64 percent) | out | fits | fits |
| 14 GiB (14,336 MiB) | out | out | out | out | **out**: 14,614 best, 15,032 worst, 89 to 92 percent | out | fits (14,752, 60 percent) | fits |
So main's schedule as stated retires, under the standing budget rule: at 6 GiB the 6 GB tier and, unless the rule is loosened to about 85 percent, the 8 GB tier (22 percent of the measured consumer cards: the RTX 3070, 3070 Ti, 3060 Ti, 4060, 4060 Ti 8 GB, 5060, 2070 Super) on day one; at 10 GiB the 10, 11 and 12 GB tiers and Apple 16 GB (another 31 percent: the RTX 3080, 1080 Ti, 2080 Ti, 4070, 4070 Ti, 4070 Super, 5070, 3080 Ti, 3060, Arc B580) at year 2; at 14 GiB the 16 GB tier (28 percent: the RTX 5060 Ti, 5070 Ti, 5080, 4080, 4080 Super, 4070 Ti Super, 4060 Ti 16 GB, RX 9070 XT, RTX A4000) at year 4, leaving 24 GB and above (16 percent of the measured consumer cards, plus every datacentre part). That is not the tier order main's note describes, so the schedule that drops the tiers in that order is priced beside it:
| Step | Dataset | Year | Who falls off (share of the 32 measured consumer cards) | Who holds, and at what share of card memory (best / worst) |
|---|---|---|---|---|
| v6 epoch | 5.5 GiB (5,632 MiB) | 0 | the 6 GB tier (RTX 2060: 3 percent) | 8 GB at 72 / 76 percent (the worst case one point over the rule); 10 GB 77 percent; Apple 16 GB unified at 72 percent; everything larger |
| +2 years | 8 GiB (8,192 MiB) | 2 | the 8 GB tier (22 percent), the 10 GB RTX 3080 (3 percent: 8,452 of 7,680), Apple 16 GB unified (8,480 of 8,192) | 11 GB at 100 percent of usable (the 1080 Ti and 2080 Ti: out in practice, 6 percent); 12 GB at 69 / 72 percent; 16 GB; 24 GB; 32 GB; Apple 32 GB at 52 percent of its usable half |
| +4 years | 11 GiB (11,264 MiB) | 4 | the 12 GB tier (22 percent) | 16 GB at 70 / 73 percent; 24 GB at 48 percent; 32 GB; Apple 32 GB at 71 percent of its usable half |
| the fixed schedule's own steps beyond | 16 GiB | the year the state brings it forward, else year 28 | the 16 GB tier (28 percent); Apple 32 GB | 24 GB at 68 percent; 32 GB |
Reading, per tier, in the form main asked for (the year each falls off, and the share of today's measured cards that is): on the priced schedule the 6 GB tier falls at the v6 epoch (3 percent), the 8 GB tier and the 10 GB RTX 3080 and the Apple 16 GB laptop at year 2 (25 percent of the consumer cards plus the base Apple laptop), the 11 GB Pascal and Turing parts in practice at year 2 (6 percent), the 12 GB tier at year 4 (22 percent), the 16 GB tier at the 16 GiB step (28 percent), and 24 GB and above hold through every step priced. On main's schedule as stated the same tiers fall two years earlier each, and the 8 GB tier falls on day one unless the 75 percent rule moves. Either way this is the fleet-retirement rule the ceiling exists to bound (section 4.2): a step every two years retires a quarter of today's measured consumer cards each time.
**Against the chips, with the number.** Three chips, by what the step does to each:
| Chip | What a step costs it | The number |
|---|---|---|
| The hybrid-bonded DRAM chip sized at launch (the Jasminer X4's shape: DRAM dies bonded to the logic at tapeout, 5 GB per unit in 2021; the E3's shape in commodity form, 4 GB of DDR3 soldered to the board) | its memory is fixed at tapeout, so it dies at the first step it cannot carry, as the E3 did 20 to 27 months after shipping. On main's schedule a chip sized to the 6 GiB floor with 8 GB of bonded DRAM dies at the 10 GiB step (year 2); on the priced schedule a chip sized to 5.5 GiB with 8 GB dies at the 8 GiB step (year 2); a chip sized with 16 GB holds through year 4 on both and dies at the 16 GiB step. But the schedule is a consensus field read at genesis, so a maker sizes to the step it wants to survive: the X4's 5 GB was Ethash's DAG plus a year, chosen off a public schedule; the E3 died because its memory was sized to the CARD FLEET's limit, not to the schedule | kills only the chip that under-sizes; sizing to 16 GB costs the X4 shape about 3x its 2021 memory die area (approximate) and the E3 shape USD 160 more of GDDR7 (8 x USD 20, chip-model-v3 5.1) on a USD 470 part |
| The f = 1 GDDR7 chip on a board (the record's class C; 16 x 2 GB devices, 32 GB) | nothing until the dataset passes 32 GB: every step priced here fits its board; a bigger step buys more devices at USD 20 per 2 GB | USD 0 per step through 16 GiB; its 5.1x per joule and USD 2.8 per MH/s stand at every step |
| The SRAM store (the f = 0 recompute chip holding the cache on die) | the dataset's size costs it nothing (it derives every item); the CACHE's doubling under option C costs it capex only: 128 mm^2 and USD 46 per good die at 256 MiB, 255 mm^2 and USD 111 at 512 MiB (year 4 on the fixed schedule, or the year the state brings the doubling forward), 510 mm^2 and USD 306 at 1 GiB; and the mirror's size is what forces it onto a 7 nm or better node (the 5 October file, section 2.5) | USD 46 to 111 per die at the year-4 doubling; its edge stays 0.92x at the op budget and 1.86x per joule (`chip-model-v3.md` 5.4), unmoved by the dataset's steps |
The honest sentence for the 20:00 reading: the dataset-floor schedule is a fleet-retirement rule with a chip tax of USD 0 to 160 per unit on the chips that matter (classes C and B), and it kills only a chip whose maker ignores a public consensus field; the one precedent of a growth rule killing a chip (the E3) is a precedent of a maker sizing to the fleet, not to the schedule. If the schedule is adopted, the 75 percent budget rule and the 6 GiB floor cannot both stand for the 8 GB tier; 5.5 GiB keeps the 8 GB card inside the rule in the best case and one point over in the worst, and the headless-rig reading (about 85 percent) is what makes 6 GiB fit. The fleet's hashrate-weighted census is owed before the share column is read as a hashrate share.
### 4.3 Layer 3: scheduled family epochs by height, every 180 days, no release ### 4.3 Layer 3: scheduled family epochs by height, every 180 days, no release
What is declared: a new instruction family goes live on a height schedule, every 180 days by default, with no release (the reserve of spec 1.13.2, ordered at genesis). The record of scheduled change against chips: What is declared: a new instruction family goes live on a height schedule, every 180 days by default, with no release (the reserve of spec 1.13.2, ordered at genesis). The record of scheduled change against chips: