Governance 1.0 是波卡的第一代开放治理模型,我们已经在《OpenGov 链上治理模块的基础介绍》一文中有所介绍。Governance 1.0 的核心特征是采用三院制的结构。
在项目发展前期阶段,三院制可以很好的协调团队与社区之间的治理权力,而且可以最大限度保证治理决策的安全与灵活。但随着项目的成熟,社区必然要求项目治理更加去中心化。OpenGov 就是波卡顺应这种诉求的产物。
相比 Governance 1.0,OpenGov 带来的最显著的变化是取消了理事会和技术委员会,所有的决策全部通过公投来处理。**与此同时,增设了更多的治理轨道(Track),完善了治理流程和委托机制,并创建了 Fellowship (专家团)。 ** 本文将为大家系统的介绍一下 OpenGov 的框架和结构。
在 OpenGov 中,一个提案从开始到终结共分为以下几个步骤:
提案被发起后进入准备期,这个阶段发起者需要放入押金,如果准备期结束时没有放入押金,提案自动失效。该阶段开始后,用户立即可以开始参与投票,但这个阶段,无论投票达到什么样的阈值,提案都不会被结束。(防止大户在其他人来不及留意的情况下,迅速通过提案)
该阶段,用户始终可以参与投票,投票达到阈值之后,进入确认期。投票阈值分为两个,分别是相对多数阈值和绝对多数阈值,也就是说,一个提案必须同时满足相对多数门槛和绝对多数门槛,才可以进入确认期。需要注意的是,这两个阈值是动态变化的,它是两条曲线,决策期越接近结束,阈值往往越小。其中,相对多数的阈值不会小于 50%
如果直到决策期结束,提案都没有满足阈值要求,该提案视为被拒绝。
在决策期满足阈值条件的提案会进入确认期,进入确认期后,用户依旧可以投票。在确认期内,该提案始终需要保持满足阈值条件,确认期一结束,提案就会正式被通过,进入执行期。如果在确认期内,用户继续投票导致提案不再满足阈值条件,该提案将退回决策期。再次进入确认期的提案,其确认期重新计时。
提案通过之后,会进入执行期,执行期结束后,该提案正式在链上生效。提案发起者可以自定义执行期,但不能小于提案所在轨道设定的最小执行期。
OpenGov 中,公投(Referenda)是唯一的权力机构,为了提升公投决策的效率,有更多的轨道用来处理提案,不同的轨道有不同的参数。
以 Polkadot 为例,Polkadot 设置了 26 个不同的轨道,如下图(截止2023.8.9)。
其中,轨道容量是指该提案轨道可以同时进行的最大提案数,押金是指提案发起者需要抵押的资金,押金的存在可以防止提案者提交垃圾提案。准备期、决策期、确认期、最小执行期则是该轨道的提案各个阶段的期限。除此之外,每个轨道的两个阈值曲线也是不同的。
这些不同的提案轨道,有的权限大,有的权限小,涉及的提案的危险程度不同,越危险的提案往往对系统越大的影响或者涉及越大金额的财库支出。我们发现权限较大的轨道容量更小,准备期、确认期、最小执行期更长,且需要的押金越大。
Small Tipper、Big Tipper、Small Spender、Medium Spender、Big Spender、Treasure 这几个轨道都可以用来发起从财库拨款的提案,但他们所能支付的单笔金额上限是不同的,对应的各项参数也不同。例如,权限最小的 Small Tipper 轨道可支持一次性从财库支付最多 250 DOT,该轨道的准备期、确认期、最小执行期分别只有 1 min、10mins、1min,提案押金仅为 1 DOT,权限最大的 Treasure 轨道可支持一次性从财库支付最多 10,000,000 DOT,其准备期、确认期、最小执行期则高达2hrs、3hrs、1day,提案抵押金高达 1000 DOT。此外,二者的轨道容量也差别很大, Small Tipper 的轨道容量为 200 个,Treasure 的轨道容量只有 10 个。
非财库类提案也是如此,权限最大的 root 轨道,支持对链上代码进行任意修改的提案,对系统影响程度重大,因此轨道容量只有 1,抵押高度 100K DOT,其准备期、确认期和最小执行期都较长。其他仅对某个细分领域进行管理,对系统影响程度较小的轨道则拥有更宽松的参数。
通过这样的设计,OpenGov 既可以做到敏捷的处理非危险提案的同时,也可以谨慎的处理危险提案。
我们还发现,有些轨道可以处理一些特殊类型的提案,例如 Referendum Canceller 和 Referendum Killer 可以用来取消垃圾提案或者恶意提案,Whitelist Caller 则可以用来处理紧急提案,Fellowship admin 可以用来管理 Fellowship 相关事务,我们将在下篇展开陈述。