Qtum DGP解析

96
Allan_Zeng
2018.11.27 22:53* 字数 2776

引言

        从最近的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特征

        智能合约。DGP使用智能合约实现,集成了智能合约的能力,使其可以公开规则、提前部署、可靠执行。

        多签名。DGP的管理委员会通常是有多个人的,目前设置最大可以有30个人;其对特性合约生效的投票过程,实际就是多签名的实现。

        热更新、软分叉。目前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)做出了可见的尝试,引领了一个有价值的探索方向。


作者

allanzeng, Senior Engineer from DeepBrain Chain.

null.zeng.cn@gmail.com

BlockChain
Gupao