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

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

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

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

| Feature | | --- | SGP (Solana治理提案) | SIMD (Solana改进文档) | | --- | --- | --- | | Primary Question | “我们应该这样做吗？” | “到底该如何做？” | | Altitude | 高层、方向性 | 详细的协议规范 | | Decided By | 基于质押权重的链上投票 | 核心开发者的技术审查 | | Maturity Required | 一个值得社区信号的明确想法 | 一个完整、可实施的设计 |

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

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

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

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

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