治理机制

概述

区块链治理机制是指区块链生态中利益相关者对决策达成一致的一套决策规则和行动标准。其目的是让去中心化的网络随着时间的推移能不断迭代发展。在区块链中，一些重要的技术，如共识机制、扩展性、安全性等，都可通过治理机制提供合理的激励方式得到更好的解决。完整的区块链治理机制应该是区块链技术、经济学和政治学的结合产物，包含权利分配、经济激励和技术实现。区块链的生态结构由开发者、矿工和用户构成，治理中各个角色需要发挥各自的价值，承担相应责任并获得对应的收益。治理的意义在于减少社区分裂和混乱的发生，帮助社区提高项目更新迭代效率，提高社区成员参与的积极性。

治理现状分析

目前治理从大的模式上分为链下治理和链上治理。链下治理由核心开发者控制，节点通过安装软件来发出决定信号，将全部责任交给那些运行完整节点的人，灵活性较高，但需要更高的社会协调成本，且缺乏合理的激励机制，限制了新开发者的加入。而链上管理有一套明确的治理流程，通过链上提案投票机制的形式强制升级，将决策权交给利益相关者。

链下治理的代表公链如比特币和以太坊，其协议的升级主要是由核心开发者进行运营，普通矿工和用户群体选择权利缺失，因此参与度低，公民基础薄弱。意识到链下治理的缺点，一些公链开始纷纷推出自己的链上治理机制，将社区的决策数字化，大大降低了利益相关者的协调成本。链上治理机制常见的权利分配方式往往是直接民主和间接民主的选择与平衡。

直接民主是由持币者直接参与制定规则，采用一代币一票的方式，去中心化程度较高，如Decred和Tezos等。在直接民主中往往存在投票率、专业性、代币集中等问题。而间接民主即代议制，通过不同方式选出代表人，依靠代表人行使权利，如EOS超级节点、Polkadot中的理事会和DFINITY中的“跟随投票”机制等。间接民主需要考虑到治理结构的设计、权利分配和激励等问题。

PlatON治理机制

在我们看来，决策权应属于“利益相关者”，即权利属于人民。但进行全民公投需考虑到实施成本以及投票率、专业性、治理效率等问题，因此公投不应该是治理常态，更应该是重大分歧情况下的治理方式。在我们的PPoS设计中，其备选节点的产生本身就是一种选举，且节点的利益和公链生态的兴衰息息相关，理应承担更多的治理责任，拥有更多的治理权利。因此，在PlatON治理中，我们采用了直接民主和间接民主结合的模式，其核心原则是：常态下由备选节点投票治理，即间接民主；重大分歧下由社区公开投票治理，即直接民主。

参与角色

• 备选节点 节点通过质押一定的Token成为候选人，其他用户可将自己的Token委托给候选人，系统根据候选人的总权益（质押+委托）进行排名，排名前201的候选人被选举成为备选节点。
• 持币人 所有Token代币持有者。
• 核心开发者 共同建设PlatON公链及社区的核心开发者。

权利分配

• 备选节点
  • 发起提案
  • 对公投提案投票
  • 对非公投提案投票
  • 对提案进行附议
• 持币人
  • 发起公投提案
  • 对公投提案投票
  • 对提案进行附议
• 开发者
  • github代码控制
  • 提案审核
  • 提案实现

提案分类

• 公投提案 公投提案的发生是在存在争议性比较大的场景下，任意持币人都可以发起公投提案，需要进行全民公投产生结果，场景如下：
  • 修改基本法
  • 进行重大的分叉，类似The Dao的分叉
  • 终止链的运行
• 非公投提案 非公投提案即普通提案，由备选节点投票产生结果，提案类型可分为以下类型：
  • 文本提案：对于无需实施的决策都可以用文本提案发起
  • 软件升级提案：用来在链上发起升级投票，达到平滑升级的目的
  • 参数修改提案：用来对系统参数等可治理的参数进行修改
  • 账户提案： 用来冻结或解冻账户（包括合约）
  • 激励提案： 用来分配治理基金账户余额
  • 取消提案： 用来取消链上正在投票中的软件升级提案

治理流程

1) 发起提案

公投提案可以由任何人发起，非公投提案由备选节点发起。每个提案都应该有与之对应的文本说明，该文本说明存储于github上的PIP仓库，由核心开发者管理，类似EIP。

为控制垃圾提案，所有类型的提案的发起都需要支付一笔提案手续费，作为提案的成本。

2) 提案筛选

• 公投提案：由于公投提案并非是常态，因此链上可以同时发起多个公投提案，这些提案将根据保证金从高到低进行排序，每个月选择出保证金最高的提案进入投票阶段。
• 非公投提案：发起提案成功即进入投票期，可多提案并行投票。

3) 提案投票

