Solana的新治理提案：战略转变

Solana 基金会已正式推出 Solana 治理提案（SGP），此举标志着网络在处理决策方面迈出了重要一步。

SGP 与 SIMD： “为什么” 与 “怎么做” 的区别 要理解 SGP，首先得明白它不是什么。很多人会自然将其与现有的 Solana 改进文档（SIMD）流程进行比较，但两者服务于不同的目的：
SIMD 是工程蓝图：它们回答 “如何实施技术变更”。这些方案需由核心开发者审查，以确保协议完整性。

• SGP 是方向性指令： 它们回答 “我们应该这样做吗？” 这关乎社群意愿和高级战略。可以这样理解：SGP 是政治意愿，而 SIMD 是工程执行。

一个完美的例子是 “Alpenglow” 提案。过去，社群曾尝试在技术细节尚未完全准备就绪前，通过 SIMD 流程推动该提案。这造成了摩擦，因为开发者需要在投入时间构建蓝图之前，获得对概念上的 “绿灯”。有了 SGP，社群可以首先投出 “同意” 票，在繁重的工程工作开始前验证方向。

| 特性 | | --- | SGP（Solana 治理提案） | SIMD（Solana 改进文档） | | --- | --- | --- | | 主要问题 | “我们应该这样做吗？” | “我们具体怎么做？” | | 层级 | 高级别、方向性 | 详细的协议规范 | | 决策者 | 基于 Stake 的链上投票 | 核心开发者的技术审查 | | 所需成熟度 | 明确的、值得社群信号的想法 | 完整、可实施的设计 |

“压力阀”，而非权力攫取 一个常见的误解是，SGP 取代了核心开发者的角色。事实并非如此。SGP 流程最好被描述为一种中断机制。正常的开发流程——即开发者提交 SIMD——照常运作。只有当社群认为某个决策足够重要，需要进行正式的、基于 Stake 的投票时，SGP 才会介入。

• 门槛： 要触发 SGP 投票，提案必须获得至少 15% 的活跃网络总 Stake 的支持。
• 意图： 这一高门槛确保网络不会被琐碎的投票堵塞。它是一个 “压力阀”，专门用于那些具有长期经济影响、且社群要求参与决策的事项。

机制如何运作 当 SGP 启动时，它会遵循一个结构化的、透明的路径。每个提案包含一份 Markdown 文档（详细说明理由）和一个链上记录，该记录链接到一个特定的、不可变的 commit SHA。这确保了正在被投票的提案不会在过程中被更改。 投票规则：

• 提交： 需要至少拥有 100,000 SOL 质押的验证者。
• 触发： 必须有 15% 的活跃 Stake 表示支持，才能进入正式投票。
• 批准： 需要参与投票的 “赞成” 和 “反对” Stake 获得三分之二（66.67%）的超级多数（弃权票不计入）。
• 时间线： 整个周期从支持门槛达到到最终结果出炉，大约需要 22 天（11 个 epoch）。

大局观：治理成熟 多年来，对 Solana 的批评一直是其治理过于中心化，严重依赖核心开发者的专业知识。虽然这种方法带来了惊人的速度和性能，但它让质押者和验证者感觉自己像是别人车上的乘客。 SGP 通过将社群的声音正式化，改变了这种动态。它既没有将治理权完全交给 DAO，也没有放缓关键的工程进展。相反，它创建了一个正式的渠道，用于处理以前依赖非正式共识的经济和战略决策。 真正的考验将在未来几个月到来。我们将关注那 15% 的门槛被触及的频率，以及有争议的经济变更是否能成功通过这一新流程进行引导。就目前而言，这代表着 Solana 的一次成熟、稳健的进化。一种平衡快速、专家主导的工程需求与社群支持的治理必要性之方式。