Qtum社區|如何經過智能合約，實現高效的鏈上治理（Onchain Governance）

*原文轉自：Qtum社區Allan_Zeng

《Qtum DGP（分佈式自治協議）解析》

引 言

從最近的BCH分叉過程來看，比特幣等POW類型鏈的治理已徹底被大型礦場主（礦霸）壟斷，成了礦霸們爭權奪利的角鬥場，令人們對區塊鏈去中心化變革的信念大受打擊。以太坊雖然有了社區化治理，但在應對突發或緊迫變故時，顯得效率低下；同時也存在「影子政府」把控權利的風險。EOS經過「中心化」架構和社區憲法等措施，使上面的問題略有改善，但依然不能知足將來區塊鏈的治理需求。

所以，以自動化、肯定性爲特徵的區塊鏈線上治理（on chain governance)方案成了你們探索的方向。這其中最有表明性的就是量子鏈（qtum）的DGP。

DGP 功能

DGP的全稱是分佈式自治協議（Decentralized Governance Protocol)。其關鍵是利用智能合約的結果肯定性、規則公開性等特色，把治理框架和規則固化到合約中，以便在須要的時候經過民主的方式進行決策，自動化地完成區塊鏈狀態管理。

DGP框架包括社區過程、智能合約（框架合約、特性合約）、合約生效過程、管理團隊等。管理團隊是指哪些人能夠參與管理，角色劃分，民主與集中機制等；管理團隊能夠起名爲管理委員會，由於全部成員（除了初始行政人員）都是通過投票產生的，其中包括行政人員（administrator）和管理人員（governor)。行政人員專門負責委員會運行機制的維護；也參與權利行使，即各類提案（包括特性合約）的投票等。管理人員專門負責委員會對外權利的行使，即負責特性合約提案投票。

理想的DGP流程應該是這樣的：

1. 在社區討論後提出提案（特性合約）

2. 由管理委員會的行政人員把提案提交到DGP框架合約，啓動投票

3. 由管理委員的全體委員對提案進行投票

4. 假如投票經過，DGP框架合約投票結束，特性合約即生效。在指定的區塊個數以後，特性合約的新特性應用於新區塊

5. 若是預約時間內投票未經過，則結束流程

合約功能

DGP的智能合約有兩類，一類是框架合約，負責完成管理委員會的工做，即權限管理和投票；另外一類是特性合約，負責提供特性數據等。Qtum的框架合約，是預設的，目前有6個（已經使用了5個）；特性合約是根據須要部署的，但目前的規則是一個框架合約只用於一個特性合約，即最多能部署生效6個特性合約。兩類合約結合在一塊兒，才能完成Qtum的鏈上治理功能。

簡單介紹下兩類合約的功能吧，框架合約主要完成管理委員會的人員管理和投票功能，人員管理包含兩個角色人員（admin和gov）的增刪等，投票功能包含投票過程和投票結果管理等。

框架合約的功能定義：

1. 提案和投票，按照msg.sender計票

2. Key Managemant（行政和管理人員的人員管理）

3. 管理特性數據（特性合約地址）

4. 禁用本身（未實現）

5. 支持修改的回滾（未作直接實現，但能夠經過部署以前的特性合約從新投票來實現）

   
   

目前Qtum的特性合約實現比較簡單，主要是提供特性數據，沒有作更多邏輯，即僅提供一個const get函數。

DGP實現

DGP的功能實現主要依賴於框架合約。框架合約中的人員管理功能的實現，以增長管理人員（govKey）的流程爲例，如圖（1）所示。（實際上也是一個投票的過程）。增長一個行政人員（adminKey）的過程和增長管理人員的過程是同樣的；刪除人員的過程也是如此。（如下圖的流程基於github上的公開代碼提煉整理而成）

圖（1）

除了人員管理，就是投票功能。啓動投票以前，須要先把特性合約部署到區塊鏈上，而後把特性合約的地址添加到框架合約中，即啓動了投票。流程以下圖（2）。

圖（2）

你們若是留意觀察流程圖，能夠發現框架合約須要設置一個初始行政人員，才能讓框架合約真正工做。這個初始行政人員也是咱們定義的管理委員會的行政人員（adminKey），每個框架合約有一個獨立的管理委員會，他是這個委員會的第一個行政人員。只有行政人員（adminKey）纔有權限發起投票，包括增減管理委員會人員和增長特性合約地址，因此部署框架合約後就須要首先初始化一個行政人員(adminKey)。

DGP功能的實現主要集中在三個函數中，addAddressProposal、removeAddressProposal和changeValueProposal。代碼的具體實現不作詳細描述了，若是你們關心實現細節，建議仔細研究addAddressProposal函數。

DGP特徵

