治理是 Web3 產品的一部分，但是治理總覺得離一般用戶很遠又飄渺，真的有能力、有必要去評估嗎？本文以最基礎的拆解方向「流程」為基礎，以 Web3 三大價值去「中心化、效率、安全」作為標準，讓每個人都能有系統的評估項目治理成效。

Web3 治理介紹

為什麼需要治理

治理已經是 Web3 產品重要的一部分。Web3 產品一律是由

• 運作系統
• 產品發展治理
• 代幣價值系統

所組成，而產品發展路線的決策若要滿足 Web3 自由傳遞價值的理念，那麼就需要將「決定價值流動」的權力也還給用戶，也就是說用戶可以共同決定產品開發未來，因此治理在 Web3 領域是重要關鍵。

因為 Web3 自由傳遞價值的理念，決定產品未來發展方向的權利本身也是一種價值，因此需要將此價值也還給用戶與代幣持有者。

為什麼需要評估治理

治理好像聽起來非常飄渺又摸不著，常常聽到某某協議的治理出現問題，真的是問題嗎？對於協議長久發展是否會有影響？其實大多數人都會跟著新聞或是風向思考，因為大多數情況相信專業好處大於壞處，並沒有對錯。

但是身處新自由主義的 Web3 世界，任何事情都要為自己負責，掌握一套自己的評估項目標準絕對利大於弊，今天就來談談 Web3 產品重要的一環 — 治理。

該如何評估

是否有什麼好的方式可以評估治理的成效呢？

如同評估其他事情的成效，例如學業表現，需要先設定要評估的標的，也就是國文、數學、英文等科目，再來需要設定評估標準，在此例子也就是考試成績須達 60 分，或是實作出一個作品等，都是一個評估標準。

治理也是如此，應該界定評估的面向有什麼，再來界定各面向的評估標準。

評估面向

評估治理這個面向時，流程正當性非常重要，如果流程有瑕疵就不可能有良好的治理品質，因此最基本要注意的治理面向就是流程。

一般來說 Web3 的治理流程又可以在細分為提案討論、提案投票、提案執行三個階段，各個階段分別有不同的重點面向需要關注：

• 提案討論：論壇活躍度、溫度測試。
• 提案投票：鏈上投票、投票權分配。
• 提案執行：執行效力。

評估標準

標準來自普遍的價值觀，於 Web3 世界最重要的價值觀就是使個體可以「自由傳遞價值」，而這個價值則由以下三大面向構成：詳情可以參考〈區塊鏈不等於 Web3？什麼才是 Web3 的剛需？〉

• 去中心化：治理的流程是否有滿足去中心化？
• 效能：治理的流程是否有效率？是否能及時反映問題？
• 安全：治理的流程是否能確保提案確實執行？

這三個 Web3 用戶的需求，治理屬於 Web3 產品的一部份，當然同樣需要滿足這三個基本需求。至於其他標準則會依照不同的協議領域與客戶差異有所不同，不過這三大項是共通的基本款。

清楚了需要評估的面向 (治理的各階段流程) 與標準 (去中心化、效率、安全)，接下來就是詳細對此作說明與案例研究。

治理去中心化

最低標準

去中心化的標準是什麼？先談談最低標準，也就是平台可以完全控制治理時，幾乎完全中心化的狀態其實還是有機會贏得部分用戶的信賴的，根據《平台獲利模式》一書中表示，平台的治理只要不違背三件事情，基本上不會讓用戶出現反感：

• 總是為顧客創造價值
• 別為了利益濫用權力改變規則
• 別貪圖公平以外的財富

舉例來說，OpenSea 的治理常常被詬病為根本就是 Web2 作風，什麼都是開發團隊單方面說的算，最常見的爭議是 OpenSea 下架侵犯版權的 NFT，但其實仔細思考這件決策，本質上並沒有違背這三個原則。

• 下架盜版可以讓顧客買到正版的 NFT，相對是提升顧客價值
• 為了原作者的利益禁止仿冒者並沒有濫用權力
• 當然，禁止侵犯版權的行為一直都是社會共識，OpenSea 也不斷以相同規則進行項目評估，此舉沒有違背社會規則，並維持一貫行為是公平的。

