Skip to content

Commit

Permalink
add more context for native vs BPF
Browse files Browse the repository at this point in the history
  • Loading branch information
buffalojoec committed Oct 29, 2023
1 parent 93322ef commit 32a6f91
Showing 1 changed file with 13 additions and 0 deletions.
13 changes: 13 additions & 0 deletions proposals/0077-programify-feature-gate.md
Original file line number Diff line number Diff line change
Expand Up @@ -78,6 +78,19 @@ implemented by all validator clients in coordination. This makes upgrading the
program to support the complete Multi-Client Feature Gate architecture
cumbersome and potentially dangerous.

However, one of the main benefits gained by instead opting for a native program
would be an easier ability to upgrade via feature gate.

Another alternative considered is to use the deployment process outlined in the
"Deploying the Program" section under "Detailed Design" to upgrade the program
behind feature gates in the future. In short, contributors would stage changes
to the program in another account and create a runtime feature gate to swap
this upgraded version of the program into the current program's place.

Note this may render the multi-signature program upgrade authority setup
useless, except for less common use cases, such as a critical upgrade that
could not be done through a feature gate.

## New Terminology

- Feature Gate program: The BPF program that will own all feature accounts.
Expand Down

0 comments on commit 32a6f91

Please sign in to comment.