PlatON治理指南
PlatON支持链上投票治理机制，以下将为大家介绍PlatON治理中提案类型以及治理升级流程。
提案类型
- 文本提案：对于无需实施的决策都可以用文本提案发起，除重要或有分歧情况下的文本提案才需在链上进行投票。
- 软件升级提案：用来在链上发起升级投票，达到平滑升级的目的
- 参数修改提案：用来对系统参数等可治理的参数进行修改
- 取消提案： 用来取消链上正在投票中的软件升级提案
链上提案流程
1) 社区讨论
提案发起人在可在社区提出改进建议，在得到社区成员的充分讨论后，就讨论结果根据不同提案类型模板编写为提案草稿，通过Pull Request的方式提交至GitHub上PlatON/PIPs仓库。在PIP-1.md可以了解更多关于PIPs仓库的操作规则。
2) 发起提案
在提案通过社区讨论和PIP仓库管理员审核后，即可在链上发起提案。提案发起人需为备选节点，即排名前101的节点。为控制垃圾提案，所有类型的提案的发起都需要支付一笔提案手续费，作为提案的成本。
3) 提案投票
只要是在该提案投票周期内当选成为备选节点的节点都能进行投票。投票周期一般为两周，软件升级提案的投票周期可根据情况由提案发起人决定。投票形式采用备选节点一人一票制度，投票后将锁定备选节点自有质押代币到投票结束。除软件升级提案外，其他类型的投票有三种投票选项，分别为：“是”、“否”、“弃权”。为了简化投票流程，软件升级提案没有显性的选项选择，各备选节点可通过是否升级本地节点来表明自己的投票立场，具体可以参考升级机制。
4) 投票结果计算
投票结果又以下两个计算维度；
- 备选节点支持率：投票支持的备选节点人数与可投票的备选节点总人数的比；
- 备选节点参与率：投票备选节点人数与总可投票备选节点人数的比值;
当同时满足：备选节点支持率>M%，备选节点参与率>N%时，该提案投票通过，否则该提案投票未通过。
不同类型提案对应的支持率和参与率如下:
| 类型 | 参与率 | 支持率 |
|---|---|---|
| 文本提案 | >50% | >=66.7% |
| 取消提案 | >50% | >=66.7% |
| 参数提案 | >50% | >=66.7% |
| 升级提案 | =100% | >=66.7% |
升级机制
升级机制是网络能够不断迭代完善的保证。对于区块链系统运行过程中可能出现的不同情况，我们应该提供有针对性的升级方式，主要有以下四种情况：
- 优化升级：此类升级是对当前链版本的功能优化。各节点可以根据情况决定是否升级，无论升级与否不会对共识造成影响。
- 投票升级：此类别的升级为添加了新功能，或者对补丁进行修复后影响到共识机制。该升级需要在链上发起软件升级提案，通过投票结果来决定是否实施升级，在不中断网络的情况下完成平滑升级。后面会重点讲解。
- 修复升级：当节点因版本低或者异常交易导致不能正常参与共识时，备选节点可以通过安装新版本软件来恢复参与网络共识。
- 快照升级：当区块链系统遇到重大异常，导致整条链无法正常出块时，可基于之前的正常网络状态生成快照，然后基于该快照恢复网络。
下面我们将重点说明链上投票升级机制。
链上投票升级
软件升级提案对应的升级包由开发者提供，该升级包必须兼容当前链版本，备选节点在升级本地节点之后即可参与投票。
1) 发起升级提案
升级提案只能由备选节点发起，发起时需要支付一笔高于普通交易的提案手续费，软件升级提案参数中需要提供以下参数：
- 升级的目的版本号。版本号有三位数字组成，如1.2.0，升级目的版本号前两位需大于当前链版本号前两位。
- github对升级信息的描述的文件的ID，即PIP-ID。该ID必须唯一
- 升级提案投票的共识轮数N。该参数将用来计算投票截止块高，即在当前共识轮开始第N个共识轮的第230个块截止投票。
链上只能存在一个处理中的软件升级提案，即当链上已经存在处于投票中的软件升级提案或参数提案时，不能再发起另外一个软件升级提案。此时遇到特殊原因或者紧急情况，需要立即发起一个新的软件升级提案，则可以发起一个取消提案来取消该软件升级提案。
取消提案说明： 只有当链上存在正在投票中的升级提案时，才能发起取消提案。取消提案的交易需要有以下参数，
- 被取消的升级提案交易hash
- github对升级信息的描述的文件的ID，即PIP-ID。该ID必须唯一
- 取消提案投票的共识轮数。由该参数计算出来的投票截止块高不能超过被取消的升级提案投票截止块高
2) 升级提案投票
软件升级提案发起成功之后，则进入投票阶段。只能由备选节点参与投票，即投票交易只能由节点质押账户发起，投票前需升级本地节点，以一人一票的方式计票。
我们对于软件升级提案的投票交易中并未设置"支持"、“反对”、"弃权"的投票选项，而是通过节点行为来表达自己的立场，如下：
- 支持者：可将本地节点版本更新到提案升级中的版本后，对升级提案发起投票；
- 中立者：可以选择升级节点，但不投票，而发起版本声明交易来声明本节点已经升级，这样不论该提案通过与否都可以正常参与共识；
- 反对者：则无需升级本地节点，无需投票。
升级提案投票交易需要提供以下参数：
- 发起提案交易的Hash
- 节点的真实版本号。该版本号需要和投票中的升级目的版本号一致，才能投票成功。
- 节点签名。该签名是节点私钥对节点版本号的签名。
投票期间虽然节点已经升级，但是当前运行的逻辑还是旧版本的逻辑。等到实施完成后才会切换到新版本的逻辑。
3) 升级提案投票结果统计
若投票支持率>=66.7%，则提案投票通过，进入实施阶段。
4) 升级提案实施
由于VRF选取备选节点具有随机性，且为了不影响共识，因此我们在实施升级时，需要保证某一个共识轮中的验证节点都是已经升级的节点。
因此，在提案投票截止块高时，该提案的支持率达到66.7%，则在下一个共识轮第一个块开始实施升级，且不再选择未升级的节点参与共识。在当前结算周期中，被淘汰的未升级节点只是不会被VRF选中参与共识,但仍然享受当前结算周期的质押收益。
5) 版本声明
由于不同版本之间可能存在数据不兼容的情况，为避免因版本问题造成共识失败，对链上的节点版本应该进行控制，因此，我们引入了版本声明。节点通过发起版本声明来表明自己节点版本和当前链版本或软件升级提案投票中的目的版本号一致，才能有机会在升级前后正常参与共识。
只有候选节点和验证节点才可以发起版本声明。新加入的节点需要先成为候选人后才能发起版本声明。各个阶段版本声明条件如下：
当节点版本和链上版本不一致（版本号前两位不同）时，该节点不会被选入参与共识，即使质押很高，此时节点可以通过发起版本声明交易来声明自己节点与链版本一致，才能在后续结算周期中正常参与共识。当链上存在正在投票中的软件升级提案时，可以发起和升级版本一致的版本声明，版本声明不代表投票，在升级提案投票通过后，声明了与升级目的版本号一致的节点即使没有投票也可以正常参与共识。
快速升级
在链上发起升级投票本是一件严肃的事情，理论上不应该存在撤销提案的可能，所有的结果都应该交给备选节点投票决定。但我们的只允许链上存在一个投票中的软件升级提案，因此当出现紧急情况时需要快速升级时，若链上存在未处理完成的提案，会直接影响紧急情况的处理速度。由此我们引入取消提案，该提案由备选节点发起，投票周期可自行确定，但必须在被取消提案投票周期内。通过发起取消提案和各节点的快速响应，即可在短时间取消正在投票中的软件升级提案，从而快速实施紧急方案。只有当链上存在正在投票中的升级提案时，才能发起取消提案。取消提案一旦发起则必须执行，因此我们提倡只在紧急情况使用取消提案。
取消提案的交易需要有以下参数：
- 被取消的升级提案交易hash
- github对升级信息的描述的文件的ID，即PIP-ID。该ID必须唯一。
- 取消提案投票的共识轮数。（由该参数计算出来的投票截止块高不能超过被取消的升级提案投票截止块高）
参数治理
备选节点可以通过发起参数治理提案来修改部分系统参数。为避免参数提案和升级提案交叉实施引发问题，因此，当链上存在投票中的升级提案或者参数提案，不允许在发起新的参数修改提案。
参数提案投票周期为两周。截止当前，我们支持的治理参数如下：
- slashing模块
| Key | 描述 | 范围 |
|---|---|---|
| slashBlocksReward | 出块率为0，削减的区块奖励块数 | [0, 50000] blocks |
| slashFractionDuplicateSign | 双签举报处罚节点自有质押金比例 | (0,10000] ‱ |
| duplicateSignReportReward | 举报人可获得处罚金的奖励比例 | (0, 80] % |
| maxEvidenceAge | 双签举报证据有效的结算周期数 | (0, 节点质押退回锁定周期）Epoch |
- block模块
| Key | 描述 | 范围 |
|---|---|---|
| MaxBlockGasLimit | 区块最大Gas | [4712388, 210000000] gas |
- staking模块
| Key | 描述 | 范围 |
|---|---|---|
| stakeThreshold | 成为备选节点候选人最低的质押Token数 | [100W,1000w] LAT |
| operatingThreshold | 委托人每次委托及赎回的最低Token数 | [10, 10000] LAT |
| unStakeFreezeDuration | 节点质押退回锁定周期 | (证据有效期,112] Epoch |
| maxValidators | 备选节点数量 | [25, 201] |