我从事链上开发工作已经有七个年头了, 在这样的时间里, 我产生的感觉是越来越深了。这种复杂化的现象在区块链领域里面, 它并不仅仅是一种概念上的炒作行为。这个情况是一个实实在在的工程困境。
从架构到共识, 再到合约以及治理, 这些层次是在一层一层地堆叠起来的。理解这一套东西所需要的成本正在呈指数级的增长。一个新的人员想要上手做这个项目的话, 他所需要的周期时间是从原来的三个月变长了, 现在的起点变成了半年这么长。
区块链复杂化指什么
换句话说, 你要知道的是, 在2017年的时候, 写一个叫做ERC20的合约, 它往往只需要几十行代码就足以应对了。可是到了现在, 光是处理跨链桥里的那种验证逻辑部分, 就能让你写出两百多行的Solidity代码来。
这还不算完, 如果你把它和预言机功能组合在一起, 还加入多重签名的机制, 再加上对时序攻击这种问题的防护措施, 那么结果就是, 单独一个合约文件里的代码行数, 会非常轻松地超过一千行的大关。
对于当前情况而言, 具体的代码数量多少根本不算是什么大困难或者大问题, 真正能够把人逼到绝路的要害地方在于这样的现象: 每多添加一层抽象的结构, 出现Bug也就是产生程序错误的盲区死角区域就会相应地增多出一片来。
就在上个月的时候, 我参与了对一个去中心化金融项目的代码审计工作。在审查过程中发现问题非常严重那个项目里面竟然引用了多达十几种第三方依赖库, 情况复杂得令人头疼。
更为糟糕的是这些依赖库各自的升级方案根本完全无法配合彼此,导致操作流程极其困难。我一旦需要修改哪怕只有一行的核心代码逻辑都不得不同时去联动修改四处相关的调用点位。最终光是为了让系统回归正常运行状态而执行的测试环节就接连进行了整整两天的时间。
区块链复杂化怎么办
现在根本就没有能解决所有问题的银弹。我们目前采用的做法是让系统变成由不可变内核和可插拔策略层这两部分构成的样子。具体来说, 就是让内核只去负责共识逻辑和状态机的运转。
而对于策略相关的部分, 则采取让治理模块进行热更新的方式来处理这么做的好处在于, 它至少能够把一些高频次的变动给隔离开, 不让它们去干扰到底层的运行环境里。
这样一来, 一旦出现需要回滚的情况, 其所需的成本就仅仅是从一个单独的模块级别出发就可以了, 而再也不会像以前那样, 需要进行全链重新开始的代价了。
另外, 团队必须得安排专人负责盯着那个复杂度预算的事情。在每次提交合并请求之前, 需要先算清楚到底新增了哪些数量的状态变量以及外部调用情况。如果超过了规定的阈值, 就直接将需求打回去处理。这种做法的好处是, 避免了等到技术债务积累到一个无法收拾的程度时, 才不得不去面对和解决那些棘手的问题。
复杂化这回事它本身是不会消失的, 不过它是可以被进行管理的。去把每一层的边界给钉牢、然后去把变更的频率给压住, 这比那种盲目地堆砌功能要更加实在得多。
