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 相關聯的鏈上記錄。這確保了正在投票的提案無法在中途被更改。

投票規則：

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

宏觀視角：治理成熟化

多年來，對 Solana 的批評一直是其治理過於中心化，過度依賴核心開發者的專業知識。雖然這種做法帶來了驚人的速度與效能，卻讓質押者與驗證者感覺像是坐在別人巴士上的乘客。

SGP 透過將社群聲音正式化來改變這種動態。它並未將王國的鑰匙交給 DAO，也不會減緩關鍵工程的進行。相反，它為先前依賴非正式共識的經濟與策略決策，創建了一個正式管道。

真正的考驗將在未來幾個月內到來。我們將觀察 15% 的門檻多常被觸及，以及有爭議的經濟變革是否能順利通過這個新流程。就目前而言，這代表 Solana 成熟、穩健的演進：一種平衡快速、專家主導的工程需求與社群支持治理必要性的方式。