干六年区块链运维，打过的补丁没有一千也有八百，其中一大半事后看都是垃圾——改个变量名、补条日志、塞个临时判断就上了链。今天把垃圾补丁的实操讲清楚，少踩坑。
垃圾补丁怎么部署
大家说的垃圾补丁最大的问题, 不是说代码写得太烂, 而是你无法确定它是否会引发共识层面的分歧。我通常采取的办法，是先把全量测试在本地环境里跑一遍, 用相同版本的客户端程序, 从发生分叉的那个地方开始重新播放历史数据, 在确认最终的状态根没有发生改变的条件下, 才把它推送到线上平台去操作。
千万要抱着不要为了求快的心理而直接把热修复代码发布到生产环境中, 因为分布在链路上的那些节点是不会给你留下第二次检查或者确认的时间窗口的。
另外还有一条规定是, 如果一个变更的数值差异超过了二十行, 就不应该把它当作普通的垃圾补丁来看待, 而是需要按照治理流程去执行。
我曾经遇到过这样一种情况, 有人把六十行的逻辑塞到了共识层里面, 并且标记为临时修复的意思, 结果三个月过去了, 根本没有人清楚这六十行代码是用来做什么的, 这导致了整个团队在代码方面的信任度直接降到了零这个水平。
垃圾补丁能回滚吗
回滚这件事情到底能不能做到, 完全得看你修改的具体代码是落在P2P层上面呢还是说落在了共识层上面去。针对P2P层里弄出的那些类似垃圾补丁一样的东西, 你只需要发布一个新的版本出来, 然后让所有的节点去执行热重载的操作就可以了, 整个过程非常快, 大概在十分钟的时间段之内整个网络就能全部切换完成。
可是你要是碰了共识层的代码的话, 哪怕就是一个最微小的字节发生了变动, 你想要进行回滚操作的话, 其实际含义就是你必须去说服所有的那些验证者强行使他们在同一时间都切回到旧版本的系统上去, 而这样做的协调成本是会以指数级的幅度急速往上涨的。
根据我的经验来看, 共识层这个地方是永远都不会去做那些所谓的垃圾补丁的。如果真正出问题了的话, 发放硬分叉这件事情其实会比进行回滚操作要来得更加靠谱一些。
因为在区块链上进行回滚这个动作, 它并不是简单意义上的退一步, 而是要让所有的节点重新去对齐到之前的那个旧的状态上面。在这个处理的过程中间, 只要有任何一个验证者发生了卡顿这种情况, 那就肯定会被算作是一场事故发生。
这个垃圾补丁它本身是不存在所谓的正确用法的, 它所能够提供的只有那种把伤害降到最低的一种做法。在能不打的情况下就不要去打击它, 但是如果是非得要打上它的话, 那就要把那套叫做回滚预案的东西写进那个叫PR描述的文档里面去, 千万不要等到出事了以后再去翻看那些代码。
