컴포넌트들이 실제 네트워크를 구성하는 모양새

출처: http://www.hitachi.com/rev/archive/2017/r2017_01/104/index.html?WT.mc_id=ksearch_96

오늘 살펴볼 하이퍼레저 패브릭의 네트워크는 공식 문서의 네트워크 구성 과정 번역으로 갈음하려고 합니다. 단, 의미를 명확히 하고자 의역된 부분이 있으며 제가 첨언한 부분도 있습니다. 또한 아래 포스팅의 이미지 출처는 모두 위 링크임을 먼저 밝힙니다.

전반적인 ‘블록체인 네트워크’의 구성은 위 그림과 같다는 것은 확실히 하고 시작하려고 합니다. 이전 포스팅에서 어떤 것들이 Hyperledger의 모델을 구성하는지 추상적인 수준에서 서술했다면, 실제 구현 레벨에서는 이들이 어떻게 직조되어 있는지 위 그림에서 확인할 수 있습니다. 1:1로 매핑하기 어렵고 상호 중첩되는 부분이 있지만, 위 다이어그램의 identity가 이전 포스팅의 security & membership service, policy는 privacy와 chaincode의 일부분, blockchain과 transaction은 ledger, consensus와 동일시할 수 있고 smart contract은 chaincode의 다른 이름입니다. 이를 유념하고 Fabric 네트워크를 살펴보겠습니다.

네트워크 생성


태초에 네트워크가 생성될 때에는 오더링 서비스(O), 생성된 네트워크에 대한 정책(NP), 클라이언트 어플리케이션(CA), 그 어플리케이션을 소유하는 네트워크 참가 조직(RD)가 필요합니다. 오더링 서비스가 네트워크 내의 채널에 대한 구성 정보를 소유하고, 이를 기반으로 하여 관리자 역할을 합니다. 각 채널에 대한 구성 정보는 채널에 대한 정책과 멤버십 정책을 뜻합니다.

컨소시움 정의


블록체인은 네트워크입니다. 하나의 조직만 참여해서는 의미가 없죠. 컨소시움 — 서로 거래해야 하는 비즈니스적 상황에 있는 조직들이 네트워크 운영을 위한 정책에 동의한 결과 — 이 생성된 바로 이후 결정됩니다. 좌측의 클라이언트 어플리케이션이 조직이 추가됨에 따라 더해졌고, 우측 상단에 RB(다른조직)이 추가되었고 이들이 X509 root certificate에 따라 서로를 확인하고 있음을 알 수 있습니다.

컨소시움에 대한 채널 생성


채널은 이전 포스팅의 privacy 부분에서 이야기한 것처럼, 네트워크 내 컴포넌트 간의 프라이빗한 통신을 지원하는 커뮤니케이션 도구입니다. 오더링 서비스 내에서 컨피그 블럭을 생성하는 것으로 구현되고, 이 블럭에서는 채널 자체의 구성정보를 관장합니다. 채널에 가입하고자 하는 조직은 이 채널의 컨피그에 따라 반드시 추가로 인증을 거쳐야 합니다. 향후에도 그 채널의 정책의 관리를 받습니다. 위 다이어그램에서는 채널 C1이 추가되고 이에 대한 CP(Channel Policy)가 더해졌으며, 여기에 참여하고 있는 조직 RA, RB가 표현되어 있죠.

피어와 채널


네트워크에 참여하는 조직에 속하는 Peer가 이제 네트워크에 등장합니다. 지금까지 구조가 완성이 됐다면 실제 참여자가 등장하는 겁니다. 위 그림에서는P1이 등장하고, 그가 들고 있는 원장(L1)이 표현이 되어 있죠. Peer에는 다음과 같은 네 가지 역할이 있고, 한 노드가 여러 역할을 수행할 수도 있습니다.

* Endorsing Peer: 스마트 컨트랙트에 수행될 트랜잭션을 시뮬레이션해보고 그 결과를 클라이언트 어플리케이션에 리턴해주는 피어입니다. 트랜잭션을 검증하는 역할을 하는 거죠.
* Committing Peer: 오더링까지 되어서 전달된 트랜잭션 블럭을 검증하고, 검증이 완료되면 자기가 갖고 있는 원장에 해당 블럭을 추가하고 관리합니다. 모든 피어는 기본적으로 committing peer입니다.
* Anchor Peer: 채널 내의 대표 피어입니다. 채널에 다른 조직이 가입하면 가장 먼저 발견하는 피어입니다.
* Leading Peer: 여러 피어를 가지고 있는 조직의 경우, 모든 피어를 대표하여 네트워크와 커뮤니케이션 하는 피어입니다.

어플리케이션과 스마트 컨트랙트


스마트컨트랙트(체인코드)가 피어에 반드시 설치되고 실행되어야만 클라이언트 어플리케이션이 정상 작동하고, 트랜잭션 프로포절이 들어올 수 있습니다. 위 다이어그램의 S4가 추가된 것에 주목하세요. 트랜잭션 프로포절이 클라이언트 어플리케이션에서 발생하면 스마트 컨트랙트가 endorsing peer에 시뮬레이션을 돌리고 그 결과(endorsement)를 다시 어플리케이션에 리턴합니다. 그 결과가 endorsement policy에 부합하면 그 결과를 Ordering service(O1)에 보내서 committing peer에 보냅니다.

네트워크 완성


다른 채널에 가입하는 것, 다른 피어가 등장하는 것은 위에 설명한 단계를 잘 이해하셨으면 어려울 게 없는 부분이라 임의로 생략했습니다. 위 다이어그램은 네트워크가 확장되고 난 모습을 보여주는데요, 여기서 ledger가 더 추가된 이유와 지금 네트워크가 어떤 상황인지 살펴보겠습니다.

* 이 네트워크에는 하나의 Ordering service(O)가 있습니다. 네트워크를 정의하는 NP가 있으며 RD라는 조직이 Ordering service를 하고 있는 것을 알 수 있네요.
* 그리고 총 RA, RB, RC, RD라는 네 개의 조직이 네트워크에 참여하고 있으며 각각 CA1, CA2, CA3, CA4라는 인증 정책을 가지고 있죠.
* 채널은 C1, C2 이렇게 두 개가 있습니다. C1은 CP1이라는 정책을, C2는 CP2를 갖고 있습니다. 각각 RA, RB / RB, RC를 채널 멤버로 갖고 있네요.
이제 피어 관점에서 봅시다. 세 개의 피어가 있고, 각각은 RA, RB, RC 조직에 속합니다. RD는 오더링 서비스를 하고 있으니 피어를 따로 갖고 있지 않는 것으로 보이네요.
* 각각의 피어는 속한 채널이 갖고 있는 원장(L)과 스마트 컨트랙트(S)를 갖고 있는데, P2의 경우 두 개의 채널에 동시에 속하니 두 개의 원장과 컨트랙트를 동시에 들고 있습니다.

다음에는 실제 트랜잭션이 어떻게 일어나는지 살펴보겠습니다.

토론 참가

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