引 言

從最近的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上的公開代碼提煉整理而成）

除了人員管理，就是投票功能。啟動投票之前，需要先把特性合約部署到區塊鏈上，然后把特性合約的地址添加到框架合約中，即啟動了投票。流程如下圖（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）做出了可見的嘗試，引領了一個有價值的探索方向。