Governance V2

波卡採用了一套精巧的治理機制,使其能夠根據利益相關者的需求不斷演進。其目標是確保大多數權益始終能夠控制網路。

本文內容可能會有變更。治理協議已經經歷了幾次迭代(v1和v2),未來還會有更多變化(v2.5)。

波卡的第一個去中心化治理系統(v1)由三個主要組件組成:

• 技術委員會:管理升級時間表
• 理事會:經選舉產生的執行"政府",負責管理參數、管理和支出提案
• 公投:普遍投票系統,賦予長期利益相關者更大影響力

該系統在最初幾年運行良好,但隨着成熟需要不斷演進以改進缺點和跟上進步。例如,在"治理v1"中,所有公投權重相同,一次只能對一個公投投票,投票期可持續數周。這導致系統傾向於仔細考慮極少數提案,而不是廣泛考慮多個提案。因此"治理v2"應運而生。

"治理v2"或稱"Gov2"改變了日常決策方法,使公投影響範圍更廣、更敏捷,從而顯著增加系統能做出的集體決策數量。

Gov2將在Kusama上啓動並測試後,再提議部署到Polkadot上。目前Gov2已經上線至Kusama網路。

以下內容將介紹Polkadot網路的核心治理原則。了解治理v1的根源,有助於更好地理解第二次迭代的方向。這些差異將在各個子主題中突出顯示。

需要注意的是,在當前階段,治理仍是不斷發展的協議。隨着治理v2的更新,治理v2.5的計劃也已在制定中。

前提

概括來說,該網路匯集了多種新穎機制,包括存儲在鏈上的無定形狀態轉換函數(以WebAssembly定義),以及多種鏈上投票機制,如具有自適應絕對多數閾值的公投和批量批準投票。

對協議的所有更改,都必須通過權益加權的公投達成一致。

機制

在治理v1中,活躍的token持有者和理事會共同管理網路升級決策。無論提案由公衆還是理事會提出,最終都必須經過全民公投,以質押額和信念值爲權重做出決定。

治理v2有幾個變化。新治理模式體現去中心化特徵的方式是:

• 通過民主投票將理事會的責任轉移給token持有者
• 解散現任理事會
• 允許用戶以更多方式將投票權委托給社區成員

公投

公投是簡單、包容性、基於質押的投票方案。每個公投都有一個相關提案,採用runtime特權函數調用形式(包括最強大的set_code調用,可切換整個runtime代碼)。

公投是具有固定投票期的離散事件。投票期結束並統計選票後,如果獲得批準,將調用相關函數。公投總是二元的;投票選擇只能是"贊成"、"反對"或完全棄權。

在治理v1中,公投可通過以下幾種方式啓動:

• 公開提交的提案
• 理事會多數或全票通過的提案
• 作爲先前公投執行的一部分提交的提案
• 由技術委員會提交並經理事會批準的緊急提案

所有公投都有相應的執行延遲期。這是從公投結束到提案實際執行之間的一段時間。

在Gov2中,任何人都可以隨時發起公投,次數不限。Gov2引入了Origins(來源)和Tracks(軌道)概念,以幫助公投協議的流程和處理。

Origin可視爲給定特權級別的描述符。提議者需要根據提案要求,爲請求選擇合適的Origin。

每個Origin都與一個公投類別關聯,每個類別都有一個Track。Track概述了提案的生命週期,並獨立於其他類別。不同的獨立軌道允許網路根據隱含的特權級別調整公投動態。

例如,Runtime升級對生態系統的影響,與國庫小費批準不同,因此需要不同的Origins,其中不同的投票率、批準率、押金和最短執行週期將預先確定。

提案公投

公衆公投

任何人都可以通過在一定時期內存入最低數量的token來提議公投。如果有人同意,他們可以存入相同數量的token表示支持。

這稱爲"背書"。獲得最高綁定token支持的提案將被選爲下一個投票週期的公投。注意這可能與背書的絕對數量不同;例如,三個帳戶每個綁定20 DOT將"超過"十個帳戶每個綁定1 DOT。

一旦提案被提交(進行投票),綁定的token將被釋放。

對於治理v1,提案隊列中最多可有100個公共提案。

在Gov2中,當公投創建後,社區就可以立即投票。但該公投並未處於可結束、計算選票、獲得批準和最終執行的狀態。相反,公投必須滿足一些標準,才能進入"決定(Deciding)"狀態。在此之前,仍處於待定狀態。

進入Decided狀態的標準如下:

• 經歷了導入期,即決定可以開始前必須經過的時間。這有助於減少"決定狙擊"的可能性,即控制大量投票權的攻擊者可能在提議後立即通過提案,而不讓全體投票者有足夠時間考慮和參與。

• 必須還有決定的剩餘空間。所有Track都對可同時決定的公投數量有限制。更強大的軌道限制更低。例如,Root級別Origin的限制爲1,意味着一次只能決定1個超級危險的提案。

• 必須支付決定押金。創建公投成本很低,因爲押金僅包含跟蹤所需鏈上存儲的價值。但對公投進行審查和決定,存在耗盡公投隊列有限位置的風險。要求提供較大但可退還的押金,有助於減少垃圾信息。

理事會公投 (v1)

理事會全票通過 - 當理事會所有成員同意一項提案時,可將其移至公投。該公投將產生負投票率偏差(即權益投票數量越少,通過所需數量越少)。

理事會多數通過 - 當只有簡單多數理事會成員同意時,也可對公投投票,但將是多數票制(獲得51%票的一方獲勝)。

