波卡创始人 Gavin Wood：波卡治理 v2 会有哪些变化？

2022 年 7 月 15 日
本文字数：8500 字
阅读完需：约 28 分钟

以下文章来源于 PolkaWorld ，作者 Gavin Wood

PolkaWorld.波卡（Polkadot）第一中文社区，带你寻找 Web 3.0 时代新机遇！

自 2020 年 7 月，波卡开启民主治理以来，波卡第一版链上治理体系已经顺利运行了近两年。在最近的一些会议上，Gavin 曾多次提到正在酝酿波卡的第二版治理体系，并透露新的治理体系会更加的去中心化，以及可能会不再有理事会（第一版治理体系中权力较大的组织）。

在近期的波卡 Polkadot Decoded 大会布宜诺斯艾利斯站上，波卡创始人 Gavin Wood 关于波卡治理 v2 发表了演讲，简要叙述了新版治理体系的内容，以及与原体系的差别。（下文由 PolkaWorld 翻译整理）

今天我想聊聊我在过去一年左右一直在做、并且希望很快能完成的东西。我会聊聊它是什么，以及我们为什么要做它。

今天的话题就是 —— 治理。治理是波卡的一个相当核心的元素，可以说我们在这方面一直是一线的领军者，并试图推动有趣的新模型和概念尝试。

治理的重要性

我们为什么要关注治理呢？

因为波卡和所有 Dotsama 生态的平行链都是可升级的，这是通过 WebAssembly 实现的，让这些链具有适应性，可以随着时间的推移而变化、进步。但为了对其变化的方向做出决定，我们需要有一套决策制定流程。

在普通的中心化组织中，一般是 CEO 或其代表来决定产品的走向。而在去中心化生态中我们做不到这一点，或者说不应该这样做，所以我们需要一个机制和流程，来就协议应该如何以及何时发展做出集体决定，这就是治理。

第一版治理体系

波卡目前的治理体系（v1 版本）是三院制的 —— 技术委员会，做的事情不多，有一些权力；理事会做的事情很多，有相当大的权力；Token 持有者拥有最终的权力，可以对一些事情进行投票。

还有一些有意思的设计，而且都实现了。

比如自适应投票人数偏见，即在不同的投票率下提案通过的条件也该有所不同，这也是在没那么多人投票的情况下，采取的一种可行的方案。

信念投票，它将我们从原有的 “币越多，就越有权力和影响力” 的模式，带到了 “如果你关心该网络的长期利益，就会有更多影响力” 的模式，本质上就是你可以将自己锁定在波卡或平行链中，从而获得影响力的加成。

代理，即作为比较被动的持有者，你可以将投票委托给别人，代表你做出决定。

第一版治理的缺点

那么这个系统的缺点在哪呢？

首先，它很慢。是出于安全起见，故意将它设计得很慢的，但我们不能否认它慢的事实。在正常流程下，从提案、通过投票、执行需要大约两个月。

而且也不够灵活。一次只能进行一项公投，也就是在 28 天的时间内，只能发生一件事。

还有就是比较难参与。如果你在波卡中提出一项投票提案，它可能永远都不会获得投票，就像很多公投都没能进入最后的投票阶段。

最后是比较丑陋的一点，即去中心化程度不够。这个体系是有中心化的元素的，比如理事会就是一个。没错，理事会成员是被投票选出的，所以某种意义上他们是可靠的。但无论如何，其实是那些被选上的人，在做出影响大家的决定，这是一个中心化风险。

解决方案

解决方案是什么呢？有两个方面。

首先是降低门槛，让治理变得简单、便宜。让提出议案、协议应该如何变化、网络该如何运行、人们如何投票变得简单和便宜。

我们尽最大可能去除中心化的元素，去掉了理事会和技术委员会，让无限的公投在同一时间内直接对所有东西投票。

听起来很简单对吧。但这有点像现代版的 “导弹指挥官” 游戏，导弹从天而降，你要用屏幕底部的枪发射子弹，在导弹摧毁城市前击落那些导弹。随着游戏难度越来越大，屏幕中下落的导弹会越来越多。

我们的新治理体系也是这个道理，如果你可以有无限数量的来自所有人的公投，那么就会有很多的恶意提案掉落，但是你只有有限的富有责任感的参与者，可以在恶意提案被执行和产生危害前把它们击落。

安全性

那我们怎样保证治理体系的安全呢？

一是限制同一时期内活跃决策的数量，让每个人需要考虑的决策不会太多。因为需要考虑的事情越多，分到每个决策身上的时间就越少，那么事情脱轨的概率就越高。那么限制决策数量就可以减少这种风险。

