From 1c40f51f019eb7f9c8452f43e6647b7e635d643f Mon Sep 17 00:00:00 2001 From: Joe C Date: Thu, 30 May 2024 13:09:32 -0500 Subject: [PATCH] amend 0089: upgrade process (#150) --- .../0089-programify-feature-gate-program.md | 36 ++++++------------- 1 file changed, 11 insertions(+), 25 deletions(-) diff --git a/proposals/0089-programify-feature-gate-program.md b/proposals/0089-programify-feature-gate-program.md index 83ab9f82..6dbcf457 100644 --- a/proposals/0089-programify-feature-gate-program.md +++ b/proposals/0089-programify-feature-gate-program.md @@ -59,9 +59,12 @@ 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 Solana Labs and potentially -Jito. +A Core BPF program - the Feature Gate program - shall be placed at the address +of `Feature111111111111111111111111111111111111` using the process outlined in +[SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88). + +The program will have no upgrade authority. If changes are required, for +essential network operations, the program will be updated using feature-gates. The program shall initially be designed to support one instruction: `RevokePendingActivation`. Any other instructions or functionality this program @@ -73,21 +76,8 @@ 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`. -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 -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, 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. +The creation of this program will not change the existing feature activation +process. ## Impact @@ -107,13 +97,9 @@ that can modify feature accounts once they've been created under 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, 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. +anyone and execute code - will be the owner of these accounts. This introduces +new risks that must be mitigated through careful implementation of Feature Gate +program functionality. ## Backwards Compatibility