[fabric] 하이퍼레저 패브릭 구조 (1) - 기본 구성과 흐름

하이퍼레저 패브릭의 구조에 대하 알아보겠습니다.

하이퍼레저 패브릭은 보는 방법에 따라 여러가지 구조로 볼 수 있습니다.

아래는 제가 공부하면서 정리해서 그린 하이퍼레저 패브릭의 구조입니다.

(저도 공부하면서 그린거라 오류가 있을 수 있습니다.)

Hyperledger Fabric Architecture

일단 크게 3가지 부분으로 볼 수있습니다.

• 클라이언트(client)
• 피어(Peer)
• OSN(Ordering Service Node, 오더러(orderer))

입니다.

"그럼 나머지 복잡한 것들은 뭔가요?"라는 말이 당연히 나오겠지만 크게 보면 저렇다는 겁니다.

 

클라이언트(client)는 블록체인에 접근하기위해 필요한 노드(node)입니다. 피어에게 보내는 거래(트랜잭션, transaction)을 만듭니다. 채널을 생성하거나 특정 피어를 채널에 참가하게 하는 트랜잭션 같은 특수한 트랜잭션들 또한 여기서 생성됩니다. 하이퍼레저 패브릭에서는 보통 도커 이미지(docker Image)를 이용해 제공되는 클라이언트 어플리케이션을 이용하거나 별도의 어플리케이션을 통해서 블록체인 네트워크와 통신을 합니다. 

클라이언트는 트랜잭션을 생성하여 피어 노드의 엔도저(endorser, 보증)에 보내는(submit) 일을 합니다. 이후 거래 보증응답이 오면 거래 제안(transaction proposal)을 생성하여 Orderer(오더러, OSN)에게 보냅니다.

 

피어(peer)는 원장(ledger, chain)를 가진 패브릭에서 가장 기본이 되는 노드입니다. 체인코드(smart contract) 또한 여기에 들어있습니다. 자신에게 요청된 트랜잭션을 검증하고 전파합니다. 오더러로부터 트랜잭션을 받으면(위에서 클라이언트가 오러러로 보낸 트랜잭션입니다.) 원장을 갱신합니다. 이후 원장이 업데이트 된것을 클라이언트에게 알려(event)줍니다. 피어는 다중 체인 코드와 다중 원장을 사용할 수 있습니다. (채널을 이용).

하이퍼레저 패브릭은 체인코드 동작을 위해 키-값 데이터베이스(Key-Value Database)를 사용합니다. 하이퍼레저 패브릭은 이러한 KVS(Key Value Store)중 기본적(Default)으로 LevelDB를 사용합니다. 레벨DB도 좋은 KV DB지만 사실 몇가지 문제점이 있습니다. 키-밸류 DB에 관해서나 이러한 문제들은 나중에 레벨DB에 관한 포스팅에서 자세히 다루겠습니다. 이때 조금더 복잡한 DB를 구성하기 위해서 카우치DB(CouchDB)를 사용합니다. 

앵커(Anchor)는 조직에 속한 다른 피어들을 검색가능하게 해줍니다. peer-to-peer간의 gossip이 가능하도록 해줍니다. 트랜잭션을 조직내의 다른 피어로 전달시킵니다. 조직내에 속한 피어 하나가 앵커로 동작하며 채널에는 반드시 하나 이상의 앵커 피어가 존재합니다. 간단히 생각해보면 다른 조직의 피어를 탐색(?) 하도록 하는 역할을 해줍니다.

엔도저(Endorser)는 트랜잭션이 발생할경우 이곳에 거래 제안(transaction proposal)의 형태로 옵니다. 보통 체인코드가 설치되어있고 트랜잭션을 시뮬래이션 해보고 불안정할 경우 차단합니다. 엔도저가 직접 원장을 업데이트 하지는 않습니다. 간단히 요약하면 체인코드가 설치된 피어들입니다.

커미터(Committer)는 블록을 전달받아 블록 내의 모든 트랜잭션을 검사하고 블록을 체인에 연결합니다. 트랜잭션이 유효 하다면 원장을 업데이트를 합니다. 간단히 요약하면 기본 기능만 하는 피어들입니다.

 

OSN(Ordering Service Node, Orderer)는 검증된 트랜잭션들을 이용해 최종적으로 블록을 만듭니다. 합의 알고리즘에 따라 클라이언트들로부터 오는 거래(transaction proposal)들을 순서화시켜 피어 노드에 전달합니다. 피어로 전달되는 거래들이 안전하게 전달되는 것을 보장합니다.(atomic broadcast 제공)

오더러는 방대한 양의 트랜잭션을 검증하고 이들을 모아서 블록을 생성하는 작업을 합니다. 트랜잭션이 많아지면 당연히 오버헤드(부하)가 걸리게 됩니다. 이를 위해 사용하는 것이 MQ Solution(message queue)입니다. 발생한 트랜잭션들을 MQ에 적재해서 처리해서 오더러가 부하를 견디도록 도와주는 역할을 합니다. 보통 kafka나 zookeeper를 사용합니다. 최근 RAFT라고 하는 것이 등장했습니다.(BFT(비잔틴 결함허용)로 가는 첫 걸음이라는 말이 있네요)

 

이제 전체적인 흐름을 다시 짚어보겠습니다.

 

출처: 하이퍼레저 패브릭 공식 홈페이지 문서

기본적인 흐름 정리

1. 클라이언트 어플리케이션이 피어에 연결합니다.
2. 연결이 되면 트랜잭션을 생성(transaction proposal)해서 피어의 endorser에 보냅니다.
3. 피어는 받은 거래제안(transaction proposal)에 대하여 체인코드를 확인합니다. 
4. 체인코드는 원장에대한 쿼리 거래(ledger query transaction)의 경우 즉시 결과를 반환합니다.
5. update와 같은 원장(ledger)에 대한 변경이 있는 거래 제안이었을 경우 피어는 받은 거래 제안에 대한 응답(response)을 합니다.
6. 응답을 받은 클라이언트는 해당 거래를 오더러(OSN)에 보냅니다.
7. 오더러는 합의 알고리즘에 의거해서 블록을 생성하고 이를 피어로 보냅니다.
8. 피어의 앵커(anchor)는 오더러로 부터 받은 거래블록(transaction block)을 받고 커미터(committer)가 트랜잭션을 확정합니다. 또한 이를 이용해서 피어는 원장을 업데이트 합니다. 이후 클라이언트에게 업데이트 이벤트를 보냅니다.
9. 클라이언트는 업데이트 이벤트를 받게되고 트랜잭션 과정이 끝납니다.

이제 흐름에 관한 기본적인 정리가 끝났습니다. 그러면 다음 포스트에서는 더 깊게 들어가보겠습니다.

다음글 : [fabric] 하이퍼레저 패브릭 구조 (2)

[fabric] 하이퍼레저 패브릭 구조 (2)

 

 

 

References

논문: Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains

공식 홈페이지 문서: https://hyperledger-fabric.readthedocs.io/en/release-1.4/index.html 

SPRI FORUM 발표자료: https://spri.kr/download/21810

IBM 홈페이지 관련 게시물: https://developer.ibm.com/kr/cloud/blockchain/blockchain-special-series/

Youtube(박승철의블록체인및정보보호론강의): https://www.youtube.com/watch?v=hh9NXQQRtx4