| simd | XXXX | |
|---|---|---|
| title | Title of SIMD. This should be concise and descriptive. | |
| authors |
|
|
| category | Standard/Meta | |
| type | Core/Networking/Interface/Meta | |
| created | (fill me in with today's date, YYYY-MM-DD) | |
| feature | (fill in with feature key and github tracking issues once accepted) | |
| supersedes | (optional - fill this in if the SIMD supersedes a previous SIMD) | |
| superseded-by | (optional - fill this in if the SIMD is superseded by a subsequent SIMD) | |
| extends | (optional - fill this in if the SIMD extends the design of a previous SIMD) |
A brief summary of what the feature is.
Why are we doing this? What use cases does it support? What is the expected outcome?
This proposal depends on the following previously accepted proposals:
-
SIMD-XXXX: Title of SIMD
A brief summary of the reason for the dependency
Is there any new terminology introduced with this proposal?
Explain the feature as if it was already implemented and you're explaining it to another Solana core contributor. The generally means:
- Explain the proposed change and how it works
- Where the feature fits in to the runtime, core, or relevant sub-system
- How this feature was/could be implemented
- Interaction with other features
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Which edge cases should the implementors of this change be aware of? Enumerate these below. This may includes topics such as extreme max/min/zero values, unusual states and scenarios that require particular attention.
Which validator components are affected by this change?
| Validator Component | Impact |
|---|---|
| Transaction Execution (Runtime) | |
| Virtual Machine | |
| Block Packing | |
| Consensus | |
| Gossip | |
| Turbine | |
| Snapshots | |
| On-Chain Core BPF Programs | |
| Other (please describe) |
What alternative designs were considered and what pros/cons does this feature have relative to them?
How will the implemented proposal impacts dapp developers, validators, and core contributors?
What security implications/considerations come with implementing this feature? Are there any implementation-specific guidance or pitfalls?
Why should we not do this?
Does the feature introduce any breaking changes? All incompatibilities and consequences should be listed.
How will all clients verify that they have correctly implemented this change?
Some examples:
- The change will be accompanied by a ledger from a localnet cluster demonstrating the behaviour prior to activation, the feature activation, and change in functionality caused by the activation. An example of how to create such a ledger: https://github.com/febo/p-token-migration
- The change will be accompanied by a pcap which contains the packets that are handled differently after the feature gate is activated.