Solana提案流程

提案是什么？

提案是一个设计文档，描述了 Solana 的新特性或其过程或环境。提案应记录该特性的理由和足够的文档，以理解其实现。

理由

提案旨在由核心工程团队和社区成员进行审查，同时考虑安全问题、权衡和向后兼容性。拥有提案流程有助于提前识别设计问题，通知社区变更情况，帮助新贡献者熟悉架构，并作为 Solana 中设计决策的历史记录。对于实施者而言，提案是特性的蓝图，有助于跟踪特性的开发。

什么时候需要遵循这个流程

如果你打算对 Validator、RPC、共识或提案流程本身进行“实质性”更改，则需要遵循此流程。什么构成“实质性”更改是动态的，基于社区规范，并根据你所提议更改的生态系统部分而有所不同，但可能包括以下内容：

• RPC API 方法格式的变化
• 验证者之间网络接口的变化
• 运行时的计算需求变化

一些更改不需要提案：

• 重新表述、重新组织、重构或其他“改变形状并不改变意义”。
• 严格改善客观的、数字质量标准的添加（去除警告、加速、更好的平台覆盖、更高的并行性、捕获更多错误等）。

提案类型

提案有两种类型：

• 标准 提案描述了影响大多数或所有 Solana 实现的任何更改，例如网络协议、共识、提议的应用标准/规范、区块或交易有效性、更改或添加任何影响使用 Solana 的应用互操作性的内容。标准提案可以分为以下几类：

  • 核心：任何影响共识或验证者的实质性更改。
  • 网络：对网络协议规范的更改或实质性改进。
  • 接口：关于客户端 JSON RPC API 规范和标准的破坏性更改。

• 元 提案描述了围绕 Solana 的过程或提议对（或过程中的）某个事件进行更改。过程提案类似于标准提案，但适用于 Solana 协议本身以外的领域。它们可以提议一个实现，但不涉及 Solana 的代码库；它们通常需要社区共识，用户通常不能自由忽视它们。示例包括程序、指南、决策过程的更改以及在 Solana 开发中使用的工具或环境的更改。任何 meta-SIMD 也被视为过程提案。

提案生命周期

提案的生命周期阶段如下：

• 想法
• 草稿
• 审查
• 已接受
• 已有
• 停滞
• 撤回
• 实施
• 激活

flowchart LR
  Idea
  Draft
  Review
  Accepted

  subgraph fail[&nbsp];
    Stagnant
    Withdrawn
  end

  style fail fill:#ffe8e7,stroke:none
  style Accepted fill:#f3f8dc,stroke:#c3db50;

  Idea ---> Draft;
  Draft ---> Review;
  Review ---> Accepted;
  Accepted ---> Implemented;
  Implemented ---> Activated;
  Review ---> Living;
  Accepted ---> Withdrawn;

  Draft ---> Stagnant;
  Review ---> Stagnant;
  Review ---> Withdrawn;

想法

在想法阶段，涉及提案的各方是你——倡导者或提案作者——审查者，以及 Solana 核心贡献者。

在你开始撰写正式提案之前，应对你的想法进行审查。首先询问 Solana 核心社区，该想法是否原始，以避免在基于以前的研究上被拒绝的事情上浪费时间。请务必将你的想法发布到 SIMD 想法讨论页面 并在正式提案之前收集反馈。

草稿

开始撰写提案草稿时，请执行以下操作：

• 分叉提案仓库
• 将 XXXX-template.md 复制到 proposals/XXXX-my-feature.md（其中“my-feature”是描述性的）
• 填写提案。在细节上一定要谨慎：未能提供令人信服的动机、缺乏对设计影响理解或对缺点或替代方案不诚实的提案通常会受到不良评估。低质量的提案和有限的参与将会被 SIMD 仓库维护者关闭。提案标题应简明且具描述性。
• 提交拉取请求。
• 现在你的提案已开启拉取请求，使用 PR 的问题编号更新 XXXX- 前缀为该编号。

审查

在审查过程中，提案的拥有者负责收集和整合反馈。提案的最相关核心贡献者应包含在审查过程中。审查将完全通过 GitHub 进行，以便收集和记录所有评论。一旦核心贡献者达成共识，提案可以被接受或撤回。此步骤通常是在考虑了足够的权衡之后，核心贡献者能够做出决策时采取的。并不需要所有参与者达成共识，但在核心贡献者之外，不应对提案存在强烈反对的共识。

已接受

一些已接受的提案代表可以立即实施的重要特性。其他已接受的提案可以等到某个任意的核心贡献者有工作意愿时再去实施。每个已接受的提案应在 Solana 仓库中有一个相关的跟踪问题。如果实施需要通过特性激活程序激活特性，则还应创建一个特性门控问题以进行跨集群跟踪。虽然提案作者不 必需 自己撰写实现，但这无疑是将提案推进至完成的最有效方式：作者不应期望其他项目开发者会承担实现已接受特性的责任。

实施

当所有相关团队完成 SIMD 特性的开发时，SIMD 被视为“实施”。

激活

当提案已被实现、测试并最终在主网 beta 上激活时，其状态将为激活。

现存

这是对设计为可以持续更新而不达到最终状态的 SIMD 的特殊状态。这 notably 包括 SIMD-1。此状态在状态从审查更新到现存时必须进行额外审查和审核。

停滞

如果提案在没有活动的情况下达到 6 个月，提案将被标记为无效以被关闭。如果提案关闭且有可能达成共识，则可以提出新提案。

撤回

作者已撤回该提案。此状态具有最终性，无法恢复。如果该想法在以后被追求，则被视为新提案。

• 原文链接： github.com/solana-founda...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～