Hyperledger Fabric 특징과 구성요소

Hyperledger Fabric 특징

1. 허가형(Permissioned) 블록체인

    공캐키(PKI)활용한 멤버십 관리 서비스로 참여자 제한

2. 일반 프로그래밍 언어 사용

    Go, Java, Node.js 와 같은 언어 사용

    이더리움의 경우 Solidity라는 언어 사용

3. 암호화폐를 사용하지 않음

    특정 목적의 허가된 사용자만 참여하기 때문에 블록체인을 유지하기위한 보상체계가 필요하지 않음

4. 고성능

    병렬처리 기능으로 다수의 거래를 동시에 처리

5. 모듈러 아키텍처

    합의 프로토콜을 교체하여 사용할 수 있는 모듈러 아키텍처

6. 다중 블록체인 지원

    채널을 설정하여 네트워크내에서 채널별 독립적인 블록체인을 활용 할 수 있음.

Hyperledger Fabric  구성요소

1. Peer

하이퍼레저 패블릭 블록체인을 구성하는 네트워크 노드 중 하나.

분산원장과 스마트컨트랙트를 관리하는 역할을 함.

하나의 Peer는 하나의 체인코드와 분산원장을 가질 수 있음.

하나의 Peer는 여러개의 체인코드와 분산원장을 가질 수 있음.

2. ChianCode 

분산원장에 데이터를 기록하거나 읽는 작업을 수행함.

주로 비즈니스 모델에 맞는 DApp과 함께 개발되어 사용됨

블록체인 참여자는 체인코드를 통해 분산원장에 데이터를 읽거나 쓸 수 있지만 대부분 비즈니스 모델에 맞는 분산 애플리케이션(DApp)과 함께 개발되어 사용 됨. 

[그림] 분산 애플리케이션을 통한 분산원장 업데이트 과정

(1) 사용자가 트랜잭션 생성을 요청함.

(2) DApp은 Peer와 연결함.

(3) 체인코드 실행을 요청함.

(4) Peer는 체인코드를 실행함.

(5) 보증허가된 트랜잭션을 DApp에게 반환함.

(6) DApp은 허가된 트랜잭션을 Orderer에게 전달함.

(7) Orderer는 트랜잭션을 정렬하여 최신블럭에 트랜잭션을 포함시킴.

(8) Orderer는 새로 생성된 블럭을 네트워크의 Peer에게 전달함.

3. 시스템 체인코드 

스마트 컨트랙트 <-- 애플리케이션 레벨에서 원장에 접근하는 일반적인 체인코드

시스템 체인코드 <-- 하이퍼레저 패블릭 시스템 레벨에서 실행.  

                           기본제공됨.

QSCC(Query System ChainCode) : 블록체인에 저장된 데이터를 읽어올 때 사용되는 시스템 체인코드 

CSCC(Configuration System ChainCode) :  채널을 설정 할 때 사용되는 시스템 체인코드

LSCC(LifeCycle System ChainCode) :  체인코드 설치 부터 인스턴스화 까지 모든 과정을 수행하는데 사용되는 시스템 체인코드 

ESCC(Endorsement System ChainCode) : 보증정책을 담당하는 시스템 체인코드

VSCC(Validation System ChainCode) :  블록을 검증할 때 사용되는 시스템 체인코드

4. 합의 알고리즘

https://developer.ibm.com/kr/cloud/blockchain/blockchain-special-series/2018/11/11/hyperledger-fabric-architecture-6-consensus-algorithms/

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

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

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

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

직전 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를 왜?

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에서부터 제공하기를 기대해봐야겠습니다.