Skip to content

Commit

Permalink
one more pass on wording
Browse files Browse the repository at this point in the history
  • Loading branch information
buffalojoec committed Oct 27, 2023
1 parent 8d85a24 commit 04f077e
Showing 1 changed file with 10 additions and 8 deletions.
18 changes: 10 additions & 8 deletions proposals/0077-programify-feature-gate.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,13 +36,13 @@ This is SIMD 1/3 expected for **Multi-Client Feature Gates**. See

### Proposal

This SIMD outlines a proposal to replace the non-existent system account at
address `Feature111111111111111111111111111111111111`, which is the owner of
all feature accounts, with an upgradeable BPF program.
This SIMD outlines a proposal to replace the non-existent program at address
`Feature111111111111111111111111111111111111`, which is the owner of all
feature accounts, with an upgradeable BPF program.

It defines the program's initial functionality - which consists solely of the
capability to revoke pending feature activations - and an initial
upgrade control process for managing upgrades of the program.
capability to revoke pending feature activations - and an initial upgrade
control process for managing upgrades of the program.

Important note: the process by which core contributors *activate* features
would remain completely unchanged by this SIMD.
Expand All @@ -55,8 +55,8 @@ The most obvious approach is to place a program in charge of these accounts.
An upgradeable BPF program presents a more logical solution over a native
program for this task, since it provides a built-in system for upgrades.

In the case of this particular proposal, a BPF program provides the capability
to revoke pending feature activations.
In the case of this particular proposal, this BPF program will provide
engineers the capability to revoke pending feature activations.

Currently, a feature is queued for activation by a keypair holder creating an
empty account and assigning it to the
Expand All @@ -74,7 +74,9 @@ revoking queued features, giving engineers more flexibility and safeguards.

The Feature Gate program could instead be a native program, rather than a BPF
program. However, this would mean any changes to the program would need to be
implemented by all validator clients in coordination.
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.

## New Terminology

Expand Down

0 comments on commit 04f077e

Please sign in to comment.