参与过多个联盟链落地项目的实施之后, 我就更加确信, 好多的人对联盟链的理解程度, 其实还是停滞在了那种认为只要把共识机制替换成PBFT这个层面的阶段里头。实际情况, 它的选型工作远比这种简单的认知要复杂得多, 像是什么共识方面, 架构方面，还有性能方面, 每一个环节里面都是有坑存在的。
联盟链共识算法怎么选
目前的共识算法可以说有十几种之多, 其中包括了PBFT、Raft和HotStuff等选择。然而当真正需要进行方案选型的时候, 大部分项目往往最终还是会回到PBFT或者Raft这两个选项上来。
这并不是说它们是唯一最优的架构, 而是因为在实际工程中, 这两个算法拥有更为成熟的生态基础以及足够丰富的缺陷排查经验支撑。
我曾亲眼目睹过一个供应链管理类的具体项目例子, 该项目在技术决策上执念于使用自主研发的BFT算法变种, 原本在测试环境里的运转状态看起来都非常良好无异常, 可是一旦部署到生产环境且节点数量增加时, 大量的网络消息突然爆发形成了流量风暴, 这种状况直接导致系统的网络带宽被彻底占满, 从而引发了严重的问题。
在进行选型工作的时候, 千万不要只是盯着理论上的吞吐量去看, 而是需要先把那些关于节点数和网络延迟以及故障容忍度等方面的因素给算得清清楚楚。毕竟, 50个节点和500个节点这两者在选择方法上面的情况是截然不同的。
联盟链性能瓶颈在哪
那些说性能不够的项目, 瓶颈多半不在共识层。真正卡住的是验签和存储。一笔交易要过十几个节点验签。每个节点都要查链上历史状态。IO压力远比计算大。
我感觉到一个比较有用的方法就是, 把那些热数据放到本地的缓存里面去, 然后让那些冷数据走对象存储的途径, 而链上这边只存储哈希值这样一操作, 冗余读取这个东西就被省掉了，之后TPS就能提升到原来的两倍或者三倍那么一点的程度, 成本的开销也能够得到降低。
在构建联盟链这一行业中, 技术层面的突破并不是最为艰巨的挑战, 真正意义上的难点在于能够将业务逻辑与区块链的运作边界梳理得清清楚楚。倘若这些边界没有被妥善且清晰地划分开来, 那么即便是实施了再多的优化措施, 最终的结果也将是一无所获, 完全没有实际意义。
