[논문 리뷰] FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second

Christian Gorenflo, Stephen Lee외 2명|arXiv (Cornell University)|2019. 01. 03.

Blockchain Technology Applications and Security참고 문헌 15인용 수 45

한 줄 요약

본 논문은 Hyperledger Fabric v1.2를 메타데이터와 데이터를 분리하고 병렬성을 강화하며 인메모리 월드 상태를 사용하고 커밋터/엔도서 하드웨어를 분리하는 플러그 앤 플레이형 변경으로 재구성하여 처리량을 ~3k에서 ~20k tx/s로 증가시키고 블록 지연을 감소시킨다.

ABSTRACT

Blockchain technologies are expected to make a significant impact on a variety of industries. However, one issue holding them back is their limited transaction throughput, especially compared to established solutions such as distributed database systems. In this paper, we re-architect a modern permissioned blockchain system, Hyperledger Fabric, to increase transaction throughput from 3,000 to 20,000 transactions per second. We focus on performance bottlenecks beyond the consensus mechanism, and we propose architectural changes that reduce computation and I/O overhead during transaction ordering and validation to greatly improve throughput. Notably, our optimizations are fully plug-and-play and do not require any interface changes to Hyperledger Fabric.

연구 동기 및 목표

• 초고속 처리 능력을 갖춘 허가형 블록체인의 필요성을 동기 부여하고 Hyperledger Fabric 1.2에서 합의 외의 처리량 병목 현상을 평가한다.
• 종단 간 트랜잭션 처리량을 증가시키기 위한 플러그 앤 플레이식 아키텍처 최적화를 설계하고 구현한다.
• 최적화가 Fabric API를 보존하고 Fabric 2.x와 통합될 수 있음을 보여준다.
• 성능 결과를 제시하고 최대 50k tx/s까지의 확장 방향을 논의한다.

제안 방법

• 거래 메타데이터를 페이로드와 분리하여 주문 서비스에 트랜잭션 ID만 전송함으로써 정렬 오버헤드를 감소시킨다.
• 주문 서비스에서 메시지 파이프라인과 병렬 처리를 도입하여 처리량을 증가시킨다.
• 크리티컬 경로의 읽기/쓰기 연산 속도를 높이기 위해 월드 상태 데이터베이스를 인메모리 해시 테이블로 교체한다.
• 블록 저장소를 커밋/엔도스먼트로부터 분리하여 전용 저장 클러스터와 엔도서 풀을 가능하게 한다.
• 커밋 및 엔도스먼트 역할을 서로 다른 하드웨어에 분리하여 경쟁을 줄인다.
• 검증 중 반복 디코딩을 피하기 위해 언마샬된 Protocol Buffers 블록을 캐시한다.

실험 결과

연구 질문

• RQ1 주문 및 검증 경로를 재구축하여 API 변경 없이 Hyperledger Fabric 처리량을 크게 증가시킬 수 있는가?
• RQ2 Fabric 1.2에서 메타데이터를 데이터와 분리하고 병렬성을 가능하게 하며 인메모리 데이터 구조를 사용하는 것이 어떤 성능 향상을 가져오는가?
• RQ3 아키텍처적 분리(커밋터 대 엔도서)와 캐싱이 엔드 투 엔드 처리량과 지연에 어떤 영향을 미치는가?
• RQ4 대표 워크로드 하에서 FastFabric의 실현 가능한 엔드투엔드 처리량은 Fabric 1.2와 비교하여 어떠한가?

주요 결과

• 엔드투엔드 처리량은 3,185±62 tx/s(Fabric 1.2)에서 19,112±811 tx/s(FastFabric)로 확장된다. 이는 100k endorsed transactions 기준이다.
• 페이로드 크기 최적화를 통한 Orderer 처리량은 구성에 따라 약 21,719–28,534 tx/s로 증가한다(Opt O-I 및 O-II).
• 피어 처리량은 ~3,200 tx/s(Fabric 1.2)에서 모든 피어 최적화(Opt P-I, P-II, P-III)로 21,000 tx/s 이상으로 개선된다.
• 최적화를 통해 블록 지연이 크게 감소하여 피크 처리량에서 원래 지연의 대략 1/3 수준에 도달한다.
• 100개의 트랜잭션 블록 크기가 조정된 병렬 처리 설정에서 최적의 엔드투엔드 처리량을 산출한다(≈21k tx/s).
• 배포된 설정에서 엔드투엔드 실험은 Fabric 1.2에 비해 6–7배의 처리량 향상을 보여준다.