Skip to content

Commit

Permalink
SIMD-0089: Programify Feature Gate Program (#89)
Browse files Browse the repository at this point in the history
* simd: programify feature gate program (2)

* clarify a few points

* add SIMD number

* add recent sync feedback

* add specific upgrade authority details

* review feedback

* drop instruction code snippet

* remove Jump from multi-sig
  • Loading branch information
buffalojoec authored Jan 26, 2024
1 parent 05c0af4 commit 9347aec
Showing 1 changed file with 121 additions and 0 deletions.
121 changes: 121 additions & 0 deletions proposals/0089-programify-feature-gate-program.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,121 @@
---
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.

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`.

## 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.

The program shall initially be designed to support one instruction:
`RevokePendingActivation`. Any other instructions or functionality this program
may support in the future will be proposed and discussed separately.

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`.

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.

## 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, 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

This change is 100% backwards compatible with the existing feature activation
process. It *only* adds the ability to revoke pending activations.

0 comments on commit 9347aec

Please sign in to comment.