实际上, 在很多的团队刚刚去触碰分布式账本这个概念的时候, 他们往往只是把目光紧紧地盯着透明化以及高效率这两个方面, 可是他们却完全忽略了代码成功部署到系统之中以后,想要进行回滚操作会变得非常困难这一种现实状况。
毕竟商业环境一直都是处于多变的状态之中的, 如果整个系统非要死守着某一种路径不放, 那么就会必然会导致系统在后期进行维护的时候, 其产生出来的成本会呈直线状地大幅飙升上去。
怎么应对区块链的不可控不灵活性
智能合约把规则写死了之后, 法务那边只要对条款进行稍微的调整, 整个程序就得重新发布新版本, 这种将特性硬编码的做法让业务部门变得非常被动, 有不少项目就因为需要对合同里的细节进行修改, 而导致节点网络直接处于停滞不前的状态。
资金流转断档只是表面现象, 真正的根源在于整体架构缺乏弹性, 对应的办法就是要提前规划好接口层设计, 把核心共识逻辑放在链下处理, 而在链上只保留存证与结算功能就可以了。
怎样规避区块链的不可控不灵活性
治理这块机制, 它得跟着那个部署的脚步走才行。你要知道, 如果是那种纯靠社区里的人去投票的话, 非常容易产生内部消耗, 所以那些用在企业级别的业务场景里面的项目, 必须在一开始就把权限的分级给设定好了。
关键参数的修改权利一定要收回到核心团队手里, 这样做是为了避免因为大家意见不一而导致工作停摆没有办法进行。如果使用的是混合云服务架构的话, 那么就能解决大多数那些死板难处理的问题。
比较敏感的信息要放在私有的链上去存储, 而面向大家的公开互动内容则要走联盟链的通道。要先让最小的一个业务闭环能够顺利跑通, 然后再考虑扩大规模的事情。
大家需要先把技术的边界给看清楚, 然后利用柔性的管理方式去弥补刚性体系里的那些不足的部分, 这样项目才可以在平稳的状态下面一步一步地去实现落地。
