SIMD-0164: ExtendProgramChecked loader-v3 instruction

[Lichtso]

No description provided.

[topointon-jump]

Looks good, would be great to just add a bit more detail. Thanks so much :)

[topointon-jump]

Could we describe:

• The discriminant of the new instruction.
• The data structure of the new instruction.
• What the new instruction will do - does it just call the ExtendProgram logic?

I know it's identical to ExtendProgram with some extra checks, but SIMD's should be able to be implemented without looking at the Agave source code.

[Lichtso]

I added a description of the interface of the new instruction. However, as we don't have a complete specification defining the exact behavior of the entire instruction is out-of-scope for this PR, in my opinion. I will gladly do so for the upcoming loader-v4 as that is more symmetric.

[buffalojoec]

This proposal looks good to me. I'm just a bit hung up on the new instruction's name.

We use the *Checked suffix across programs in SPL to typically imply that there's some kind of check being applied on the account data. Since the original ExtendProgram does this already (finalized check), naming the new one ExtendProgramChecked implies that there's been an additive check to the program's account data. However, this is not the case. It expects a signature now.

Is it possible to just change the instruction itself, since the feature gate you've proposed would disable the old one and enable the new one? Specifically, can't we add a feature gate to ExtendProgram that, once activated, requires this signer and performs the check?

This would be akin to the reverse of the Relax Authority feature gate for the Lookup Table builtin.

[Lichtso]

We can't modify / add stuff to existing instructions. That would break block explorer instruction parsing and the CLI tools.

The reason the new instruction is named Checked is because it adds an authority check, the same way we extended SetAuthority to SetAuthorityChecked.

[buffalojoec]

We can't modify / add stuff to existing instructions. That would break block explorer instruction parsing and the CLI tools.

The reason the new instruction is named Checked is because it adds an authority check, the same way we extended SetAuthority to SetAuthorityChecked.

Hm, okay - if we definitely need to do a new instruction and you've already used the *Checked suffix for an authority check before, then I'm good with it.

[smcio]

The SIMD looks good to me.

[joncinque]

Note that for tools like multisigs (squads, etc) and DAOs (realms, etc), this constitutes a breaking change, since the upgrade authority is typically a PDA, and those programs give limited control over what instructions they will sign with the DAO / multisig's PDA.

Before, it was very easy to just increase the size of the program permissionlessly if needed on a new deployment, and stick with the old process for upgrading the program. With this change, they'll need to check the size and optionally add the new instruction to extend whenever needed.

As another option, is it possible to simply add a lower bound for the extension? For example, just require that a program must be extended by at least 10k bytes.

[Lichtso]

We will concentrate our efforts on loader-v4 (and migrating loader-v3 programs to it). That combined with the concerns raised here made me retract this proposal.