我们还可以限制这些公投的可能的影响，也就是限制这些天降的导弹如果真的坠地，会造成的破坏程度。

另外我们还可以在一项投票通过和产生影响前，要求很高的投票率或者通过标准。

最后我们可以增加这些决策被采用所需的时间。更多时间，意味着有更多人有足够的时间去考虑其造成的结果和影响，他们是否认为这是个好主意，他们有更多时间可以投票，不管是赞成还是反对。

我们可以增加投票开始前的时间；可以增加投票进行中的时间，比如当投票看起来快通过了时，增加一个 “你确定希望它通过吗” 的时间；甚至可以增加投票结束之后的时间，可以有机会撤销决策，并且如果有人强烈反对该提案对网络和协议造成的影响，他们此时可以退出或者自行采取一些中和措施。

安全性 vs 敏捷性

下面我聊聊安全性和敏捷性的取舍。

安全性和便捷性之间的取舍是老生常谈了。你有一个滑动条，可以选择非常安全但不敏捷，或者非常敏捷但是不太安全。

治理的第一版限制了活跃度，差不多一个月进行一次公投，并引入了信任，即中心化机构，因此它比较安全。

但是我们希望有更敏捷的版本，速度更快、更灵活，而且没那么中心化的版本。所以第二版治理允许我们使用更多的元素来让治理变得安全，以便获得最佳和最具影响的平衡。也就是说，对于不同类型的公投，可能会有不同类型的安全措施。

所以我们实际做要做的是，对吞吐量进行限制，根据某项公投理论上可能造成的损害拉长投票周期。如果我们可以把一项公投归类为低影响的，那么就不必采取非常保守的保障措施。即并非所有的公投、提案都是平等的。

按影响力分级

在第一版治理中，对所有公投和提案都是平等对待的。对于了解一些技术的人来说，波卡和基于 Substrate 的平行链都在这样一个框架内，代码执行的权限级别被称为 “来源（origin）”，不同的来源表示不同的权限级别，有点像 Unix 操作系统上的用户。

一项议案中其实有两个东西：一是操作，即你想做什么，比如 “从国库花费 100 DOT”、 “部署一条平行链”、“在此插槽中创建一条新的系统平行链并部署一些代码” 等等你希望用治理来做到的事。第二是来源，也就是该操作将运行的权限级别，即谁/什么授权该操作发生。

大部分操作都需要特定的来源，但不是所有的操作都如此，部分操作可以使用很多不同来源。一个例子是转账操作，这个操作很常用，如果你想把一些 DOT/KSM 或其他币从你的账户转账到其他账户，这就叫转账操作，你将它包装到一笔交易中，并发送到网络。网络做的就是检查，它会看是谁授权了这笔转账，它检查的来源是已签名的来源，意味着你签名了这笔交易，证明了确实是你本人想授权这笔转账，确保该来源已被签署。

来源和轨道

在第二版治理中我们的做法是，有很多的不同类型的来源，授权了不同的事情，一些事情是影响大的，一些是影响小的，我们给每种来源类型都准备了不同的轨道。每个轨道都可以有不同的参数，不同的（通过）阈值。我们可以保证，对于影响小的事的轨道，这些参数和阈值可以不那么严格；对于本质上更危险的事的轨道，就需要更保守的参数和更高的阈值。

我们来想象一些来源。

比如 Root，它是波卡、Kusama、Substrate 链中的全能起源，这是旧治理体系中执行的所有内容，只有一个级别，就是超级用户级别的 Root，可以做任何事。

我们还有其他来源，比如 ParachainAdmin，可以用来创建新平行链，如果你想创建一条新的系统平行链，你不需要能够做任何事，只需要能做这件事就行，而 ParachainAdmin 就能做到这件事。

BigSpender 来源，可以从国库花掉一大笔钱；Tipper 是超小额花费，只能从国库花掉一点点钱。

我们很容易看出，这些事的影响是不同的，能做任何事的影响高于能从国库花掉 10 DOT 的影响。

在这些公投轨道中，我们可以自定义一些东西。

比如导入期，即在投票真正变得重要之前需要经历多长时间。确认期，即当一项公投马上要通过时，它需要保持这个状态多久，才能真正被批准并且进入公投。投票率和批准要求，这是一个投票系统中最重要的部分，有多少人愿意去投票，其中又有多少人希望该议案通过。同时可以进行多少项公投，一些影响小的事情，可以一下投很多项，没关系；如果是影响重大的事情，那么可能要限制到每次几项甚至一项。

