04. Fabric Network Setting Guide

목표 ! : Fabric 의 전체적인 구조도와 구조도 속의 네트워크의 구성요소

Fabric 네트워크의 세팅 과정 알아보기 ( 머리속의 그림 그리기)

패브릭의 가장 중요한 요소

1. 오더러
   1. 트랜잭션을 블럭에 차곡차곡 쌓아서 피어에게 던져줌
   2. 피어는 그 블록을 검증을 하고 원장에 작성함.
   3. 블록체인 네트워크에 관련된 전반적인 기능을 수행
2. 피어
   1. 블록체인 데이터를 보유 ( 원장 보유 )
   2. 체인코드를 가지고 원장에 직접적으로 접근하고
3. 유저 , 어플리케이션 ( A )
   1. 트랜잭션들을 만들어서 자신의 키로 서명해서 피어에게 전달하고 다시 전달 받은걸 오더러에게 전달
4. Ledger(블록체인) ( L )
   1. 오더러도 원장을 들고는 있지만 실제로 직접적으로 렛저 데이터에 접근하고 렛저데이터를 시뮬레이팅하고 validation 하는건 피어 노드다.
5. ChainCode ( S )
   1. 피어가 들고 있음. 구체적으로는 피어가 있는 인스턴스에 도커의 형태로 체인코드가 올라감. 도커 피어 인스턴스가 있고 도커 체인코드 인스턴스가 올라간다
   2. 체인코드가 예를 들어 Fabcar 체인코드가 인스턴스가 하나 뜬다 . 체인코드 별로 도커 인스턴스가 올라간다.
6. CA , Fabric -CA ( CA )
7. Organization ( R )
8. channel configuration ( CC )
9. Network Config ( NC )
10. Channel ( C )

 

 

패브릭 구성요소 중 가장 중요 한것 중 하나는 구성요소들의 권한들을 어떻게 할 것인가 ?

• 권한관리는 기본적으로 인증서 기반으로 함. ( X.509 기반) 인증서를 만들고 관리하고 삭제하고 하는 것들을 CA컴포넌트를 통해 제공
• 인증서 기반으로 작동을 하기 때문에 처음에 중간에 그 이후에 계속 패브릭 네트워크가 진행중인 상황동안 인증서 관리를 어떻게 할것인가?

채널은 ?

• 피어들이 채널에 가입 할 수있는데 같은 채널 안에 있는 피어들은 해당 채널에 있는 스마트 컨트랙트 , 원장을 공유할 수 있다.
• 채널에 가입되어 있는 피어들끼리 공유를 하기 위해서는 같은 체인코드가 있어야 한다.

P1이 다른 채널에 중복가입하게 된 경우?

• 같은 채널에 있는 같은 데이터만 공유 할 수 있음.

Organization ?

• Identity를 관리하는 하나의 그룹
• 패브릭에서 네트워크를 관리하고 설정을 할 때 Org 단위로 많이 관리를 함.

1. 크립토 관련 작업
2. Fabric - CA
3. Cryptogen
4. Orderer, Peer 띄우기
5. Kafka, zookeeper
6. 채널생성

 

질문정리 !

 

질문 1번

설명해주신 네트워크는 기업이 Org로 참여했을시에 이상적인 네트워크 구조인 것 같은데, 기업들이 네트워크에 Org가 아닌 Peer로써 참여했을때, Endorse, Anchor, Commit 의 역할 배분을 어떻게 해야하는지 궁금합니다.

 

답변 :

 이 부분은 비즈니스적으로 생각하여 역할을 나누어야 하고, 각 구성원의 이해관계에 따라 많이 달라질 것 같은데요, 제가 생각하는 방향은 이렇습니다.  a) 일단 모든 피어는 커미터의 역할을 가지기 때문에 따로 배분이 없을 것 같습니다.   b) 앵커의 경우는 비즈니스적인 역할 보다는 개발적인 관점에서 네트워크에서 서로 노드 정보를 공유합니다. 따라서 어떤 업체가 하든 상관없지만 개발 관련해서 좀 더 유지보수를 잘 하는 업체 쪽이 좋을 것 같습니다.  c) 트랜젝션을 검증하는 Endorse의 역할을 하느냐 안 하느냐가 핵심적인 부분이 될 것 같은데요. 블록체인이 서로 신뢰하지 않는 당사자들을 연결해주는 네트워크이므로 그러한 이해당사자들은 기본적으로 endorse의 역할을 가지는게 맞지 않나 생각합니다. 그리고 그 이해당사자들 사이에 중재를 해줄 수 있는 3rd party가 들어오는 것도 좋고요. 또는 아예 반대로 3rd party(여러 개일 경우)만 endorse의 역할을 하는 것도 고려 해 볼 수 있을 것 같습니다.  

 

질문 2번

