Governance V2

波卡采用了一套精巧的治理机制,使其能够根据利益相关者的需求不断演进。其目标是确保大多数权益始终能够控制网络。

本文内容可能会有变更。治理协议已经经历了几次迭代(v1和v2),未来还会有更多变化(v2.5)。

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

• 技术委员会:管理升级时间表
• 理事会:经选举产生的执行"政府",负责管理参数、管理和支出提案
• 公投:普遍投票系统,赋予长期利益相关者更大影响力

该系统在最初几年运行良好,但随着成熟需要不断演进以改进缺点和跟上进步。例如,在"治理v1"中,所有公投权重相同,一次只能对一个公投投票,投票期可持续数周。这导致系统倾向于仔细考虑极少数提案,而不是广泛考虑多个提案。因此"治理v2"应运而生。

"治理v2"或称"Gov2"改变了日常决策方法,使公投影响范围更广、更敏捷,从而显著增加系统能做出的集体决策数量。

Gov2将在Kusama上启动并测试后,再提议部署到Polkadot上。目前Gov2已经上线至Kusama网络。

以下内容将介绍Polkadot网络的核心治理原则。了解治理v1的根源,有助于更好地理解第二次迭代的方向。这些差异将在各个子主题中突出显示。

需要注意的是,在当前阶段,治理仍是不断发展的协议。随着治理v2的更新,治理v2.5的计划也已在制定中。

前提

概括来说,该网络汇集了多种新颖机制,包括存储在链上的无定形状态转换函数(以WebAssembly定义),以及多种链上投票机制,如具有自适应绝对多数阈值的公投和批量批准投票。

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

机制

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

治理v2有几个变化。新治理模式体现去中心化特征的方式是:

• 通过民主投票将理事会的责任转移给token持有者
• 解散现任理事会
• 允许用户以更多方式将投票权委托给社区成员

公投

公投是简单、包容性、基于质押的投票方案。每个公投都有一个相关提案,采用runtime特权函数调用形式(包括最强大的set_code调用,可切换整个runtime代码)。

公投是具有固定投票期的离散事件。投票期结束并统计选票后,如果获得批准,将调用相关函数。公投总是二元的;投票选择只能是"赞成"、"反对"或完全弃权。

在治理v1中,公投可通过以下几种方式启动:

• 公开提交的提案
• 理事会多数或全票通过的提案
• 作为先前公投执行的一部分提交的提案
• 由技术委员会提交并经理事会批准的紧急提案

所有公投都有相应的执行延迟期。这是从公投结束到提案实际执行之间的一段时间。

在Gov2中,任何人都可以随时发起公投,次数不限。Gov2引入了Origins(来源)和Tracks(轨道)概念,以帮助公投协议的流程和处理。

Origin可视为给定特权级别的描述符。提议者需要根据提案要求,为请求选择合适的Origin。

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

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

提案公投

公众公投

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

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

一旦提案被提交(进行投票),绑定的token将被释放。

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

在Gov2中,当公投创建后,社区就可以立即投票。但该公投并未处于可结束、计算选票、获得批准和最终执行的状态。相反,公投必须满足一些标准,才能进入"决定(Deciding)"状态。在此之前,仍处于待定状态。

进入Decided状态的标准如下:

• 经历了导入期,即决定可以开始前必须经过的时间。这有助于减少"决定狙击"的可能性,即控制大量投票权的攻击者可能在提议后立即通过提案,而不让全体投票者有足够时间考虑和参与。

• 必须还有决定的剩余空间。所有Track都对可同时决定的公投数量有限制。更强大的轨道限制更低。例如,Root级别Origin的限制为1,意味着一次只能决定1个超级危险的提案。

• 必须支付决定押金。创建公投成本很低,因为押金仅包含跟踪所需链上存储的价值。但对公投进行审查和决定,存在耗尽公投队列有限位置的风险。要求提供较大但可退还的押金,有助于减少垃圾信息。

理事会公投 (v1)

理事会全票通过 - 当理事会所有成员同意一项提案时,可将其移至公投。该公投将产生负投票率偏差(即权益投票数量越少,通过所需数量越少)。

理事会多数通过 - 当只有简单多数理事会成员同意时,也可对公投投票,但将是多数票制(获得51%票的一方获胜)。

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

投票时间表

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

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

不能在同一时期对多项公投表决,紧急公投除外。与常规公投同时发生的紧急公投是唯一可同时对多项公投投票的情况。

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

公投投票(治理v2)

在治理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。

token被锁定后,仍可用于投票和质押;只被禁止将这些token转移到另一账户。

选票总是在同一时间"计算",即在投票期结束时。这不受token锁定期影响。

自适应群体偏见

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

理事会

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

除控制国库外,理事会还主要负责三项治理任务:

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

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

取消公投

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

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

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

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

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

技术委员会

在治理v1中,技术委员会(TC)作为Kusama治理的三院之一(另外两院是理事会和公投)而引入。TC由成功实施或定义Polkadot runtime或Polkadot Host的团队组成。通过理事会的简单多数投票,可以在TC中添加或删除团队。

TC的目的是防止恶意公投、实施bug修复、逆转错误的runtime更新或添加新的但经过实战检验的功能。TC有权使用Democracy pallet加速提案,并且是唯一能够