[论文解读] Early Detection for Multiversion Concurrency Control Conflicts in Hyperledger Fabric

Helmi Trabelsi, Kaiwen Zhang|arXiv (Cornell University)|Jan 15, 2023

Blockchain Technology Applications and Security被引用 4

一句话总结

本文提出了一种名为 EMVCC（MVCC 冲突的早期检测）的新机制，通过在 Hyperledger Fabric 的背书阶段使用本地密钥缓存，提前检测事务冲突，显著降低端到端延迟并提升吞吐量。性能最佳的实现方案 SyncMap 相较于基线 Fabric，可将吞吐量提升最高达 23%，延迟降低最高达 80%，方法是在 EOV 流水线中更早地中止存在冲突的事务。

ABSTRACT

Hyperledger Fabric is a popular permissioned blockchain system that features a highly modular and extensible system for deploying permissioned blockchains which are expected to have a major effect on a wide range of sectors. Unlike traditional blockchain systems such as Bitcoin and Ethereum, Hyperledger Fabric uses the EOV model for transaction processing: the submitted transactions are executed by the endorsing peer, ordered and batched by the ordering services, and validated by the validating peers. Due to this EOV workflow, a well-documented issue that arises is the multi-version concurrency control conflict. This happens when two transactions try to writes and read the same key in the ledger at the same time. Existing solutions to address this problem includes eliminating blocks in favor of streaming transactions, repairing conflicts during the ordering phase, and automatically merging the conflicting transactions using CRDT (Conflict Free Replicated Data) techniques. In this paper, we propose a novel solution called Early Detection for MVCC Conflicts. Our solution detects the conflicting transactions at an early stage of the transaction execution instead of processing them until the validation phase to be aborted. The advantage of our solution is that it detects conflict as soon as possible to minimize the overhead of conflicting transaction on the network resulting in the reduction of the end-to-end transaction latency and the increase of the system's effective throughput. We have successfully implemented our solution in Hyperledger Fabric. We propose three different implementations which realize early detection. Our results show that our solutions all perform better than the baseline Fabric, with our best solution SyncMap which improves the goodput by up to 23% and reduces the latency by up to 80%.

研究动机与目标

• 解决 Hyperledger Fabric 的 EOV 事务模型中因 MVCC 冲突导致的性能瓶颈，即冲突事务仅在验证阶段后期才被检测到。
• 降低因事务中止而消耗区块空间并需客户端重试所造成的开销，从而提升系统吞吐量和效率。
• 通过在背书阶段即检测冲突，而非等待排序和验证阶段，从而最小化端到端事务延迟。
• 通过主动识别并中止高冲突概率的事务，避免其消耗网络和存储资源，从而提升系统吞吐量。
• 提供一种灵活、模块化的解决方案，与现有 Fabric 架构向后兼容，且对链码或网络配置的修改需求极小。

提出的方法

• 在背书节点处引入本地密钥缓存，用于追踪读写集，并在事务排序前检测潜在的 MVCC 冲突。
• 实现三种变体——SyncMap、无锁（Lock-Free）和互斥锁（Mutex Lock），采用不同的并发数据结构管理密钥缓存，以在性能与一致性之间实现不同权衡。
• 将 EMVCC 检测逻辑集成到背书阶段，实现因版本不匹配而本应失败的事务的早期中止。
• 利用理论建模分析基于背书策略、组织数量和节点分布的冲突检测有效性。
• 设计该方案对客户端透明，且与现有 Fabric 组件（包括 MSP 和链码执行）兼容。
• 在不同工作负载、链码访问模式（使用 Zipf 分布）和网络拓扑下评估该方案的可扩展性与鲁棒性。

实验结果

研究问题

• RQ1 是否可以在 EOV 流水线中更早地检测 Hyperledger Fabric 中的 MVCC 冲突，以降低延迟并提升吞吐量？
• RQ2 背书策略的选择（AND 与 OR）如何影响早期冲突检测的有效性以及误报/漏报率？
• RQ3 网络拓扑（包括每个组织的节点数量）对早期冲突检测性能有何影响？
• RQ4 链码的访问模式（如通过 Zipf 分布实现的键访问倾斜）如何影响 EMVCC 的检测率和性能增益？
• RQ5 在并发数据结构（SyncMap、Lock-Free、Mutex Lock）中，哪一种能实现性能、可扩展性与冲突检测准确率的最佳平衡？

主要发现

• SyncMap 实现方案相较基线 Hyperledger Fabric，吞吐量最高提升 23%，端到端事务延迟最高降低 80%。
• 在 AND 策略下，两个组织、每组织两个节点时，未检测到的冲突（漏报）比例达到 22%，表明检测覆盖范围仍有提升空间。
• 增加每个组织的节点数量可提升吞吐量和吞吐量，尤其在 AND 背书策略下，因冲突检测能力增强和负载分布更优。
• OR 背书策略导致更高的误报率，尽管原始吞吐量更高，但性能增益被抵消，因此在优先考虑冲突检测时 AND 策略更有效。
• 在高冲突率场景下（如 Zipf 分布中 s = 1.5），SyncMap 相较 Fabric 可将吞吐量提升 35%，表明在真实工作负载下具备出色的可扩展性。
• 当与 AND 背书策略、每个组织的最少节点数以及精细调整区块大小以最小化块内与块间冲突相结合时，该方案效果最佳。