关于版本升级提案的改进方案

目前PlatON&Alaya的版本升级(这里是指需要分叉的升级)的一般流程是:

  1. 首先社区讨论,形成初步共识。
  2. 链上发起对此议题的文本提案,并投票。
  3. 如果投票通过,则进入开发
  4. 开发完成后,还需要在社区讨论,决定什么时间提议升级提案(此时并不能确定具体升级区块高度,只能是大概)
  5. 提案节点在链上发起升级提案,此提案打包上链后,具体的投票截止块高,升级块高也将确定(如果此提案投票通过)
  6. 想投票的节点,首先完成本地版本升级,并对升级提案投票
  7. 投票截止块高统计投票数,如果通过,则通票的节点将在确定的块高开始分叉;而本地虽然升级了客户端代码、但是没有投票,或者没有升级客户端代码的节点,将继续链的原有逻辑。
  8. 在分叉后,如果没有升级的节点,想重新加入新版本链,则可以通过升级本地客户端代码,然后发起版本声明操作交易,此后该节点将加入新链。

这个流程的特点:

  1. 链上处于投票期、待生效期的版本升级提案,只能有一个。
  2. 升级提案投票后,如果通过,则意味着必须分叉。
  3. 新版本生效后,未升级的(未投票,也未声明新版本)节点,将被踢出新链。也就是说,节点能否成为候选备选节点,备选节点,出块节点,是和版本相关的。
  4. 版本升级提案消耗的gas, gas price是确定的,目前是固定值,设置的比较高,防止节点随意提议版本升级,从而造成其它节点被踢出)。

而目前一些其它的版本升级方案的流程是:

  1. 首先社区讨论,形成初步共识。
  2. 开发
  3. 社区讨论,确定升级块高,修改最终代码,内置分叉区块高度
  4. 节点完成客户端升级
  5. 到指定区块,完成分叉

这个流程的特点:

  1. 治理提案,和实际升级分叉,可以分离。即使升级提案通过,确定要升级分叉,但是在真的实施升级分叉前,都还是可以取消的
  2. 提案可以多个,提案费用可以比较低,不用担心通过提案作恶
  3. 节点升级简单,只要升级客户端代码即可

PlatON&Alaya的版本管理是通过结合治理的方式来实现,也就是线下对版本实现,然后线上发起版本升级提案,由节点们一起来投票完成线上版本的升级,线上版本升级通过后线下版本就开始自动应用了。这对整个版本的规划来讲,线上和线下可以保证完全一致,并且也是符合去中性化的特性,由社区共同参与整个版本的治理升级。

但是这样又带来几个问题:

  • 强耦合:线下是版本规划,而线上治理的规划只是做线上版本号的变更,这两个步骤的强关联,也导致治理模块和Staking高度耦合,而且Staking模块中很多功能都完全依赖线上的版本号,整体复杂度很高。
  • 升级提案的定价:因为版本升级是通过发送升级提案的交易来启动,所以整个生态体系中的任何人都可以发起版本升级,而版本的规划对系统来说是至关重要的,所以升级提案只能串行处理,只能同时存在一个升级提案,而且升级提案需要持续一段时间来接受投票,又因为所有人都能发起升级提案,所以就需要提高发起的成本,避免恶意的提案的占位影响正常提案的发起,但是随着链的发展、市场价格的上升,发起成本水涨船高,这对提案人来说发起提案的成本已经无法接受,整个提案的积极性也将备受影响。

讨论

有两个想法,从不同角度去改善目前版本升级所存在的不足点:

  • 版本升级方式的变更: 把线上线下区分开,线上版本提案改为"功能改进、协议改进和投票的作用",专门针对方案的提议和投票,并且支持并行提案。而线下,根据有效提议通过的方案进行开发实现,利用符合区块链特征的方式进行升级,也就是在指定区块高度将新版本规划的内容应用到链上。

    这样区分各模块职能,降低整体复杂度,但同样由于现在整个系统的庞大,其中很多涉及到版本治理升级相关的联系,包括质押的节点信息中也包含了版本号,节点的选取也会依赖版本号等等,所以该方案的实现也会带来极大的复杂度。

  • 发起升级的定价方案: 考虑到市场价格的变化,导致发起版本升级成本的不确定性,所以,考虑从成本上动态调整,例如:将提案价格改成治理参数形式,或者其它更好方案?

3 个赞

以上是对目前治理版本升级改进方案的初步提议,也欢迎各位能者献计献策,一同探讨

总的来说,目前PlatON/Alaya采取的治理方式,比较复杂,也有些约束,比如不能同时有多个提案。对于需要紧急处理的提案,不够灵活。另外提案的费用是固定的,目的是让捣乱的成本足够高,但是随着PlatON/Alaya的发展,这个固定费用是否足够,也是个问题。

因此,集思广益,看看社区能否为治理提供些新思路?

1 个赞

固定开销,让捣乱的提案发起者成本足够高, 也会让合理改进提案发起者要付出同样的代价, 这势必限制了发起合理提案的积极性。
以其他的方式,即不需要付出成本,又能抑制恶意的提案确实不太好实现, 一个可以解决问题的方案是给提案发起人设定一个“白名单”, 但这个白名单怎么维护? 会不会导致中心化? 现在还不是太清楚。

看看大家有什么更好的建议呢?