引 言

從最近的BCH分叉過程來看，比特幣等POW類型鏈的治理已完全被大型礦場主（礦霸）壟斷，成了礦霸們爭權(quán)奪利的角斗場，使人們對區(qū)塊鏈去中心化變革的信念大受打擊。以太坊雖然有了社區(qū)化治理，但在應(yīng)對突發(fā)或緊迫變故時，顯得效率低下；同時也存在“影子政府”把控權(quán)利的風(fēng)險。EOS通過“中心化”架構(gòu)和社區(qū)憲法等措施，使上面的問題略有改善，但依然不能滿足未來區(qū)塊鏈的治理需求。

因此，以自動化、確定性為特征的區(qū)塊鏈線上治理（on chain governance）方案成了大家探索的方向。這其中最有代表性的就是量子鏈（qtum）的DGP。

DGP 功能

DGP的全稱是分布式自治協(xié)議（Decentralized Governance Protocol）。其關(guān)鍵是利用智能合約的結(jié)果確定性、規(guī)則公開性等特點，把治理框架和規(guī)則固化到合約中，以便在需要的時候通過民主的方式進行決策，自動化地完成區(qū)塊鏈狀態(tài)管理。

DGP框架包括社區(qū)過程、智能合約（框架合約、特性合約）、合約生效過程、管理團隊等。管理團隊是指哪些人可以參與管理，角色劃分，民主與集中機制等；管理團隊可以起名為管理委員會，因為所有成員（除了初始行政人員）都是經(jīng)過投票產(chǎn)生的，其中包括行政人員（administrator）和管理人員（governor）。行政人員專門負責(zé)委員會運行機制的維護；也參與權(quán)利行使，即各種提案（包括特性合約）的投票等。管理人員專門負責(zé)委員會對外權(quán)利的行使，即負責(zé)特性合約提案投票。

理想的DGP流程應(yīng)該是這樣的：

1. 在社區(qū)討論后提出提案（特性合約）

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

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

4. 假如投票通過，DGP框架合約投票結(jié)束，特性合約即生效。在指定的區(qū)塊個數(shù)之后，特性合約的新特性應(yīng)用于新區(qū)塊

5. 如果預(yù)定時間內(nèi)投票未通過，則結(jié)束流程

合約功能

DGP的智能合約有兩類，一類是框架合約，負責(zé)完成管理委員會的工作，即權(quán)限管理和投票；另一類是特性合約，負責(zé)提供特性數(shù)據(jù)等。Qtum的框架合約，是預(yù)設(shè)的，目前有6個（已經(jīng)使用了5個）；特性合約是根據(jù)需要部署的，但目前的規(guī)則是一個框架合約只用于一個特性合約，即最多能部署生效6個特性合約。兩類合約結(jié)合在一起，才能完成Qtum的鏈上治理功能。

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

框架合約的功能定義：

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

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

3. 管理特性數(shù)據(jù)（特性合約地址）

4. 禁用自己（未實現(xiàn)）

5. 支持修改的回滾（未做直接實現(xiàn)，但可以通過部署之前的特性合約重新投票來實現(xiàn)）

目前Qtum的特性合約實現(xiàn)比較簡單，主要是提供特性數(shù)據(jù)，沒有做更多邏輯，即僅提供一個const get函數(shù)。

DGP實現(xiàn)

DGP的功能實現(xiàn)主要依賴于框架合約?？蚣芎霞s中的人員管理功能的實現(xiàn)，以增加管理人員（govKey）的流程為例，如圖（1）所示。（實際上也是一個投票的過程）。增加一個行政人員（adminKey）的過程和增加管理人員的過程是一樣的；刪除人員的過程也是如此。（以下圖的流程基于github上的公開代碼提煉整理而成）

除了人員管理，就是投票功能。啟動投票之前，需要先把特性合約部署到區(qū)塊鏈上，然后把特性合約的地址添加到框架合約中，即啟動了投票。流程如下圖（2）。

大家如果留意觀察流程圖，可以發(fā)現(xiàn)框架合約需要設(shè)置一個初始行政人員，才能讓框架合約真正工作。這個初始行政人員也是我們定義的管理委員會的行政人員（adminKey），每一個框架合約有一個獨立的管理委員會，他是這個委員會的第一個行政人員。只有行政人員（adminKey）才有權(quán)限發(fā)起投票，包括增減管理委員會人員和增加特性合約地址，所以部署框架合約后就需要首先初始化一個行政人員（adminKey）。