因此雖然目前 OpenSea 是十足的中心化治理，不論是下架機制、產品發展決策等，相對其他 Web3 專案都是中心化的，但是因為沒有明顯違背決策的底線原則，所以社群還是有一定的接受程度的，若維持這個方針現階段不太會有問題，反而去中心化治理以現在的環境更容易產生其他問題。

總結來說目前 OpenSea 的治理雖然不是去中心化的，現階段仍可以被社群接受。但是需要考量到 Web3 文化，逐步地隨著環境與市場需求作出調整。

最高標準

當然，如果平台是完全去中心化的，包含鏈上投票與鏈上執行，那麼就不用在乎上文論述。不過現階段非常難達到完全的去中心化，不論是技術、應用必要性、用戶認知等發展都還有很大的進步空間。分析去中心化標準需要以治理各階段作分析：

• 提案討論：論壇活躍度、溫度測試。
• 提案投票：鏈上投票、投票權分配。
• 提案執行：執行效力。

接下來分別說明各階段，協議治理去中心化判斷質化指標：

提案討論：是否有建立治理論壇是很重要的指標，治理論壇代表社群溝通的管道，同時也是提案構思的搖籃。例如 Sushiswap 擁有自家的治理論壇，作為提案前的討論空間，最終投票再使用 Snapshot 進行。當然也可以使用 Telegram 或是 Discord 代替，但是擁有一個可以追蹤提案與討論紀錄、觀察稻草民調、議題完整分類專門的工具或平台，當然對於協議的治理機制會更好。

提案投票：重點是投票是否有在鏈上進行，在鏈上的投票過程才可以確實達到去中心化。另外還要評估投票分數計算方式是否合理，是否有不合理的計分規則。例如 Curve 的投票規則是依據代幣鎖倉時間計算權重，確實可以讓真正在意協議的用戶更好地表達自身意見。

提案執行：執行是否確實有效力，這一部分與「治理安全」標準類似，下方會詳細說明。

治理效率

為什麼治理效率重要？因為如果治理速度太慢，很多時候往往無法反映現實狀況作出調整，就失去治理的效果，例如近期 Curve 自家代幣 CRV 因為遭到駭客攻擊價格暴跌，借貸協議 AAVE 為了不被此事件波及，需要作出危機應變措施。但因為受限於治理程序，做出反應的時間稍微慢了些，雖然這次 AAVE 並沒有因此受到影響，但確實是一個潛在的風險。

如果要將全部的議題都以鏈上治理進行，效率會變成非常低，從 Uniswap 治理規則可以知道，Uniswap 提案被執行需要經過三個投票：

1. temperature check：門檻 2.5 萬 UNI 參與 snapshot。
2. consensus check：門檻 5 萬 UNI 參與 snapshot。
3. 鏈上投票：門檻 250 萬 UNI 參與鏈上投票。鏈上投票需要經過提案者提交經過審核代碼後投票。

Uniswap 從提案討論到提案執行投票，通常要一整年，因為要過最後一關的鏈上投票之前，提案者要先把代碼寫完，還得要經過審計，才可以送交鏈上提案，可以想像是一件多大的工程，由此案例就可以知道鏈上的治理，追求去中心化會多大程度地犧牲效率。

在效率當道之下，治理不一定需要投票：是為了可以快速反應外在變化，否則產品失去競爭力將會使治理將失去意義，

在治理各階段分析治理效率的重點也不相同：

• 提案討論：討論提案的速度與機制是否可以在短時間到位，社群成員的活躍度會影響效率。
• 提案投票：投票機制是否能在短時間內反應大多核心參與者與社群成員意向。
• 提案執行：執行是否能確實快速解決問題。

治理效率雖然越高越好，但是通常效率高，就會降低去中心化。因此理想的狀態應該是以緊急程度將提案分類，協議未來發展性的議題應該盡可能的去中心化，像是 Uniswap 目前的機制。但是如果緊急狀態發生，那麼應該允許團隊做出應變措施，但是這樣就會帶到第三個標準 — 安全性，如果團隊可以自行利用某種方式做出足以影響產品發展的行為，那麼安全性必然會受到質疑。

治理安全

治理安全主要會著重在幾個議題：

• 提案討論：治理攻擊，例如 Tornado Cash 案例
• 提案投票：治理攻擊，例如 MakerDAO 案例
• 提案執行：執行效力，例如 Pancakeswap 案例

