OpenGov（三）：新波卡治理机制有哪些可期待？

OpenGov维持波卡开创的信念投票，与以前相同的方式进行，使用WebAssembly和几个链上投票机制。也就是说，OpenGov通过降低障碍，来更好地管理网络的日常决策，将流程推向去中心化。真正的重点是使提案的范围与通过治理流程的方式保持一致。

波卡OpenGov提案过程

波卡治理变得更简单了。当提交提案时，不再会有提案在进入公投阶段之前需要获得支持的启动期。这意味着任何社区成员可以没有延误进行公投。不像Gov1，在OpenGov的支持下，成千上万的决策可以同时发生。这个一流的决策制定机制称为公投。

公投：社区对单一想法（称为提案）的普遍投票

OpenGov公投支持以下情况：

• 可以在任何时候开始
• 可以由任何人开始
• 可以根据提案者的意愿开始多次
• 可以由任何DOT持有者投票
• 在某一特定时间内不限数量

提案：提出供社区考虑和讨论的正式书面计划或建议

公投是基于提案的。社区成员汇总希望在波卡上实施的想法，并将其提交给社区，在公投中进行投票。

“提案”也是波卡上“运营”的另一种说法（例如交易的操作如何由用户提议）。这个区别非常重要，因为波卡可以执行很多不同的操作（例如转账、质押等），OpenGov提案根据运营的优先级组织。

波卡上的一些操作需要更多权力（思考、计算能力 — — 更深层次的逻辑和安全授权），一些没那么重要。举例而言，与在dApp上添加夜间模式功能相比，升级到底层技术层将是更关键的操作/提案。这些级别的复杂性或特权由“Origin”一词描述。

简化提案和公投的Origin和Track

Origin：描述优先级。在OpenGov中，Origin是基于授权的交易来源，用于决定公投发布的Track。Origin有不同等级，范围从最高优先级的Root Origin到最低优先级的Tip Origin。

在OpenGov出现前，每一次提议的民主公投都是作为Root Origin运行的。这是最强大的级别参数，对于低优先级的公投来说有点矫枉过正。按这种方式运行每一次公投的结果就是提案挤压，并且自始自终28天的投票窗口，给予每份提案相同的时间和关注，即使有些提案要比其他的重要。错过投票窗口意味着要等到队列中的下一个位置打开才能将提案放到链上，从而造成进一步的延迟和混乱。

在OpenGov的支持下，提案者选择意愿提案被执行的Origin等级。每个Origin都与不同标准的公投种类有关（例如，维护模式激活、Runtime升级、XCM通道打开）。

Track：提案在公投期间通过的特定于Origin的传递途径

Track是特定于Origin的，因此与其他Origin track是分离的，允许不同track中的提案（同时）和其他track中的提案运行。稍微不重要一些的Origin track可以同时拥有多个正在进行中的公投，因为提案中的更改不像一次只有一个的Root Origin track那样危险。

Track最大决策或容量：一次可以决定该track上的公投数量的限制。

不同track中的公投遵循不同的规则，这些规则与其Origin级别成正比。举例而言，更重要和特权的公投将有更多的保障、更高的门槛和更长的批准审议期。

提案如何在波卡OpenGov中通过

波卡OpenGov提供了一个组织总体治理系统的框架和过程，以给予用户可以在民主和公平的情况下更改网络的能力。此过程旨在投票和制定提案之前，创建举行社区讨论的一致的动态。不同的Origin Track有不同的批准标准。尽管如此，所有Origin Track获得批准的一般过程都是相同的。

任何Origin Track的链上提案概览

在OpenGov中，公投由一个共同的过程完成，而批准要求的细节是根据Track的。Track中，参数在以下方面有所不同：

• 决定期间、确认期间、最短制定期间和准备期间。
• Curve，或公投通过所需的批准和支持量
• 可以同时进行的全民公决的数量，或容量。

OpenGov提案批准过程：