• 公投提案公投提案的核心的权益投票。投票将持续两周，有三种投票选项，分别为：“支持”、“反对”和“弃权”。只有参与质押和委托的代币才能进行投票。投票形式采用“备选节点代投+个人投票覆盖”的模式。即：备选节点投票权重是自有质押代币和接受委托代币数量之和，若委托人与该备选节点持不同意见，则该委托人可自行投票，其投票权重为委托数量，该权重对应的投票选项将被覆盖。所有的投票将会锁定代币到投票结束。为缓解由于多数代币被少数节点控制而导致的投票中心化问题，参与投票的备选节点数量应该足够多，若多数备选节点不同意或没有参与投票，该提案仍然不会通过。
• 非公投提案非公投提案的投票的核心是备选节点投票。只要是在该提案投票周期内当选成为备选节点的节点都能进行投票。投票周期一般为两周，软件升级提案的投票周期可根据情况由提案发起人决定。投票形式采用备选节点一人一票制度，投票后将锁定备选节点自有质押代币到投票结束。除软件升级提案外，其他类型的投票有三种投票选项，分别为：“是”、“否”、“弃权”。为了简化投票流程，软件升级提案没有显性的选项选择，各备选节点可通过是否升级本地节点来表明自己的投票立场，具体可以参考升级机制。

4) 投票结果计算

• 公投提案： 公投提案结果计算维度有以下三个:
  • 备选节点支持率：投票支持的备选节点人数与可投票的备选节点总人数的比值
  • Token支持率：支持的Token数量与总参与投票的Token数量的比值
  • Token参与率：总参与投票的Token数量与总质押的Token数量的比值
  当同时满足：备选节点支持率>P%，Token支持率>Q%且Token参与率>K%时，该提案投票通过，否则该提案投票未通过。
• 非公投提案：非公投提案的计算维度有以下两个；
  • 备选节点支持率：投票支持的备选节点人数与可投票的备选节点总人数的比
  • 备选节点参与率：投票备选节点人数与总可投票备选节点人数的比值
  当同时满足：备选节点支持率>M%，备选节点参与率>N%时，该提案投票通过，否则该提案投票未通过。不同类型提案对应的支持率和参与率如下:

升级机制

升级机制是网络能够不断迭代完善的保证。对于区块链系统运行过程中可能出现的不同情况，我们应该提供有针对性的升级方式，主要有以下四种情况：

• 优化升级：此类升级是对当前链版本的功能优化。各节点可以根据情况决定是否升级，无论升级与否不会对共识造成影响。
• 投票升级：此类别的升级为添加了新功能，或者对补丁进行修复后影响到共识机制。该升级需要在链上发起软件升级提案，通过投票结果来决定是否实施升级，在不中断网络的情况下完成平滑升级。后面会重点讲解。
• 修复升级：当节点因版本低或者异常交易导致不能正常参与共识时，备选节点可以通过安装新版本软件来恢复参与网络共识。
• 快照升级：当区块链系统遇到重大异常，导致整条链无法正常出块时，可基于之前的正常网络状态生成快照，然后基于该快照恢复网络。

下面我们将重点说明链上投票升级机制。

1) 发起升级提案

升级提案只能由备选节点发起，发起时需要支付一笔高于普通交易的提案手续费，软件升级提案参数中需要提供以下参数：

• 升级的目的版本号。版本号有三位数字组成，如1.2.0，升级目的版本号前两位需大于当前链版本号前两位。
• github对升级信息的描述的文件的ID，即PIP-ID。该ID必须唯一
• 升级提案投票的共识轮数N。该参数将用来计算投票截止块高，即在当前共识轮开始第N个共识轮的第230个块截止投票。

链上只能存在一个处理中的软件升级提案，即当链上已经存在处于投票中的软件升级提案或参数提案时，不能再发起另外一个软件升级提案。此时遇到特殊原因或者紧急情况，需要立即发起一个新的软件升级提案，则可以发起一个取消提案来取消该软件升级提案。

取消提案说明： 只有当链上存在正在投票中的升级提案时，才能发起取消提案。取消提案的交易需要有以下参数，

• 被取消的升级提案交易hash
• github对升级信息的描述的文件的ID，即PIP-ID。该ID必须唯一
• 取消提案投票的共识轮数。由该参数计算出来的投票截止块高不能超过被取消的升级提案投票截止块高

2) 升级提案投票

软件升级提案发起成功之后，则进入投票阶段。只能由备选节点参与投票，即投票交易只能由节点质押账户发起，投票前需升级本地节点，以一人一票的方式计票。

我们对于软件升级提案的投票交易中并未设置”支持”、”反对”、”弃权”的投票选项，而是通过节点行为来表达自己的立场，如下：

• 支持者：可将本地节点版本更新到提案升级中的版本后，对升级提案发起投票；
• 中立者：可以选择升级节点，但不投票，而发起版本声明交易来声明本节点已经升级，这样不论该提案通过与否都可以正常参与共识；
• 反对者：则无需升级本地节点，无需投票。

