原文链接:https://dl.acm.org/doi/10.1145/3318464.3389693
相关预备知识文章:
[1]Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, et al. 2018. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference. ACM, 30.
[2]Ankur Sharma, Felix Martin Schuhknecht, Divya Agrawal, and Jens Dittrich. 2019. Blurring the Lines between Blockchains and Database Systems: the Case of Hyperledger Fabric. In Proceedings of the 2019 International Conference on Management of Data. ACM, 105–122.
Abstract: Smart contracts have enabled blockchain systems to evolve from simple cryptocurrency platforms to general transactional systems. A new architecture called execute-order-validate has been proposed in Hyperledger Fabric to support parallel transactions. However, this architecture might render many invalid transactions when serializing them. This problem is further exaggerated as the block formation rate is inherently limited due to other factors beside data processing, such as cryptography and consensus. Inspired by optimistic concurrency control in modern databases, we propose a novel method to enhance the executeorder-validate architecture, by reordering transactions to reduce the abort rate. In contrast to existing blockchains that adopt database’s preventive approaches which might overabort serializable transactions, our method is theoretically more fine-grained: unserializable transactions are aborted before reordering and the rest are guaranteed to be serializable. We implement our method in two blockchains respectively, FabricSharp on top of Hyperledger Fabric, and FastFabricSharp on top of FastFabric. We compare the performance of FabricSharp with vanilla Fabric and three related systems, two of which are respectively implemented with one standard and one state-of-the-art concurrency control techniques from databases. The results demonstrate that FabricSharp achieves 25% higher throughput compared to the other systems in nearly all experimental scenarios. Moreover, the FastFabricSharp’s improvement on FastFabric is up to 66%.
摘要: 智能合约使得区块链系统从简单的加密货币平台发展成了通用交易系统。在Hyperledger Fabric中提出了一种被称为execute-order-validate的新架构用于支持并行交易。但是当序列化交易时,该结构会呈现许多无效事务。因为除数据处理之外的其他因素,如密码学和共识因素,使得块形成率受到固有的限制时,这个问题被进一步放大了。受到现代数据库中乐观并发控制的启发,我们提出了一个新颖的方法,通过重排序事务从而降低事务中止率,以优化execute-order-validate结构。现有区块链数据基于数据库的预防性方法(悲观控制)会过度终止序列化的交易,与其相反,我们的方法从理论上而言更加细粒度:无法序列化的交易将在重排序前被中止,其他的交易则保证可序列化。我们分别在两个区块链中实现我们的方法,基于Hyperledger Fabric的FabricSharp,基于FastFabric的FastFabricSharp。我们将FastFabric和vanilla Fabric和其他三个关联的系统进行性能比较,其中两个分别基于数据库上的一个标准并发控制技术和一个最新的并发控制技术实现。结果表明,FabricSharp在几乎所有实验场景中,其吞吐量均高于其他系统25%。并且FastFabricSharp相比FastFabric优化高达66%。
论文解决问题:
Fabric为了提高事务的并行化,提出了EOV结构,但Fabric在验证时会中止大量事务。如何减少这部分事务的中止率并保持高并行效率?
解决方案:
1.分析EOV结构与传统数据库乐观并发锁的相似性
2.提出新理论找出一定不可串行化的交易,提前中止这部分交易从而提高计算效率,保证剩余交易一定可串行化,对其重排序
3.在Fabric和FastFabric上分别实现该算法,进行吞吐量和延迟等性能比较
算法细节:
与Fabric++[2]较为相似,也分为前期判环早期中止事务,验证过程重载c-ww冲突并重排序两部分,只是较Fabric++更细粒度化,对可串行化事务中止率下降:
1.生成除c-ww依赖之外的其他依赖组成的依赖图,判环,存在环则不可串行化,通过中止事务防止冲突
2.生成块时重载c-ww依赖,若存在环,交换c-ww交易顺序,改变依赖方向,从而防止冲突