Hyperledger Fabric Model: 패브릭을 구성하는 컴포넌트

Hyperledger Fabric에서 제시하는 ‘모델’, 즉 이 플랫폼의 구성원은 총 여섯 가지입니다. Asset, Chaincode, Ledger, Privacy, Security & Membership Service, Consensus 인데요, 이들을 알아야 Fabric을 이해할 수 있습니다. 본 포스팅에서는 각각의 정의와 예시, 관련된 또 다른 주요 개념들을 짚어보겠습니다.

Asset과 Ledger


블록체인은 ‘거래’를 전제로 하는 ‘네트워크’입니다. 달리 말해보자면, 무언가가 오고 가고, 그 오고 감의 과정에서 많은 사람들이 개입한다는 것입니다. 그렇다면 뭔가 ‘오고 갈 것’이 있겠죠? 그게 Asset입니다. 이 경우에는 딸기가 되겠죠.

그런데 거래의 과정에 따라, 이 Asset에는 상태값(State)이 생깁니다. 이 딸기가 생산되었다, 생산돼서 지금 포장 중이다, 매장으로 이동 중이다, 매장 어디에 진열되어 있다, 누가 사갔다 이런 것들, 즉 이 asset의 현재 상태를 의미하는 값이 state가 됩니다. 그리고 그 State 값의 변하는 것을 한줄 한줄 기록해둔 것이 원장(ledger)입니다. 이 딸기가 우리에게 오기까지의 모든 발자취를 기록한 것이죠. 이게 모든 블록체인의 핵심이자 출발점입니다. 뒤에 설명드릴 것들은, 그 원장을 업데이트 하는 방법과 업데이트하는 과정을 견고히 하는 장치들이라고 생각하시면 됩니다.

Chaincode와 Consensus


Chaincode와 Consensus는 블록체인을 블록체인답게 해주는 부분입니다. 블록체인에 조금씩 가까워지면서 자연스럽게 드는 의문은 의외로, 이걸 왜 꼭 블록체인으로 해결해야만 하는거지?입니다. 블록체인과 종종 혼동되기도 하는 분산 데이터베이스는 정말 많은 문제를 해결해왔고, 앞으로도 그럴 것입니다. 그런데 ‘신뢰’의 문제는 해결하지 못하죠. 여기에서의 신뢰는 누가 네트워크에 들어올 수 있느냐가 아니라, DB에의 업데이트 시도가 정말로 믿을 수 있느냐는 관점에서의 신뢰입니다. 누군가가 State 값을 업데이트하고 원장에 기록하고자 시도할 때 — 딸기를 포장 상태에서 배달 상태로 바꿀 때 — 여기에 대해 어떻게 programatic한 의사결정을 할 것인가를 chaincode와 consensus가 구현합니다.

Chaincode는 STATE 값에 변화를 주고 (배달중->진열완료) 원장에 업데이트를 하는 실제 로직 부분이라고 생각하시면 됩니다. 권한에 따라 한 네트워크에 있더라도 접근할 수 있는 chaincode가 달라집니다. Consensus는 블록체인 네트워크 내의 peer들이 항상 동기화된 State과 원장을 갖도록 하는 핵심 기술입니다. 특정 조건*에 의해 승인된 업데이트 시도 만을 골라서 chaincode를 실행하게 합니다. 또한 여러 트랜잭션이 동시에 발생한다면, 그 발생한 순서에 따라 제대로 ordering* 되었을 때에만 실제 원장에 반영하도록 하는 것이죠.

*특정 조건이란 endorsement policy를 뜻하며, Ordering service는 hyperledger fabric의 핵심 consensus를 이루는 한 축입니다. 이 둘에 대해서는 향후 포스팅에서 보다 더 자세히 다룰 예정입니다.

Privacy

블록체인에서는 원장 내용과 자산의 상태가 네트워크에 참여한 모든 사람에게 공유됩니다. 그렇지만 비즈니스라는 게, 하다 보면 다른 사람들 모르게 하고 싶은 이야기가 생기기 마련이죠. 전체 채널 말고 따로 상호작용 해야 할 피어들이 있다면 Hyperledger Fabric에서는 Channel이라는 것을 만들 수 있습니다. Channel 이란 여러 피어들의 그룹으로, 네트워크 서브넷 개념으로 생각하시면 됩니다. 그 안에서만 공유되는 내용이 있는데 그 서브넷(채널) 밖으로는 전파되지 않는 거죠. 채널 안에서 피어들은 프라이빗하게 정보를 주고 받을 수 있고, state 값을 임의로 수정하는 등의 작업을 할 수 있습니다. 기업용 블록체인을 지향하는 Fabric의 특성 중 하나로 꼽을 수 있는 지점입니다.

Security & Membership Service

Hyperledger Fabric의 전제는, 신원이 확인되고 가입에 대해 사전 승인을 받은 조직/개인 만이 네트워크에 가입할 수 있다는 것입니다. Membership Service Provider라는 모듈이, 이러한 Fabric의 접근 통제를 구현합니다. 어느 조직에서 누가 클라이언트로, 누가 피어로, 누가 endorser로 들어 올 수 있는지, orderer는 누가 될 것인지 등등을 컨트롤하는 것이죠.

Hyperledger Fabric의 기본적인 개념은 이렇습니다. 다음 포스팅에서는 이를 기반으로 하여, 실제 네트워크를 구성할 때에 어디에 누가 어떻게 배치되는지를 중점적으로 살펴보겠습니다. 궁금한 점이나 보완이 필요한 부분, 토론하고 싶은 부분이 있으시면 댓글로 남겨주세요. 살펴보겠습니다. :)

토론 참가

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