[论文解读] Impact of network delays on Hyperledger Fabric

Thanh Son Lam Nguyen, Guillaume Jourjon+2 more|arXiv (Cornell University)|Mar 21, 2019

Blockchain Technology Applications and Security参考文献 6被引用 7

一句话总结

本文评估了网络延迟对基于PBFT共识的许可区块链Hyperledger Fabric的影响。通过在法国和德国的地理上分散的云环境（Sorbonne University和Heidelberg University）中部署系统，并引入最高达3.5秒的可控延迟，研究发现区块传播延迟导致账本严重不同步——第100个区块在两地节点间出现134秒的偏移，表明系统在缺乏一致性保证的情况下，不适用于银行等关键应用。

ABSTRACT

Blockchain has become one of the most attractive technologies for applications, with a large range of deployments such as production, economy, or banking. Under the hood, Blockchain technology is a type of distributed database that supports untrusted parties. In this paper we focus Hyperledger Fabric, the first blockchain in the market tailored for a private environment, allowing businesses to create a permissioned network. Hyperledger Fabric implements a PBFT consensus in order to maintain a non forking blockchain at the application level. We deployed this framework over an area network between France and Germany in order to evaluate its performance when potentially large network delays are observed. Overall we found that when network delay increases significantly (i.e. up to 3.5 seconds at network layer between two clouds), we observed that the blocks added to our blockchain had up to 134 seconds offset after 100 th block from one cloud to another. Thus by delaying block propagation, we demonstrated that Hyperledger Fabric does not provide sufficient consistency guaranties to be deployed in critical environments. Our work, is the fist to evidence the negative impact of network delays on a PBFT-based blockchain.

研究动机与目标

• 调查网络延迟对基于PBFT的许可区块链Hyperledger Fabric的一致性和性能的影响。
• 评估Hyperledger Fabric在存在显著传输延迟的真实网络条件下是否能维持强一致性保证。
• 识别当延迟超过阈值时，系统架构中区块传播和共识协调方面的故障点。
• 评估系统在高延迟条件下的弹性，特别是在跨云区域的长距离部署中。
• 提供实证证据表明，当前版本的Hyperledger Fabric不适用于低延迟、高一致性要求的关键应用，如金融交易或实时结算系统。

提出的方法

• 在法国（Sorbonne University）和德国（Heidelberg University）的两个云环境中部署Hyperledger Fabric，以模拟长距离网络条件。
• 使用流量控制工具（如tc）引入可控的网络延迟，模拟节点间高达3.5秒的传输延迟。
• 通过跟踪两地节点中区块的时间戳，测量区块传播时间和账本同步偏移。
• 使用Wireshark等网络分析工具，监控系统在延迟增加时的行为，包括缓冲区溢出和节点断开事件。
• 通过逐步增加交易负载（最高达30,000笔交易）进行实验，评估高负载下性能退化和偏移增长情况。
• 分析记 orderer 与 peer 之间的通信模式，特别是 peer 在接收到区块前即发送接收确认信号的反馈机制，该机制会放大延迟。

实验结果

研究问题

• RQ1 网络延迟如何影响Hyperledger Fabric基于PBFT共识的区块传播和账本同步？
• RQ2 Hyperledger Fabric在出现显著不同步或系统故障前，能容忍的最大网络延迟是多少？
• RQ3 当延迟超过3.5秒时，系统行为如何变化，特别是在节点断开和共识停止方面？
• RQ4 orderer的缓冲区大小在高延迟环境中对传播延迟累积的贡献程度如何？
• RQ5 Hyperledger Fabric能否在具有真实网络延迟的生产级长距离部署中维持强一致性保证？

主要发现

• 在3.5秒的网络延迟下，第100个区块在法国和德国peer之间出现了134秒的同步偏移，表明存在严重不同步。
• 在3.5秒延迟下，第一个区块出现128秒的偏移，第100个区块达到134秒的偏移，表明延迟呈指数级增长。
• 当网络延迟超过3.5秒（如3.58秒）时，Docker swarm检测到Sorbonne节点已断开，导致系统全面故障。
• 系统故障的根本原因在于反馈机制：peer向orderer发送确认信号，导致orderer将下一批区块的发送延迟一个往返时间，从而放大延迟。
• 在30,000笔交易和3.5秒延迟条件下，偏移量增加至超过1小时10分钟，表明高交易量会加剧不同步。
• orderer的缓冲区大小被确定为延迟累积的关键因素；当缓冲区达到容量时，orderer停止工作，导致整个系统停机。