（杨士弘）针对Fabric 0.6的几点技术改进...update-7.8

2017-05-27 FINTECH观点 区块链底层技术改良及难点攻克
2017-05-26 20:40 头条/转载 区块链底层技术改良及难点攻克
原文刊于 2017Q1 联动风采『基于fabric0.6 的技术改良及难点攻克』
作者：杨士弘，供职于联动优势科技有限公司

Fabric，全称 Hyperledger fabric，中文称“超级账本” ，它是以区块链技术为基础设计的去中心化底层架构。

在接触区块链时，我们是从以太坊开始研究学习的，后续还了解学习了比特币，小蚁，超级账本等区块链相关的项目。对于金融业务，因其对系统的稳定性，健壮性，处理性能以及应用的可扩展性等方面有很高的要求，通过从各方面对比，最终选择了超级账本作为项目的底层框架。在我们深入研究超级账本的过程中，发现其并不是一个完善的框架，还存在着很多问题。

Fabric 0.6整体架构图

上图为Fabric 0.6版的整体架构图，被标记部分是经过我们改良的模块，主要有以下几点：

1.改良共识通道及消息处理机制

在进行性能测试时，发现超级账本网络对高并发交易的处理能力存在瓶颈。

编者按：1. 一般网络规模不能超过16个节点。2. 采用LinuxOne服务器，TPS性能可达2000+笔/秒。3. 采用普通PC服务器机器，TPS性能约300笔/秒。

通过深入分析，发现在整个底层系统中存在多种不同类型的消息流，例如节点间用于广播交易的消息和共识的消息等，而每个节点处理这些消息流的管道却只有一个，这就好比一条高速路上只有一个检票口一样，检票口的处理能力直接影响到高速的堵车概率。而在系统中，由于消息处理管道很容易被阻塞，导致优先级高的消息因无法及时被处理而大量堆积，进而导致整个系统宕机。

通过分析，我们使用分流的方式来解决管道阻塞的问题（如上图）。

• 用单独的A号管道去处理优先级低但调用频率高的消息（如节点间广播消息），
• 而一些优先级高的消息（例如共识消息）则通过B号管道去处理。

当A号管道出现阻塞时，通过B号管道及时处理，可以逐渐消耗并恢复A号管道的能力。通过分流方式，保证各类消息能被及时处理，进而提高了系统的处理能力，也提升了系统的稳定性。

我们知道，最小的超级账本网络需要四个节点才能正常运行，所以这些节点之间的通信能力就成了影响该网络能力的一个重要因素。在测试中，我们也发现节点之间的各类通信都是通过一个通道进行处理的，当有大并发量的交易进入网络，节点之间大部分时间都在进行频繁的交易广播（将自己收到的交易信息发送给其他节点，以保障交易不被丢失），无法及时处理共识，这直接影响了该网络处理交易的能力，所以，我们通过使用双通道，将消息分开进行处理，使消息能够被及时处理，进一步提升系统的处理能力及稳定性。

2.内存溢出

通过前面的修改，我们的重点开始落在系统对交易处理的能力上，而这个现象就是在压力测试时出现的。当我们以400笔每秒的速度向底层写入数据时，随着数据量的增加，某个节点就会出现宕机的现象，并且无法恢复，影响了系统的健壮性。通过分析日志、代码，发现当系统重启时，会加载大量的已被存储的数据，这样使得大量的内存被消耗，没有资源去处理其他操作，使得系统宕机。

我们通过修改加载数据的逻辑，在保证对数据无影响的情况下，使系统快速恢复运行，提高了系统的健壮性。

3.视图异常

视图是共识中一个比较重要的概念，用于网络中各节点的共识，其主要包含共识过程中产生的所有信息及状态。在稳定性测试过程中，当长时间向超级账本系统中写入大量数据时，会出现网络中节点之间共识失败，无法记录交易的现象，通过跟踪分析输出日志，发现是由于各节点之间所存储的视图信息不一致而导致的。

修改代码逻辑之后，通过将视图阶段性标识（即每执行一定量的交易后记一个标识）和添加证书的方式来保证各节点所记录的视图信息的一致性，这样使得网络中各节点能够稳定运行，即使出现视图紊乱，也会很快达成一致，恢复正常。

4.交易处理异常

image.png

对于一个金融系统，最不能容忍的就是丢失交易或出现“双花”的现象，而超级账本存在丢交易和双花问题。

1. 因为当大量交易涌入到系统中，由于超出了系统的处理能力，部分交易的丢失就成为可能。为了防止这种现象的产生，我们通过增加中间层服务，控制流向底层网络的数据量；启用非验证节点，使交易均等分发至其他节点，进而保证底层网络中的节点能够处理所有的交易，防止交易丢失。
2. 而对于“双花”现象，由于超级账本网络中各节点处理交易的延时，会导致部分交易被重复提交。经过分析，我们通过调整过滤机制及过滤的时机，保证一笔交易只执行一次， 进而防止“双花”现象的出现

5.读写异常

在进行压力测试时，起初只是关注了底层系统对写数据的能力，并未关注对数据读取的能力。在后续进行并发读写数据操作时，发现一段时间后节点与合约之间的通信会断开，导致进入网络的数据无法记，而查询操作也会失败。深入剖析代码，发现主要原因是由于原版设计中读写锁设计不合理所导致的。

通过修改读写部分的代码逻辑，在不影响最终结果的情况下，将通信断开的问题进行修复，进而保证了系统的稳定性及功能的完善。相关修改方案已经由团队的廖同学提交到超级账本官方网站（gerrit.hyperledger.org)上，为超级账本的发展贡献了自己的一份力量。

提交记录：https://gerrit.hyperledger.org/r/#/c/7297/
补充说明：由于0.6版已经不再维护，所以没有通过。
Commit Message
core/chaincode/handler.go
core/chaincode/shim/handler.go

小结

就现在而言，超级账本仍处于概念验证阶段，0.6版本不能在生产环境实施运行。而通过我们团队不懈的努力，改进后的0.6版本已经初步具备了上线运行的条件。随着技术的成熟，即将在5月份推出的fabric 1.0 Alpha 版本新增了许多新特性，并且此版本是官方推出可用于生产环境部署的商业级应用，期待1.0正式版本为我们带来的惊喜。

---

参加超级账本上海黑客松大赛的花絮（3.11-3.12）

大赛中

评选中

大赛后