Hyperledger fabric docs 예제중 fabcar를 따라하다보면 계정 관련하여 admin , user1 이런식으로 계정을 따로따로 생성하는데, 이렇게 나누는 의미에 대해 궁금합니다. 기업내부에서 Cli(app)을 사용하는 사용자의 권한?을 나누는 건가요 ?  

 

답변 :  

네 맞습니다. 어떤 시스템에서든 권한의 분리는 보안의 핵심 요소인데요, 만약 어드민이 아닌 일반 사용자가 자기 마음대로 네트워크의 채널을 날려 버리거나 체인코드를 없애버리는 건 좋지 않은 일일 겁니다. 그래서 fabric은 여러 가지로 권한을 분리할 수 있는 요소가 있습니다.  

 

질문 3번

질문 하나 드려도 될까요.. 3강에서 말씀해주신 공부방법대로 진행해보고 있습니다. VM으로 HostOnly 네트워크 설정, Fabric-ca를 이용하여 커맨드 명령을 통하여 테스트 체인코드를 설치하고 트랜잭션 테스트를 완료해 보았습니다. 다음 github에서 fabric-sample 1.3을 다운받아 node.js로 구현된 sdk를 테스트 해보려고 하는데 진행방향에 대해 질문드리고 싶습니다. 테스트 환경을 보니 sample 내에 있는 .sh 파일을 이용하여 fabric-ca, peer, orderer등의 컨테이너를 설치하여 테스트 하는 것 같은데 앞서 HostOnly 네트워크 방식에서 테스트 하였던 것처럼 VM을 이용하여 fabric-ca, peer, orderer 등의 이미지 파일을 만들고 VM에서 테스트 가능하게끔 하려면 sample의 balance-transfer/artifacts에 있는 .yaml 파일들의 path 내용을 수정하여 진행 하면 될까요?   HostOnly 네트워크 설정하여 테스트 했던 VM 이미지 파일을 가져와서 적용하려고 키, 인증서 파일들의 path를 기존 설치된 path로 수정하니 자꾸 아래와 같은 에러가 발생합니다. 인증서에 대한 문제일 거라 추측하고 있습니다. 내용이 어려워 많이 헤매고 있습니다 도움 부탁드릴게요.. ㅠ failed Error: Calling enrollment endpoint failed with error [Error: write EPROTO 140217326716736:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:827:\n]   또 fabric-sample 1.3 환경의 2CA는 같은 채널 내에 가입된 다른CA의 두 peer를 통해 intermediate CA를 의미하는것이 맞다고 이해 하면 될까요?  

 

답변 :

말씀하신 대로 yaml 파일의 path를 수정해주시면 됩니다. 거의 network-config.yaml 파일 위주로 수정 하시면 될 것 같습니다.     마지막 질문 같은 경우는 첫 CA를 상위로 하는 intermediate CA로 보셔도 되고, org마다 또 다른 root CA를 구성했다고 봐도 문제 없을 것 같습니다. balance-transfer 예제에서는 org1, org2가 각각 root ca를 따로 가지고 있습니다.  

 

질문 3-1번

 HostOnly 네트워크 설정하여 테스트 했던 VM 이미지 파일을 가져와서 적용하려고 키, 인증서 파일들의 path를 기존 설치된 path로 수정하니 자꾸 아래와 같은 에러가 발생합니다. 인증서에 대한 문제일 거라 추측하고 있습니다. failed Error: Calling enrollment endpoint failed with error [Error: write EPROTO 140217326716736:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:827:\n] 제가 path 설정을 잘못한 탓일까요..?   그리고 org마다 다른 root CA를 구성하였는데 다른 root CA로부터 인증받는 두 peer가 같은 채널에 속하여 트랜잭션을 실행 할 수 있는것이 가능한가요???  

 

답변:

흠 해당 에러 같은 경우는 제가 생각해도 path와 인증서 관련 문제일 것 같은데요. 해당 에러 라인만 보고 어떤게 문제인지 파악하기는 어렵네요 ㅠㅠ...   네 그리고 org마다 다른 root CA여도 가능한데요,   아래 링크의 댓글들을 읽어보시면 좋을 듯 합니다. https://stackoverflow.com/questions/48087326/fabric-ca-root-server-and-intermediate-server   그리고 balance-tranfser의 arifacts의 cryptogen, configtx yaml 파일들을 한 번 참조해보시면 좋을 것 같습니다. 주석과 함께 설명이 잘 나와있습니다^^  

 

질문 3-2 번

링크해주신 댓글 잘 읽어 보았습니다. 트랜잭션 실행에 관해서 peer들은 다른 root CA로부터 등록된 것에 영향을 받지 않고 소속된 채널의 orderer에 의존하는것으로 트랜잭션을 수행 할 수 있다. 라고 이해 할 수 있을까요? 질문이 꼬리에 꼬리를 물어 죄송합니다..   그리고 sample의 config에 "container_name:"을 입력하는 란이 있는데 이부분은 VM으로 테스트 할 경우 삭제하여도 되는걸까요? hostname을 입력해주어야 하는걸까요..?  

 

답변:

