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

Solana 基金會正式推出了 Solana 治理提案（SGP），此舉標誌著該網路在決策方式上邁出了重要一步。 SGP 與 SIMD：「為什麼」vs「如何」 要理解 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 來說是一個成熟、穩健的演進。一種在快速、專家主導的工程需求與社群支持的治理必要性之間取得平衡的方式。