详解波卡新版治理Gov2：实现去中心化治理需要做什么？

原文标题：《Governance V2》

撰文：Polkadot

编译：PolkaWorld

文本是波卡官方文档 Polkadot Wiki 中的「治理 V2」部分，描述了波卡的新版治理体系，以及其和原治理体系（治理 V1）的对比。

Polkadot 采用一种复杂精巧的治理机制，使其能够根据利益相关者集合的最终要求优雅地进化。其目标是确保大多数权益始终可以控制网络。

本文档中的内容会有更改。该治理协议已经经历了几次迭代（v1 和 v2），并且有更多变化正在计划中（v2.5）。

Polkadot 的第一个去中心化治理系统 (v1) 由三个主要组件组成。

技术委员会：管理升级时间表的技术委员会。
理事会：一个经过投票批准、选举产生的执行「政府」，负责管理参数、admin 和支出提案。
公投：对其他所有事物的普遍投票系统，该系统赋予长期利益相关者更大的影响力。该系统在运行的头几年运行良好，有助于确保适当使用国库资金并能够及时升级和修复。与大多数早期技术一样，系统和协议必须随着自身的成熟而不断进化，以改进其缺点并跟上现有的进步。例如，在「治理 v1」中，所有公投都具有相同的权重，因为一次只能对一个公投进行投票，并且投票期可以持续数周。这导致系统倾向于仔细考虑极少数提案，而不是广泛考虑许多提案。于是「治理 v2」应运而生了！

「治理 v2」或者叫「Gov2」改变了日常决策的实际方法，使公投的影响范围更广、更敏捷，从而显着增加系统能够做出的集体决策的数量。

在对其代码进行最终专业审核后，Gov2 将在 Kusama 上启动。在 Kusama 上进行测试后，会提出将其部署在 Polkadot 上的提案。（PolkaWorld：Gov2 目前已经上线至 Kusama 网络，详见：又一里程碑！下一代去中心化治理系统 OpenGov 上线 Kusama 网络！）

以下内容将首先介绍 Polkadot 网络上的许多核心治理原则。了解治理 v1 的根源，对于更好地理解第二次迭代的方向很重要。这些差异和区别将在各个子主题中突出显示。

话虽这么说，但重要的是要记住，在其生命周期的这个阶段，治理是不断发展的协议。随着治理 v2 的更新进入网络，治理 v2.5 的计划也已经在制定中。

前提

概括来讲，该网络汇集了各种新颖的机制，包括存储在链上并以平台中立的中间语言（即 WebAssembly）定义的无定形状态转换函数，以及多种链上投票机制，例如具有自适应绝对多数阈值和批量批准投票机制的公投。

对协议的所有更改，都必须通过权益加权的公投来达成一致。

机制

在治理 v1 中，活跃的 token 持有者和理事会共同管理网络升级决策。无论该提案是由公众（token 持有者）提出还是由理事会提出，最终都必须经过所有持有者的全民公投，以质押额（stake）和信念值（conviction）为权重做出决定。

为更好地了解理事会的组成方式，请阅读本章内容。[1]

治理 v2 有几个变化。新治理模式反映其去中心化特征的方式是：

通过民主投票将理事会的所有责任转移给 token 持有者
解散现任理事会集体
允许用户以更多方式将投票权委托给社区成员 Gov1 中的理事会履行了其作为被动 token 持有者的代表、国库守护者和立法发起者的角色，但通常被视为一个中心化实体。为了进一步去中心化 Polkadot 和 Kusama 网络，Gov2 提议将理事会的职责交还给社区。

公投

公投是简单、包容性、基于质押的投票方案。每个公投都有一个与之相关的特定提案，该提案采用 runtime 特权函数调用的形式（其中包括最强大的调用：set_code，它可以切换 runtime 的整个代码，实现本来需要需要「硬分叉」才能实现的功能）。

公投是具有固定投票期的离散事件。当投票期结束并统计选票时，如果投票获得批准，将调用函数 (set_code )。公投总是二元的；你在投票中的选择只能是「赞成」、「反对」或完全弃权。

在治理 v1 中，公投可以通过以下几种方式之一启动：

