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

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

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

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

| 特性 | | --- | SGP (Solana治理提案) | SIMD (Solana改进文档) | | --- | --- | --- | | 核心问题 | “我们是否应该这样做？” | “我们具体如何做？” | | 层级 | 高层级、方向性 | 详细的协议规范 | | 决策方 | 权益加权链上投票 | 核心开发者技术审查 | | 所需成熟度 | 一个值得社区信号佐证的清晰想法 | 一个完整、可实施的设计 |

一个“减压阀”，而非权力争夺 一个常见的误解是SGP取代了核心开发者的角色。事实并非如此。SGP流程最好被描述为一种中断机制。正常的开发管道——开发者在此提出SIMD——继续照常运行。只有当社区认为某项决策足够重要，需要进行一次正式的权益加权投票时，SGP才会启动。

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

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

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

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