公投的生命周期

下面看看第二版治理中的公投的生命周期，包括几个阶段。

提案

第一阶段是提案。我给这个图标加了个牛仔帽，因为这是最 “牛仔” 的一个阶段。

其他阶段都是决定、思考，但这一阶段就是 —— 没关系，让我们搞出一大堆议案，也不限制每个账户的提案数量，不限制提案的总数，任何人都可以随时提出公投。只要你提案了一项公投，这条链上的每个人都可以对其投票。所以参与的门槛超级低，押金是为了防止链出问题所规定的最低金额。

决定

下一阶段就要认真起来了，当我们有了所有这些公投议案之后，我们必须决定某项公投是否应该通过。这些公投都处于待定状态，大家可以对它进行投票，但是我们暂时不会采取任何行动。在采取行动之前，需要有三件事情发生。

第一件事，需要支付一笔 “附议” 押金。不一定是最初提案的人来交押金，也可以是一帮其他人来交。这笔额外的押金也是为了防止某些数据结构被垃圾信息攻击。

第二件事，是让导入期完成。根据轨道的不同，选民的集合/代币持有者/决策者会收到一些通知，让他们知道这项公投正在进行中。

最后一件事，就是轨道的容量。容量是该轨道可以同时发生的公投的最大数量。轨道是完全独立的。有的轨道，例如 Tipper（打赏）轨道可能会有很高的容量，可能有成千上万个的容量。就算其中的一部分在没人注意的情况下就通过了，也没什么关系。而如果是一项升级议案，或是 Root 级别的议案就很重要了，这时我们就得确保每个这类提案都经过深思熟虑，因此容量会很低。

确认

这三件事都满足后进入下一阶段 —— “确认” 阶段，这是一个故障保险。如果一项恶意公投出于某种原因快要通过了，可能是大家都在休假，或者大家都在忙着听一个演讲，这时有人趁大家不注意搞出了一个很狡猾的议案，然后自己疯狂投票，让这个议案马上要通过了。但他们不会得逞，因为我们进入了这个确认的新阶段，大家可以在一项公投完成前投票否决它。也就是说，一项公投在快通过的时候，需要保持该状态一段时间，这段时间就叫确认期。有的轨道确认期很长，有的则短得多。

如果是 Root 轨道等权力很大的轨道，确认期有两天左右。即在快要通过的状态需要保持两天，如果出于什么原因它中断了，比如有人投了反对票或者有人改票了，那么它就得打回去，再次进入快要通过的状态，再经历两天的确认期。那些有争议的公投，可能会进入这种确认状态的循环。要想结束一项公投必须经历完整的确认期。

那么 “快要通过（Passing）” 是什么意思呢？有两个元素，在公投进行过程中我们会不断衡量这两个元素。

第一是衡量 “支持（Support）”，有点像投票率，是博弈论上更合理的投票率。衡量投票率（投票人数/总票数）的问题是，如果你想反对某件事，你得决定是否去投票。因为如果你投了反对票，你同时也拉高了投票率，反而让该公投显得更有正当了。如果已经有很多人希望它通过，你投 “反对” 票的做法其实在推动它通过。这是个很大的问题。

那么为了计算反对票，我们不去数反对票数，而是只去数支持票数，去算支持票数占总票数的比例。计算的时候忽略信念乘数，因为我们想计算真实的票数。

第二是衡量 “赞同（Approval）”，即赞成票数 / 总票数，但是是算上了信念乘数的，也就是你可以将自己的 Token 锁定在网络中从而加强投票权重，这样我们就能衡量长期利益绑定的投票者的意见。

有趣的是，一项公投通过的门槛要求会随着时间推移而变化。在最初，通过的门槛很高。在最后，门槛在不影响我们的民主关系的前提下尽可能低。

为什么呢？原因很简单。这让我们可以在公投过程中非常灵活。如果某个议案没有什么争议，支持的人很多，网络中的每个人都认为它很棒，那我们应该让它快点通过。如果某个议案有争议，要么是投票率高但赞成率低，要么是赞成率高但投票率低，这时就需要给出更多时间，让网络可以形成一个更加深思熟虑的观点。

下面是 “支持” 的示例曲线。支持就是赞成票数占总票数的比例，我们可能期望看到的曲线是这样的，最初从 50% 开始，有 28 天的硬性限制，在 28 天后下降至最低水平，大概是 10%。不同的轨道有不同的参数，和不同的曲线，有的可能会下降得很快，有的可能会在很长一段时间内保持高位。

