Solana 的新治理提案：戰略轉變

Solana 基金會正式推出 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 文件（詳述理由）以及一個鏈上記錄，該記錄連結到一個特定的、不可變的提交 SHA。這確保了正在投票的提案不能中途更改。 投票規則：

• 提交： 需要一個質押至少 100,000 SOL 的驗證者。
• 觸發： 必須有 15% 的活躍權益發出支持信號，才能進入正式投票。
• 批准： 需要參與投票的「贊成」與「反對」權益（棄權票不計）獲得三分之二（66.67%）的超級多數。
• 時間線： 從達到支持門檻到最終結果，整個週期大約需要 22 天（11 個紀元）。

大局觀：治理成熟化

多年來，對 Solana 的批評一直是其治理過於集中化，過度依賴核心開發者的專業知識。雖然這種方法帶來了驚人的速度和效能，但卻讓質押者和驗證者感覺像是搭上了別人公車的乘客。 SGP 透過將社群的聲音正式化來改變這種動態。它既沒有將王國的鑰匙交給 DAO，也沒有減慢關鍵的工程速度。相反，它為先前依賴非正式共識的經濟和戰略決策創建了一個正式管道。 真正的考驗將在未來幾個月到來。我們將觀察 15% 的門檻多久能被達到，以及有爭議的經濟變革是否能順利通過這個新流程。就目前而言，這代表了 Solana 成熟、穩健的演進——一種在快速、專家主導的工程需求與社群支持的治理必要性之間取得平衡的方式。