MakerDAO治理研究

最近，由于某个区块链项目的设计需要，使我想到了治理代币的事情，这对我也是很有诱惑力的一件事情。于是周末利用碎片时间，研究了很多文档，加上我的想象，觉得如果自己去搞，应该可以做一套低配的治理代币的系统出来。

在我的脑海里，所谓治理代币，就是代币持有人，去对这个代币所在的系统的一些方案进行投票，这个投票应该跟DPOS系统差不多，代币代表了投票人说话声音的大小，就是权重，那么这个方案本身可能是一个智能合约，如果某个方案通过了，那么这个智能合约的地址应该会成为目标智能合约系统里某个修改参数的函数的owner，或者类似这么个角色，类似下面这个函数：

function setParameter(uint commission) public onlyArbitrator

当某个方案代表的修改参数的智能合约被选中，很可能有这么个函数，把这个合约地址加入到合法的Arbitrator角色里去：

function addArbitrator(address)

为了验证我的想法和现实的差距，我研究了这些文档，努力搞懂makerDAO的治理机制，它的投票方案有两种类型：管理型和执行型的（governance and executive），管理型投票就是笼统的一个建议，不是涉及特别的技术细节，投票时候就是Yes 或者No，你同一个笼统建议，还有许多不同的执行方式呢，对于执行型建议，会有很多，投票人可以投几个，这个有点像DPOS系统里投票，最后权重数量最大的那个获奖，它是一种叫做“approval voting”的方式。获奖的那个提议，就可以更改系统参数。这是我从官方网站截取的图，很能说明它的设计理念。

首先，这里体现了MKR的治理代币的属性，只能用它来抵押投票，把这个锁定到投票合约（ ds-chief）里，获取同等价值的IOU（I Own You）的代币，任何时候可以用IOU代币从投票合约里换取MKR，这个我不是很理解，为何要引入IOU，增加了系统的复杂性，我觉得这个从技术简单角度说，就抵押MKR，然后想取出来就取出来，反正系统可以记录msg.sender，要么它是考虑可以用投票代理，就像DPOS机制里投票代理一样，但是那也不是什么问题啊，反正我觉得这里有些奇怪。

被投票的提议被封装在一个叫做“slates mapping”的结构里，这个slate实际上是一个索引，对应一堆提议的合约地址：

vote(bytes32 slate) 投票给现有的提议集合
vote(address[] yays) 创建出新的提议集合，并且也封装到一个新的slate中：etch(address[] yays)

投票合约（ ds-chief）通过加权计算得到的获胜的提议，给它一顶帽子（hat），这样任何人都可以执行这个合约去修改母合约（就是MakerDAO系统）的参数了。具体的过程，估计得去查看MakerDAO的代码了，但是有了这个设计思路已经足够，每人实现方法不一样，大同小异。

这里有几个重要概念需要澄清有助于理解它的投票机制：

hat - 当某个新提议（spell ）的权重票数比当前这个提议多的时候，一个叫做lift的函数就会被调用，给这个新提议戴上帽子，表示它是现在权重票数最多的，投票系统有个时间限制，时间到了，被戴上帽子的提议才能被执行。

cast - 当某个提议被戴上了帽子，它就可以被执行（cast）去修改Maker system的系统参数。这个提议只能被执行一次。

lift - 这是个函数，给新的权重数最多的提议戴上帽子，替代旧的提议。

我觉得现在不必要费力气多挖掘各个区块链系统的原理，因为大家都是刚开始，都不完善，所以你费尽心思弄明白了，它说不定过一阵都变了，或者过一阵被新的系统替代掉。当然，这是我这种懒人的思维模式。

FEATURED TAGS

FRIENDS

分享:

FEATURED TAGS

FRIENDS