SIMD-0089: Programify Feature Gate Program

[buffalojoec]

This proposal suggests replacing the non-existent native program at address
Feature111111111111111111111111111111111111 with a Core BPF Program, as
described in
SIMD 0088.

Feature accounts are already assigned the owner program address
Feature111111111111111111111111111111111111. Deploying a Core BPF program at
this address would provide engineers with the capability to revoke pending
feature activations.

Note: The process by which core contributors activate features would
remain completely unchanged.

EDIT: Linking roadmap for procedural purposes #76.

[buffalojoec]

Ok @CriesofCarrots I believe I've address all your feedback!

@lheeger-jump @ripatel-fd I would really appreciate you guys having a look at this one as well, when you have a chance.

[ripatel-fd]

I support the general direction of codifying the feature flag. Some thoughts on the exact feature queuing mechanism:

This SIMD effectively introduces a council of contributors that can vote to stop any feature activation.

It doesn't seem appropriate to me for a multi-sig to take on the critical task of managing the feature activation queue, even if validator governance is still required for activation. It's unclear to me what the risks are if this multi-sig gets compromised (e.g. via a supply chain attack). What if the multi-sig majority (two entities) blocks all feature activations or schedule features in an unsafe way? (considering some features depend on each other)

This means there is no recourse in the case of a mistaken queuing, discovery of a bug, or simply a desire to manage the cadence and schedule of activations.

Is this the gist of the problem we are trying to solve? I would prefer to address this problem in a different way: Prevent haphazard queuing of new feature flags.

In the current mechanism, upgrading the Solana Labs software version automatically signals feature flag support. As far as I understand, the only way to opt out is to not upgrade. However, validators operators are strongly incentivized to keep their software up-to-date.

IMHO, Feature flag activations and core BPF programs should instead only be upgradable via validator governance where each validator explicitly and manually signals support for (or disapproval of) a feature. This would greatly reduce the risk of accidental queuing or the process getting compromised. Emergency deactivation of features is still possible if a minority of stake mobilizes. (Albeit slower, but without the centralization of power on the multi-sig)

I would imagine validator operators running commands like this after an upgrade:

solana-validator feature approve "elf-loader-v5"
solana-validator feature disapprove "yet-another-elliptic-curve"

If there are features that require ordering, maybe we can just hardcode the dependencies of each feature in each validator implementation instead of managing the exact schedule via a native program.

[buffalojoec]

@ripatel-fd I appreciate the thoughts on the larger feature process overhaul, but I think it might be a bit easier to handle the building out of the new process piecemeal, focusing on one step at a time and what each step aims to solve.

This proposal specifically aims to solve the following problem: In our current feature activation process, we want to be able to revoke pending feature activations.

The proposal here is suggesting simply to replace Feature111111111111111111111111111111111111 with a BPF program that has a revoke instruction. We just need a good way to manage that program's upgrade authority.

It doesn't seem appropriate to me for a multi-sig to take on the critical task of managing the feature activation queue

This isn't what's being proposed here. Instead this multi-sig would only control the upgrade of the Feature Gate program at Feature111111111111111111111111111111111111. The actual control of queued features is unchanged from the current process.

IMHO, Feature flag activations and core BPF programs should instead only be upgradable via validator governance

I generally agree with this but unfortunately until we have proper validator governance we can't be blocked on engineering efforts. In my opinion a multi-sig is appropriate as an interim control until someday we decide to potentially replace that control with true validator governance, when the mechanism is available.

I think the rest of your thoughts on the larger effort are great and belong in the later SIMDs that will follow this one. What do you think?

[ripatel-fd]

This proposal specifically aims to solve the following problem: In our current feature activation process, we want to be able to revoke pending feature activations.

@buffalojoec That makes total sense and sounds good to me. I guess I overspeculated the long-term intention of this new feature gate program. That is probably out of scope for this SIMD anyways.

[ripatel-fd]

I support this SIMD since it improves security of the feature activation process. I think it would be worthwhile defining a contingency plan that the validator community can adopt in case they distrust or want to replace the veto multi-sig.

[lheeger-jump]

I am going to approve this but I expect it will be amended after we (FD) see a first implementation with more details. Before or after merging, can you link to a reference implementation?

[buffalojoec]

I am going to approve this but I expect it will be amended after we (FD) see a first implementation with more details. Before or after merging, can you link to a reference implementation?

https://github.com/solana-labs/solana-program-library/tree/master/feature-gate

Keep in mind the actual implementation of the program's source code is decoupled from this SIMD. The proposal herein is outlining:

• This program will exist as Core BPF
• This program will be upgradeable, managed by a multi-sig
• This program will possess the capability to revoke pending feature activations by clearing their data and assigning them back to the system program

Anything more code-specific beyond that last bullet I believe can be addressed within the PR review process without needing to amend this SIMD, right?

[lheeger-jump]

I am going to approve this but I expect it will be amended after we (FD) see a first implementation with more details. Before or after merging, can you link to a reference implementation?

https://github.com/solana-labs/solana-program-library/tree/master/feature-gate

Keep in mind the actual implementation of the program's source code is decoupled from this SIMD. The proposal herein is outlining:

• This program will exist as Core BPF
• This program will be upgradeable, managed by a multi-sig
• This program will possess the capability to revoke pending feature activations by clearing their data and assigning them back to the system program

Anything more code-specific beyond that last bullet I believe can be addressed within the PR review process without needing to amend this SIMD, right?

I think so!

[lheeger-jump]

Lets merge this on 08/01/2024?

[buffalojoec]

Lets merge this on 08/01/2024?

Sorry, is this DD/MM/YYY?

Fwiw, we need #88 first, but I think we're close to consensus on that one, too.

[jacobcreech]

Looks like we've got general consensus. Last call for any objections. We'll merge this after #88 on Thursday, January 25th if no objections are made.

[jacobcreech]

With #88 merged and the last call ended for this one, lgtm. Thanks for pushing this through and gathering consensus