任何時間只能有一個有效公投,除非有正在進行的緊急公投。

投票時間表

在治理v1中,假設隊列中至少有一個提案,每28天就會進行一次新的公投。理事會批準的提案有一個隊列,公衆提交的提案也有一個隊列。將在兩個隊列中排名靠前的提案之間輪流進行公投。

排名最靠前的提案由其背後綁定的質押數量確定。如果當前隊列選擇嘗試創建沒有提案的公投(隊列爲空),並且另一個隊列有排隊中的提案,則另一個隊列中最靠前提案將進入公投。

不能在同一時期對多項公投表決,緊急公投除外。與常規公投同時發生的緊急公投是唯一可同時對多項公投投票的情況。

當提案獲得批準時,治理v2共享相同的28天資格期。如果在此階段結束時仍未獲批準,則該提案將自動被拒絕。

公投投票(治理v2)

在治理v2中,如果提案滿足批準率和支持率要求,則該提案將獲得批準,即刪除了自適應羣體偏見系統。

批準率(Approval)被定義爲批準投票權重(在conviction調整後)佔總投票權重(包含批準和拒絕)的份額。

支持率(Support)是批準的總票數(忽略conviction調整)與系統中可能進行的總票數的比較。

它必須在確認期的最短時間內滿足此標準。不同軌道有不同的確認期和批準及支持要求。現在可以配置通過所需的支持量和總體批準。對於使用較低特權來源的提案,與使用高特權類別(如Root)的提案相比,更早地將所需投票率降低到更現實的數量更爲合理。具有較大政治意義的課程可以盡早要求更高的批準,以避免爭議。

在Gov2中,28天後未獲批準的提案將被視爲默認拒絕,並退還Decision Deposit。如果提案在確認期結束前保持通過,則視爲已獲批準,並計劃在制定期之後從提議的來源開始執行。制定期在全民投票提議時指定,但也受制於基於軌道的最小值。更強大的Tracks會強制執行更長的執行期,以確保網路有足夠時間爲提案可能帶來的變化做準備。

自願鎖定

Polkadot使用"自願鎖定"概念,允許token持有者通過聲明願意鎖定token多長時間來增加投票權,因此,每個token持有者的投票數將使用以下公式計算:

投票數 = token * conviction乘數

鎖定期數每番一倍,conviction乘數都會將投票乘數增加一。

鎖定期數投票乘數 00.111224384165326

鎖定期"加倍"的最大次數設置爲6(總共32個鎖定期),一個鎖定期等於28天。只允許加倍,例如,不能鎖定24個週期並使conviction增加5.5。

token被鎖定後,仍可用於投票和質押;只被禁止將這些token轉移到另一帳戶。

選票總是在同一時間"計算",即在投票期結束時。這不受token鎖定期影響。

自適應羣體偏見

自適應羣體偏差在治理v2中使用的時間更長,並被Approval/Support系統所取代。

理事會

在治理v1中,波卡上的被動利益相關者由稱爲"理事會"的管理機構代表。理事會是一個鏈上實體,由多個參與者組成,每個參與者代表一個鏈上帳戶。在Polkadot上,理事會目前由成員組成。

除控制國庫外,理事會還主要負責三項治理任務:

• 提案明智的公投
• 取消危險或惡意的公投
• 選舉技術委員會

在治理v2中,需要替代策略來取代理事會以前作爲選民委托機構的職責,以彌補許多人選擇不參與日常治理的事實。Gov2建立在v1的投票委托功能之上,選民可以選擇將投票權委托給系統中的另一個選民。它通過改進稱爲多角色委派的功能來實現,選民可以爲系統中的每一類公投指定不同的代表。因此,選民可以委托某個實體來管理某個影響不重大的公投類別,而選擇另一個不同的代表來管理另一個具有更重大後果的不同類別,並且仍然保留對任何剩餘類別的完全投票權。

取消公投

在治理v1中,如果技術委員會一致同意取消提案,或者如果Root來源(如sudo)觸發此功能,則可以取消提案。已取消提案的押金將被銷毀。

此外,理事會三分之二多數可以取消公投。如果在公投提案中發現問題較晚(如該提案將執行的runtime代碼中存在錯誤),這可能會作爲最後的手段。

如果取消的爭議足夠大,以至於理事會無法獲得三分之二多數,那麼將由利益相關者共同決定提案的命運。

在治理v2中,有一個名爲Cancelation(撤銷)的特殊操作,用於幹預已經投票的提案。該操作將立即拒絕正在進行的公投,無論其狀態如何。還有一項規定,如果提案是惡意的或垃圾信息,則確保提議者的押金被罰沒。

Cancelation本身是一種治理操作,必須由網路投票才能執行。撤銷伴隨着它自己的Origin和Track,它具有很短的導入期和批準率/支持率曲線,通過門檻下降得稍微迅速一些,因爲它是在情況緊迫時才調用的。

技術委員會

在治理v1中,技術委員會(TC)作爲Kusama治理的三院之一(另外兩院是理事會和公投)而引入。TC由成功實施或定義Polkadot runtime或Polkadot Host的團隊組成。通過理事會的簡單多數投票,可以在TC中添加或刪除團隊。

TC的目的是防止惡意公投、實施bug修復、逆轉錯誤的runtime更新或添加新的但經過實戰檢驗的功能。TC有權使用Democracy pallet加速提案,並且是唯一能夠