[논문 리뷰] FireLedger: A High Throughput Blockchain Consensus Protocol

Yehonatan Buchnik, Roy Friedman|arXiv (Cornell University)|2019. 01. 10.

Blockchain Technology Applications and Security참고 문헌 56인용 수 6

한 줄 요약

FireLedger는 통신 오버헤드를 줄이기 위해 옵티미스틱하게 정상적인 제안자를 가정하는 고처리량 블록체인 합의 프로토콜이다. 이로 인해 통신 라운드당 한 블록 결정이 가능하며, 메시징을 최소화할 수 있다: 제안자는 단지 자신의 제안을 전송하고, 다른 노드들은 각각 한 비트씩 전송한다. 10개의 노드를 가진 단일 데이터센터 환경에서 512바이트 트랜잭션에 대해 최대 16만 tps를 달성하며, HotStuff 및 BFT-SMaRt보다 구성에 따라 20%~600% 빠르다.

ABSTRACT

Blockchains are distributed secure ledgers to which transactions are issued continuously and each block of transactions is tightly coupled to its predecessors. Permissioned blockchains place special emphasis on transactions throughput. In this paper we present FireLedger, which leverages the iterative nature of blockchains in order to improve their throughput in optimistic execution scenarios. FireLedger trades latency for throughput in the sense that in FireLedger the last f + 1 blocks of each node's blockchain are considered tentative, i.e., they may be rescinded in case one of the last f + 1 blocks proposers was Byzantine. Yet, when optimistic assumptions are met, a new block is decided in each communication step, which consists of a proposer that sends only its proposal and all other participants are sending a single bit each. Our performance study demonstrates that in a single Amazon data-center, FireLedger running on 10 mid-range Amazon nodes obtains a throughput of up to 160K transactions per second for (typical Bitcoin size) 512 bytes transactions. In a 10 nodes Amazon geo-distributed setting with 512 bytes transactions, FireLedger obtains a throughput of 30K tps. Moreover, on higher end Amazon machines, FireLedger obtains $20%-600%$ better throughput than state of the art protocols like HotStuff and BFT-SMaRt, depending on the exact configuration.

연구 동기 및 목표

• 블록체인의 반복적 성격을 활용하여, 바이진트라스터 장애가 드문 허가된 환경에서 블록체인 처리량을 향상시키는 것.
• 정상적인 운영 조건을 옵티미스틱하게 가정함으로써 합의 프로토콜의 통신 오버헤드를 줄이고, 일반 운영 시 메시지 양을 최소화하는 것.
• 강력한 최종성 보장을 유지하면서도 일반적인 전용 환경이 아닌 하드웨어에서 고성능을 달성하는 프로토콜을 설계하는 것.
• 실제 배포 조건에서 기존 최첨단 합의 프로토콜인 HotStuff 및 BFT-SMaRt보다 처리량과 효율성 면에서 뛰어나도록 하는 것.

제안 방법

• FireLedger는 마지막 f+1개의 블록을 일시적 상태로 유지하여, 이 윈도우 내의 제안자가 바이진트라스터일 경우 복구가 가능하도록 하면서도, f+1라운드 후에는 최종성 보장을 확보한다.
• 라운드 기반 합의 모델을 사용하며, 각 라운드는 하나의 새로운 블록을 결정한다. 제안자는 단지 자신의 제안만 전송하고, 다른 노드들은 동의를 알리기 위해 각각 한 비트씩 전송한다.
• 암호학적 인증을 활용하고 두 단계 통신 패턴을 사용한다: 첫 번째 단계에서는 블록 헤더를 확산하고, 두 번째 단계에서는 복구가 필요한 경우에만 거래 데이터를 전송한다.
• 각 블록의 거래를 버치하여 블록 헤더와 거래 데이터를 분리함으로써 확장성 향상과 대역폭 압박 감소를 도모한다.
• 장애가 발생한 제안자를 감지할 경우에만 복구 메커니즘이 활성화되어 정상 운영 시 오버헤드를 최소화한다.
• 배치 크기(β), 워커 수(ω), 블록 크기(σ)와 같은 구성 매개변수를 통해 CPU 효율적인 설계와 성능 최적화를 실현한다.

실험 결과

연구 질문

• RQ1 제안자가 정상적이라는 옵티미스틱 조건을 가정함으로써, 블록체인 합의 프로토콜이 상당히 높은 처리량을 달성할 수 있는가?
• RQ2 최종성이나 보안을 희생시키지 않고도 바이진트라스터 장애 내성 합의에서 통신 오버헤드를 어느 정도까지 줄일 수 있는가?
• RQ3 다양한 네트워크 토폴로지, 특히 단일 데이터센터와 지리적으로 분산된 배포 환경에서 옵티미스틱 합의 프로토콜의 성능 스케일링은 어떻게 되는가?
• RQ4 유사한 하드웨어 및 장애 내성 제약 조건 하에서 FireLedger는 HotStuff 및 BFT-SMaRt와 같은 선도적 프로토콜에 비해 처리량과 지연 시간 면에서 어떻게 비교되는가?

주요 결과

• 10대의 중급 수준 노드가 있는 단일 아마존 데이터센터에서 FireLedger는 512바이트 트랜잭션에 대해 최대 16만 건의 트랜잭션 per 초(tps)를 달성한다.
• 10개의 노드가 지리적으로 분산된 환경에서는 FireLedger가 3만 tps를 달성하여 광역망에서도 뛰어난 성능을 보인다.
• 다양한 구성과 클러스터 크기에서 FireLedger는 HotStuff보다 20%~300%, BFT-SMaRt보다 40%~600% 높은 처리량을 기록한다.
• FireLedger의 지연 시간은 클러스터 크기가 증가함에 따라 f+1 최종성의 영향을 받아 증가하지만, n ≤ 30 노드일 경우 Libra의 10초 최종성 목표를 충족시켜 경쟁력 있는 성능을 유지한다.
• 배치 크기(β)와 노드 수(n)가 증가함에 따라 처리량이 증가하며, 이는 더 나은 CPU 활용도와 버치 효과 덕분이며, 특히 더 큰 클러스터에서 두드러진다.
• 큰 크기의 트랜잭션에서는 데이터 전달이 통신 오버헤드의 주요 원인이 되어 프로토콜 수준의 이점이 줄어들며, FireLedger와 HotStuff의 성능 격차가 좁아진다.