SIP 作为特性开关

动机

区块链上的协议如果需要升级，并且无法与旧的版本兼容，也是大家常说的『硬分叉』升级，通常的做法是通过高度设置一个特性开关(feature flag)，约定好在某个高度激活该升级。但这种方式面临几个挑战：

代码要合并进主分支的时候，就需要确定一个激活的高度，如果社区对是否支持该特性，以及激活时间不能达成一致，则会导致该特性的代码一直不能合并进入主代码分支，无法进入版本发布流程。
代码合并进入主分支并发布版本后，到激活高度这段时间，是留给矿工（或者验证者）的"投票"时间，矿工通过是否升级来进行投票。如果大多数算力的矿工决定不升级，则会导致链分叉为两条。

按照 Starcoin 白皮书中的治理设计原则『技术创造可能，社区决定取舍』，我们对链上的协议升级做出了改进，通过链上的特性开关机制和 DAO 来实现不兼容性协议升级。

定义一个链上的 SIP module，并提供判断方法来检测该 Module 是否存在，如果存在则认为改 SIP 已经激活。对 Feature Flag 的投票按照 stdlib 升级流程即可。

address 0x1{
module SIP_2{
}

module SIP_2{
}

}

在链的代码框架中提供简便的方法来根据链的状态判断某个 SIP 是否激活。

trait StateReader {

    is_activated(sip: SIP): bool;

}

用户或者社区开发者提出需要升级的特性需求，并提交 SIP 提案。
核心开发者从技术角度评估该 SIP 并决定是否接受。
接受的 SIP 进入开发流程，开发测试完成后，需要合并到主代码分支的时候，核心开发者只需要通过以下角度进行评估：
- 实现的特性是否和 SIP 的目标相符。
- 新的逻辑是否被特性开关控制，是否会影响旧的逻辑。
- 是否满足技术性指标：比如性能，可维护性等。
合并之后，新的版本中就会携带该特性的逻辑，但处于未激活状态，矿工正常升级即可。
发起一次 stdlib 升级提案，该 stdlib 的版本中定义新的 SIP 的 flag Module, 呼吁社区进行投票，决定是否激活改特性，以及激活的时间。
投票通过，升级 stdlib， flag Module 写入链上，特性开关生效，全网启用新特性。
投票未通过，该特性将一直处于未激活状态，等待必要的时候清理。

加速功能以及版本的迭代速度，让争议后置处理。实现『技术创造可能，社区决定取舍』的目标。