OpenGov：迈向完全去中心化的治理（下篇）

Bifrost Finance

我们在上篇中讲到了 OpenGov 取消了 Gov 1.0 中的理事会和技术委员会，将公投作为唯一的决策权力主体。所有的公投提案被划分在不同的轨道，这些轨道拥有不同的参数，用来处理不同“危险度”的提案。此外，OpenGov 中的公投提案流程更加细化，一个提案将经历准备期、决策期、确认期、执行期四个阶段。

除了上述改进之外，OpenGov 的创新还包括对危险提案的干预流程、更灵活的委托机制和 Fellowship。

危险提案的干预

为了保证治理过程是安全的，防止恶意提案被通过。OpenGov 除了设置准备期之外，还设置了对危险提案的干预流程。

我们看到 Polkadot 治理轨道中，有两个特殊的轨道，分别是 Referendum Canceller 和 Referendum Killer。这两个轨道需要质押较多的 DOT，且轨道容量几乎不设限。这两个轨道是用于取消其他提案的，不同之处是 Referendum Canceller 仅仅取消提案，而 Referendum Killer 会在取消提案的同时罚没提案发起者的押金。可以说， Referendum Killer 是对恶意提案者的一个有效威慑。

一旦有提案进入 Referendum Canceller 和 Referendum Killer 的流程，该提案无论出于何种状态（即便在执行期），都将立即暂停其流程。

分轨道委托

OpenGov 继承了 Gov 1.0 的信念投票机制。在该机制下投票效用不止与投票的治理通证数量有关，还与治理通证的质押时长有关。质押时长越长，代表“信念”越强，能获得的投票效用加成会越高。

在治理实践中，往往很多治理 Token 持有者没有足够的时间来参与治理决策，而且很多治理 Token 持有者没有足够的能力和背景信息做出明智的决策，因此委托机制是必要的。Gov 1.0 允许用户将他们的治理 Token 委托给其他人代为行使治理权力，当然，用户也可以随时撤回委托或者更改委托对象。OpenGov 则进一步细化了该规则，用户可以针对不同的轨道将同一份投票权委托给不同的人。

这样做的好处是可以让不同议题的专家，能够充分发挥其专业性。例如我可以将财库类决策的投票权委托给一个运营专家，而将技术类决策的投票权委托给另一个技术专家。

Fellowship

Fellowship 是一个自治的专家团体，可以理解为是一个更加去中心化的技术委员会。尽管 Fellowship 的初始成员将来自技术委员会，但与技术委员会不同的是，Fellowship 旨在囊括更广泛的、数以万计的成员。波卡将通过一定的激励机制，鼓励他们对波卡生态的发展和优化持续做出贡献。此外，Fellowship 并不是一个严格意义上的治理主体，也不直接拥有治理权力上的任何特权。

只有一个特殊的轨道，也就是 Whitelist Caller 会和 Fellowship 有所关联。Whitelist Caller 的定位类似于 Gov 1.0 中的 Fast Track，用于执行一些紧急的漏洞修复。该轨道的准备期和确定期都比较短，投票通过的两个阈值衰减较快，阈值曲线较为陡峭。只是，处于该轨道的提案被通过，进入执行期之后，需要 Fellowship 进行二次投票确认才能正式执行。

Fellowship 有自己的治理界面，该界面可以用来针对 Fellowship 成员的招募、清退、等级变更等事务进行治理。新成员的加入需要由以为现有成员推荐，并经过内部投票确认。Fellowship 的成员有各自的等级，等级由成员对波卡生态的贡献决定，等级将决定内部投票时的权重。具体细则可参考官方发布的文档：

https://github.com/polkadot-fellows/manifesto/blob/5e01eef15eded63f1db9be808b0f7c11bb9f4a12/manifesto.pdf

公投中的 Fellowship admin 轨道也可以对 Fellowship 的事务进行管理，其权限高于 Fellowship 内部的自治决策。

小结

总之，从 Gov 1.0 迭代到 OpenGov ，波卡的治理过程在兼顾安全的前提下，提升了治理效率和治理灵活度，同时实现了高水平的去中心化。总体来看：

在权利分布方面，OpenGov 中，治理通证的持有者完全掌握了治理权力，不再有其他的治理权力主体。

在决策效率方面，OpenGov 通过开设多个轨道，以满足不同类型提案的不同流程设置和容量设置，这些轨道可以同时进行，决策效率大幅提升。

在治理安全方面，Gov 1.0 更多依赖理事会作为唯一的防火墙，OpenGov 则依赖机制上的巧妙设计。