下面是 “赞成” 的示例曲线。最初从 100% 开始，意味着所有人都赞成，这个非常难达到。但随着时间流逝会逐渐下降，直到 50% 左右。也就是说，必须有大多数人赞成。不过如果只赞成人数只是微微高于一半的话，就需要 28 天才能让网络接受它（前提是没有更多的投票将其拉低），因为我们希望保证安全。

临近结束

临近结束（Ending）阶段。如果 28 几天过去了，议案没有通过，那么默认情况下它会自动被拒绝。它唯一能被接受的方式是，它在这 28 天的确认期内的某个时间点通过了。就只有这两种结果，要么议案通过从而提前结束，要么走完 28 天然后失败。

如果议案通过了，并且计划执行，在通过和真正执行之间还有一个阶段，叫做执行期。这个概念来自第一版治理系统，已经存在了。每个轨道都有一个最短期限的限制（没有最长的限制，如果你希望它在 10 年后执行也是可以的），在它正式执行前你不能提出什么东西。这也是一个安全措施。

干预

下面来聊一下干预。

虽然人们可能会出于网络的最大利益行事，但有时并非所有信息都可用，最终大家会有一个协调的时间。

假设你离议案通过还剩半天时间，差不多是确认期的临近结束时，但这时发现了一个 bug。这时如果时间足够的话，每个之前投了赞成票的人都会投反对票，但是时间可能不够了。这时怎么办呢？我们允许做干预。

干预其实就是一个特殊的来源 —— ProposalCancellation（议案取消）或 ProposalDelay（议案延迟），比其他的来源启动速度更快，耗时会更短。它所做的要么是取消，要么是推迟到另一次公投。这让网络可以恢复，并且可以安全地自我纠正。

敏捷委托

我们在第二版治理中还有什么呢？—— 敏捷委托（代理）。

我对这个功能非常满意，我认为所有的民主体都应该有这个功能，但我们可能是第一个真正实现了这一点的。

我们对委托的概念很熟悉了，大概就是你可以选择某人，把你的投票权交到他们手上，因为你觉得他们的利益和你的一致，或者你认同他们过往的投票记录，并且你期望他们代表你对你有好处。

不巧的是，不同的人给不同事情投票时表现不同。在民主制度中，在某件事的投票上，你可能和政客张三的意见相同，但在另一件事上，你可能完全不同意他的投票，相反你更同意政客李四的观点。这有点像，我希望在环境问题上把我的投票权给到这个派别，在民权问题上把投票权给到那个派别。但是在传统的投票系统中没办法做到这一点，就算是在敏捷的流动民主风格的委托系统中也无法做到。

现在在波卡和任何使用第二版治理体系的系统中就能做到这一点。对于不同来源的事情，你可以拥有不同的代表。比如对于打赏，你可以委托给某个人或组织；对于网络升级，你可以委托给另一个人；对于国库花费，你可以委托给另一个人；对于公共利益平行链的部署，你又可以委托给不同的人。你可以委托的不同来源数没有上限。你可能会说，我才没那么关心呢，我直接委托给一个人，这当然也是可以的。

被动委托

下面讲被动委托。

这是我们将要引入的一项功能，但是不会在最初的治理中就上线，而是之后再升级，还有另一件事也与之相关。它大概的意思是，你作为 Token 持有人，不必发送交易来将投票权委托给其他人，你可以免费做到这一点。

你的钱包可以帮你做到这一点，你自己不用采取太多行动。一个负责的钱包应该与你核对，你想委托给谁，我希望生态中的所有钱包都能做到这点。

这项功能是说 “我允许这个账户使用我账户的投票权”，而且你可以在不支付任何交易费的情况下做到这一点。这有点像是集体调用，如果他们愿意接受你的投票委托的话，他们来付交易费。

免费解除委托

除此之外，还有免费解除委托。

当这和上一个功能结合，就意味着，当钱包构建这些功能时，可以有一个非常低摩擦的界面，不需要用户花费任何资金，而且可能在后台发生。这让钱包可以说 “你想要和哪个个人/生态实体/组织的投票保持一致”，而用户不需要关心委托和解除委托的成本，钱包可以直接在后端进行所有的这些底层交易，不用改变整体用户体验。

参与治理的激励

我们可能还会引入针对参与治理的激励措施。现在只是有这个想法，但还没定下来。这是个两方面都需要认真考虑的问题。

及时转变

我们先来看看正常情况下的治理，它是相当轻松的 —— 几天过去了，你来看了一眼，觉得看起来挺不错的，就投一票，表示赞成或反对。那紧急情况下会发生什么呢？之前 Kusama 网络也发生过一两次。万一时间非常紧张，需要快速通过某项议案呢？

