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

Solana Foundation 已正式推出 Solana 治理提案（SGP），此举标志着网络决策方式迈出了重要一步。
SGP 与 SIMD：“为什么”与“怎么做”
要理解 SGP，首先需要明白它不是什么。许多人会自然将其与现有的 Solana 改进文档（SIMD）流程进行比较，但两者服务于不同目的：
SIMD 是工程蓝图：它们回答“如何”实施技术变更。核心开发者会对其进行审查，以确保协议完整性。

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

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

| 特性 | | --- | SGP（Solana 治理提案） | SIMD（Solana 改进文档） | | --- | --- | --- | | 核心问题 | “我们是否应该这样做？” | “我们究竟如何做到这一点？” | | 层面 | 高层级、方向性 | 详细的协议规范 | | 决策者 | 基于质押量的链上投票 | 核心开发者的技术审查 | | 所需成熟度 | 值得社区信号反馈的清晰想法 | 完整、可实施的设计 |

“泄压阀”，而非权力争夺
一个常见的误解是 SGP 取代了核心开发者的角色。事实并非如此。SGP 流程最好被描述为一种“中断机制”。正常的开发流程（开发者在此流程中提出 SIMD）将继续照常运作。只有当社区认为某项决策足够重要，需要进行正式的基于质押量的投票时，SGP 才会介入。

• 阈值： 要触发 SGP 投票，提案必须获得至少 15% 的活跃网络总质押量的支持。
• 意图： 这一高门槛确保网络不会被琐碎投票阻塞。它是一个“泄压阀”，仅用于那些具有长期经济影响、社区要求拥有发言权的事项。

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

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

大局观：治理成熟化
多年来，对 Solana 的批评是其治理过于中心化，严重依赖核心开发者的专业知识。虽然这种方法带来了惊人的速度和性能，但让质押者和验证者感觉像是别人车上的乘客。
SGP 通过将社区的声音正式化来改变这一动态。它既没有将王国的钥匙交给 DAO，也没有拖慢关键工程。相反，它为之前依赖非正式共识的经济和战略决策创建了一个正式渠道。
真正的考验将在未来几个月到来。我们将观察 15% 的阈值多久会被触发，以及有争议的经济变更是否能顺利通过这一新流程。就目前而言，这代表了 Solana 成熟、审慎的演变，一种平衡快速、专家主导的工程与社区治理必要性的方式。