트랜젝션 실행에 관해서 해당 peer가 실행하고자 하는 체인코드를 실행할 수 있는 권한(체인코드가 설치 되어 있고, endorser 등의 역할을 할 수 있는)이 있으면 되고, 그 상태에서는 오더러와 상관이 없다고 보면 될 것 같습니다. (+ 추가: 처음에 crypto 인증서들을 생성할 때에는 오더러와 피어는 도메인을 기반으로 바인딩 되어 있어야 하구요, 이 인증서를 fabric-ca를 이용해서 생성하느냐 외부 ca를 이용하느냐가 상관이 없다 라고 보시면 될 것 같습니다.)     그리고 container_name은 docker-compose.yaml을 말씀하시는 건가요? VM위에 fabric의 도커를 다시 띄우는게 아니라 네이티브 go 프로그램으로 띄우시는 상황인지 잘 모르겠는데 저는 항상 기본적으로 도커 이미지를 띄우는 식으로 진행을 해서 정확히 대답을 드리기 어렵네요 ㅠㅠ.   트랜잭션 실행 조건에 대해 이해 되었습니다. 서로 다른 fabric-ca에서 인증서를 발급받은 두 피어가 같은 채널에 가입하여 트랜잭션을 실행 가능한지 궁금했습니다. 직접 환경구성 하여 테스트 진행 예정입니다. 아직 많은 공부가 필요 한 것 같습니다.   그리고 container_name 질문은 docker-compose.yaml에 있는 container_name을 말씀드린 것이 맞습니다. 이 부분 역시 제가 다시 확인해보겠습니다.    

 

질문 4

동영상 마지막부분에서 피어2가 추가됬을떄 체인코드,레저 둘다 공유한다고하셨는데 체인코드만 공유하고 레저는 서로 독립적으로 가지는거아닌가요? 2. 피어2가 조인할떄 피어2의 레저는 피어1의 레저로 동기화를 하나요? 만약, 피어 11,12,13,14가 같은채널에 더 있다고했을떄는 누구의 레저로 동기화를 하나요?  

 

답변:

1. 피어별로 체인코드도, 레저도 독립적으로(라고 하는게 정확한 표현인지 잘 모르겠는데요) 가지게 됩니다. 체인코드를 피어별로 각각 install(설치하면 도커or프로세스의 형태로 띄워집니다)하고, 레저도 독립적으로 가지고 있다고 봐야 할 것 같습니다. peer2가 또 다른 채널에 가입 되어 있어서 다른 체인코드들을 들고 있을 수 있으니까요.    

2. 네. 한 org에 있는 피어들은 피어들 중 한 명이 leader 피어가 되는데, 영상의 상황에서는 peer1이 리더 피어이므로 peer1의 레저도 동기화합니다.. 이후 다른 피어가 추가 되어도 리더 피어를 기준으로 레저를 동기화하게 됩니다.  다만 fabric topic에 따르면 좀 지난 블록의 경우에는 리더 피어가 아닌 피어의 블록을 가지고도 싱크할 수 있다고 하네요.(https://lists.hyperledger.org/g/fabric/topic/29165834)  

 

질문 4-1

 리더피어는 채널을 생성한 상태에서 "처음"으로 조인한 피어가 리더피어가 되나요? 2. 리더피어가 더이상 살아있지않다면 "누가" "어떤" 조건으로 새로운 리더로 선정되나요?  

 

답변:

Peer와 Orderer가 서로 커뮤니케이션 하는 프로토콜을 fabric에서는 gossip protocol이라고 정의하고 있습니다. 이 gossip protocol 안에 피어들이 리더 피어를 선정하는 방법, 피어들끼리 서로를 발견(디스커버리) 하는 방법들이 포함 되어 있습니다. 

1. 네, 네트워크에 피어 그룹(1개여도)이 존재 할 때 리더 피어가 존재해야 오더러로부터 블록을 가져 올 수 있습니다.

2. 이 부분은 fabric readdoc이 아니라 소스코드에 소스와 함께 pseudo 알고리즘이 쓰여 있는데요, 기본적으로 리더 피어가 존재할 때 리더 피어는 주기적으로 피어들에게 heartbeat을 보내는데, heartbeat이 끊기면 새 리더 선출로 들어간다고 합니다. 리더 선출 과정으로 들어가면 서로 메시지를 주고 받는데 이 때 서로의 peer id를 비교해서 더 낮은 id를 가지고 있는 피어가 리더로 선정됩니다.     다음 링크에 더욱 자세한 설명이 있습니다.     https://hyperledger-fabric.readthedocs.io/en/release-1.4/gossip.html https://github.com/hyperledger/fabric/blob/release-1.4/gossip/election/election.go  

 

본 게시글은 Dapp Campus 의 강의를 보고 정리한 내용입니다!

https://www.youtube.com/watch?v=EJjJg5uN6zU&list=PLlYCl1UOH8dima_f8QOIeY1ieuOAYKo_G&index=3