区块链底层逻辑怎么做好：架构师踩坑后的几条硬经验

导读： 区块链底层的逻辑, 大家说简单点其实就归结为三件事情, 那就是共识机制到底选择得对不对, 系统扩展能力能不能稳稳地扛住压力安全底线有没有真正地兜牢。...

区块链底层的逻辑, 大家说简单点其实就归结为三件事情, 那就是共识机制到底选择得对不对, 系统扩展能力能不能稳稳地扛住压力安全底线有没有真正地兜牢。我自己花了整整七年的时间去搞公链协议的软件开发, 中间也掉进过不少的大坑里头, 今天就把这一些最核心的判断办法掰开揉碎了给大家讲明白。

区块链底层怎么设计

关于共识机制的问题, 并不是速度提升得越快就会越好。我曾经亲身参与过一条区块链项目, 当时团队把出块的间隔时间压缩到了五百毫秒, 结果导致拜占庭容错的全部防线瞬间崩溃, 分叉的发生率迅速飙升到了百分之十二。

在后来我们把出块的时间调整拉长到了三秒之后, 最终一致性的表现反而变得稳定了。所以对于共识参数的设定, 必须和网络实际拥有的节点数量相匹配, 千万不要把实验室里的数据直接放到线上环境中去使用。

存储层面的分片策略, 出问题的可能性比搞共识机制还要大。在最早的时候, 我们采用的是利用哈希算法来均衡地进行分片操作。

在系统上线运行了三个月之后热点账户全部扎堆到了一个分片上面, 导致每秒请求数直接被打满。后来我们将方案改为基于账户维度以及结合时间窗口来组成的复合键形式, 系统的负载才终于真正开始分散到各个节点上去。

区块链逻辑怎么落地

大家必须清楚地知道, 协议的设计工作虽然已经完成了, 但这并不代表它就可以直接投入使用了。根据我个人的观察和经验, 我见过有三支团队就是这样做的。

他们在他们的白皮书当中所宣传的概念是“模块化可组合”, 然而在他们实际编写的代码之中, 却把执行层和结算层强制性地绑定在了同一个进程里面, 这种操作方式导致了它们根本不具备独立进行升级的可能性。

因此, 对于底层的架构体系而言, 务必需要在项目开始的第一天就提前预留出了解耦的接口条件, 即便这样做会造成初期性能出现百分之五左右的下降也在所不惜。

测试这件事, 绝对不可以仅仅只去跑那种基准测试。在真正的网络环境下, 节点会出现掉线的情况, 还会出现网络分区的情况, 还有恶意分叉这样的情况。

对于以上这些场景, 一定要先在预发布的环境里, 通过混沌工程的方法去进行长期的压力测试, 必须要把时间足足地跑满七十二个小时以后, 才能允许上线进入到主网里去。

我们这里之所以强调这一点, 是因为曾经有一条区块链, 它在处于第四个星期进行灰度发布这个阶段的时候，就暴露出了关于状态回滚方面的一个竞争条件问题, 这个问题最后又花费了整整两个星期的时间才把它修复完毕并且让系统恢复到了稳定可用的状态。

只有把这几个环节全都真正地从头到尾走完一遍, 并且确认它们已经连通了, 这个最基础的核心原理才能够算是真正站稳了脚跟。