1. 提案/公投创建：社区成员必须指定交易的Origin并添加提案想法。
2. 带入期：投票开始，但在此阶段的提案“未定”，直到通过指定track的标准（即满足的最少投票时间、track中可用空间、已支付的决定押金）。
3. 决定期：社区在有限的时间内使用Token继续投票“决定”提案。
4. 确认期：获得批准和足够支持（最低DOT数量）的提案将通过，并在设定的决定期内的整个track特定确认期内保持此状态。
5. 批准或拒绝：如果提案在决定期结束前未获批准，则该提案将被拒绝。如果提案在其确认期通过，即使决定期尚未结束，它也会被批准。
6. 制定期：批准的提案等待指定时间（在原始提案中规定）付诸实施。

带入期

当提案进入公投时，社区开始投票，此时称为“带入期”。通常来说，带入期是讨论的时间段。Track上需要有空间给提案去继续进行。社区在该时期对提案投票，如果此时有多个提案在Track上等待空间，投票的提案会移至前方，但这些投票不属于决定期。

从带入期至决定期的标准：

1. 公投已发布所需最短时间：这允许投票，并防止提案未经讨论就进入下一阶段。
2. 在选中的Track中有提案空间：Track对可以同时运行的公投数量有不同的限制（例如，Root Origin需要考虑更多安全影响，因此同时间只能有一个公投在Root Origin Track的决定期）
3. 已经缴纳决定押金：为完成标准，必须支付押金。此押金可能因不同track而异。押金的目的是保护公投的链上存储并阻止垃圾信息。

决定押金：在做出决定之前必须缴纳的存款数额。

决定期和确认期

当一个提案符合带入期标准，该提案已经在相应的Track上占据一席之地，投票也将在决定期继续进行。提案从决定期进入确认期还需符合两个标准：批准与支持。确认期比决定期时间更短，并且可在指定的决定期中任何时间内“符合”。

批准与支持

批准与支持的标准用于决定期和确认期。通常来说，这两个标准需要有权重的信念值中的大部分投票（投票权重有利于提案），并且还要有大量的足够多的可用DOT参与。

批准是指提案从决定期进入确认期并最终在确认期获得批准所需的“同意”票的百分比。不像支持，批准考虑投票信念。

支持是指参与公投所需的最低票数。支持标准反映为总供应量的百分比，例如DOT总供应量的 [x]% 需要投票同意、反对、弃权。

信念：锁定Token以增加投票乘数，从而加强投票权重。例如，锁定最多32个锁定期（896 天）的Token将他们的选票乘以6。

批准：信念调整后的批准投票权重与批准和拒绝投票权重的标题数的份额。

支持：与系统中可能进行的总票数相比，批准的总票数（忽略信念调整）。支持也包括弃权票。

批准和支持标准分别由批准曲线和支持曲线确定。

批准曲线：该曲线明确最少的赞成票为批准所需的整体信念加权票数的百分比，作为进入决定期的时间函数。

支持曲线：该曲线明确最少的预信念赞成投票（“支持”）为批准所需的整体数的百分比，作为进入决定期的时间函数（考虑到弃权票）。

决定期

在决定期的提案有几天时间达到批准和支持的要求，方可进入确认期。如果该提案没有满足要求，那么会被拒绝。

假设不是恶意提案，一个被拒绝的提案可以重新提任意次数。被拒绝后，决定押金通常会被退回。如果提案获得批准，将进入制定期。

决定期：在拒绝前，决定被批准进入确认期可能需要的时间。

确认期

在提案移至确认期后，也必须满足批准和支持的要求一段时间。提案需要连续通过这一段时间。通过的批准和支持要求会根据投票曲线随时间变化。每个track都有特定的投票曲线。

确认期可防止提案被操纵（通过暂时提高批准标准的高权重投票）而快速获得批准。如果不存在维持批准的投票，则该提案无法在规定的时间内维持其已批准和支持的状态，并且必须重新开始确认期。

