-
Notifications
You must be signed in to change notification settings - Fork 205
Feature Gate Setup Process
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.
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.
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.
Note: These instructions provide mechanics on September 2024. It is possible specific commands will have changed since then.
- 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
- 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
- After code has been pushed in, refer to Feature Activation Process for next steps
- General
- Feature Gates
- Technical
- Policy
- Schedule
- Migration
- Restart Instructions