公开提交的提案；
理事会以多数票或全票通过的提案；
作为先前公投执行的一部分提交的提案；
由技术委员会提交并通过理事会批准的紧急提案。所有公投都有相应的执行延迟期。这是从公投结束到提案实际执行（假设提案通过的话）之间的一段时间。

如果一项公投关闭和完成了统计，则该公投被视为已完成。同样，假设该提案获得批准，它将被安排执行。如果公投正在等待结果，即正在被投票，则该公投被认为是未完成的。

如果提案是由公众或理事会提交的，则有 28 天的固定执行延迟期。作为先前公投执行的一部分提交的提案可以根据需要设置执行延迟期。紧急提案处理需要「快速跟进」的网络重大问题，从而缩短了执行时间。

在 Gov2 中，任何人都可以随时开始公投，而且想发起多少次公投都可以。Gov2 引入了几个新功能，叫做 Origins（来源）和 Tracks（轨道），以帮助公投协议的流程和处理。

Origin 可以被认为是给定特权级别的丰富描述符。公投的提议者现在需要根据提案的要求，为他们的请求选择一个合适的 Origin。

每个 Origin 都与一个公投类别相关联，每个类别都与一个 Track 相关联。Track 概述了提案的生命周期，并且独立于其他类别的 Track。拥有不同的独立轨道，允许网络根据其隐含的特权级别来调整公投的动态。

例如，Runtime 升级（set_code 调用）对生态系统的影响，与国库小费的批准（reportAwesome 调用）不同，因此需要不同的 Origins，其中不同的投票率、批准率、押金和最短执行周期将在 pallet 上预先确定。

提案公投

公众公投

任何人都可以通过在一定时期（区块数）内存入最低数量的 token 来提议一项公投。如果有人同意该提议，他们可以存入相同数量的代币以表示支持。

此操作称为「背书」。获得最高绑定 token 支持的提案将被选为下一个投票周期的公投。请注意，这可能与背书的绝对数量不同；例如，三个账户每个绑定 20 DOT 将「超过」十个账户每个绑定 1 DOT 的效力。

一旦提案被提交（即进行投票），绑定的 token 将被释放。

对于治理 v1，提案队列中最多可以有 100 个公共提案。

在 Gov2 中，当一项公投被创建出来时，社区就可以立即对其进行投票。但是，该公投并没有处于可以结束，或以其他方式计算其选票、获得批准和最终执行的状态。相反，公投必须满足一些标准，然后才能进入称为「决定（Deciding）」的状态。在它们处于这种状态之前，仍然是待定状态。

进入 Decided 状态的标准如下：

经历了导入期（lead-in period），即在决定可以开始之前必须经过的时间量。这有助于减少「决定狙击」的可能性，在这种情况下，控制大量投票权的攻击者可能会在提议后立即通过提案，而不是让全体投票者有足够的时间来考虑和参与。
必须还有决定的剩余空间。所有 Track 都对可以同时决定的公投数量进行了限制。具有更强大能力的轨道将具有更低的限制。例如，Root 级别 Origin 的限制为 1，这意味着一次只能决定 1 个超级危险的提案。
必须支付决定押金。创建公投的成本很低，因为押金价值仅包含跟踪它所需的链上存储所需的价值。但是，对公投进行审查和决定，却存在着耗尽公投队列中有限位置的风险。要求提供一笔金额更大但可退还的押金，有助于减少垃圾信息。

理事会公投 (v1)

理事会全票通过 - 当理事会的所有成员都同意一项提案时，可以将其移至公投。该公投将产生负投票率偏差（即权益投票的数量越少，通过所需的数量就越少 —— 参见自适应群体偏见 Adaptive Quorum Biasing[2]）。

理事会多数通过 - 当只有简单多数理事会成员同意时，也可以对公投进行投票，但它将是多数票制（获得 51% 票的那方获胜）。

在任何给定时间只能有一个有效公投，除非还有正在进行的紧急公投。

投票时间表

在 Governance v1 中，假设其中一个队列中至少有一个提案，每 28 天就会进行一次新的公投。理事会批准的提案有一个队列，公众提交的提案也有一个队列。将在两个队列中排名靠前的提案之间轮流进行公投。

