鏈上治理：技術堆疊詳解

治理經常被談論得像一個政治流程，但背後的機制純粹是軟體工程：智慧合約、代幣會計和共識規則決定誰能改變系統和如何改變。如果你在評估某個 DAO 或協議升級路徑，理解技術堆疊比讀使命陳述書重要得多。

核心元件

大多數鏈上治理系統由一小組部分組成：

• 投票合約 — 追蹤提案、計算投票結果並強制實施法定人數門檻
• 代幣或聲譽權重 — 決定給定地址的投票權重多少（代幣加權、二次方或委託）
• 時間鎖合約 — 延遲通過提案的執行，通常 24-72 小時，讓使用者在變化落地前作出反應
• 執行模組 — 一旦投票通過，實際呼叫受影響合約的程式碼路徑

Compound 的 Governor Bravo 和 OpenZeppelin 的 Governor 合約是大多數較新專案分叉或擴展的參考實現。如果你要讀一份程式碼庫來理解這個模式，讀 OpenZeppelin 的 Governor.sol — 註釋詳細，展示了完整的提案生命週期：提議、投票、排隊、執行。

提案如何實際通過系統

提案不只是被非正式投票的論壇貼文。在鏈上，它是 calldata：一個目標合約地址、函數選擇器和編碼的參數。當有人提交治理提案時，他們提交的是如果投票通過就會執行的確切交易。

流程通常如下：

1. 提議人提交 calldata 加上說明，通常需要最少代幣餘額以防止垃圾提案
2. 投票延遲（通常 1 區塊到幾天）讓持有人在投票開始前有時間審查
3. 投票期開始進行（Compound 預設大約 3 天，雖然許多分叉配置更長的窗口）
4. 如果達到法定人數和批准門檻，提案進入時間鎖佇列
5. 時間鎖延遲過期後，任何人都可以呼叫執行來執行交易

投票關閉和執行之間的間隔是安全後盾。這是社群能注意到惡意或有缺陷提案的窗口，在極端情況下，協調應急回應 — 假設協議有應急守護角色或多簽覆蓋，許多協議在早期治理階段都有。

權重邏輯變得複雜的地方

簡單的代幣加權投票有一個已知問題：持有最多代幣的人控制結果，投票人出席率通常很低。一些治理論壇報告例行提案的投票人出席率只有流通供應量的個位數百分比。

專案嘗試了幾個修正：

• 委託 — 代幣持有人將投票權分配給委託人而不轉移代幣，這是 Compound 和 Uniswap 如何處理代議制投票的方式
• 二次方投票 — 額外投票的成本以二次方增加，旨在減少鯨魚主導，但 Sybil 抵抗（一個人創建多個地址）仍然是開放的問題
• 確信投票 — 由某些 Gitcoin 相關工具使用，其中投票權的累積時間越長代幣保持對某個立場的承諾，相比快照投票更看重持續偏好

這些都沒有完全解決代幣投票的低出席率、傾向寡頭政治的動態。它們是緩解措施，不是修正，任何聲稱否則的詞彙表條目都是過度推銷技術。

鏈下信號與鏈上執行

許多被稱為