在Root Origin中的公投可能会对网络安全产生重大影响，因此确认期比不会对网络产生太大影响的Track更长。

如果提案通过确认期的时间要求，该提案将被认作“已批准”且进入制定期。如果提案没有通过，将返回至决定期，如果决定期未结束，将寻求确认期新的批准和支持。

确认期：在提案被批准前，批准和支持标准所需时间。

从决定移至确认的标准

1. 批准：要求的投票结果符合Origin Track的批准曲线，包括信念值
2. 支持：与符合支持曲线并考虑到已弃权的投票者的可能投票总数相比，足够多的投票者批准了该提案。
3. 确认期：在公投决定期中具有一定时间的批准和支持要求的提案将被批准；在决定期中没有符合标准，在确认期仍有批准和支持提案将被拒绝

假设不是恶意提案，一个被拒绝的提案可以重新提任意次数。被拒绝后，决定押金通常会被退回。如果提案获得批准，将进入制定期。

制定期

当提案在流程中进入此阶段时，将获得批准并在等待或制定期后发送。制定期的时间由提案者在最初公投提案的时候建议，但每个Origin Track也有最短时间要求。

制定期：在批准后，必须在发送队列通过批准的提案的最少时间

在制定期的时间确保网络对于提案更改的而做出的准备。Root Origin批准在批准后需要较长的等待期，因为波卡网络可能需要适应更改的深度。

OpenGov对不良提案的干预

没有一个过程是完美的，为了应对挑战，OpenGov内置了一些措施来应对这些挑战。在某些情况下，提案会包含问题或恶意意图。

取消

如果发现已经进入投票阶段的提案有问题，可能需要阻止其通过。这些实例可能涉及恶意活动或技术问题，导致由于最近的网络升级而无法实施更改。

取消：具有自己的Origin track的治理操作，可以立即拒绝正在进行的公投（无论其状态是否通过）。

OpenGov具有两个取消Origin，Emergency Canceller用于针对包含不可预见问题的公投，Emergency Killer用于损害网络的不良公投。

Emergency Canceller track会导致提案被拒绝，并退回决定押金；Emergency Killer track会导致取消并押金惩罚，也就是押金的数额被销毁。

取消必须由网络投票方可执行。取消提案比常见的提案更快，因为必须在寻求取消的提案制定之前做出决定，但遵循与其他公投相同的过程。Cancellation Origin Track具有一个短的带入时间，和为通过降低门槛的批准和支持曲线。

OpenGov中的投票委托

在波卡与所有人保持进度是亘古不变的工作。许多Token持有者并不会花很多时间研究、讨论、考虑每个提案，但他们仍然在网络中享有一席之地，因此在决策中拥有发言权。

波卡最初的理事会是为弥补缺席投票而设立的投票者委托机构。Kusama和波卡上的OpenGov不再有理事会，但投票委托功能仍然保留，并且改进以确保缺席投票者的声音也能被听见。

投票委托：投票人可以将其投票权（包括信念投票）给另一位投票人。

多角色委托：用户可以在系统中给每个track或者公投等级指定不同委托人。

OpenGov投票委托针对灵活性进行了优化，并引入了多角色委托。Token锁定在信念投票中，即使通过委托也不会离开自己的钱包。投票者使用委托可以更改委托者，或随时收回投票权。

多角色委托是此次OpenGov增添的特殊功能。为确保正确的人代表用户对正确的提案进行投票，可以使用多角色委托根据提案将投票权赋予不同的实体。

用户可能会为Root Origin track提案委托其投票给更技术性的实体，另一个给不太重要的track。这些委托可以由用户自行决定针对一次公投或每个track进行。

举例而言，用户可以委托投票给技术方面的决定（例如Runtime升级），同时保留投票权给其他决定（例如grant批准，或是对网络的重大变更），并按委托者意愿撤销或改变委托。