Hyperledger Fabric Architecture: 1 들어가며

아키텍쳐 연재 개요 및 비즈니스를 위한 블록체인의 기준

Jiwon Yeom
5 min readJul 27, 2018

사실 이전 포스팅들은 제가 공부한 내용들을 정리하고자 작성했습니다. 그러다보니 포스팅 흐름이랄 것이 없었죠. 감사하게도 찾아주시는 분들이 많아져서, 보다 체계적으로 + Fabric이 생소하신 분들도 아키텍쳐를 익혀가실 수 있는 내용으로 연재를 시작하고자 합니다.

5차 이전에는 개념적으로 Fabric의 전반을 훑습니다. 그 이후에는 보다 Deep-dive 해서 살펴볼 예정입니다. 내용은 다음과 같아요:

→ 아래 목차는 9/9 기준으로 수정되었습니다. 아래 내용과 더불어 간간히 Permissioned Blockchain에 대한 저의 의견을 담은 칼럼을 공유드릴 예정입니다.

1. 들어가며: 연재 개요 및 비즈니스를 위한 블록체인의 기준
2. Hyperledger Fabric Model: 패브릭을 구성하는 컴포넌트
3. Hyperledger Fabric Network 1: 컴포넌트들이 실제 네트워크를 구성하는 모양새
4. Hyperledger Fabric Network 2: 그래서 트랜잭션이 어떻게 일어난다구요?
5. Hyperledger Fabric Architecture: 트랜잭션과 gRPC
6. Hyperledger Fabric Architecture: 합의 알고리즘 종류와 HLF가 Kafka를 선택한 이유
7. Hyperledger Fabric Architecture: 블록체인에서의 Sharding
8. Hyperledger Fabric Architecture: 블록체인을 위한 보안

비즈니스를 위한 블록체인은 어때야 하는가

블록체인의 개념에 대해서는 다른 분들이 글을 많이 써주셨으니 저는 언급하지 않겠습니다. 그리고 이제는 IT 바닥에서 블록체인을 논하지 않는 사람이 없습니다. 그리고 이게 마법의 키인 것처럼 이야기되는 경우도 정말 많죠. 그런데 사실, 많은 경우 꼭 블록체인이 필요하지는 않습니다. 나에게 정말 블록체인이 필요할까? 궁금하시다면 이 논문을 한 번 살펴보세요. 3페이지 도표를 살펴보시면 어떤 기준으로 블록체인을 도입해야 하는지 감을 잡을 수 있습니다.

블록체인 플랫폼 선택을 위한 의사결정 흐름을 한 번 생각해보시죠. 지금의 기업 성격— 보안과 기밀이 중요하고 정보의 신뢰성과 무결성이 보장되어야 하는 —을 고려한다면, 대개 도입하게 될 블록체인은 위 논문의 Permissioned Private Blockchain일 것입니다. 그렇다면 그 Permissioned Private Blockchain은 어때야 할까요? Hyperledger Fabric의 답변은 다음과 같습니다.

  • 모든 참여자들의 신원이 확인되어야 함.
  • 네트워크 상의 모든 트랜잭션이 적법한 절차에 따라 허가되어야 함.
  • 트랜잭션 throughput이 보장되어야 함.
  • 트랜잭션 최종 승인에 대한 latency 최적화.
  • 트랜잭션과 해당 데이터에 대한 기밀이 유지되어야 함.

위 요건들을 모두 만족시켜야 한다면, 최적의 플랫폼은 Hyperledger Fabric입니다. 여러분이 금융권이라면 R3 Corda를, 조금 더 자유로운 비즈니스라면 이더리움을, 도전을 원한다면 EOS 등 기타 플랫폼에 도전할 수 있죠. 그렇지만 다음과 같은 이유 때문에 Fabric이 저는 안전한 선택이라고 생각해요:

  1. Configurable Module 구조: 블록체인 네트워크에는 많은 컴포넌트와 정책들이 있습니다. 그 모든 게 ‘조립식'으로 원하는 비즈니스 모델에 맞게 취사 선택할 수 있으니, 유연하게 첫 프로젝트를 시작할 수 있겠죠. 샌드박스 용으로 접근하기도 용이합니다.
  2. 일반 개발 언어 사용 가능: 제가 Fabric에서 가장 좋아하는 점! 블록체인이라는 게 생소하기도 하고, 아키텍쳐 문서들 보면 뭔가 압도되는 것 같은 중압감을 느낍니다. 그런데 거기다가 solidity나 다른 언어를 추가로 배워야 한다고요? 러닝 커브 각도 수직 상승하는 소리가 여기까지 들립니다..! Fabric은 golang, nodejs, java 등을 지원해서 보다 가볍게 시작하기 좋더라구요.
  3. 실행-정리(order)-검증 단계: 다른 플랫폼은 보통 실행하고 검증합니다. Fabric은 이와 달리 order라는 단계가 추가되는데요, 이는 원장에 대한 트랜잭션이 비결정성(non-determinism)을 갖는 경우를 배제하기 위해서입니다. 비결정성이라는 건, a라는 인풋에 대해 b라는 아웃풋이 하나로 결정되는 것이 아니라 [b,c..] 처럼 여러 개의 아웃풋이 나오는 경우를 뜻합니다. 하나의 원장을 동일한 상태로 업데이트해야 하는 블록체인의 미션을 위해하는 경우죠. 다른 블록체인 플랫폼에서는 고유 개발 언어(solidity..)로 이를 컨트롤 하는데, Fabric에서는 일반 언어를 차용하되 아키텍쳐를 달리하여 이를 해결합니다.
  4. 데이터 기밀을 위한 채널: 비즈니스라는 상황에서, 어떨 때에는 몇몇 사람끼리만 특정 내용을 공유해야 하는 경우가 반드시 생깁니다. 그렇지만 일반 블록체인 플랫폼에서는 이런 경우를 지원하지 못하죠. 이럴 때에는 전혀 다른 채널을 통해서 커뮤니케이션 해야 하는 상황이 발생합니다. Fabric은 이런 비즈니스 요건까지 네트워크 안에서 포용하고, 다양한 상황에 유연하게 대처하고자 채널이라는 요소를 넣었습니다. 피어는 하나 이상의 채널에 가입하게 되고, 그 채널에서 공유되는 내용을 구독할 수 있게 됩니다. 슬랙의 채널과 유사하죠.

비즈니스를 말하는 블록체인이 갖추어야 할 것은 이렇습니다. 이런 관점에서 Hyperledger Fabric은 꽤 마음에 드는 플랫폼이죠. 다음 포스팅에서는 Fabric을 구성하는 컴포넌트와 각자의 역할에 대해서 알아보겠습니다.

--

--