Roadmap: Multi-Client Feature Gates

[buffalojoec]

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:

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

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

3. 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:

1. Feature Creation: Anyone can create a new feature gate.
2. Authorized Feature Queuing: An authority (multi-sig or governance) controls the queuing of features to be activated.
3. Safeguards for Pending Activations: Expanded control over pending feature activations (ie. ability to revoke).
4. 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 on Feature111111111111111111111111111111111111 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