对升级流程优化的建议

首先恭喜PlatON再次线上升级成功!
在喜悦之后,个人感觉,升级成本还是有点大。
不论是对研发人员,编写的脚本,需要考虑各种各样的情况,哪怕是大牛,也肯定不轻松。
对于验证节点,对于不在共识中的节点还好,对于在共识中的,哪怕按照流程升级完成,心里也是提心掉胆。

社区也讨论过,官方考虑时间原因,会安排到后期来优化实现,个人表示理解。提几点个人意见,希望对以后的升级有帮助。

1、定时启动的工作,可以让platon来做,这样大家可以一起升级,在同一时间启动,降低误操作或者运行环境不同造成的错误,也可以减少节点的心里压力。
2、采用快照数据。当网络在某个高度出错时,可以适当回滚到一个数据比较正常的高度,以这个高度来启动网络。
3、启动的时候,是否可以考虑从新选共识节点,或者优先选定基金会的节点。网络启动的时候,可能会不稳定,这样选定网络中断时的共识节点为共识节点,感觉有点不公平
4、当网络中断或者重大升级,建议迭代测试网版本。

以上是根据自己的个人经验提的建议,欢迎大家多多指教。

7 Likes

后续的版本,我们对于零出块处罚进行优化以后,这样的升级应该会变得简单许多,期待下一个更好的版本尽快到来。

感谢你的建议!

2 Likes

感谢您的建议,我们仔细研究调整。

1 Like

:+1:感谢您的建议,我们即将进行零出块处罚进行优化方案的梳理噢,同时针对节点的AMA我们也在火热准备中,诚邀您的参与哈

1 Like

感谢您的建议,几点意见供大家参考:

  1. 在测试网阶段我们还是尽量尝试不同的升级方案
  2. 快照数据回滚的方案我们也有准备,合适的时间我们会进行演练,到时候希望大家配合
  3. 当前轮共识节点是在270个区块前就确定的,按照目前的设计是不能修改的,您的方案我们也会综合考虑一下
  4. 零出块处罚规则后续考虑做一定的修改,在保证安全性的基础上给与更多的容错性,后续升级就会方便很多
2 Likes

赞,期待快照数据回滚方案的演练:+1::+1:

期待,到时一定参加,向大佬们学习 :+1:

1 Like