排名最靠前的提案由其背后绑定的质押数量确定。如果当前队列选择尝试创建没有提案的公投（队列为空），并且另一个队列有排队中的提案，则另一个队列中的最靠前提案将进入公投。

不能在同一时期对多项公投进行表决，紧急公投除外。与常规公投（公开或理事会提议）同时发生的紧急公投是唯一一种能同时对多项公投进行投票的情况。

当提案获得批准时，治理 v2 共享相同的 28 天资格期。如果在此阶段结束时仍未获得批准，则该提案将自动被拒绝。

公投投票（治理 v2）

在 Governance v2 中，如果提案满足批准率和支持率的要求，则该提案将获得批准，即删除了自适应群体偏见系统。

批准率（Approval）被定义为批准投票权重（在 conviction 调整后）占总投票权重（包含批准和拒绝）的份额。

支持率（Support）是批准的总票数（忽略 conviction 调整）与系统中可能进行的总票数的比较。

它必须在确认期的最短时间内满足此标准。不同的轨道有不同的确认期和批准和支持要求。现在可以配置通过所需的支持量和总体批准。对于使用较低特权来源的提案，与使用高特权类别（例如 Root）的提案相比，更早地将所需的投票率降低到更现实的数量更为合理。具有较大政治意义的课程可以尽早要求更高的批准，以避免争议。

在 Gov2 中，28 天后未获批准的提案将被视为默认拒绝，并退还 Decision Deposit。如果提案设法在确认期结束之前保持通过，则视为已获批准，并计划在制定期之后从提议的来源开始执行。制定期在全民投票提议时指定，但也受制于基于轨道的最小值。更强大的 Tracks 会强制执行更长的执行期，以确保网络有足够的时间为提案可能带来的任何变化做准备。

自愿锁定

Polkadot 使用一种称为「自愿锁定」的概念，它允许 token 持有者通过声明他们愿意锁定 token 多长时间来增加他们的投票权，因此，每个 token 持有者的投票数将使用以下公式计算：

投票数 = token * conviction 乘数

锁定期数每番一倍，conviction 乘数都会将投票乘数增加一。

锁定期数投票乘数 00.111224384165326

锁定期「加倍」的最大次数设置为 6（因此总共 32 个锁定期），一个锁定期等于 28 天。只允许加倍，例如，你不能锁定 24 个周期并使你的 conviction 增加 5.5。有关治理事件时间表的更多信息，请查看 Polkadot 参数页面[3]上的治理部分。

token 被锁定后，你仍然可以使用它进行投票和质押；你只被禁止将这些 token 转移到另一个帐户。

选票总是在同一时间「计算」，即在投票期结束时。这不受代币锁定期的影响。

自适应群体偏见

自适应群体偏差在 Governance v2 中使用的时间更长，并被 Approval/Support 系统所取代。

理事会

在治理 v1 中，波卡上的被动利益相关者由称为「理事会」的管理机构代表。理事会是一个链上实体，由多个参与者组成，每个参与者代表一个链上账户。在 Polkadot 上，理事会目前由成员组成。

除了控制国库外，理事会还主要负责三项治理任务：

提案明智的公投
取消危险或恶意的公投
选举技术委员会

在治理 v2 中，需要一种替代策略来取代理事会以前作为选民委托机构的职责，以弥补许多人选择不参与日常治理的事实。Gov2 建立在 v1 的投票委托功能之上，选民可以选择将他们的投票权委托给系统中的另一个选民。它通过改进称为多角色委派的功能来做到这一点，选民可以在该功能中为系统中的每一类公投指定不同的代表。因此，例如，选民可以委托某个实体来管理某个影响不重大的公投类别，而选择另一个不同的代表来管理另一个具有更重大后果的不同类别，并且仍然保留对任何剩余类别的完全投票权。

取消公投

在治理 v1 中，如果技术委员会一致同意取消提案，或者如果 Root 来源（例如 sudo）触发此功能，则可以取消提案。已取消提案的押金将被销毁。

此外，理事会三分之二多数可以取消公投。如果在公投提案中发现问题较晚（例如该提案将执行的 runtime 代码中存在错误），这可能会作为最后的手段。

如果取消的争议足够大，以至于理事会无法获得三分之二多数，那么将由利益相关者共同决定提案的命运。