常规的方案是，如果我们想要加快速度，那么我们得在其他方面让它更安全。所以我们必须确保来源是影响很低的，让议案在这方面是安全的，或者我们要知道它的时间很紧迫。

我们要如何确定该议案是安全的呢？就像我说的，其来源要影响低。但有时候要在紧急情况下修复某样东西，你需要能够做任何事的权限，你需要进行代码升级，需要对状态做一些更改等。

从链外上传专家信息

那么在时间紧迫的情况下我们如何确保一个议案的是安全的呢？显而易见的做法是，我们直接把信息从链外上传过去（oraclize），比如我们有一些专家，去告诉网络这是安全的，你可以在一个更快的轨道中运行。

将专家信息 oraclize 过去，有三个步骤需要做。第一要跟踪每个人的专业水平，第二要让每个人都记录其选择，第三进行汇总。

第二和第三步都超级简单，区块链太擅长做这些了。但是第一步就不太简单了，相当的困难。那怎么办呢？我们引入另一个机构，用一个符合博弈论的解决方案来解决，该机构的名字是波卡协会（Polkadot Fellowship）。在这里我不会展开讲，它值得另起一个演讲来聊聊，接下来几周我们会单独聊。

Polkadot Fellowship

简而言之，它是一个链上的会员组织。它鉴别大家的专业水平，并且补偿所有拥有波卡协议专业知识且行为符合广泛利益和理念的人。也就是说它是一个评价组织，有点像武术协会，当你达到顶峰时，就会有清晰的结构和评价标准，去评价你的艺术性和专业水平。

大多数等级的审核都是同行评审，但是当你达到最高水平，并且影响力增大时，就需要通过公投审核了。这是为了避免小团体的出现。

进入该组织有一个最小的财务门槛。每个人都可以报名成为候选人，每个等级的专业水平和必须达到的目标，都有开放和明确的要求。该组织技术上应该能容纳大量的成员，我们的目标是在未来一两年内容纳数万人。这可能有点野心太大了，但是肯定得要有数百人吧，希望过一段时间后能达到数千人。

这个模块其实挺酷的。对于那些熟悉 Substrate 和基于它编程的人来说，这个逻辑和实现，这些公投、治理的东西，比如轨道、授权、多角色、来源等，这些不仅适用于 Token 持有者的信念投票，还适用于这个 fellowship。所以实际上有两种不同的公投实例，其中一种是针对 Token 持有者的，另一种是针对 fellowship 成员的。

我们的想法是仅有一个 fellowship，它涵盖了所有的波卡协议，Kusama 用的也是波卡协议。所以 Kusama 会桥接过来，fellowship 会充当这两个网络的 fellowship。

Fellowship 的权力并不大。我想强调一下，fellowship 不能直接影响波卡网络或任何网络，它没有任何权力去改变协议。它能做的唯一的事，是声明它相信一个特定的议案是安全且时间紧迫的，它只是一个预言机而已。

白名单模块

现在我们把它放到白名单上。白名单其实就是有一个叫 Whitelist 的 pallet（Substrate 模块）。它里面有这个白名单，有一个特殊的治理来源叫做 WhitelistedRoot，它有着自己的轨道，比 Root 轨道更敏捷。

Root 轨道非常非常不敏捷，因为它很危险。但是 WhitelistedRoot 轨道危险性小一些，因为虽然该轨道上的项目也可以执行 Root 级别的权限，但必须要先被列入白名单，而这就让它本质上不那么危险。因此我们就可以拥有一个由公投运行的，参数不那么保守的轨道。

如果一项议案由于某种原因被列入 WhitelistedRoot，但它又不在白名单里，那它什么也做不了，只是消失了。

其他变化

这版治理还有其他一些变化。

没有理事会（Council）了。国库也运行不了了，因为之前都是理事会在决定国库支出。打赏机制也运行不了了，因为打赏也是由理事会成员决定的。

其实国库支出和打赏的运作方式还是相同的，都是从国库资金中花钱。现在它们和其他东西的运行方式相同，那就是经过公投。好消息是现在的公投很灵活，可以快速决策。

时间表

第二版治理的上线，至少是新版治理议案的提出已经近在眼前了。相关的 Pull Request 已经有了，而且已经有一段时间了，马上要开始审计了。当然 Kusama 的审计不会太久，毕竟它是未经测试的早期实验性网络。一旦这个 PR 合并，就会在 Kusama 网络上出现一个 runtime 升级议案，很快就要发生了。