Feature Gate Program

[buffalojoec]

Problem

Once a feature is scheduled to be activated, there's no way to revoke (or cancel) a pending activation. This can be problematic in the case of a feature that suddenly needs revision, or has been otherwise decided to not be activated.

Proposed Solution

Control feature activations through an on-chain program.

Overview

Currently, when features are scheduled to be activated, accounts are created for these feature activations. These accounts are assigned under ownership of a specific empty account with address Feature111111111111111111111111111111111111.

We can simply replace the empty account at Feature111111111111111111111111111111111111 with an on-chain Feature Gate program at the same address, leaving the existing flow for features completely unchanged.

How Features Are Created

In a nutshell, features are requested to be activated via GitHub issue (see this example). In order to request feature activation, one must generate a keypair - as described in these comments - and submit the public key with the issue.

A feature account is then created using this instruction set with data representing a None value for the feature state and the feature ID is added to the feature set. The feature is now marked for activation.

At the epoch boundary, the validator checks for all new feature activations, and writes the bank slot (the slot the feature is activated at) into the feature account state (ie. Some(slot)) (see Bank's compute_active_feature_set function). The feature is now active.

The Feature Gate Program

With an on-chain program in place of Feature111111111111111111111111111111111111, instructions can be added to this program to control the account state of pending feature activations.

To specifically address the problem stated in this issue (revoking features slated for activation), this program would have a RevokeFeature instruction.

This RevokeFeature instruction would look something like this:

enum FeatureGateProgramInstruction {
  /// Revokes a pending feature activation.
  ///
  /// Accounts expected by this instruction:
  ///
  ///   0. `[w]` Feature
  ///   1. `[ ]` Destination (for rent lamports)
  ///   2. `[s]` Authority
  RevokeFeature,
...

This RevokeFeature instruction would do the following when invoked:

• Withdraw rent lamports from the feature account
• Realloc the data to zero
• Assign the account to the System Program
• Refund the lamports to the specified destination

With this new account state, the bank's attempt to load the feature ID as a valid feature would fail gracefully, since the owner would no longer match (see feature::from_account(..)).

This would effectively revoke (or delete) a pending feature!

Note: Swapping Feature111111111111111111111111111111111111 for an on-chain program would also allow us to add other instructions that may one day be necessary for managing feature activations.

Procedure

Step 1: Modify the function replace_program_account in runtime/src/bank.rs to replace both the program account and the program data account.

This will make it possible to replace the existing empty account at Feature111111111111111111111111111111111111 with a program

Step 2: Replace Feature111111111111111111111111111111111111 with a no-op program using a feature activation.

We would start with a no-op program, effectively leaving our feature gate process completely unchanged.

Step 3: Upgrade the no-op program at Feature111111111111111111111111111111111111 to the functioning Feature Gate program, complete with a RevokeFeature instruction (described above).

This will allow us to revoke features as described above

Note: For any cluster, the change in step 1 must be activated in order to execute step 2.