在治理 v2 中，有一个名为 Cancelation（撤销）的特殊操作，用于干预已经投票的提案。该操作将立即拒绝正在进行的公投，无论其状态如何。还有一项规定，如果提案是恶意的或垃圾信息，则确保提议者的押金被罚没。

Cancelation 本身是一种治理操作，必须由网络投票才能执行。撤销伴随着它自己的 Origin 和 Track，它具有一个很短的导入期和批准率 / 支持率曲线，它们的通过门槛下降得稍微迅速一些，因为它是在情况紧迫时才调用的。

技术委员会

在治理 v1 中，技术委员会 ( 以下简称 TC) 作为 Kusama 治理的三院之一（另外两院是理事会和公投）在《Kusama 的上线和治理》https://polkadot.network/blog/kusama-rollout-and-governance/ 中引入。TC 由成功实施或定义 Polkadot runtime 或 Polkadot Host 的团队组成。通过理事会的简单多数投票，可以在 TC 中添加或删除团队。

TC 的目的是防止恶意公投、实施 bug 修复、逆转错误的 runtime 更新或添加新的但经过实战检验的功能。TC 有权使用 Democracy pallet 加速提案，并且是唯一能够触发提案加速功能的来源。我们可以将 TC 视为无法生成提案但能加速现有提案的「唯一来源」。

快速公投是唯一一种可以与另一场公投同时进行的公投。因此，通过快速公投，可以同时进行两个活跃的公投。对其中一个投票不会阻止用户对另一个投票。

在治理 v2 中，引入了一个新的继任委员会，称为「Polkadot Fellowship」，以取代技术委员会。它将服务于 Polkadot 和 Kusama 网络。请参阅下面的其他详细信息。

Polkadot Fellowship

该 Fellowship 是一个基本自治的专家机构，其主要目标是代表具有 Polkadot 网络和协议的技术知识库的人类。Fellowship 通过「等级」将成员进行分类，来代表其观点的明智程度、技术基础的良好程度，以及符合 Polkadot 利益的程度。

与当前的 Technical Collective 不同，它旨在扩大成员范围（即可以容纳数以万计的成员）并且进入门槛低得多（在管理流程和专业知识期望方面）。成为 Fellowship 的候选成员很简单，只需存入一笔小额押金。

Fellowship 成员可以对任何给定的 Fellowship 提案进行投票，并且成员的综合意见（按等级加权）构成 Fellowship 的考虑意见。

Fellowship 投票的机制与 Polkadot 利益相关者对已提案公投的投票机制相同。

等级系统

那么这个等级系统究竟是如何运作的呢？

为了防止一小部分参与者获得对网络的有效控制，该系统将坚持三个主要原则：

Fellowship 绝不能对网络拥有硬权力：它不能更改参数、进行修复或移动资产。他们在治理方面的唯一权力在于能够缩短公投发生的时间表。
Fellowship 在总体意见中对等级较高的人给予更多的权重，但是与来自较低级别成员的一致意见相比，权重不应高到使少数较高成员的意见无法超越。
Fellowship 应旨在增长和发展其成员及其专业知识的总体水平，并在此过程中确保其整体决策能力随着时间的推移而变得更强大。为了支持这些条件，Fellowship 将制定章程，其中概述了个人获得和保持某等级的要求和期望。较高等级的人员可以根据本章程投票和提拔较低级别的人员。

在给定的时间段过去，并且某成员无法向其他成员证明自己的地位时，降级会自动发生。

停职只能通过公投才能发生，这确保了 Fellowship 的偏见本身不一定会导致开除。

为了防止 Fellowship 成为一个阴谋集团（仅靠 Fellowship 的声望不足以获得最高等级），获得最高等级将需要进行公投。

如果想申请加入 Fellowship 或详细了解其运作，请阅读《波卡 Fellowship 详细文档》。

白名单

Whitelist pallet 做一件事：它允许一个 Origin 为某个操作提升另一个 Origin 的特权级别。

在 Gov2 中，它允许 Fellowship 授权一个新的来源（称为 Whitelisted-Root）以 Root 级别的权限执行，并且只会与 Fellowship 授权的某些特定命令一起使用。Whitelist pallet 验证两件事：