目前PlatON&Alaya的版本升级（这里是指需要分叉的升级）的一般流程是：
- 首先社区讨论，形成初步共识。
- 链上发起对此议题的文本提案，并投票。
- 如果投票通过，则进入开发
- 开发完成后，还需要在社区讨论，决定什么时间提议升级提案（此时并不能确定具体升级区块高度，只能是大概）
- 提案节点在链上发起升级提案，此提案打包上链后，具体的投票截止块高，升级块高也将确定（如果此提案投票通过）
- 想投票的节点，首先完成本地版本升级，并对升级提案投票
- 投票截止块高统计投票数，如果通过，则通票的节点将在确定的块高开始分叉；而本地虽然升级了客户端代码、但是没有投票，或者没有升级客户端代码的节点，将继续链的原有逻辑。
- 在分叉后，如果没有升级的节点，想重新加入新版本链，则可以通过升级本地客户端代码，然后发起版本声明操作交易，此后该节点将加入新链。
这个流程的特点：
- 链上处于投票期、待生效期的版本升级提案，只能有一个。
- 升级提案投票后，如果通过，则意味着必须分叉。
- 新版本生效后，未升级的（未投票，也未声明新版本）节点，将被踢出新链。也就是说，节点能否成为候选备选节点，备选节点，出块节点，是和版本相关的。
- 版本升级提案消耗的gas, gas price是确定的，目前是固定值，设置的比较高，防止节点随意提议版本升级，从而造成其它节点被踢出）。
而目前一些其它的版本升级方案的流程是：
- 首先社区讨论，形成初步共识。
- 开发
- 社区讨论，确定升级块高，修改最终代码，内置分叉区块高度
- 节点完成客户端升级
- 到指定区块，完成分叉
这个流程的特点：
- 治理提案，和实际升级分叉，可以分离。即使升级提案通过，确定要升级分叉，但是在真的实施升级分叉前，都还是可以取消的
- 提案可以多个，提案费用可以比较低，不用担心通过提案作恶
- 节点升级简单，只要升级客户端代码即可
PlatON&Alaya的版本管理是通过结合治理的方式来实现，也就是线下对版本实现，然后线上发起版本升级提案，由节点们一起来投票完成线上版本的升级，线上版本升级通过后线下版本就开始自动应用了。这对整个版本的规划来讲，线上和线下可以保证完全一致，并且也是符合去中性化的特性，由社区共同参与整个版本的治理升级。
但是这样又带来几个问题：
- 强耦合：线下是版本规划，而线上治理的规划只是做线上版本号的变更，这两个步骤的强关联，也导致治理模块和Staking高度耦合，而且Staking模块中很多功能都完全依赖线上的版本号，整体复杂度很高。
- 升级提案的定价：因为版本升级是通过发送升级提案的交易来启动，所以整个生态体系中的任何人都可以发起版本升级，而版本的规划对系统来说是至关重要的，所以升级提案只能串行处理，只能同时存在一个升级提案，而且升级提案需要持续一段时间来接受投票，又因为所有人都能发起升级提案，所以就需要提高发起的成本，避免恶意的提案的占位影响正常提案的发起，但是随着链的发展、市场价格的上升，发起成本水涨船高，这对提案人来说发起提案的成本已经无法接受，整个提案的积极性也将备受影响。
讨论
有两个想法，从不同角度去改善目前版本升级所存在的不足点：
-
版本升级方式的变更： 把线上线下区分开，线上版本提案改为"功能改进、协议改进和投票的作用"，专门针对方案的提议和投票，并且支持并行提案。而线下，根据有效提议通过的方案进行开发实现，利用符合区块链特征的方式进行升级，也就是在指定区块高度将新版本规划的内容应用到链上。
这样区分各模块职能，降低整体复杂度，但同样由于现在整个系统的庞大，其中很多涉及到版本治理升级相关的联系，包括质押的节点信息中也包含了版本号，节点的选取也会依赖版本号等等，所以该方案的实现也会带来极大的复杂度。
-
发起升级的定价方案： 考虑到市场价格的变化，导致发起版本升级成本的不确定性，所以，考虑从成本上动态调整，例如：将提案价格改成治理参数形式，或者其它更好方案？