Roadmap: Multi-Client Feature Gates
Opened this issue · 0 comments
buffalojoec commented
Roadmap: Multi-Client Feature Gates
This outline serves to articulate procedural and engineering efforts to introduce a new & improved strategy for managing Solana protocol changes and activating their corresponding feature gates, particularly in an environment with multiple validator clients.
Procedural Changes
Desired procedure:
- SIMDs are changes to the Solana protocol, not any particular validator client. All Solana protocol features require a SIMD.
Ideally, SIMD merges should always be coupled to a relevant change to the Solana specification, however, at this time we do not have enough specifications published on Solana to enforce this.
- Structured SIMD review process:
- Required reviews from members of each validator client on Solana.
- Concept of "priority level" for proposals, for ease of review.
- Ability to request validator reviews on proposals effecting validator economics.
- Tracking of feature implementation across clients after SIMD is merged:
- Tracking development progress of merged proposals across each client.
- Target dates for implementation and feature activation, agreed upon by all clients.
- Linking of relevant code changes back to their corresponding original proposal.
- Improved Feature Gate Activation Schedule integrated with development progress tracking.
Tasks
- Enforce SIMDs for all feature gates.
- Establish GitHub teams and review requirements for SIMDs.
- Introduce priority labels on SIMD pull requests.
- Establish a process for optionally requesting validator review on proposals.
- Develop a project board for tracking implementation with targets, linked changes, and an improved Feature Gate Activation Schedule.
- (Optional) Publish a public web page for observing SIMDs and their development progress. See Ethereum's EIP page.
Protocol Changes (SIMDs)
Desired architecture:
- Feature Creation: Anyone can create a new feature gate.
- Authorized Feature Queuing: An authority (multi-sig or governance) controls the queuing of features to be activated.
- Safeguards for Pending Activations: Expanded control over pending feature activations (ie. ability to revoke).
- Automated Network Partition Protection: Prevention of network partitions during feature activation via built-in runtime functionality.
✅ SIMD 1/4: Enable Core BPF Programs (#88)
- Establish a robust process for migrating builtin (native) programs to Core BPF.
✅ SIMD 2/4: Programify Feature Gate Program (#89)
- Migrate the (ephemeral) builtin
Feature111111111111111111111111111111111111
to a Core BPF program. - Enable the
RevokePendingActivation
instruction onFeature111111111111111111111111111111111111
for revoking features queued for activation.
🟠 SIMD 3/4: Feature Gate Threshold Automation (#72)
- Add functionality to the Feature Gate program to manage feature “recognition”, including:
- Tracking a node’s recognized features on-chain
- Recording this information through a well-defined program instruction
- Implement an automated process for marking proposed features as "eligible" based on stake support, including:
- Assessing stake support for particular features through Feature Gate program on-chain data
- Marking eligible only those with the necessary support
SIMD 4/4: Governance for Queuing Feature Activations
- Establish a validator governance process for queueing eligible runtime features, possibly using the existing Feature Proposal program.
✅ = SIMD merged
🟠 = SIMD pending review