[ 하이퍼 레저 패브릭 ] Gossip 프로토콜 이 란 ? 본문 
 [ 하마 ] 이승현 ( wowlsh 93 @ gmail . com ) 2018 . 08 . 28 14 : 53 
 1 . Gossip 프로토콜 일반 
 이 더리 움 의 DEVp 2 p 네트 워킹 보다 는 비교 적 으로 간단 한 편 인 하이퍼 레저 패브릭 에서 의 네트 워킹 구조 를 살펴보 자 . 
 참고 로 이 더리 움 의 DEVp 2 p 에 관련 되 어 이전 에 작성 한 글 이 있 으니 Public 체인 에서 는 어떻게 하 는지 참 고 하 자 . 
 -> [ Ethereum ] Node Discovery with Kademlia 
 -> [ 이 더리 움 코어 ] DevP 2 P 소스 코드 분석 ( feat . golang ) 
 암튼 둘 다 Goosip 을 이용 하 는데 , Gossip 즉 소문 이란 무엇 인가 ? 내 가 주변 몇 사람 한테 연예인 에 대한 잘못 된 소문 을 내 는 순간 에 그 들 이 또 각자 소문 을 내 고 이런 식 으로 내 가 전체 에게 알리 지 않 아도 전체 가 알 게 되 는 것 을 말 하 며 특징 은 이런 것 이 있 을 수 있 으려나 . 
 - 전체 에 말 하 지 않 아도 되 는 편리 함 . 
 - a 라는 사람 에게 도착 하 는 순서 가 정해져 있 지 않 음 . 어떤 경로 가 끊어져도 , a 는 다른 경로 를 통해서 전달 받 을 수 있 다 . 
 - 중복 전달 될 수 도 있 다 . 
 - 구라 가 횡횡 할 수 있 다 . 
 이런 특징 을 그대로 구현 한 것 이 Goosip 프로토콜 이 다 . 근데 좀 룰 을 정한 게 있 는데 
 - 한 노드 는 다른 노드 의 주소 를 모두 알 고 있 어야 한다 . 
 - 한 노드 는 주변 연결 된 노드 들 의 살 아 있 는지 계속 확인 해야 한다 . 
 - 한 노드 는 자기 가 알 고 있 는 노드 들 의 정보 를 주변 에 계속 알려 줘서 전체 네트워크 가 현재 상황 에 대해 알 수 있 게 한다 . 
 - 소문 을 낼 때 에 는 전체 노드 중 몇 개 를 랜덤 하 게 정해서 소문 을 퍼트린 다 . 
 - 이 더리 움 은 구라 를 수용 하 면서 신뢰 를 만들 고 , 하이퍼 레저 패브릭 은 인증 을 통해서 원천 봉쇄 한다 . 
 자 이 아이디어 를 머리 에 담 고 하이퍼 레저 패브릭 을 살펴보 자 . 
 이미 아 시 는 분 도 있 겠 지만 하이퍼 레저 패브릭 의 워크 플로우 를 간단히 설명 하 면 , 
 1 . 클라이언트 는 어플리케이션 ( SDK ) 를 통해서 Peer 들 에게 트랜잭션 을 실행 시킨다 . 
 2 . Endorsement 역할 을 하 는 이 Peer 들 은 체인 코드 를 실행 시키 고 장착 된 컨 센서스 알고리즘 에 따라서 결과 를 내 어 다시 클라 쪽 으로 read / write 셋 을 전달 한다 . ( 이 과정 에서 장부 를 업데이트 하 지 않 음 ) 
 3 . 이 결과 셋 을 가지 고 orderer 서비스 에게 순서 를 정해서 블록 화 해 달 라고 요청 한다 . 
 4 . orerer 서비스 는 블록 화 한 후 에 Peer 들 에게 이 블록 을 검증 하 고 저장 하 여라 ~~ 하 고 보내 준다 . 
 이 과정 중 에서 Gossip 프로토콜 이 이용 되 는 것 이 바로 4 번 flow 에서 이 다 . 
 즉 orderer 는 모든 peer 과 커뮤니케이션 을 하 는 게 아니 라 , 대표 peer 하나 에게 알리 면 이 peer 가 gossip 을 통해 점진 적 으로 전체 로 전달 되게 되 는 것 이 다 . 각 피어 는 전달 받 은 블록 ( 트랜잭션 뭉치 들 ) 을 검증 하 고 장부 ( LevelDB ) 에 저장 한다 . 
 2 . Gossip 프로토콜 with 하이퍼 레저 패브릭 
 다시 좀 더 자세히 알 아 보 자 . 위 에서 설명 했 듯이 하이 퍼래 저 패브릭 에서 는 트랜잭션 실행 피어 와 트랜잭션 정렬 노드 사이 에서 업무 를 분담 해서 네트 웍 부하 를 처리 한다 . 이런 분리 된 네트워크 에서 확장 성 , 보안 성 등 에 대한 처리 를 유연 하 게 하 기 위해 패브릭 은 가 쉽 데이터 전파 프로토콜 을 만들 었 다 . 
 각 가십 메세지 들 은 서명 되 어서 전달 되 며 , 그 에 따라 중간 에 악의 적 인 노드 의 메세지 도 쉽 게 확인 되 며 , 가 쉽 프로토콜 특성 상 늦 게 도착 하 거나 , 몇몇 노드 들 의 네트워크 분단 상황 에서 도 결국 싱크 는 맞춰 지 게 된다 . 
 패 프릭 네트워크 에서 가 쉽 데이터 전파 프로토콜 의 주요 3 가지 기능 으로 는 다음 과 같 다 . 
 피 어 발견 및 채널 멤버 쉽 을 관리 한다 . ( 이용 가능 한 피어 들 을 계속 해서 체크 함 ) 
 장부 에 기록 할 데이터 들 을 모든 채널 상 의 피어 들 에 전파 . 싱크 가 안 맞 는 피어 들 을 확인 하 여 모자란 블럭 정보 들 을 계속 해서 공급 해 줌 . 
 새로운 피어 가 참여 하 면 peer to peer 로 장부 데이터 들 을 업데이트 해줌 . 
 동일 한 채널 위 의 피어 들 은 메세지 를 계속 해서 수신 하 고 , 주변 피어 에 전파 하 며 , 싱크 를 맞추 게 된다 . 주변 피어 의 갯 수 는 설정 으로 정해져 있 으며 , Pull 메커니즘 을 따른다 . 따라서 메세지 가 올 때 까지 기다리 는 게 아니 라 , 적극 적 으로 가지 고 오 려는 행동 을 한다 . 채널 상 의 각 조직 의 리더 피어 는 오 더러 에게 데이터 를 가져 ( Pull ) 온 후 자신 의 조직 에 포함 된 피어 들 에게 전파 하 기 시작 한다 . 
 다음 과 같이 2 가지 방식 이 있 다 . 
 Static – 시스템 관리자 는 조직 마다 하나 의 피어 를 설정 으로 정한다 . 
 Dynamic – 리더 선출 프로세스 에 따라 결정 되 는데 , 자세 한 것 은 젤 아래 레퍼런스 ( 정식 문서 ) 를 참 고 하 자 . 
 앵커 ( Anchor ) 피 어 
 앵커 피어 는 다른 조직 들 간 의 가 쉽 커뮤니케이션 을 용이 하 게 하 기 위해 사용 된다 . 즉 하나 의 조직 에서 다른 조직 에 가 쉽 메세지 를 전달 할 때 앵커 피어 에게 전달 한다 . 체인 코드 를 호출 할 때 보증 을 맡 는 피어 가 자신 의 조직 에 만 있 는 것 은 아니 기 않 나 . 그리고 이 말 은 앵커 피어 는 조직 간 커뮤니케이션 에 SPOF 도 된다는 의미 이 다 . 앵커 피어 에 대한 정보 는 채널 설정 에서 정의 되 어 있 다 . 참고 로 앵커 피어 가 리더 피 어 역할 을 해 되 도 되 며 , 독립 적 일 수 도 있 다 . 
 1 . 각 피어 간 의 메세지 보안 은 TLS 레이어 에 의해 작동 하 며 서명 을 요구 하 지 않 는다 . 피어 들 은 그 들 의 신 원서 ( CA 에 의해 부여 된 certificates ) 로 인증 ( authenticated ) 되 며 , TLS certs ( ECerts 를 가지 고 TCA 에 의해 만들 어 지 는 ) 가 사용 될 지 라도 , 가 쉽 레이어 에서 인증 되 는 것 은 피 어신 원서 이 다 . 장부 블록 은 오 더러 서비스 에 의해 서명 되 며 , 채널 의 리더 피어 들 에게 전달 된다 . 
 2 . 인증 ( Authentication ) 은 피어 의 " MSP " 에 의해 조정 받 는다 . 피어 가 처음 으로 채널 상 에 접속 하 게 되 면 , TLS 세션 은 멤버 쉽 아이 덴 터 티 와 엮이 는데 , 이것 은 기본 적 으로 각각 의 피어 를 채널 과 네트 웍 상 의 멤버 쉽 으로 인증 하 는 것 이 된다 . 
 이렇게 정리 된 내용 을 토대 로 다음 에 는 실제 하이퍼 레저 패브릭 의 gossip 에 관련 된 코드 를 분석 해 보 도록 한다 . 
 언제 하 냐고 ? 신 이 나 면 ~~ 
 https : / / hyperledger - fabric . readthedocs . io / en / release - 1 . 2 / gossip . html 
 https : / / github . com / hyperledger / fabric / tree / release - 1 . 2 / gossip 
 Prev 1 · · · 10 11 12 13 14 15 16 17 18 · · · 627 Next