基于区块链的线上分布式自治协议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上的公开代码提炼整理而成）

除了人员管理，就是投票功能。启动投票之前，需要先把特性合约部署到区块链上，然后把特性合约的地址添加到框架合约中，即启动了投票。流程如下图（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）做出了可见的尝试，引领了一个有价值的探索方向。