[논문 리뷰] How to Databasify a Blockchain: the Case of Hyperledger Fabric

Ankur Sharma, Felix Schuhknecht외 2명|arXiv (Cornell University)|2018. 10. 31.

Distributed systems and fault tolerance참고 문헌 12인용 수 9

한 줄 요약

이 논문은 트랜잭션 재정렬과 조기 취소를 통합한 데이터베이스 기반 최적화 기법을 적용한 Hyperledger Fabric의 향상된 버전인 Fabric++을 제안한다. 이는 직렬화 충돌을 줄이고 잘못된 트랜잭션을 파이pline의 조기에 취소시켜 트랜잭션 처리량을 크게 향상시킨다. 기존 Fabric 대비 최대 3배까지 성공적인 트랜잭션 처리량을 달성하면서도 확장성은 유지한다.

ABSTRACT

Within the last few years, a countless number of blockchain systems have emerged on the market, each one claiming to revolutionize the way of distributed transaction processing in one way or the other. Many blockchain features, such as byzantine fault tolerance (BFT), are indeed valuable additions in modern environments. However, despite all the hype around the technology, many of the challenges that blockchain systems have to face are fundamental transaction management problems. These are largely shared with traditional database systems, which have been around for decades already. These similarities become especially visible for systems, that blur the lines between blockchain systems and classical database systems. A great example of this is Hyperledger Fabric, an open-source permissioned blockchain system under development by IBM. By having a relaxed view on BFT, the transaction pipeline of Fabric highly resembles the workflow of classical distributed databases systems. This raises two questions: (1) Which conceptual similarities and differences do actually exist between a system such as Fabric and a classical distributed database system? (2) Is it possible to improve on the performance of Fabric by transitioning technology from the database world to blockchains and thus blurring the lines between these two types of systems even further? To tackle these questions, we first explore Fabric from the perspective of database research, where we observe weaknesses in the transaction pipeline. We then solve these issues by transitioning well-understood database concepts to Fabric, namely transaction reordering as well as early transaction abort. Our experimental evaluation shows that our improved version Fabric++ significantly increases the throughput of successful transactions over the vanilla version by up to a factor of 3x.

연구 동기 및 목표

• Hyperledger Fabric와 같은 블록체인 시스템과 전통적인 분산 데이터베이스 시스템 간의 개념적 유사점과 차이점을 탐구하는 것.
• 트랜잭션 순서가 비효율적이고 늦은 취소 결정으로 인해 발생하는 Fabric의 트랜잭션 파이프라인 내 성능 저하 요인을 특정하는 것.
• 기존의 데이터베이스 기술이 분산 블록체인 시스템의 성능 향상에 효과적으로 적용될 수 있는지 탐색하는 것.
• 처리량과 효율성을 향상시키기 위해 데이터베이스 기반 최적화를 통합한 수정된 Fabric 버전인 Fabric++를 설계하고 평가하는 것.

제안 방법

• 직렬화 충돌을 최소화하기 위해 블록 내 트랜잭션을 재정렬하는 고급 트랜잭션 재정렬 메커니즘을 도입하여 유효한 트랜잭션 수를 늘리는 것.
• 파이프라인의 여러 단계에서 조기 취소를 구현하여 자원을 소비하기 전에 잘못된 트랜잭션을 조기에 탐지하고 거부하는 것.
• 시뮬레이션 단계와 순서 정렬 단계를 분리하여 충돌을 더 이르게 탐지하고 파이프라인 경쟁을 줄이는 방식으로 트랜잭션 흐름을 최적화하는 것.
• 108개의 다양한 워크로드 및 시스템 구성에서 Fabric++의 성능을 평가하고, 기존 Fabric과의 처리량과 실패율을 비교하는 것.
• 블록 크기, 읽기/쓰기 비율, 클라이언트/채널 수를 변경할 수 있는 구성 가능한 벤치마크 환경을 사용하여 확장성과 최적화 효과를 평가하는 것.
• 제어된 실험을 통해 각 최적화 기법(재정렬 및 조기 취소)의 기여도를 개별적으로 및 조합적으로 분석하는 것.

실험 결과

연구 질문

• RQ1 Hyperledger Fabric와 전통적인 분산 데이터베이스 시스템 간에는 어떤 개념적 유사점과 차이점이 존재하는가?
• RQ2 기존의 데이터베이스 기술이 Hyperledger Fabric과 같은 허가된 블록체인 시스템의 성능 향상에 어느 정도 적용될 수 있는가?
• RQ3 트랜잭션 재정렬 및 조기 취소 메커니즘이 Fabric의 트랜잭션 파이프라인 처리량과 효율성에 어떤 영향을 미치는가?
• RQ4 재정렬과 조기 취소의 조합 효과는 무엇이며, 실질적으로 이들 기법은 어떻게 상호작용하는가?
• RQ5 기존 Fabric 대비 Fabric++는 채널 수와 클라이언트 수 증가에 따라 어떻게 확장되는가?

주요 결과

• 최적의 구성 조건에서 Fabric++는 기존 Fabric 대비 성공 트랜잭션 처리량을 최대 3배까지 향상시킨다.
• 트랜잭션 재정렬 또는 조기 취소를 별도로 활성화할 경우 처리량이 약 100에서 약 150건의 성공 트랜잭션/초로 증가한다.
• 두 최적화 기법을 동시에 활성화할 경우 최대 처리량 약 220건의 성공 트랜잭션/초를 달성하여 상호보완적인 성능 향상 효과를 입증한다.
• 조기 취소와 재정렬의 조합은 오직 성공 가능성이 있는 트랜잭션들만 재정렬 대상으로 고려하도록 하여 파이프라인 경쟁을 줄인다.
• 다양한 채널에 걸쳐 확장할 경우 처리량은 4개 채널까지 향상되지만, 이후 자원 경쟁으로 인해 처리량 저하와 트랜잭션 실패 증가가 발생한다.
• 채널당 클라이언트 수 증가로 인해 자원 경쟁이 심화되어 실패율이 증가하고 처리량이 감소한다. 특히 Fabric++에서는 고밀도 클라이언트 환경에서 성능 저하가 더 두드러진다.