Skip to content

Feature Gate Setup Process

WillHickey edited this page Sep 17, 2024 · 7 revisions

Overview

This page seeks to explain why feature gates are used, how they work, and some of the mechanics for setting them up. Enablement is in a separate wiki page here.

Why Feature Gates?

Feature gates are useful for ensuring the entire cluster is in sync when enabling some capability. Without feature gates, each validator would asynchronously enable the capability whenever they decide to update or pass some config parameter. This could tear the cluster apart if a feature results in different account state, hashing, ticks, etc. as updated vs. non-updated nodes will not be able to reach consensus. Any code update that changes whether a specific transaction will succeed or fail must be feature gated.

How do Feature Gates Work?

Feature gates work by creating a keypair so that features can be identified by a pubkey (and activated via private key). The set of active/inactive features are stored in the Bank, and the set of active features gets updated on epoch boundaries (which is the exact same time with respect to slots across the cluster). Conditional logic can then be used in the code which queries whether a feature has been activated.

How do I Add a Feature Gate?

Note: These instructions provide mechanics on September 2024. It is possible specific commands will have changed since then.

  1. Follow the steps described at the top of sdk/feature-set/src/lib.rs to generate keypair, create public module, and add desired feature switch logic
  2. Create a new issue in the Feature Gate Tracker repo. If you don't have access please contact the Anza devops team in Solana Discord #devops
  3. After code has been pushed in, refer to Feature Activation Process for next steps
Clone this wiki locally