From 8595666492042bae199c0fd9140dd7b56a5b5467 Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 21 Nov 2023 18:09:03 +0000 Subject: [PATCH 1/8] simd: programify feature gate program (2) --- proposals/programify-feature-gate-2.md | 149 +++++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 proposals/programify-feature-gate-2.md diff --git a/proposals/programify-feature-gate-2.md b/proposals/programify-feature-gate-2.md new file mode 100644 index 00000000..52518f6e --- /dev/null +++ b/proposals/programify-feature-gate-2.md @@ -0,0 +1,149 @@ +--- +simd: '0089' +title: Programify Feature Gate Program +authors: + - Joe Caulfield +category: Standard +type: Core +status: Draft +created: 2023-11-21 +feature: (fill in with feature tracking issues once accepted) +supersedes: '0077' +--- + +## Summary + +This proposal suggests replacing the non-existent native program at address +`Feature111111111111111111111111111111111111` with a Core BPF Program, as +described in +[SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88). + +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. + +## Motivation + +Currently, a feature is queued for activation by a keypair holder creating an +empty account and assigning it to the +`Feature111111111111111111111111111111111111` program. + +Because there is no actual program implementation at this address, the queuing +is irreversible; if the runtime knows about a feature gate at some address, it +will activate it at the next epoch boundary. 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. + +A fully-implemented Core BPF program would take ownership of those accounts and +support revoking queued features, giving engineers more flexibility and +safeguards. + +## Alternatives Considered + +The Feature Gate program could instead be implemented as a built-in native +program, rather than a Core BPF program. However, this would mean any changes to +the program would need to be implemented by all validator clients in +coordination. This makes upgrading the program cumbersome and potentially +dangerous. + +With the Feature Gate program instead implemented as a Core BPF program, the +program could be upgraded through the official feature-gate process. Thus, +changes to the program need only to be done once and are protected by the +feature activation process. + +Another alternative to a Core BPF program is a standard, upgradeable BPF program +whose upgrade authority is controlled by a multisig, with key-holders from each +client team - Solana Labs, Jito, Jump, and possibly Syndica. This arrangement +would make gating upgrades behind feature gates much more difficult. + +## New Terminology + +- Feature Gate program: The Core BPF program that all feature accounts will be + assigned to +- "Revoke" or "revoke pending activation": The act of reallocating a feature + account's data to zero, assigning it to the System Program, and defunding its + lamports balance - effectively removing it from the runtime's recognized set + of pending feature activations. + +## Detailed Design + +The program would initially be designed to support one instruction: +`RevokePendingActivation`. Any other instructions or functionality this program +may support in the future is outside the scope of this SIMD. + +As mentioned above under "New Terminology", when this instruction is invoked by +a feature key-holder, the program will reallocate the account to zero, assign it +back to the System Program, and defund its lamports balance. As a result, the +runtime will no longer recognize this feature as pending, since it will no +longer be owned by `Feature111111111111111111111111111111111111`. + +Consider the instruction as it may appear in the Feature Gate program: + +```rust +pub enum FeatureGateInstruction { + /// Revoke a pending feature activation. + /// + /// A "pending" feature activation is a feature account that has been + /// allocated and assigned, but hasn't yet been updated by the runtime + /// with an `activation_slot`. + /// + /// Features that _have_ been activated by the runtime cannot be revoked. + /// + /// Accounts expected by this instruction: + /// + /// 0. `[w+s]` Feature account + /// 1. `[w]` Destination (for rent lamports) + RevokePendingActivation, +} +``` + +The non-existent program at `Feature111111111111111111111111111111111111` can be +considered analogous to a no-op native program. Thus, the official processes +outlined in +[SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88) +for migrating a native program to Core BPF and upgrading a Core BPF +program can be used to enable this new program. + +Consider the following steps to activate Feature Gate: + +1. Migrate the native no-op program at + `Feature111111111111111111111111111111111111` to a Core BPF no-op. +2. Upgrade the Core BPF no-op to add the `RevokePendingActivation` instruction. + +Executing these two steps would effectively activate Feature Gate without any +changes to existing processes. + +## Impact + +Core contributors are positively impacted by this change, since the ability to +revoke pending feature activations is a significant security advantage. + +There is otherwise no change to the activation process whatsoever. This includes +queuing features for activation with the CLI and the timing of their activation +by the runtime. + +## Security Considerations + +Currently the accounts used for feature-gating are owned by a program ID that +does not have any implementation. This means that there is no on-chain authority +that can modify feature accounts once they've been created under +`Feature111111111111111111111111111111111111`. This allows the runtime to +confidently update their state upon activation. + +With this proposal, a live BPF program - which can accept instructions from +anyone and execute code - will be the owner of these accounts. This creates some +risk if _both_ the program's processor code as well as a secure system for +upgrading the program are not properly managed. + +However, since this program would be Core BPF, its upgrades are protected by the +feature gate process. Thoroughly reviewed and safe processor code should +mitigate any new risks associated with this change. + +## Backwards Compatibility + +This change is 100% backwards compatible with the existing feature activation +process. It *only* adds the ability to revoke pending activations. From 114f261d65312d5af3aaf5b9ba0399dcde6819e7 Mon Sep 17 00:00:00 2001 From: Joe Date: Thu, 7 Dec 2023 21:49:23 -0600 Subject: [PATCH 2/8] clarify a few points --- proposals/programify-feature-gate-2.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/programify-feature-gate-2.md b/proposals/programify-feature-gate-2.md index 52518f6e..fd1d4451 100644 --- a/proposals/programify-feature-gate-2.md +++ b/proposals/programify-feature-gate-2.md @@ -51,9 +51,11 @@ coordination. This makes upgrading the program cumbersome and potentially dangerous. With the Feature Gate program instead implemented as a Core BPF program, the -program could be upgraded through the official feature-gate process. Thus, -changes to the program need only to be done once and are protected by the -feature activation process. +program could be upgraded through the official feature-gate process described +in +[SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88). +Like all Core BPF programs, changes to the program only need to be done once +and are protected by the feature activation process. Another alternative to a Core BPF program is a standard, upgradeable BPF program whose upgrade authority is controlled by a multisig, with key-holders from each @@ -63,7 +65,7 @@ would make gating upgrades behind feature gates much more difficult. ## New Terminology - Feature Gate program: The Core BPF program that all feature accounts will be - assigned to + assigned to, with address `Feature111111111111111111111111111111111111`. - "Revoke" or "revoke pending activation": The act of reallocating a feature account's data to zero, assigning it to the System Program, and defunding its lamports balance - effectively removing it from the runtime's recognized set From 47b6e9d28b4f15cf8c64c85394046a5a00fc5f31 Mon Sep 17 00:00:00 2001 From: Joe Date: Wed, 13 Dec 2023 09:37:36 -0500 Subject: [PATCH 3/8] add SIMD number --- ...-feature-gate-2.md => 0089-programify-feature-gate-program.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{programify-feature-gate-2.md => 0089-programify-feature-gate-program.md} (100%) diff --git a/proposals/programify-feature-gate-2.md b/proposals/0089-programify-feature-gate-program.md similarity index 100% rename from proposals/programify-feature-gate-2.md rename to proposals/0089-programify-feature-gate-program.md From d7717d1478a9d2e171dfc4df136d7de90be4d77a Mon Sep 17 00:00:00 2001 From: Joe Date: Wed, 13 Dec 2023 09:45:33 -0500 Subject: [PATCH 4/8] add recent sync feedback --- .../0089-programify-feature-gate-program.md | 21 +++++++------------ 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/proposals/0089-programify-feature-gate-program.md b/proposals/0089-programify-feature-gate-program.md index fd1d4451..a3475d9b 100644 --- a/proposals/0089-programify-feature-gate-program.md +++ b/proposals/0089-programify-feature-gate-program.md @@ -51,16 +51,10 @@ coordination. This makes upgrading the program cumbersome and potentially dangerous. With the Feature Gate program instead implemented as a Core BPF program, the -program could be upgraded through the official feature-gate process described -in +program could be upgraded through the official multi-sig process described in [SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88). -Like all Core BPF programs, changes to the program only need to be done once -and are protected by the feature activation process. - -Another alternative to a Core BPF program is a standard, upgradeable BPF program -whose upgrade authority is controlled by a multisig, with key-holders from each -client team - Solana Labs, Jito, Jump, and possibly Syndica. This arrangement -would make gating upgrades behind feature gates much more difficult. +Thus, changes to the program need only to be done once and are protected by +the multi-sig process. ## New Terminology @@ -107,8 +101,7 @@ The non-existent program at `Feature111111111111111111111111111111111111` can be considered analogous to a no-op native program. Thus, the official processes outlined in [SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88) -for migrating a native program to Core BPF and upgrading a Core BPF -program can be used to enable this new program. +for migrating a native program to Core BPF can be used to enable this new program. Consider the following steps to activate Feature Gate: @@ -138,11 +131,11 @@ confidently update their state upon activation. With this proposal, a live BPF program - which can accept instructions from anyone and execute code - will be the owner of these accounts. This creates some -risk if _both_ the program's processor code as well as a secure system for +risk if *both* the program's processor code as well as a secure system for upgrading the program are not properly managed. -However, since this program would be Core BPF, its upgrades are protected by the -feature gate process. Thoroughly reviewed and safe processor code should +However, since this program would be Core BPF, its upgrades are protected by a +multi-sig authority. Thoroughly reviewed and safe processor code should mitigate any new risks associated with this change. ## Backwards Compatibility From d13394a2d4fb86a7c5275a2c1fe146486c9713b0 Mon Sep 17 00:00:00 2001 From: Joe Date: Thu, 14 Dec 2023 21:09:26 -0500 Subject: [PATCH 5/8] add specific upgrade authority details --- .../0089-programify-feature-gate-program.md | 21 ++++++++++++------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/proposals/0089-programify-feature-gate-program.md b/proposals/0089-programify-feature-gate-program.md index a3475d9b..31a659ba 100644 --- a/proposals/0089-programify-feature-gate-program.md +++ b/proposals/0089-programify-feature-gate-program.md @@ -51,10 +51,7 @@ coordination. This makes upgrading the program cumbersome and potentially dangerous. With the Feature Gate program instead implemented as a Core BPF program, the -program could be upgraded through the official multi-sig process described in -[SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88). -Thus, changes to the program need only to be done once and are protected by -the multi-sig process. +program could be changed only once, eliminating this duplication of work. ## New Terminology @@ -67,7 +64,12 @@ the multi-sig process. ## Detailed Design -The program would initially be designed to support one instruction: +The Feature Gate program shall be a Core BPF program whose upgrade authority +will be controlled by a multi-sig authority, with keyholders from each validator +client implementation. This includes Solana Labs, Jito, and Jump. In the future, +this can be expanded to include new clients such as Syndica. + +The program shall initially be designed to support one instruction: `RevokePendingActivation`. Any other instructions or functionality this program may support in the future is outside the scope of this SIMD. @@ -112,6 +114,9 @@ Consider the following steps to activate Feature Gate: Executing these two steps would effectively activate Feature Gate without any changes to existing processes. +As mentioned previously, the upgrade in step 2 would be conducted by the Feature +Gate program's multi-sig upgrade authority. + ## Impact Core contributors are positively impacted by this change, since the ability to @@ -134,9 +139,9 @@ anyone and execute code - will be the owner of these accounts. This creates some risk if *both* the program's processor code as well as a secure system for upgrading the program are not properly managed. -However, since this program would be Core BPF, its upgrades are protected by a -multi-sig authority. Thoroughly reviewed and safe processor code should -mitigate any new risks associated with this change. +However, this program's upgrades will be protected by a multi-sig authority. +Thoroughly reviewed and safe processor code should mitigate any new risks +associated with this change. ## Backwards Compatibility From dd1b1799cc3d6307b158473a8c247cc8661fe362 Mon Sep 17 00:00:00 2001 From: Joe Date: Wed, 20 Dec 2023 10:25:05 -0500 Subject: [PATCH 6/8] review feedback --- .../0089-programify-feature-gate-program.md | 55 ++++++++----------- 1 file changed, 24 insertions(+), 31 deletions(-) diff --git a/proposals/0089-programify-feature-gate-program.md b/proposals/0089-programify-feature-gate-program.md index 31a659ba..bceca1d8 100644 --- a/proposals/0089-programify-feature-gate-program.md +++ b/proposals/0089-programify-feature-gate-program.md @@ -47,37 +47,32 @@ safeguards. The Feature Gate program could instead be implemented as a built-in native program, rather than a Core BPF program. However, this would mean any changes to the program would need to be implemented by all validator clients in -coordination. This makes upgrading the program cumbersome and potentially -dangerous. +coordination. This makes upgrading the program cumbersome. -With the Feature Gate program instead implemented as a Core BPF program, the -program could be changed only once, eliminating this duplication of work. +With the Feature Gate program instead implemented as a Core BPF program, any +changes need only be done once, eliminating this duplication of work. ## New Terminology - Feature Gate program: The Core BPF program that all feature accounts will be assigned to, with address `Feature111111111111111111111111111111111111`. -- "Revoke" or "revoke pending activation": The act of reallocating a feature - account's data to zero, assigning it to the System Program, and defunding its - lamports balance - effectively removing it from the runtime's recognized set - of pending feature activations. ## Detailed Design The Feature Gate program shall be a Core BPF program whose upgrade authority -will be controlled by a multi-sig authority, with keyholders from each validator -client implementation. This includes Solana Labs, Jito, and Jump. In the future, -this can be expanded to include new clients such as Syndica. +will be a multi-sig authority, with keyholders from each validator client +implementation. This includes Solana Labs, Jito, and Jump. In the future, this +can be expanded to include new clients such as Syndica. The program shall initially be designed to support one instruction: `RevokePendingActivation`. Any other instructions or functionality this program -may support in the future is outside the scope of this SIMD. +may support in the future will be proposed and discussed separately. -As mentioned above under "New Terminology", when this instruction is invoked by -a feature key-holder, the program will reallocate the account to zero, assign it -back to the System Program, and defund its lamports balance. As a result, the -runtime will no longer recognize this feature as pending, since it will no -longer be owned by `Feature111111111111111111111111111111111111`. +When this instruction is invoked by a feature key-holder, the program will +reallocate the account to zero, assign it back to the System Program, and defund +its lamports balance. As a result, the runtime will no longer recognize this +feature as pending, since it will no longer be owned by +`Feature111111111111111111111111111111111111`. Consider the instruction as it may appear in the Feature Gate program: @@ -99,23 +94,21 @@ pub enum FeatureGateInstruction { } ``` -The non-existent program at `Feature111111111111111111111111111111111111` can be -considered analogous to a no-op native program. Thus, the official processes -outlined in +The official process outlined in [SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88) -for migrating a native program to Core BPF can be used to enable this new program. - -Consider the following steps to activate Feature Gate: +for migrating a native program to Core BPF will be used to enable this new +program, with the addition of the `RevokePendingActivation` instruction as a +separate BPF prgoram-upgrade step. 1. Migrate the native no-op program at - `Feature111111111111111111111111111111111111` to a Core BPF no-op. -2. Upgrade the Core BPF no-op to add the `RevokePendingActivation` instruction. - -Executing these two steps would effectively activate Feature Gate without any -changes to existing processes. - -As mentioned previously, the upgrade in step 2 would be conducted by the Feature -Gate program's multi-sig upgrade authority. + `Feature111111111111111111111111111111111111` to a Core BPF no-op, with the + new program's upgrade authority set to the Feature Gate multi-sig. +2. Upgrade the Core BPF no-op to add the `RevokePendingActivation` instruction + using the new multi-sig authorization. + +Because the only change to the program is the addition of the +`RevokePendingActivation` instruction, these steps will enable Core BPF Feature +Gate without any changes to the existing feature activation process. ## Impact From 8fe56d0a0ec40ef03b7437ed652d5198d00d382e Mon Sep 17 00:00:00 2001 From: Joe Date: Wed, 3 Jan 2024 10:28:25 -0600 Subject: [PATCH 7/8] drop instruction code snippet --- .../0089-programify-feature-gate-program.md | 20 ------------------- 1 file changed, 20 deletions(-) diff --git a/proposals/0089-programify-feature-gate-program.md b/proposals/0089-programify-feature-gate-program.md index bceca1d8..80ee16e2 100644 --- a/proposals/0089-programify-feature-gate-program.md +++ b/proposals/0089-programify-feature-gate-program.md @@ -74,26 +74,6 @@ its lamports balance. As a result, the runtime will no longer recognize this feature as pending, since it will no longer be owned by `Feature111111111111111111111111111111111111`. -Consider the instruction as it may appear in the Feature Gate program: - -```rust -pub enum FeatureGateInstruction { - /// Revoke a pending feature activation. - /// - /// A "pending" feature activation is a feature account that has been - /// allocated and assigned, but hasn't yet been updated by the runtime - /// with an `activation_slot`. - /// - /// Features that _have_ been activated by the runtime cannot be revoked. - /// - /// Accounts expected by this instruction: - /// - /// 0. `[w+s]` Feature account - /// 1. `[w]` Destination (for rent lamports) - RevokePendingActivation, -} -``` - The official process outlined in [SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88) for migrating a native program to Core BPF will be used to enable this new From ec0e88166f55d09bc1ebef10dc4aad954e47d34e Mon Sep 17 00:00:00 2001 From: Joe Date: Thu, 4 Jan 2024 09:36:23 -0600 Subject: [PATCH 8/8] remove Jump from multi-sig --- proposals/0089-programify-feature-gate-program.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/proposals/0089-programify-feature-gate-program.md b/proposals/0089-programify-feature-gate-program.md index 80ee16e2..83ab9f82 100644 --- a/proposals/0089-programify-feature-gate-program.md +++ b/proposals/0089-programify-feature-gate-program.md @@ -60,9 +60,8 @@ changes need only be done once, eliminating this duplication of work. ## Detailed Design The Feature Gate program shall be a Core BPF program whose upgrade authority -will be a multi-sig authority, with keyholders from each validator client -implementation. This includes Solana Labs, Jito, and Jump. In the future, this -can be expanded to include new clients such as Syndica. +will be a multi-sig authority with keyholders from Solana Labs and potentially +Jito. The program shall initially be designed to support one instruction: `RevokePendingActivation`. Any other instructions or functionality this program