HyperledgerFabric/Core Concept

08. Fabric Gossip Protocol

서견 2023. 7. 14. 10:46

목표 !

  • 패브릭에서 구성요소들이 어떻게 서로 커뮤니케이션을 하는지 ( Gossip protocol ) 을 알아보자

비트나 이더 같은 경우는 마이닝을 하면서 정해직 규칙을 한번씩 검증을 함.

패브릭은 인증서를 기반으로 소통을한다 . ( 피어와 오더러 ,,, 등)

 

Peer의 역할 종류

  • 커밋터
    • 모든 피어는 커밋터 피어임.
    • 레저를 가지고 있고 , excute, validate 하는 역할
  • 앵커
    • 자신이 속한 Organization의 네트워크 정보를 가지고 있고, 전달 해주는 역할.
    • 한 org에 여러 앵커 피어가 있을 수 있다. ( 기본적으로 하나의 앵커피어가 있다.)
  • 리더
    • 오더러부터 블록을 받아온다.
    • 어드민이 리더를 정해줄 수 도 있고, 피어들끼리 선택할 수도 있다.

앵커피어

  • (cli를 이용하여) 채널을 만들 때 오더러 옵션을 통해서 알리게 된다.
  • 앵커 피어 : 앵커피어 트랜젝션을 통해서 네트워크에 알릴 수 있다.
  • 부트스트랩 피어 설정

리더피어

  • 어드민이 정의
    • 환경변수 or core.yaml 을 통해 정의
  • 다이나믹으로 선언
    • 1 leader, 나머지는 follower
    • 피어들은 항상 서로에게 heart beats를 날림
    • 리더의 heart beats가 오지 않으면 새로운 리더 선출 ( ID가 가장 낮은 peer가 리더가 됨 )

오더러 연결

  • configtx 를 통해서 연결 ( genesis.block )

질문?

네트워크 환경이 갖춰진 후에 체인코드가 업데이트 된다거나, 채널에 새로운 피어가 가입이 되는경우등 수정 사항이 생길 때 각 peer들이 가지고 있는 config 파일들이 어떻게 업데이트 되는 것인가요..?

그리고 컨테이너를 통해서 환경 구축중인데 fabric-ca,peer,orderer,kafka등의 이미지를 설치 한 후 exec로 접근하여 내부에서 첫세팅(enroll, MSP설치, 필요한 config 생성, 수정등)을 해주는것인가요?

답변

  1. 말씀해주신 경우들이 각각 방법이 다른데요, a) 체인코드 업데이트는 체인코드를 install, instanciate 하는 것과 방식과 똑같은 방법으로 update(upgrade)를 할 수 있습니다(필요한 경우 endorser들의 sign을 받고 package를 제출하는 등). b) 새 organization을 채널에 추가하는 경우는 기본적으로 config용 tx를 만들어서 블록에 던지면 피어들이 해당 블록을 받아서 정보를 반영하는 식으로 진행이 됩니다. 그런데 이 과정이 꽤 복잡해서 fabric readthedocs에 해당 과정을 자세히 설명해 놓은 링크가 있습니다. 여기를 참조해주세요^^

https://hyperledger-fabric.readthedocs.io/en/release-1.4/channel_update_tutorial.html

c) 기존 가입 되어 있는 organization에 새 피어를 추가할 때는 새 피어의 crypto 관련 인증서를 새로 만들고, 처음에 채널을 만들었을 때 생성된 블록 정보를 가지고 피어를 띄우시면 될 것 같습니다^^.

  1. 방법은 여러가지가 될 수 있는데요, 말씀해주신대로 bash로 직접 접근해서 수정을 해도 됩니다. 저 같은 경우는 docker-compose 파일을 통해서 환경변수와 volume 설정을 통해서 대부분의 설정을 하고 노드를 띄웁니다. msp 폴더 설정 같은 경우 cryptogen이나 ca를 통해서 인증서를 만들고 volume을 붙여서 진행하고요(fabric tutorial이 사용하는 방식), 다른 config들도 비슷한 방법으로 설정을 하고 있습니다. fabric-samples/first-network의 byfn.sh와 해당 폴더 안의 yaml 파일들을 보시면 과정을 좀 더 자세하게 파악하실 수 있을 것 같습니다.

질문

마지막(오더러연결)부분에 대한 질문입니다.

제네시스블럭은 처음 체인이 구동될때 자동으로 config.yaml 파일을 읽어서 그안의 특정내용들을 트랜잭션으로 만들어서 제네시스블럭안에 집어넣고 제네시스블럭을 만든다 라고 이해를했는데 맞나요?

마지막으로, 오더러들은 채널과 관련없이 하이퍼레저 전체네트워크에서 독립적인 노드들이 맞나요(어떤 특정채널에 귀속되있지않음 왜냐하면 엔드유저로부터오는 트랜잭션은 각채널의 체인데이터를 기반으로하기때문에 그것들을 잘 정리해서 올바른 채널로던져주는역할을 하기위해 독립된 노드들로써 "중개자" 역할정도를 한다) 라고 이해를 하고있습니다. 괜찮은 이해가맞을까요?

답변

제네시스 블럭과 오더러 부분 둘 다 정확히 이해하신 것 같습니다.

오더러들은 기본적으로 제네시스 블록을 가지고 오더러용 시스템 채널에만 가입된 상태로 오더링 서비스를 시작하게 됩니다. 다른 일반 채널들(일반 피어들이 가입하는)에는 가입하지 않고요.

 

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

 

https://www.youtube.com/watch?v=10uaSz-vYdM&list=PLlYCl1UOH8dima_f8QOIeY1ieuOAYKo_G&index=8

'HyperledgerFabric > Core Concept' 카테고리의 다른 글

10. Fabric User Management  (0) 2023.07.19
07. Fabric Channel  (0) 2023.07.14
06 . Fabric Identity - 2  (0) 2023.07.14
05. FabricIdentity - 1  (0) 2023.06.23
04. Fabric Network Setting Guide  (0) 2023.06.23