Hyperledger Fabric은 왜 Kafka와 SBFT를 선택했나

이번 포스팅에서 살펴볼 것은, 개인적으로 제가 가장 어렵고 헷갈렸던 합의 알고리즘입니다. 이상하게 Hyperledger Fabric의 합의 알고리즘은 참 이해하기가 어려웠습니다. 이더리움의 POS(Casper)나 EOS의 dPOS 같이 상대적으로 명확히 잡히는 알고리즘 개념은 아니었죠. 조금 더 세세히 뜯어보니 그럴 만한 이유가 있었다는 개인적인 깨달음(?)을 얻었습니다.

합의 알고리즘에 대해 조금이라도 찾아보신 분이라면 Byzantine General Problem 라는 말을 잘 아실 겁니다. 비잔틴 장군이 메신저를 통해 오는 전갈들의 내용을 어떻게 검증할 것인가 문제를 해결하고자 하는 데에서 시작했죠. 그리고 이걸 해결하고자 등장한 알고리즘들이 POW, POS, dPOS 등등, 우리가 흔히 말하는 블록체인의 합의 알고리즘 입니다. 그 많은 합의 알고리즘 중 Kafka는 사실 많이 들리는 단어는 아닙니다. 왜 그런지, HLF의 합의 알고리즘은 도대체 무엇인지 살펴보겠습니다.

Hyperledger Fabric의 트랜잭션 사이클: Execute-Order-Validate

출처: https://www.ibm.com/blogs/research/2018/02/architecture-hyperledger-fabric/

직전 Architecture 4 포스팅에서 트랜잭션의 처리 과정을 다루었고, 최초 Architecture 1 포스팅에서 Execute-Order-Vaildate 을 처음 언급했습니다. 이 부분은 단연 HLF를 다른 블록체인 플랫폼과 구분짓는 차별 포인트입니다. 다른 플랫폼에서는 Order-Execute 처리만 하나의 트랜잭션으로 처리합니다. 그 과정에서 발생할 수 있는 Non-determinism의 문제 — 하나 이상의 값을 리턴하여 값의 신뢰성을 저하시키는 문제 — 는 Solidity와 같은 도메인 특수 언어를 별도로 사용함으로써 해결하고, 소위 합의 알고리즘이 이 트랜잭션에 적용이 되는 겁니다.

이에 반해 HLF에서는 몇몇 노드들이 먼저 실행하고 결과값을 검증하는 단계, 모든 노드에게 적용하는 단계를 분리하여 처리합니다. Execute 단계에서는 일단 피어들이 실행하고 결과값을 서로 비교하는 작업을 하는 겁니다. 그리고 Order 단계에서 그 순서를 정렬하여 모든 피어에게 전송하죠. 마지막으로 각 피어에서 순서대로 요청 온 내용을 적용하고 Validate 합니다. 이 마지막 단계에서 마침내 원장에 업데이트가 이루어지는 거죠. 이 Execute-Order-Validate 이라는 단계 자체가 일종의 합의인 것입니다. 그렇지만 정확히 말하면 우리가 생각하는 블록체인 합의 알고리즘과는 약간 다릅니다. 그렇다면 Kafka를 합의 알고리즘이라고 할 수 있을까? 그렇지도 않습니다.HLF의 합의 알고리즘이라 종종 불리우는 Kafka는 사실 Order 단계에만 사용되기 때문에 정확한 표현이라 할 수 없습니다.

보다 정확히 표현해보자면 HLF는 합의가 2중으로 일어나는 구조입니다. Execute, Validate 단계에서는 네트워크에서 정의하고 있는 Endorsement Policy에 따라서 자체적인 Endorse 과정을 거칩니다. 알고리즘으로 수행되는 게 아니라 네트워크에 정의한 ‘정책’에 따라서 합의 여부가 결정되는 겁니다. 그리고 중간의 Order 단계에서, 해당 네트워크에서 지정된 Orderer들이 Kafka 방식으로, 제출된 트랜잭션을 정렬하고 Orderer 간의 합의가 이루어지게 되는거죠.

메시징 시스템인 Kafka를 왜?

출처: https://blog.cloudera.com/blog/2014/09/apache-kafka-for-beginners/

Kafka는 엄밀히 말하면 블록체인 합의 알고리즘이 아닙니다. 그래서 접하기 어렵습니다. Kafka는 Linkedin에서 개발한 분산 메시징 시스템으로, 실시간 대용량 로그 처리에 특화되어 있습니다. 그래서 다른 합의 알고리즘들이 BFT — 전달되는 내용에 대한 검증을 하는 — 인 반면, Kafka는 CFT (Crash Fault Tolerance) 입니다. 순서만 정확히 쌓이도록 해주는 겁니다. Kafka에 대해 더 알고 싶으신 분들은 여기를 확인해보세요.

그렇다면 HLF를 과연 진정한 ‘합의’를 기반으로 한 블록체인이라고 할 수 있는 걸까요? 개인적으로 Kafka를 차용한 것은, HLF의 성능 향상을 위한 아키텍처적 고민에서 비롯되었다고 생각합니다. 최초 0.x HLF에서는 PBFT 를 기본으로 장착하고 있었죠. 그렇지만 지속적으로 성능(TPS)에 대한 비판이 제기되었고, HLF 개발진들은 이에 대한 대책을 마련해야 했을 겁니다. 여전히 강력하지만 효율적인 합의 방식을 찾게 된 거죠. Kafka는 pub-sub 구조 내에서 빠르게 메시지를 pull 방식으로 전달하여 수신 피어 측의 부담을 최소화하고 속도를 향상시킬 수 있다는 점에서 매력적인 솔루션이었습니다. BFT 적 검증은 할 수 없지만 Permissioned Blockchain의 성격을 적극 활용해 CA 단에 위험을 1차 차단하고, 추가로 endorsement policy로 구멍이 없이 보완하는 방식으로 문제를 해결한 것입니다.

Simple BFT

HLF의 조직 간 BFT적 검증을 하고 싶다면 어떻게 해야 할까요? 쉽습니다. HLF의 합의 알고리즘은 modular 방식으로, 개발자가 어떤 합의 방식을 택할지 선택할 수 있기 때문이죠— 이 방식의 적용은 Order 단계에만 된다는 점을 유의해야 합니다. HLF가 기본적으로 제공하고자 하는 BFT 검증 방식은 SBFT 입니다. 1.3 release 기준 아직 포함되지는 않았지만, 올 초 발표한 2018 roadmap에서는 포함되어 있었으니 1.4 release에서부터 제공하기를 기대해봐야겠습니다.

에 대한 댓글이 1건 있습니다"[Hyperledger Fabric] Architecture: 6 합의 알고리즘"

  1. 김도훈 3월 22, 2019

    안녕하세요.
    작성하신 글은 잘 봤습니다.
    작성하신 글에서 발췌된 내용의 의미를 알고자 토론에 참가하게 되었습니다.

    – 발췌 –
    “다른 플랫폼에서는 Order-Execute 처리만 하나의 트랜잭션으로 처리합니다. 그 과정에서 발생할 수 있는 Non-determinism의 문제 — 하나 이상의 값을 리턴하여 값의 신뢰성을 저하시키는 문제 — 는 Solidity와 같은 도메인 특수 언어를 별도로 사용함으로써 해결하고, 소위 합의 알고리즘이 이 트랜잭션에 적용이 되는 겁니다.”
    해당 내용에서 타 플랫폼에서는 execute-order처리만 하나의 트랜잭션으로 처리한다는 말이 어떤 의도록 작성한것인지 궁금합니다.

    감사합니다.

토론 참가

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다