Requesting Access Level 1 for HaoranYi

Discord id haoranyi

Requesting Access Level [1] for Madhav

Discord id - madhavg#4168

Requesting Access Level 1 for @t-nelson

Discord id: trent.sol

cc/ @jacobcreech

Requesting Access Level [1] for [taozhu-chicago]

Discord id:Tao#2945

Requesting Access Level 1 for buffalojoe

Discord: buffalojoe

Requesting Access Level [2] for [jeffwashington]

Discord id:jwash#5045

Requesting Access Level [1] for [CriesofCarrots]

Discord id: Tyera#6263

Requesting Access Level [1] for [joncinque]

Discord id: jon#1892

Requesting Access Level 2 for @buffalojoec

Discord id: buffalojoe

I'm Matt Sorg from Solana Foundation. I'll help managed and evolve of the SIMD process, and facilitate collaboration across protocol dev teams. Requesting Lvl 1 access as that'll obviously be necessary to perform this role.

Discord id: Tamgros#9322

Requesting Access Level [1] for [AshwinSekar]

Discord id is ashwinsekar#3708

Requesting Access Level 2 for @sakridge

@sakridge has authored several feature gates / SIMDs and is a long time contributor who should have write access to review, approve, veto, merge others' contributions.

Requesting Access Level 2 for @lheeger-jump

I am a current core developer working on Firedancer requesting write access to the SIMD repo.

Discord ID: CantelopePeel-jump

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

Problem

The Solana monorepo docs section has two directories containing previous network proposals.

• proposals
• implemented-proposals

Having multiple repos for proposals fragments resources and attention. Would be good to have it all in a single place.

Suggested Fix

• Move over documents from monorepo into this repo
• Add SIMD header and assign number
• Preserve original Git authorship attribution

Requesting Access Level [2] for [0xSol]

Discord id: 0xSol0x

The Git history of this repo is a monstrosity. Can disable all merge types other than squash merge to keep it concise?

Requesting Access (Level [1]) for Lichtso

Discord id: Lichtso#3389

not ideal. please enable Dismiss stale pull request approvals when new commits are pushed for all branch protection rules

Requesting Access Level [1] for [brooksprumo]

Discord id: brooks#7217

when a feature being proposed has already been implemented in part or in full, it leads to a sparse proposal document which leans on the implementation rather than stands alone and a bias toward what already exists. this defeats the proposal process altogether as the point is to agree on what a feature should look like and publish a document that is sufficiently detailed that someone can implement it from scratch.

at most a SIMD might include mock data structures or pseudo code to help describe complex logic, but even these should be kept to an absolute minimum and described as well as possible in prose.

--

i'm not sure we've decided on how to amend existing SIMDs, but this should fit into 0001 or its successor

Requesting Access Level [1] for mvines

Discord id: mvines

Requesting Access Level 2 for ripatel-jump

Requesting write access to the SIMD repository on behalf of the Firedancer team.
Firedancer is an effort to implement a second implementation of the Solana protocol.

Contact: [email protected]

Requesting Access Level 2 for @t-nelson

Discord id: trent.sol

cc/ @jacobcreech

Requesting Access Level 1 for @lheeger-jump
I am a current core developer working on Firedancer requesting triage access to the SIMD repo.

Discord ID: CantelopePeel-jump

I'm interested in having L2s/rollups connected to Solana. Interoperability between these would aim to have latency reduced to the minimum.

One challenge is time to finality. Is there a plan to move towards a single slot finality model in the future? Or am I missing anything?

Thanks for your time.

Requesting Access Level [1] for [apfitzge]

Discord id: andrew.fitzgerald#1084

Requesting Access Level 2 for pgarg66

Discord id: pgarg

Requesting Access Level [1] for behzadnouri

Discord id: behzad#1355

current workflow is not ideal for a globally distributed team.

proposal 1: solana tech discord contributor role should be able to trigger ci / lint run on solana-foundation/solana-improvement-documents
proposal 2: ci just autoruns on every request, as long as PR doesn't touch the ci config, lint tools are pretty lightweight

Requesting Access Level 1 for pgarg66

Discord id : pgarg

Requesting Access Level [1] for [0xSol]

Discord id: 0xSol0x

I'm Matt Sorg from Solana Foundation. I'll help manage and evolve of the SIMD process, and facilitate collaboration across protocol dev teams. Requesting Lvl 3 access as that'll obviously be necessary to perform this role.

Discord id: Tamgros#9322

Currently, as I see, the numbering of an SIMD is being choosen by the author themselves.

This may cause problems later as the SIMD proposals increase in number.

Recommendation:

The SIMD proposal created in PRs get the PR# assigned to it when PR is created an later merged, keeping the SIMD number unique.

e.g.: Add SIMD-0003: Dynamic Base fees #4

Here, the SIMD choosen by the author is 3 whereas the PR# is 4

Requesting Access Level 2 for @joncinque

@joncinque has authored several feature gates / SIMDs and is a long time contributor who should have write access to review, approve, veto, merge others' contributions.

Requesting Access Level 3 for benhawkins18

Discord id benhawkins18

Requesting Access Level [1] for [jeffwashington]

Discord id:jwash#5045

Requesting Access Level 1 for sakridge

Discord id is @sakridge

cc @jeffwashington @pgarg66
Discord id:

Requesting Access Level [1] for [anoushk1234]

Discord id: anoushk

Requesting Access Level 1 for jstarry

Discord id: jstarry

cc @jeffwashington @pgarg66

Discord id: mvines

My L1 approved access request is at #18

Requesting Access Level 2 for joncinque

Discord id: jonc5

Per Jacob's nomination, requesting write access to the SIMD repo for myself

Requesting Access Level 2 for @CriesofCarrots

Discord id tyera

@CriesofCarrots has authored several feature gates / SIMDs and is a long time contributor.
She should have write access so she can approve, veto, merge others' contributions.

Requesting Access Level [3] for [0xSol]

Discord id: 0xSol0x

Requesting Access Level triage for @nickfrosty

Discord id nickfrosty#7853

Requesting Access Level 2 for benhawkins18

Discord id benhawkins18:

Requesting Access Level 1 for 2501babe

Discord id: 2501babe

cc @jacobcreech @buffalojoec

I'm Matt Sorg from Solana Foundation. I'll help managed and evolve of the SIMD process, and facilitate collaboration across protocol dev teams. Requesting Lvl 2 access as that'll obviously be necessary to perform this role.

Discord id: Tamgros#9322