1. 智能合約：DGP使用智能合約實現，集成了智能合約的能力，使其能夠公開規則、提早部署、可靠執行。

2. 多簽名DGP：的管理委員會一般是有多我的的，目前設置最大能夠有30我的；其對特性合約生效的投票過程，實際就是多簽名的實現。

3. 熱更新、軟分叉：目前Qtum對DGP的使用只是對區塊鏈基本屬性的動態修改，特性合約僅僅提供屬性新數據，能夠在線部署，並且其生效過程也不會致使硬分叉。

缺陷與不足

儘管目前Qtum的DGP實現採用了儘量簡化的方式，但從上面的功能實現分析中，咱們仍是能夠發現一些缺陷和不足。

首先，當前的DGP框架靈活性有限。DGP功能徹底依賴於預設的框架合約，且每一個框架合約只能管理單一屬性。因此，對應一個框架合約只能有一個提案處於投票狀態，即當前提案。

第二，DGP框架合約沒有構造函數。管理參數沒有初始化，使用不方便。最開始部署時，管理委員會僅僅只有一個adminKey，雖然能夠經過直接調用changeValueProposal接口設置管理參數，但這是一個投票過程，初始化走投票過程有些牽強。

第三，角色劃分的邊界不清晰。adminKey和govKey雖然有角色上的區分，但adminKey能夠參與全部行爲，包括對特性合約的投票，這樣govKey角色的功能得不到突顯。建議adminKey只負責管理委員會行政事務，好比發起投票，而不參與決策；govKey負責一切立法過程，即投票，從而體現出是經過公共權力產生了決策結果。

第四，框架合約不可無限次使用。用來保存歷史值的paramHistory是一個數組，作爲合約的狀態保存在區塊鏈上，但對它的使用是隻增元素而不減小。這會形成使用的代價原來越高。

第五，投票狀態的結束條件不可靠。若是一個投票，在規定時間（區塊數）內，達不到投票數目，若再也不有人繼續投票，則該投票會持續處於投票狀態，不能自動結束。在該框架合約上不能啓動新特性合約的投票，必須有人使用原合約地址和類型再調用一次。（這主要是受限於智能合約的能力，你們都知道智能合約不會自發運行，因此靠智能合約內部是不能實現定時功能的，須要經過外部來保障定時的可靠性。）

另外，目前尚未體系化的安全保障。雖然白皮書中提到了一些安全設計，好比延遲生效、不容許針對特定地址的DGP合約等，但尚未體系化，安全保障不完善。好比沒有對特性合約的安全性審查機制，複雜的特性合約如何保障安全，諸如此類。

DGP的將來

雖然目前Qtum的鏈上治理方案還不完美，但不得不說，DGP自己確實是一個極具創意的設計。它爲區塊鏈行業研究鏈上治理方案提供了一個探索的方向。

DGP結合了智能合約的能力，而智能合約的能力在理論上有無限提高的空間，隨着虛擬機能力的提高，智能合約將能作更加智能化的工做。你們都在設想，將來能夠把相對複雜的AI算法寫到智能合約中，甚至智能合約能夠訪問外部世界的數據時，區塊鏈實現自動化管理、自我管理的那一天就近了。以我理解，理想的鏈上治理方案就應該是依據算法實現自動的管理，而不是由人來投票實現的低效的管理模式；或者至少是以自動管理爲主，特別場景下才須要人蔘與。

就目前而言，Qtum DGP僅作了一個簡單的框架，但在這個方向上，將來再設計和擴展的空間很大，鏈上治理的能力還能夠進一步提升。

DGP的意義

用一句話總結，雖然Qtum DGP不夠完善，但意義重大，它爲鏈上治理（on-chain governance)作出了可見的嘗試，引領了一個有價值的探索方向。

關於更多Qtum DGP

連載：Qtum量子鏈設計文檔（五）：分佈式自治協議DGP

Qtum量子鏈分佈式自治協議（DGP）代碼剖析

區塊鏈治理（OnChain Governance）與智能合約的新方向探討

Qtum量子鏈經過DGP實現區塊鏈自治和升級

《區塊鏈治理將走向何方？Qtum量子鏈給你答案》

互動環節

本篇文章由Qtum量子鏈開發社區Allan_Zeng撰寫，深刻淺出講述了關於Qtum量子鏈鏈上治理DGP詳細技術解析，從獨特技術視角寫出了DGP的技術意義以及相關待改進的研究方向。

Qtum量子鏈始終保持開放嚴謹的態度願與Qtum社區開發者一塊兒共建更好的區塊鏈技術生態，本次獎勵Allan_Zeng社區用戶Qtum量子鏈挖礦樹莓派一臺！

若是你也對Qtum技術有着獨到的理解和建議，歡迎投稿和撰寫更多精彩技術分享，一經採納，也會有更多驚喜等着你喲！