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

Solana基金會已正式推出Solana治理提案（SGP），此舉標誌著網路在決策方式上邁出重要一步。 SGP vs. 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來說代表著一種成熟、穩健的演進，一種平衡快速、專家主導的工程與社群支持治理需求的方式。