Governance V2

Polkadot采用了一种精密的治理机制,能够根据利益相关者的需求优雅地进化。其目标是确保大多数权益始终能控制网络。

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

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

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

这个系统在运行初期运作良好,有助于合理使用国库资金并及时升级修复。但随着系统成熟,需要不断改进缺点并跟进进展。例如在"治理v1"中,所有公投权重相同,一次只能对一个公投投票,投票期可持续数周。这导致系统倾向于仔细考虑极少数提案,而非广泛考虑多个提案。因此"治理v2"应运而生。

"治理v2"或称"Gov2"改变了日常决策方式,使公投影响更广、更敏捷,大幅增加系统能做出的集体决策数量。

在对代码进行最终专业审核后,Gov2将在Kusama上启动。在Kusama上测试后,会提出将其部署到Polkadot的提案。

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

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

前提

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

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

机制

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

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

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

Gov1中的理事会履行了被动token持有者代表、国库守护者和立法发起者的角色,但通常被视为中心化实体。为进一步去中心化网络,Gov2提议将理事会职责交还给社区。

公投

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

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

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

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

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

如果公投关闭并完成统计,则视为已完成。假设提案获批,它将被安排执行。如公投正在等待结果即正在投票,则视为未完成。

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

在Gov2中,任何人都可以随时开始公投,且可发起多次公投。Gov2引入了Origins(来源)和Tracks(轨道)新功能,以助公投协议的流程和处理。

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

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

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

提案公投

公众公投

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

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

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

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

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

进入Decided状态的标准如下:

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

理事会公投 (v1)

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

理事会多数通过 - 当只有简单多数理事会成员同意时,也可对公投进行投票,但它将是多数票制(获得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乘数都会将投票乘数增加一。

锁定期数 投票乘数 0 1 1 2 2 3 4 4 8 5 16 6 32 6

锁定期"加倍"的最大次数设置为6(因此总共32个锁定期),一个锁定期等于28天。只允许加倍,例如,你不能锁定24个周期并使你的conviction增加5.5。

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

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

自适应群体偏见

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

理事会

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

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

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

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

取消公投

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

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

如取消的争议足够大,以