DGP功能的實現(xiàn)主要集中在三個函數(shù)中，addAddressProposal、removeAddressProposal和changeValueProposal。代碼的具體實現(xiàn)不做詳細描述了，如果大家關(guān)心實現(xiàn)細節(jié)，建議仔細研究addAddressProposal函數(shù)。

DGP特征

1. 智能合約：DGP使用智能合約實現(xiàn)，集成了智能合約的能力，使其可以公開規(guī)則、提前部署、可靠執(zhí)行。

2. 多簽名DGP：的管理委員會通常是有多個人的，目前設(shè)置最大可以有30個人；其對特性合約生效的投票過程，實際就是多簽名的實現(xiàn)。

3. 熱更新、軟分叉：目前Qtum對DGP的使用只是對區(qū)塊鏈基本屬性的動態(tài)修改，特性合約僅僅提供屬性新數(shù)據(jù)，可以在線部署，而且其生效過程也不會導(dǎo)致硬分叉。

缺陷與不足

盡管目前Qtum的DGP實現(xiàn)采用了盡可能簡化的方式，但從上面的功能實現(xiàn)分析中，我們還是可以發(fā)現(xiàn)一些缺陷和不足。

首先，當(dāng)前的DGP框架靈活性有限。DGP功能完全依賴于預(yù)設(shè)的框架合約，且每個框架合約只能管理單一屬性。所以，對應(yīng)一個框架合約只能有一個提案處于投票狀態(tài)，即當(dāng)前提案。

第二，DGP框架合約沒有構(gòu)造函數(shù)。管理參數(shù)沒有初始化，使用不方便。最開始部署時，管理委員會僅僅只有一個adminKey，雖然可以通過直接調(diào)用changeValueProposal接口設(shè)置管理參數(shù)，但這是一個投票過程，初始化走投票過程有些牽強。

第三，角色劃分的邊界不清晰。adminKey和govKey雖然有角色上的區(qū)分，但adminKey可以參與所有行為，包括對特性合約的投票，這樣govKey角色的功能得不到突顯。建議adminKey只負責(zé)管理委員會行政事務(wù)，比如發(fā)起投票，而不參與決策；govKey負責(zé)一切立法過程，即投票，從而體現(xiàn)出是通過公共權(quán)力產(chǎn)生了決策結(jié)果。

第四，框架合約不可無限次使用。用來保存歷史值的paramHistory是一個數(shù)組，做為合約的狀態(tài)保存在區(qū)塊鏈上，但對它的使用是只增元素而不減少。這會造成使用的代價原來越高。

第五，投票狀態(tài)的結(jié)束條件不可靠。如果一個投票，在規(guī)定時間（區(qū)塊數(shù)）內(nèi)，達不到投票數(shù)目，若不再有人繼續(xù)投票，則該投票會持續(xù)處于投票狀態(tài)，不能自動結(jié)束。在該框架合約上不能啟動新特性合約的投票，必須有人使用原合約地址和類型再調(diào)用一次。（這主要是受限于智能合約的能力，大家都知道智能合約不會自發(fā)運行，所以靠智能合約內(nèi)部是不能實現(xiàn)定時功能的，需要通過外部來保障定時的可靠性。）

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

DGP的未來

雖然目前Qtum的鏈上治理方案還不完美，但不得不說，DGP本身確實是一個極具創(chuàng)意的設(shè)計。它為區(qū)塊鏈行業(yè)研究鏈上治理方案提供了一個探索的方向。

DGP結(jié)合了智能合約的能力，而智能合約的能力在理論上有無限提升的空間，隨著虛擬機能力的提升，智能合約將能做更加智能化的工作。大家都在設(shè)想，未來可以把相對復(fù)雜的AI算法寫到智能合約中，甚至智能合約可以訪問外部世界的數(shù)據(jù)時，區(qū)塊鏈實現(xiàn)自動化管理、自我管理的那一天就近了。以我理解，理想的鏈上治理方案就應(yīng)該是依據(jù)算法實現(xiàn)自動的管理，而不是由人來投票實現(xiàn)的低效的管理模式；或者至少是以自動管理為主，特別場景下才需要人參與。

就目前而言，Qtum DGP僅做了一個簡單的框架，但在這個方向上，未來再設(shè)計和擴展的空間很大，鏈上治理的能力還可以進一步提高。

DGP的意義

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