Hyperledger fabric의 config 파일을 보면 ( core.yaml )
gossip:
bootstrap: 127.0.0.1:7051
useLeaderElection: true
orgLeader: false
.
.
.
gossip에 대한 설정이 가능하다.
fabric내에서 gossip protocol의 역할을 보기에 앞서, transaction life cycle을 보겠다.
위의 그림과 같이
(1~3)client가 특정 chaincode에 대해 invoke를 하면, endorsing peer에서 해당 proposal에 대한 검증을 하고 올바를 경우 chaincode를 실행하고, response를 생성해 client에게 보낸다.
(4~5)단순히 원장을 조회하는 transaction이면 여기서 끝이지만, 만약 원장을 update하는 transaction일 경우, 해당 transaction을 orderer에게 보낸다.
orderer는 transaction을 검증한 뒤, 블록을 생성하여 피어들에게 전송한다.
committing peer는 orderer로 부터 받은 블록을 원장에 append한다.
위 그림의 4.1번에 orderer가 블록을 만들어 committing peer에게 전파하는 부분을 보자. 사실상 committing peer란 해당 채널에 모든(다수의)peer일테고, ordered 입장에서 각 블록을 peer들에게 전달해주는 것은 부담이 가게 된다.
이런 부담을 줄여주기 위하여 hyperledger fabric에서는 gossip protocol을 사용한다.
즉 orderer는 한 peer에게만 블록을 전달하고, 그 peer가 나머지 peer들에게 블록을 전달해주는 방식이다.
여기서 orderer에게 직접적으로 블록을 받는 peer가 leader peer이다.
패브릭을 처음 접할 때, peer 사이의 gossip protocol과 orderer 사이의 raft의 차이점을 잘 모르겠던 기억이 나서 적어보았다.
이 외에도…
- 피어 발견 및 채널 멤버쉽을 관리한다. (이용 가능한 피어들을 계속해서 체크함)
- 장부에 기록 할 데이터들을 모든 채널 상의 피어들에 전파.싱크가 안맞는 피어들을 확인하여 모자란 블럭 정보들을 계속해서 공급해줌.
- 새로운 피어가 참여하면 peer to peer 로 장부 데이터들을 업데이트 해줌.
출처: https://hamait.tistory.com/988 [HAMA 블로그]
이러한 기능을 수행한다. 위 블로그에 정리가 참 잘되어 있는 것 같다.
