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

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

SGP 与 SIMD：“为什么”与“怎么做”

要理解 SGP，首先必须理解它不是什么。许多人自然会将其与现有的 Solana 改进文档 (SIMD) 流程进行比较，但它们服务于两个不同的目的：

SIMD 是工程蓝图：它们回答“如何”实现技术变更。这些由核心开发者审查以确保协议完整性。

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

一个完美的例子是“Alpenglow”提案。过去，社区曾试图在技术细节完全准备好之前通过 SIMD 流程推动该提案。这造成了摩擦，因为开发者需要在花费时间构建蓝图之前获得概念上的“绿灯”。借助 SGP，社区现在可以先投出“赞成”票，在繁重的工程工作开始之前验证方向。

| Feature | | --- | SGP (Solana Governance Proposals) | SIMD (Solana Improvement Documents) | | --- | --- | --- | | Primary Question | “Should we do this?” | “How exactly do we do this?” | | Altitude | High-level, directional | Detailed protocol specification | | Decided By | Stake-weighted on-chain vote | Technical review by core developers | | Maturity Required | A clear idea worth a community signal | A complete, implementable design |

“压力阀”，而非权力争夺

一个常见的误解是 SGP 取代了核心开发者的角色。事实并非如此。SGP 流程最好被描述为一种中断机制。正常的开发流程——开发者提出 SIMD——照常运行。SGP 仅在社区认为某个决策足够重要、需要正式且基于质押权重的投票时才会启动。

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

机制如何运作

当发起 SGP 时，它会遵循一条结构化、透明的路径。每个提案由一个 markdown 文档（详细说明理由）和一个链接到特定、不可变的 commit SHA 的链上记录组成。这确保了正在投票的提案不能在中途被更改。

投票规则：

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

大局：治理成熟

多年来，对 Solana 的批评是它的治理过于中心化，严重依赖核心开发者的专业知识。虽然这种方法带来了惊人的速度和性能，但它让质押者和验证者感觉像是别人车上的乘客。

SGP 通过将社区声音法典化来改变这种动态。它并没有将王国钥匙交给 DAO，也没有减慢关键工程的速度。相反，它为之前依赖非正式共识的经济和战略决策创建了一个正式渠道。

真正的考验将在未来几个月到来。我们将关注 15% 的门槛多久被达到一次，以及有争议的经济变革能否通过这一新流程成功引导。就目前而言，它代表了 Solana 成熟、稳健的演进。一种平衡快速、专家主导的工程需求与社区支持的治理必要性的方式。