Take the aggregate apart: the join tree is the floor, not resolution

[defenwycke]

Stacked on #199 (which it merges), so review that first. Three findings from reading the code against the day's coordinator logs — two correct published figures, one identifies the real parallelism floor.

1. tx_prevouts cannot be dropped — it is a security invariant

The aggregate recomputes every accumulator leaf via coin_leaves_batch even though the chunks supply chunk_leaves. That looks like removable waste. It is not:

"take script validity from the chunks — but ONLY after proving the chunk verified THIS input… recompute the same binding digest the chunk committed… so a chunk cannot substitute a different valid spend of the coin, or validate it under attacker-chosen weaker flags."

⇒ The recomputation is the anti-substitution check. Sending less is not on the table.

2. ⛔ The resolution figures are stale — resolution is ~40x cheaper than believed

seg_serve_cmd's own comment estimates resolves at "roughly 11.35 M cycles each — about 175 s for sixteen". Measured, with resolves pushed to workers (#153):

block	po2	chunks	resolves	per resolve
741,000	22	4	1.0-1.2 s	0.28 s
741,000	20	16	4.4 s	0.28 s

Cleanly linear at 0.28 s — the chain model is right, the constant was not.

⛔ §8.10 records 16.3 s for the same block, same po2, same 4 chunks — 14x this measurement. It almost certainly predates #153 moving resolves off the coordinator, which is exactly the win that issue describes. Its companion 196 s figure for block 962,000 inherits the doubt, and both are now flagged at source.

⇒ Resolution is not the floor. It also corrects a claim made earlier in this session that resolution becomes 26% of the aggregate after the read fix.

⚠ Not fully settled: block 962,000 has 376 segments against 741,000's 28, so a conditional-size dependence cannot be excluded from within-block evidence. Re-measure on a tip block.

⚠ It is linear in chunk count, so fan-out is not free forever — 64 chunks ≈ 18 s serial, 128 ≈ 36 s. Worth knowing before picking a chunk count for a large fleet.

3. ⏰ The join tree is level-synchronous — that is the real floor

while level_recs.len() > 1 {
    loop {                                    // hard barrier
        if have == npairs { break; }
        sleep(300ms);
    }

A 116-segment aggregate is 7 levels of [58, 29, 14, 7, 4, 2, 1], and the tail cannot fill a fleet:

cards	join-tree efficiency	levels that cannot fill the fleet
2	93%	0 of 7
8	68%	4 of 7
16	54%	5 of 7
32	40%	6 of 7

⛔ This is why #199's two-card measurement looked healthy — N=2 is the one regime where the problem is invisible.

Two separable problems:

1. Barriers — fixable, host-side. Start a join as soon as its two children exist rather than waiting for the level. No METHOD_ID move, ships alone.
2. Narrow tail — structural. The last levels hold 4, 2, 1 jobs; no binary tree avoids that. ✅ But it is free under the bounded-lag framing, because block h's tail overlaps block h+1's wide segment phase — a performance argument for that framing on top of the cost one.

⚠ The projection calibrates one unit cost from a single N=2 point and assumes t_join ≈ t_seg, unverified. The shape follows from the tree arithmetic alone.

Ranked levers

lever	worth	where	METHOD_ID?
witness read → write_slice	2.05x on the aggregate	guest	yes — rides #139
pipeline the join tree	up to ~1.4x at 32 cards	host	no
resolution	~4.5 s at 16 chunks	—	not worth attacking
tx_prevouts	⛔ breaks soundness	—	—
seg-serve dispatch	no evidence it binds	—	—

Docs only.

https://claude.ai/code/session_015nyynoX7kXHe7zCF3j6Jbf