升级提案投票交易需要提供以下参数：

• 发起提案交易的Hash
• 节点的真实版本号。该版本号需要和投票中的升级目的版本号一致，才能投票成功。
• 节点签名。该签名是节点私钥对节点版本号的签名。

投票期间虽然节点已经升级，但是当前运行的逻辑还是旧版本的逻辑。等到实施完成后才会切换到新版本的逻辑。

3) 升级提案投票结果统计

在投票截止块高统计对升级提案的投票结果，若投票周期内投票情况如上图所示：

• 结算周期1内总备选节点数： P₁，备选节点发起升级投票数量为M₁
• 结算周期2内总备选节点数： P₂，备选节点发起升级投票数量为M₂
• 结算周期N内总备选节点数： P_n，备选节点发起升级投票数量为M_n

则最后支持率：

若SR≥66.7 ，则提案投票通过，进入实施阶段。

4) 升级提案实施

由于VRF选取备选节点具有随机性，且为了不影响共识，因此我们在实施升级时，需要保证某一个共识轮中的验证节点都是已经升级的节点。

因此，在提案投票截止块高时，该提案的支持率达到66.7%，则在下一个共识轮第一个块开始实施升级，且不再选择未升级的节点参与共识。在当前结算周期中，被淘汰的未升级节点只是不会被VRF选中参与共识,但仍然享受当前结算周期的质押收益。

5) 版本声明

由于不同版本之间可能存在数据不兼容的情况，为避免因版本问题造成共识失败，对链上的节点版本应该进行控制，因此，我们引入了版本声明。节点通过发起版本声明来表明自己节点版本和当前链版本或软件升级提案投票中的目的版本号一致，才能有机会在升级前后正常参与共识。

只有候选节点和验证节点才可以发起版本声明。新加入的节点需要先成为候选人后才能发起版本声明。各个阶段版本声明条件如下：

当节点版本和链上版本不一致（版本号前两位不同）时，该节点不会被选入参与共识，即使质押很高，此时节点可以通过发起版本声明交易来声明自己节点与链版本一致，才能在后续结算周期中正常参与共识。当链上存在正在投票中的软件升级提案时，可以发起和升级版本一致的版本声明，版本声明不代表投票，在升级提案投票通过后，声明了与升级目的版本号一致的节点即使没有投票也可以正常参与共识。

快速升级

在链上发起升级投票本是一件严肃的事情，理论上不应该存在撤销提案的可能，所有的结果都应该交给备选节点投票决定。但我们的只允许链上存在一个投票中的软件升级提案，因此当出现紧急情况时需要快速升级时，若链上存在未处理完成的提案，会直接影响紧急情况的处理速度。由此我们引入取消提案，该提案由备选节点发起，投票周期可自行确定，但必须在被取消提案投票周期内。通过发起取消提案和各节点的快速响应，即可在短时间取消正在投票中的软件升级提案，从而快速实施紧急方案。只有当链上存在正在投票中的升级提案时，才能发起取消提案。取消提案一旦发起则必须执行，因此我们提倡只在紧急情况使用取消提案。

取消提案的交易需要有以下参数：

• 被取消的升级提案交易hash
• github对升级信息的描述的文件的ID，即PIP-ID。该ID必须唯一。
• 取消提案投票的共识轮数。（由该参数计算出来的投票截止块高不能超过被取消的升级提案投票截止块高）

参数治理

备选节点可以通过发起参数治理提案来修改部分系统参数。为避免参数提案和升级提案交叉实施引发问题，因此，当链上存在投票中的升级提案或者参数提案，不允许在发起新的参数修改提案。 参数提案投票周期为两周。截止当前，我们支持的治理参数如下：

• staking模块

• slashing模块

• block模块

• reward

• restricting

奖惩机制

在设计治理机制时，需要有良好的制度来鼓励更多有兴趣、有能力的专业人士参与到治理中，同时也应该对恶意占用网络资源等行为进行惩罚。

奖励

• 提案奖励：提案奖励在提案投票通过后自动发放一定奖励到提案发起账户
• 投票奖励：投票后需要锁定代币到提案投票结束，因此投票奖励和投票锁定时间长度成正比，在提案投票结束时统一发放至各个投票账户
• 开发者奖励：开发者奖励需在链上发起提案，通过投票结果决定是否发放
• 漏洞悬赏：在确认漏洞真实存在后，需在链上发起提案，通过投票结果决定是否发放

惩罚

若不诚实的节点通过伪装版本而达到升级的目的，当链升级成功后，该备选节点被选择参与共识时，会由于出块不能被共识导致出块率低，从而受到系统的惩罚，严重者可直接取消验证节点资格。

治理基金

治理基金来源于基金会，每年从基金会的账户划拨固定比例的资金到治理账户，通过提案投票的方式分配治理账户余额，用于激励、薪酬分发。当提案投票通过后，通过多重签名方式自动下发。