11) Gossip data dissemination protocol

원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/gossip.html

• Hyperledger Fabric에서는 blockchain network 성능 및 보안 및 확장성을 최적화 하기위해, transaction을 나누어서 처리 합니다.
• 이러한 네트워크 분리운영에는 데이터의 무결성 및 일관성을 보장하기 위해, 좋은 '전파 프로토콜'이 있어야 합니다.
• 이러한 요구사항을 만족하기 위해서, 'gossip data dissemination protocol'이 구현된것 입니다.
• Gossip protocol
  
  • peer는 gossip를 활용하여 확장 가능한 형태로 ledger 및 channel 데이터를 방송 합니다.
  • gossip 메세지는 지속적이고, channel에 모든 peer는 이를 끊임없이 수신을 하면서~ 전체 ledger의 일관성이 유지되는것 입니다.
  • 각각에 gossip 메세지는 서명이된었기 떄문에, Byzantine 참가자는 가짜 메세지를 쉽게 확인 할 수 있습니다.
  • 그리고 원치않는 대상으로의 메시지도 방지 할 수 있는것 입니다.
  • 네트워크 단절 등으로 peer에 지연이 발생하여, block의 누락이 발생하면~ 다른 peer에게  ledger 동기화를 요청 할 수 있습니다.
  • ;
  • 이렇듯 Hyperledger Fabric 네트워크의 'gossip data dissemination protocol'은 아래와 같은 3가지 주요 기능이 있습니다.
    • 1. peer 및 channel membership을 관리하면서, 지속적으로 peer 온라인 상태를 확인하고~ 오프라인 상태를 감지 함.
    • 2. ledger 데이터는 channel의 모든 peer에게 전파되고, 데이터 누락이 발생한 peer는 스스로 옳바르게 동기화 합니다.
    • 3. peer-to-peer의 ledger 데이터 전송이 가능해서, 새로운 연결된 peer의 속도를 높일수있습니다.
  • gossip 방송은 channel의 다른 peer로부터 메세지를 수신하는 peer들에 의해 운영이 되는것 입니다.
  • 즉, 수신한 메세지를 임의로 선택한 몇개의 또 다른 peer에게 전달을 하는식인 것이죠. (갯수는 설정가능)
  • 물론 특정 peer가 메세지를 한없이 기다릴 필요는 없고, 떙겨올수도 있습니다.
  • 이러한 메커니즘이 반복이 되는것 이고, channel membership 기반하에~ 전체 ledger 및 state 정보가 동기화 되는것 입니다.
  • 새 block로 치면, 최초에 leader-peer가 orderer로부터 데이터를 떙겨오고~ 자신의 organization에게 'gossip 전파'를 다시 하는것 입니다.
• Leader election
  
  • leader 선출 메커니즘은 한 organization당 하나의 peer을 선출해, orderer와 연결되어 새로운 block의 유통하는것 입니다.
  • leader 선출을 통해서, orderer 대역폭을 효율적으로 사용할수있는것 입니다. (병목현상 방지)
  • 아래와 같은 2가지의 leader 선출 방식이 있습니다.
    • 1. Static : 시스템 관리자가 organization의 특정 peer를 직접지정 하는것
    • 2. Dynamic : peer들이 절차를 수행해서 선출 하는것.
  • Static leader election
    
    • 특정 organization에 leader-peer를 하나 또는 여러개 지정할수있는데, 많이 지정하면~ orderer병목이 발생 하겠죠?
    • 물론 leader-peer의 "failure or crashes"에 관한 HA는 고려되어야 할 것 입니다. (고정되 있으니까!)
    • 아래와 같이 core.yaml에서 설정 할 수 있습니다.
    • peer:
      • # Gossip related configuration
      • # Both `true` is ambiguous and will lead to an error
      • gossip:
        • useLeaderElection: false
        • orgLeader: true
    • 또한 아래와 같이 환경변수으로 재설정 할 수 있습니다.
      • export CORE_PEER_GOSSIP_USELEADERELECTION=false
      • export CORE_PEER_GOSSIP_ORGLEADER=true
  • Dynamic leader election
    
    • ...
    • peer:
      • # Gossip related configuration
      • # Dynamic leader-peer 는 나머지 peer에게 heartbeat 메세지를 계속보냄
      • # 네트워크 단절 및 복구가 되는 상황에서는 일시적으로 복수개의 leader가 나옴
      • gossip:
        • election:
          • leaderAliveThreshold: 10s
        • useLeaderElection: true
        • orgLeader: false
    • ...
