Moonbeam上的治理¶
概览¶
Moonbeam治理机制的目标是根据社区意愿推进协议。在这个共同使命中，治理过程寻求包括所有Token持有者。关于协议的任何以及所有更改都必须通过公投，以便所有的Token持有者可以根据质押权重对决策提出建议。
如Moonbeam社区论坛和Polkassembly的社区治理论坛将开放讨论，并允许根据社区建议完善提案。自主生效和无分叉升级将社区团结起来，共同完成推进协议的使命。
随着波卡治理的第二个阶段OpenGov（初始定义为Gov2）的推出，对治理流程进行了几个修改。关于OpenGov所有修改的详细内容，请参考OpenGov：什么是Polkadot Gov2。
在Runtime 2400时，所有Moonbeam网络使用OpenGov作为他们的治理系统。
原则¶
参与Moonbeam治理流程的“基本”原则包括：
- 对希望参与Moonbeam网络的和受到治理决策影响的Token持有者持开放包容的态度
- 即使与Moonbeam意见相左，仍需支持Token持有者的参与
- 承诺决策过程中的公开透明
- 以生态利益为先，个人利益为后
- 始终以道德作为行事的出发点
- 与其他Token持有者的互动中始终保持耐心和慷慨的心态，但不代表容忍辱骂性或破坏性的语言、行动和行为，并遵守Moonbeam的行为准则
以上原则很大程度上受到Vlad Zamfir先生关于区块链治理的著作的启发。如需了解更多详情，请参阅他撰写的文章，尤其是如何以诚信（和礼貌）的方式参与区块链治理这篇Medium文章。
链上治理机制¶
Moonbeam的“硬性”治理流程将由链上流程驱动，该方式能够确保与Moonbeam网络相关的关键决策由多数Token作出。这些决策将以提案公投的形式出现，并根据投票权重得出投票结果。
这一治理机制的主要组成部分包括：
- 公投 — 基于质押量的投票计划，每次公投均与更改Moonbeam系统的特定提案相关，包括关键参数值、代码升级或治理系统本身的修改
- 投票 — 公投将由Token持有者以质押量权重为基础进行投票。通过的公投将会延迟生效，以便有不同意决策的Token持有者有时间退出网络
- Governance V1理事会 & 技术委员会 — 一个由社区成员组成的团体，成员在系统中拥有特殊投票权
- OpenGov技术委员会 — 一个由社区成员组成的团体，成员可以将特定提案列入Whitelisted Track中
更多关于Substrate框架pallet如何实施链上治理的细节，请查阅波卡治理概览博客文章以及波卡治理Wiki。
Governance v2: OpenGov¶
此部分将涵盖您需要了解的关于Moonbeam上OpenGov的所有信息。
一般定义¶
- 提案 — 原像哈希定义的行动或项目，由Token持有者提议并开放供其他Token持有者讨论
-
公投 — 由Token持有者投票的提案。每次公投均与更改Moonbeam系统的特定提案相关，包括关键参数值、代码升级或治理系统本身的修改
-
原像哈希 — 要颁布提案的哈希。提出提案的第一步是提交原像。哈希只是一个标识符。原像的提议者可以不同于将原像作为正式提案提出的用户
-
原像保证金 — 提交原像时提议者需要绑定的一笔Token数量。该金额计算为每个网络的基本保证金加上提议的原像的每字节费用
-
Origin - 基于授权的调度来源，用于决定公投发布的Track
-
Track - 概述提案生命周期的特定于Origin的管道。目前，有五个Track：
Origin Track 描述 公投示例 Root 最高优先级的提案 Runtime更新、技术委员会管理 Whitelisted 在发送前由技术委员会列入白名单的提案 快速处理操作 General Admin 用于基本链上决策 XCM费用、Orbiter计划、平行链质押参数、registrar的更新 Emergency Canceller 用于取消公投。保证金退还 错误的公投 Emergency Killer 用于处理不良公投。保证金没收 不良公投 -
投票 — Token持有者用于批准（“Aye”）或拒绝（“Nay”）提案的工具。投票权重由两个因素决定：锁定的Token数量和锁定期限（称为信念值）
- 信念值(Conviction) — Token持有者投票时自愿锁定Token的时间：锁定时间越长，投票权重越大
- 锁定余额 — 用户提交投票的Token数量（请注意，这与用户的总账户余额不同）
Moonbeam使用自愿锁定的概念，允许Token持有者通过锁定Token一段更长的时间来增加其投票权。无锁定期意味着用户的投票权重为其锁定余额的10%。通过增加信念值可获得更高的投票权重。每增加一次信念值（投票乘数），则锁定期会加倍。
-
批准 — 获得批准所需的最低“赞成（Aye）”票数占整体权重投票数的百分比
-
支持 — 最低“赞成”票数（不考虑信念权重投票数）占批准所需总供应量的百分比
-
带入期 — 最初的提案投票和讨论期。在此阶段，提案处于未定状态直至其通过指定Track的某些标准，包括：
- 准备期 — 公投提交后进入一下阶段前需要等待的最短时间
- 容量 — 指定Track上一次可以决定的公投数量的限制
- 决定保证金 — 在带入期结束后公投进入决定期所需的最低保证金金额。由于每个Track有一个固定的容量，此保证金要高于提交的保证金，其目的是防止不良提案的提交
Track会有不同的标准参数，这些参数与Origin级别成正比。举例而言，更重要和特权的公投将有更多的保障、更高的门槛和更长的批准审议期。 请参考治理参数部分获取更多信息
-
决定期 - Token持有者继续在公投上进行投票。如果公投在期限结束时未通过，则提案会被拒绝，决定保证金将被退还
- 确认期 - 决定期内的一段时间，在此期间公投需要获得足够的批准和支持数量才能进入生效等待期
-
生效等待期 - 一段指定的时间，它是在提案创建时定义的，是已批准的公投在发送之前的等待时间。每个Track有一个最短等待期限
-
投票委托 — 投票者将其投票权（包括信念投票）委托给其他有经验并能做出具体决定的Token持有者
- 多角色委托 — 在每个Track的基础上委托投票权，Token持有者可以为每个Track指定不同的委托
治理参数¶
| 变量 | 值 |
|---|---|
| 原像基础保证金 | 500 GLMR |
| 每个字节的原像保证金 | 0.01 GLMR |
| 提案提交保证金 | 1000 GLMR |
| 变量 | 值 |
|---|---|
| 原像基础保证金 | 5 MOVR |
| 每个字节的原像保证金 | 0.0001 MOVR |
| 提案提交保证金 | 10 MOVR |
| 变量 | 值 |
|---|---|
| 原像基础保证金 | 5 DEV |
| 每个字节的原像保证金 | 0.0001 DEV |
| 提案提交保证金 | 10 DEV |
Track的基本参数¶
| Track | Track ID | 容量 | 决定 保证金 |
|---|---|---|---|
| Root | 0 | 5 proposals | 2000000 GLMR |
| Whitelisted | 1 | 100 proposals | 200000 GLMR |
| General Admin | 2 | 10 proposals | 10000 GLMR |
| Emergency Canceller |
3 | 20 proposals | 200000 GLMR |
| Emergency Killer |
4 | 100 proposals | 400000 GLMR |
| Track | Track ID | 容量 | 决定 保证金 |
|---|---|---|---|
| Root | 0 | 5 proposals | 100000 MOVR |
| Whitelisted | 1 | 100 proposals | 10000 MOVR |
| General Admin | 2 | 10 proposals | 500 MOVR |
| Emergency Canceller |
3 | 20 proposals | 10000 MOVR |
| Emergency Killer |
4 | 100 proposals | 20000 MOVR |
| Track | Track ID | 容量 | 决定 保证金 |
|---|---|---|---|
| Root | 0 | 5 proposals | 100000 DEV |
| Whitelisted | 1 | 100 proposals | 10000 DEV |
| General Admin | 2 | 10 proposals | 500 DEV |
| Emergency Canceller |
3 | 20 proposals | 10000 DEV |
| Emergency Killer |
4 | 100 proposals | 20000 DEV |
Track的时间期限参数¶
| Track | 准备期 | 决定期 | 确认期 | 最短生效等待期 |
|---|---|---|---|---|
| Root | 7200 blocks (1 day) |
100800 blocks (14 days) |
7200 blocks (1 day) |
7200 blocks (1 day) |
| Whitelisted | 50 blocks (10 minutes) |
100800 blocks (14 days) |
50 blocks (10 minutes) |
150 blocks (30 minutes) |
| General Admin | 300 blocks (1 hour) |
100800 blocks (14 days) |
7200 blocks (1 day) |
7200 blocks (1 day) |
| Emergency Canceller |
300 blocks (1 hour) |
100800 blocks (14 days) |
900 blocks (3 hours) |
50 blocks (10 minutes) |
| Emergency Killer |
300 blocks (1 hour) |
100800 blocks (14 days) |
900 blocks (3 hours) |
50 blocks (10 minutes) |
| Track | 准备期 | 决定期 | 确认期 | 最短生效等待期 |
|---|---|---|---|---|
| Root | 7200 blocks (1 day) |
100800 blocks (14 days) |
7200 blocks (1 day) |
7200 blocks (1 day) |
| Whitelisted | 50 blocks (10 minutes) |
100800 blocks (14 days) |
50 blocks (10 minutes) |
150 blocks (30 minutes) |
| General Admin | 300 blocks (1 hour) |
100800 blocks (14 days) |
7200 blocks (1 day) |
7200 blocks (1 day) |
| Emergency Canceller |
300 blocks (1 hour) |
100800 blocks (14 days) |
900 blocks (3 hours) |
50 blocks (10 minutes) |
| Emergency Killer |
300 blocks (1 hour) |
100800 blocks (14 days) |
900 blocks (3 hours) |
50 blocks (10 minutes) |
| Track | 准备期 | 决定期 | 确认期 | 最短生效等待期 |
|---|---|---|---|---|
| Root | 7200 blocks (1 day) |
100800 blocks (14 days) |
7200 blocks (1 day) |
7200 blocks (1 day) |
| Whitelisted | 50 blocks (10 minutes) |
100800 blocks (14 days) |
50 blocks (10 minutes) |
150 blocks (30 minutes) |
| General Admin | 300 blocks (1 hour) |
100800 blocks (14 days) |
7200 blocks (1 day) |
7200 blocks (1 day) |
| Emergency Canceller |
300 blocks (1 hour) |
100800 blocks (14 days) |
900 blocks (3 hours) |
50 blocks (10 minutes) |
| Emergency Killer |
300 blocks (1 hour) |
100800 blocks (14 days) |
900 blocks (3 hours) |
50 blocks (10 minutes) |
Track的支持和批准参数¶
| Track | 批准曲线 | 批准参数 | 支持曲线 | 支持参数 |
|---|---|---|---|---|
| Root | Reciprocal | Day 0: 100% Day 4: 80% Day 14: 50% |
Linear | Day 0: 25% Day 14: 0.5% |
| Whitelisted | Reciprocal | Day 0: 100% Day 1: 96% Day 14: 50% |
Reciprocal | Day 0: 2% Hour 1: 1% Day 14: 0% |
| General Admin | Reciprocal | Day 0: 100% Day 4: 80% Day 14: 50% |
Reciprocal | Day 0: 50% Day 7: 10% Day 14: 0% |
| Emergency Canceller |
Reciprocal | Day 0: 100% Day 1: 96% Day 14: 50% |
Reciprocal | Day 0: 10% Day 1: 1% Day 14: 0% |
| Emergency Killer |
Reciprocal | Day 0: 100% Day 1: 96% Day 14: 50% |
Reciprocal | Day 0: 10% Day 1: 1% Day 14: 0% |
| Track | 批准曲线 | 批准参数 | 支持曲线 | 支持参数 |
|---|---|---|---|---|
| Root | Reciprocal | Day 0: 100% Day 4: 80% Day 14: 50% |
Linear | Day 0: 25% Day 14: 0.5% |
| Whitelisted | Reciprocal | Day 0: 100% Day 1: 96% Day 14: 50% |
Reciprocal | Day 0: 2% Hour 1: 1% Day 14: 0% |
| General Admin | Reciprocal | Day 0: 100% Day 4: 80% Day 14: 50% |
Reciprocal | Day 0: 50% Day 7: 10% Day 14: 0% |
| Emergency Canceller |
Reciprocal | Day 0: 100% Day 1: 96% Day 14: 50% |
Reciprocal | Day 0: 10% Day 1: 1% Day 14: 0% |
| Emergency Killer |
Reciprocal | Day 0: 100% Day 1: 96% Day 14: 50% |
Reciprocal | Day 0: 10% Day 1: 1% Day 14: 0% |
| Track | 批准曲线 | 批准参数 | 支持曲线 | 支持参数 |
|---|---|---|---|---|
| Root | Reciprocal | Day 0: 100% Day 4: 80% Day 14: 50% |
Linear | Day 0: 25% Day 14: 0.5% |
| Whitelisted | Reciprocal | Day 0: 100% Day 1: 96% Day 14: 50% |
Reciprocal | Day 0: 2% Hour 1: 1% Day 14: 0% |
| General Admin | Reciprocal | Day 0: 100% Day 4: 80% Day 14: 50% |
Reciprocal | Day 0: 50% Day 7: 10% Day 14: 0% |
| Emergency Canceller |
Reciprocal | Day 0: 100% Day 1: 96% Day 14: 50% |
Reciprocal | Day 0: 50% Day 1: 1% Day 14: 0% |
| Emergency Killer |
Reciprocal | Day 0: 100% Day 1: 96% Day 14: 50% |
Reciprocal | Day 0: 10% Day 1: 1% Day 14: 0% |
信念乘数¶
信念乘数与公投通过批准后进入生效等待期的Token锁定期限数量有关。如果您愿意锁定Token的时间越长，则您的投票权重就越大。 您也可以选择不锁定Token，但投票权重会大大降低（在公投期间Token仍处于锁定状态）。
举例来说，如果您以6倍的信念投票1000个Token，您的投票权重将为6000。也就是说，1000个锁定的Token乘以信念（在本示例中为6倍）。但是如果您决定不在生效后锁定您的Token，您可以以0.1倍的信念进行投票。在这种情况下，您的投票权重为100。
每个网络的信念乘数如下所示：
| 生效后的锁定期 | 信念乘数 | 预计锁定时间 |
|---|---|---|
| 0 | 0.1 | None |
| 1 | 1 | 1 day |
| 2 | 2 | 2 days |
| 4 | 3 | 4 days |
| 8 | 4 | 8 days |
| 16 | 5 | 16 days |
| 32 | 6 | 32 days |
| 生效后的锁定期 | 信念乘数 | 预计锁定时间 |
|---|---|---|
| 0 | 0.1 | None |
| 1 | 1 | 1 day |
| 2 | 2 | 2 days |
| 4 | 3 | 4 days |
| 8 | 4 | 8 days |
| 16 | 5 | 16 days |
| 32 | 6 | 32 days |
| 生效后的锁定期 | 信念乘数 | 预计锁定时间 |
|---|---|---|
| 0 | 0.1 | None |
| 1 | 1 | 1 day |
| 2 | 2 | 2 days |
| 4 | 3 | 4 days |
| 8 | 4 | 8 days |
| 16 | 5 | 16 days |
| 32 | 6 | 32 days |
注意事项
预计锁定时间基于常规的12秒区块时间。区块生产可能会有所不同，因此显示的锁定时间仅供参考。
提案步骤¶
在提交提案之前，提案的作者可以将其提案的想法提交到Moonbeam治理论坛的Democracy Proposals部分，以获得来自社区的至少五天的反馈。作者可以根据收集的反馈对提案进行调整。
作者准备完毕后，便可以在链上提交提案。首先，需要提交提案原像。提交者必须绑定一笔费用以在链上存储原像。提交者取消注释原像后该保证金将被退还。接下来，提交者可以提交真实的提案并支付提交保证金，确保能够支付提案的链上存储费用。然后，将进入带入期，社区可以通过锁定Token为提案进行“赞成”或“反对”的投票。为了让公投从带入期进入决定期必须满足以下条件：
- 公投必须等待准备期的持续时间，以便在进入下一阶段之前有足够的时间讨论提案
- 所选的Track类型中有足够的容量
- 完成符合Track类型最低要求的决定保证金
如果公投满足以上条件，将会进入决定期并占据指定Track类别的其中一个位置。在决定期，投票将持续进行，公投设置了一定的天数来达到所需的批准和支持要求才能进入确认期。
当进入确认期后，公投必须在此期间持续满足批准和支持要求。如果公投未达到要求，则返回到决定期。如果在决定期还剩下足够的时间，并且公投再次满足批准和支持要求，则可以再次进入到确认期，决定期将会延迟到确认期结束。如果决定期结束，但未获得足够的批准和支持，则公投将被拒绝，决定保证金将被退还。该提议可以在任何时候再次提出。
如果公投在确认期继续获得足够的批准和支持，则会被批准并进入生效等待期。在正式被发送之前，将在生效等待期等待。
下方图片显示了提案步骤：
提案示例流程¶
在Moonriver上的General Admin Track提交的提案（及其原像）将具有以下特征：
- 批准曲线从第Day 0天的100%开始，在第Day 4天达到80%
- 支持曲线从第Day 0天的50%开始，在第Day 7天达到10%
- 公投以0%的“赞成”票开始决定期（带入期不开放投票）
- Token持有者开始投票并在第Day 4天将批准率增加到80%以上
- 如果批准和支持在确认期（7200区块，约为1 day天）达到数量要求，则公投会被批准
- 如果在决定期未达到批准和支持数量要求，则该提案将被拒绝。请注意，必须在确认期达到此数值。 因此，如果该提案满足要求但在确认期完成之前决定期已经到期，则该提案将被拒绝
批准和支持的比例可以使用以下方式计算：
Approval = 100 * ( Total Conviction-weighted "Aye" votes / Total Conviction-weighted votes )
Support = 100 * ( Total non-Conviction-weighted votes / Total supply )
提案取消¶
如果发现已经进入投票阶段的提案有问题，则需要阻止该提案通过。这些实例可能涉及恶意活动或由于近期的网络升级而无法实施更改的技术问题。
取消公投需要通过网络投票才可执行。取消提案的流程会比普通提案更快，因为该提案必须在生效之前快速决定，但遵循与其他公投相同的过程。
有一个取消Origin用于对抗包含不可预见问题的公投，称为Emergency Canceller。Emergency Canceller Origin和Root Origin可以取消公投。无论Origin如何，如果提案被取消，它将被拒绝，并且Decision Deposit将被退还。
另外，还有一个Kill Origin，用于恶意公投，意图危害网络，称为Emergency Killer。Emergency Killer Origin和Root Origin具有否决公投的能力。在这种情况下，提案将被取消，Decision Deposit将被削减，这意味着无论Origin如何，押金的金额都会被销毁。
OpenGov技术委员会的权力¶
根据Polkadot的Wiki表示，在波卡上，Governance v1的技术委员会将被Fellowship所取代。Fellowship是一个基本自治的专家机构，其主要目标是代表具有波卡和/或Kusama网络和协议的技术知识的成员。
对于Moonbeam的OpenGov实现，社区OpenGov技术委员会取代了Fellowship，其具有与Fellowship非常相似的权力。他们在治理方面有权力将提案加入白名单。如果提案在加入白名单后能够防止网络出现安全漏洞，OpenGov技术委员会成员可能只能为提案加入白名单进行投票。OpenGov技术委员会成员对于是否将提案列入白名单的通过门槛是由治理决定的。因此，OpenGov技术委员会对网络的权力非常有限。其目的是对Token持有人提出的紧急安全问题进行技术审查。
虽然仍然受制于治理，但Whitelist track背后的想法是它将有不同的参数，以加快提案的通过速度。 Whitelist Track参数，包括批准、支持和投票，由Moonriver或Moonbeam的Token持有者通过治理决定，OpenGov技术委员会无权更改。
OpenGov技术委员会由拥有基于Moonbeam网络方面技术知识和专业知识的社区成员组成。
OpenGov相关指南¶
关于如何使用OpenGov在Moonbeam上提交公投和投票，请查看以下指南：
| Created: March 26, 2021