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技术有着独到的理解和建议，欢迎投稿和撰写更多精彩技术分享，一经采纳，也会有更多惊喜等着你哟！