• Anchor peers
  
  • anchor-peer는 gossip에서 서로다른 organization의 peer가 서로에 대해 알수있도록 하는데 사용 합니다.
  • anchor-peer를 업데이트하는 config-block이 커밋되면, peer들은 anchor-peer에게 접근해서~ 그가 알고있는 모든 peer를 알게 됩니다.
  • 각 organization로 부터 최소 하나의 peer는 anchor-peer와 연결이 되고, anchor-peer 역시 해당 channel의 모든 peer를 알게 됩니다.
  • 이렇게 gossip 이 지속적으로 진행이 되면서, peer는 모르는 peer의 존재에 관해서 계속 말하게 되고~ 이렇게 해당 channel의 공통적인 membership이 형성될수있게 되는것 입니다.
  • ;
  • ... 그로소리 ...
  • ;
  • organization간에 걸치는 통신은 gossip에 의존적 이기 때문에, 최소 하나의 anchor-peer는 정의되어야 합니다.
  • 그리고 모든 organization는 자신들에  anchor-peer의 HA를 제공해야 합니다.
  • 참고적으로 leader-peer 와 anchor-peer 가 같은 필요가 없다는것은... 잘 이해하셨기를 바랍니다.
  • External and internal endpoints
    
    • gossip이 효과적으로 동작을 하기위해, peer는 자기 및 남에 organization에 endpoint 정보를 잘 가지고 있어야 합니다.
    • peer의 core.yaml에 peer.gossip.bootstrap 속성으로 자기 organization를 명시 합니다. (디폴트 core.peer.address 속성)
    • peer의 core.yaml에 peer.gossip.bootstrap 속성으로 남에 organization를 명시 합니다. 
    • 예) : export CORE_PEER_GOSSIP_BOOTSTRAP=<a list of peer endpoints within the peer's org>
    • 예) : export CORE_PEER_GOSSIP_EXTERNALENDPOINT=<the peer endpoint, as known outside the org>

• Gossip messaging
  • 온라인 상태의 peer는 "alive 메세지"를 계속 방송하면서 자신의 상태를 나태냄니다.
  • 이 메세지에는 "PKI ID" 와 "발신자의 서명"이 포함되어 있습니다.
  • peer는 channel membership을 "alive 메세지" 수집을 통해 유지하게 됩니다.
  • 만약에 특정 peer의 "alive 메세지"를 아무도 받지 못하면, 그 peer는 죽은것이고~ channel membership에서 폐기 됩니다.
  • "alive 메세지"는 암호화 되어 있고, 이 떄문에 악의적인 peer가 있더라도~ 흉내낼수없게됩니다. (서명키가 없으니)
  • ;
  • gossip 과정에서 수신한 메세지를 자동전달 하는것 이외에도, 'state 조정(reconciliation)' 프로세스는 각 channel의 peer간에~ world state를 동기화 합니다.
  • 각각에 peer는 state에 불일치가 확인되면, 다른 peer로 부터 block을 땡겨와서 스스로 고칩니다.
  • gossip의 데이터 전파 과정은 기본적으로 고정된 연결상태를 유지할 필요가 없습니다.
  • 그래서 node-crash 같은 상황에도, 안정적으로 '공유 ledger' 데이터의 일관성 및 무결성을 제공하는~ 내성(tolerance)이 있는것 입니다.
  • ;
  • channel이 분리되어있기 떄문에, 한 channel의 peer가 다른 channel으로 메세지를 보넬 수 없습니다.
  • peer는 복수개의 channel에 속할수있지만, 분할된 메세지이기 때문에~ channel에 없는 peer에게 block이 전파되는것을 막을수있는것 입니다.
  • peer의 channel 구독을 기반으로 메세지 라우팅 정책이 이루어 집니다.
  • (!) Note
    • ...

-끝-