分別舉例討論：

提案討論：惡意治理提案攻擊，討論與實際提出的程式碼並不是相同一回事，可能包含惡意隱藏的事實或是意圖。例如過去 Tornado 被美國政府封殺之後，代幣價格因此一落千丈。此時因為代幣價格相對較便宜，讓有心人士利用治理惡意提案，授權自己不公平的投票，最終獲得協議控制權。上述事件會因為該協議論壇失去社群維護，或是沒有清楚表達提案內容、經過充分討論導致提案討論流程出現問題。

提案投票：利用不適當的方式取得投票權，使得真正的利害關係人的投票權益被稀釋甚至直接被顛覆。例如 MakerDAO 早期的提案，借貸整合協議 B Protocol 的團隊利用閃電貸從 dYdX 借出了巨額貸款並購買大量 MKR 代幣進行投票，影響投票結果。

解決方法是帶入時間機制與其他計算權重的方式，而不能以代幣樹作為唯一全種衡量標準。只是要注意還是有可能會因為代幣突然變得很便宜，使得代幣被單一買家買走，控制治理解結果，例如 Terra 崩盤後官方防範治理攻擊的措施。

提案執行：執行效力有兩個面向，分別是對於投票結果否有強制力，另一方面是團隊是否可以自行藉由某些方式改變產品，也就是智和合約是否有後門。

對於投票結果否有強制力：建立在兩件事情上是否有作到位：

• 程式碼先提交：如同治理效率段落所述，如果希望提案具有強制力，那麼就需要在提案投票前把程式碼撰寫完成並提交，這樣可以確保治理結果可自動化執行 (通過時自動運行寫好的程式碼)，而不會有提案通過卻發現團隊做不出來或是不想做的情況。目前只有 Uniswap 有做到這個標準，只要沒有完全由程式碼控制，那麼就仍需要回歸信任，需要相信團隊會按照設社群提案方向前進，而程式碼先提交可以有效增加提案執行效力。
• 提案冷卻時間：例如 Pancakeswap 提案常常有這問題。很巧妙地提供幾個選項，如果提案不通過團隊會再與社群短暫溝通，然後稍微修改選項後再進行一次投票，就算投票再不通過，團隊還是會馬上發行下一輪投票，直至通過，這樣導致提案不通過的意義全失。更好的方式是應該要設立提案冷卻時間，這也是治理結果執行力不可或缺的。

對於智能合約是否有後門：很多智能合約其實都有後門，也就是讓團隊可以藉由一些手段影響智能合約運作的後門，這部分設計許多技術門檻，但是一般人可以使用 a16z 提供的工具檢測。來看看 CAKE 代幣的合約，檢測結果發現合約內存在 delegatecall 函數，代表該合約可以調用其他合約的程式碼，包含自毀合約，白話文就是可以藉此機制更新合約內容，某方面就是開發者的後門機制。

理想上，最後是全部都顯示 NO，對於協議後門防範會更全面，也更可以確保不論是協議本身或是治理結果，執行的安全性。

安全性看似複雜並且有許多細節，但另一面，可以從中很好的判斷團隊對於治理的重視程度。

結論

治理是 Web3 產品的一部分，如何評估治理以示至關重要的技能。

治理不是單一面向的評估，評估標準也不是只有一種。

本文探討了治理的基本評估架構，將 Web3 治理最基礎的流程，拆解成提案討論、提案投票、提案執行三階段，分別去檢視 Web3 最重要的三個價值去中心化、效率、安全是否有達到。藉此大致評估團隊對於治理的重視與經驗，對於自身評估項目的方法將有所提升。

總結上述各階段面向與評估標準，大致可以歸納此表：

	提案討論	提案投票	提案執行
去中心化	是否有建立治理論壇	是否有在鏈上進行 投票計算方式是否合理	對於投票結果否有強制力 智能合約是否有後門
效率	討論提案的速度 社群成員的活躍度	是否能在短時間反應社群成員意向	是否能快速確實解決問題
安全	提案內容與程式是否相符 是否有防範治理攻擊機制	是否有持有時間門檻短期持有者	對於投票結果否有強制力 智能合約是否有後門

未來看待項目的治理，將可以更立體的分析各階段優劣，進而作整體的評估。

持續思考，呵護熱情，下次見。