Detailed state structure: x7 milestone

x7 state structure — exact-7× bloatnet (block 24,641,589)

Detailed state-structure metrics for the exact 7× milestone, mirroring the mainnet report in #5 and the x5 report above.

Source: sidecar full bootstrap scan + an independent structural depth walk, both run as read-only RocksDB secondaries against the frozen FlatDb @ block 24,641,589 (stateRoot 0x232a7e563b670eef36517683dea143b067fab0cc6e51fa9d89d324d30ef5ec93). Every trie node was classified during a fresh full scan, so counts and the node-type breakdown are exact (no incremental-counter drift). Composition total = 1,550.02 GB = 7.001× mainnet, at the mainnet composition ratio 27.28 / 66.67 / 6.05 (account / storage / code). The two independent scans agree to within 0.01–0.1% on every total (the small gap is RLP-embedded inline child nodes that the structural walk descends into but the flat node-store does not separately key — same as x5).

Counts (exact)

Metric	Value
accountsTotal	2,769,423,698
contractsTotal (accounts with code)	418,717,675
unique codehashes (deduplicated)	not separately computed this run¹
contractsWithStorage	24,303,628
emptyAccounts	0
storageSlotsTotal	10,374,152,812
codeBytesTotal	93,768,798,488 (87.33 GiB)

¹ This scan ran in codesExternal mode and did not deduplicate codehashes (the per-shard counter reported unique == contract count). At x5 the dedup was real (243.5M unique / 357.4M contracts). The x7 figure is therefore omitted rather than reported as a spurious "no-sharing" result; codeBytesTotal above is the authoritative aggregate and matches the live composition sensor (93,775,576,510).

Trie sizes (exact)

Metric	Value
Account trie bytes	422,845,804,693 (393.81 GiB)
Storage trie bytes	1,033,401,336,163 (962.42 GiB)
Code bytes	93,775,576,510 (87.33 GiB)
Total	1,550,022,717,366 (1,443.57 GiB) — 7.001× mainnet

(The independent bootstrap full-scan reports 422,829,838,423 / 1,033,401,335,667 / 93,768,798,488 for the three components — within 0.004% of the live composition sensor above.)

Slot-count distribution per contract (exact)

Binned over the 20,990,659 distinct storage tries found by the storage scan. The account-trie walk counts 24,303,628 accounts with a non-empty storage root; the ~3.31M difference is contracts that share an identical storage-trie root with another contract (common among bloat-deployed contracts with identical storage layouts — the scan bins each distinct storage trie once).

Slots in contract	# contracts
0	0
1	14,358,324
2-3	4,030,290
4-7	1,537,127
8-15	509,166
16-31	195,946
32-63	124,647
64-127	85,612
128-255	52,337
256-511	37,217
512-1k	22,278
1k-2k	14,821
2k-4k	9,654
4k-8k	6,115
8k-16k	3,571
16k+	3,554

(Σ = 20,990,659 distinct storage tries.) 3,554 contracts hold ≥16,384 slots each and account for the bulk of the 10.37B total slots — x7 storage remains heavily concentrated in a small number of very large contracts (the structural depth walk spent ~80% of its 4 h runtime inside these deepest storage tries).

Account / storage trie node-type breakdown (exact)

Counted by classifying every node during the full bootstrap scan (flat node-store). Account leaves = accountsTotal and storage leaves ≈ storageSlotsTotal, as expected.

	branches	extensions	leaves
account trie	897,708,166	31,262,365	2,769,423,698
storage trie	3,588,753,325	107,559,351	10,374,152,812

(account-trie node total = 3,698,394,229; storage-trie node total = 14,070,465,488.) The independent structural walk counts ~0.1% more nodes (account branch 898,826,647 / leaf 2,769,423,716; storage branch 3,588,753,325 / leaf 10,375,038,061), the difference being RLP-inline children with no separate flat-store entry — both exact under their respective definitions.

Trie depth distribution (structural levels, exact)

Source: a root→leaf structural walk of the FlatDb (sidecar depth scan), using the same depth convention as Nethermind's TrieDiffWalker that produced the mainnet/x3.5/x5 figures in #5 — every branch and extension edge counts as one level (extensions do not add their skipped-nibble length). Format mirrors #5: fullNodeCount=branch, shortNodeCount=ext+leaf, valueNodeCount=leaf value (shifted +1 level, per the Geth/#5 convention).

Account trie — max depth 13, avg depth 8.32 levels, avg branch occupancy 4.08/16:

depth	shortNodeCount	fullNodeCount	valueNodeCount
0	0	1	0
1	0	16	0
2	0	256	0
3	0	4,096	0
4	0	65,536	0
5	0	1,048,576	0
6	0	16,777,216	0
7	129,013	268,297,462	0
8	1,482,850,405	558,156,578	91,758
9	1,208,270,342	52,819,876	1,453,160,383
10	106,121,316	1,648,175	1,206,743,860
11	3,297,287	8,838	106,112,731
12	17,676	21	3,297,266
13	42	0	17,676
14	0	0	42

Storage trie — max depth 13, avg depth 7.44 levels, avg branch occupancy 3.88/16:

depth	shortNodeCount	fullNodeCount	valueNodeCount
0	12,954,284	11,349,344	0
1	40,063,644	17,078,595	12,950,471
2	49,925,182	38,789,807	39,715,548
3	127,360,080	92,060,438	49,128,269
4	294,834,368	118,505,266	125,078,910
5	333,227,605	156,087,464	291,000,717
6	469,099,465	359,963,444	329,404,930
7	1,176,283,094	1,848,343,296	462,693,811
8	6,010,866,753	877,065,511	1,136,934,777
9	1,828,615,447	68,182,746	5,961,387,972
10	136,712,201	1,321,536	1,827,380,921
11	2,643,533	5,870	136,706,454
12	11,740	8	2,643,525
13	16	0	11,740
14	0	0	16

Takeaways (x7 vs x5)

1. Trie depth is structurally stable from 5× → 7×. Account trie max depth holds at 13, avg depth 8.32 (x5: 8.20); storage trie max depth 13, avg 7.44 (x5: 7.24). The tries gain one more populated branch level (account branches fill through depth 6→7) but typical witness depth stays ~8 — matching the proof-sampling maxDepth p50 = 8 in #27.
2. Account count grew 1.39× (1.99B → 2.77B), storage slots 1.33× (7.79B → 10.37B) vs x5, tracking the 1.40× total-size step at the held composition ratio.
3. Storage stays concentrated in a small set of mega-contracts. 3,554 contracts hold ≥16k slots; these dominate the 10.37B total slots and the deepest trie levels. The bulk of contracts-with-storage (14.36M of ~21M) hold exactly 1 slot.
4. Cross-method validation: two independent read-only scans (flat bootstrap + structural depth walk) of the same frozen state agree to within 0.01–0.1% on every node-type and byte total, and storage leaves (10.374B) match the live composition sensor exactly.

Scans run on the frozen exact-7× FlatDb as RocksDB read-only secondaries; the node was not advanced. Tooling: eth-perf-research/orchestrator sidecar (--mode=bootstrap) + cmd/statescan depth walk.

Start by comparing this x7 report with the mainnet report in #5, the x5 report, and the proof-sampling results in #27. The payload names the orchestrator bootstrap sidecar and cmd/statescan depth walk as the relevant entry points. No documentation change or completion criterion is specified, so the intended work must be clarified before implementation.