理事会（Council）负责对财务类提案进行批准，同时拥有发起外部提案（External Proposal ）的特权；
技术委员会的权力是可以将外部提案移入快读轨道 (Fast Track)，缩短其投票周期，该机制主要应用场景式处理技术故障、修复关键漏洞。
公投（Refrenda）则是针对公共提案（Public Proposal），适用于大多数非紧急事务的决策，任何治理通证的持有者都可以发起公共提案。治理通证持有者通过信念投票机制来对公共提案进行投票。同一时间，只有一个公共提案可以处于投票阶段。
在项目发展前期阶段，三院制可以很好的协调团队与社区之间的治理权力，而且可以最大限度保证治理决策的安全与灵活。但随着项目的成熟，社区必然要求项目治理更加去中心化。OpenGov 就是波卡顺应这种诉求的产物。
相比 Governance 1.0，OpenGov 带来的最显著的变化是取消了理事会和技术委员会，所有的决策全部通过公投来处理。与此同时，增设了更多的治理轨道（Track），完善了治理流程和委托机制，并创建了 Fellowship （专家团）。
本文将为大家系统的介绍一下 OpenGov 的框架和结构。
治理流程
在 OpenGov 中，一个提案从开始到终结共分为以下几个步骤：
准备期（Prepare Period）
提案被发起后进入准备期，这个阶段发起者需要放入押金，如果准备期结束时没有放入押金，提案自动失效。该阶段开始后，用户立即可以开始参与投票，但这个阶段，无论投票达到什么样的阈值，提案都不会被结束。（防止大户在其他人来不及留意的情况下，迅速通过提案）
决策期（Decision Period）
该阶段，用户始终可以参与投票，投票达到阈值之后，进入确认期。投票阈值分为两个，分别是相对多数阈值和绝对多数阈值，也就是说，一个提案必须同时满足相对多数门槛和绝对多数门槛，才可以进入确认期。需要注意的是，这两个阈值是动态变化的，它是两条曲线，决策期越接近结束，阈值往往越小。其中，相对多数的阈值不会小于 50%。
如果直到决策期结束，提案都没有满足阈值要求，该提案视为被拒绝。
确认期（Confirm Period）
在决策期满足阈值条件的提案会进入确认期，进入确认期后，用户依旧可以投票。在确认期内，该提案始终需要保持满足阈值条件，确认期一结束，提案就会正式被通过，进入执行期。如果在确认期内，用户继续投票导致提案不再满足阈值条件，该提案将退回决策期。再次进入确认期的提案，其确认期重新计时。
执行期（Enact Period）
提案通过之后，会进入执行期，执行期结束后，该提案正式在链上生效。提案发起者可以自定义执行期，但不能小于提案所在轨道设定的最小执行期。
治理轨道
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 相关事务，我们将在下篇展开陈述。
危险提案的干预
为了保证治理过程是安全的，防止恶意提案被通过。OpenGov 除了设置准备期之外，还设置了对危险提案的干预流程。
我们看到 Polkadot 治理轨道中，有两个特殊的轨道，分别是 Referendum Canceller 和 Referendum Killer。这两个轨道需要质押较多的 DOT，且轨道容量几乎不设限。这两个轨道是用于取消其他提案的，不同之处是 Referendum Canceller 仅仅取消提案，而 Referendum Killer 会在取消提案的同时罚没提案发起者的押金。可以说， Referendum Killer 是对恶意提案者的一个有效威慑。
一旦有提案进入 Referendum Canceller 和 Referendum Killer 的流程，该提案无论出于何种状态（即便在执行期），都将立即暂停其流程。
分轨道委托
OpenGov 继承了 Gov 1.0 的信念投票机制。在该机制下投票效用不止与投票的治理通证数量有关，还与治理通证的质押时长有关。质押时长越长，代表“信念”越强，能获得的投票效用加成会越高。
在治理实践中，往往很多治理 Token 持有者没有足够的时间来参与治理决策，而且很多治理 Token 持有者没有足够的能力和背景信息做出明智的决策，因此委托机制是必要的。Gov 1.0 允许用户将他们的治理 Token 委托给其他人代为行使治理权力，当然，用户也可以随时撤回委托或者更改委托对象。OpenGov 则进一步细化了该规则，用户可以针对不同的轨道将同一份投票权委托给不同的人。
Bifrost 作为波卡生态的一员，也将采取和波卡同构的治理机制。目前 Bifrost 采用的是 OpenGov 1.0，将在不久之后过渡到 OpenGov。
这样做的好处是可以让不同议题的专家，能够充分发挥其专业性。例如我可以将财库类决策的投票权委托给一个运营专家，而将技术类决策的投票权委托给另一个技术专家。
Fellowship
Fellowship 是一个自治的专家团体，可以理解为是一个更加去中心化的技术委员会。尽管 Fellowship 的初始成员将来自技术委员会，但与技术委员会不同的是，Fellowship 旨在囊括更广泛的、数以万计的成员。波卡将通过一定的激励机制，鼓励他们对波卡生态的发展和优化持续做出贡献。此外，Fellowship 并不是一个严格意义上的治理主体，也不直接拥有治理权力上的任何特权。
只有一个特殊的轨道，也就是 Whitelist Caller 会和 Fellowship 有所关联。Whitelist Caller 的定位类似于 Gov 1.0 中的 Fast Track，用于执行一些紧急的漏洞修复。该轨道的准备期和确定期都比较短，投票通过的两个阈值衰减较快，阈值曲线较为陡峭。只是，处于该轨道的提案被通过，进入执行期之后，需要 Fellowship 进行二次投票确认才能正式执行。
Fellowship 有自己的治理界面，该界面可以用来针对 Fellowship 成员的招募、清退、等级变更等事务进行治理。新成员的加入需要由以为现有成员推荐，并经过内部投票确认。Fellowship 的成员有各自的等级，等级由成员对波卡生态的贡献决定，等级将决定内部投票时的权重。具体细则可参考官方发布的文档：
https://github.com/polkadot-fellows/manifesto/blob/5e01eef15eded63f1db9be808b0f7c11bb9f4a12/manifesto.pdf
公投中的 Fellowship admin 轨道也可以对 Fellowship 的事务进行管理，其权限高于 Fellowship 内部的自治决策。
小结
总之，从 Gov 1.0 迭代到 OpenGov ，波卡的治理过程在兼顾安全的前提下，提升了治理效率和治理灵活度，同时实现了高水平的去中心化。总体来看：
在权利分布方面，OpenGov 中，治理通证的持有者完全掌握了治理权力，不再有其他的治理权力主体。
在决策效率方面，OpenGov 通过开设多个轨道，以满足不同类型提案的不同流程设置和容量设置，这些轨道可以同时进行，决策效率大幅提升。
在治理安全方面，Gov 1.0 更多依赖理事会作为唯一的防火墙，OpenGov 则依赖机制上的巧妙设计。
来源：，本站：/zixun/726.html
0 条评论