Gossip protocol on Blockchain

※ 원글 작성 : 23년 6월 12일

Gossip Protocol

Gossip protocol은 클러스터를 이루고 있는 분산 노드들 간의 정보를 공유하기 위한 프로토콜이다. 특정 노드가 가지고 있는 정보를 다수의 노드들에게 빠르게 전달하기 위한 프로토콜로써 클러스터 내의 전체 노드에 전달하지 않아도 소문이 퍼지는 것처럼 결국은 모든 노드가 해당 정보를 알게되는 구조이다. Gossip은 가볍기 때문에 여러 블록체인 플랫폼에서 노드 discovery나 consensus 등에 사용되고 있다. TCP/UDP를 사용하여 정보를 전달하고, 실제 network OSI 7 layer에 포함된 protocol이라기 보다는 네트워크 상에서 '이렇게 사용하겠다'하는 사회적 규약에 더 가깝다. Gossip protocol 본연의 기능 및 특징에 관해서는 좋은 블로그 게시물이나 설명 글이 많기 때문에 제외하고 여기서는 블록체인에 사용되는 gossip에 대해 아주 간략히 개념만 확인 해보려 한다.

Gossip on the Tendermint(Cosmos)

Cosmos의 gossip protocol은 PBFT consensus를 이룰 때 사용된다. Tendermint의 consensus 과정은 이전 글에서 간단히 확인할 수 있다. 이전 글에서 consensus를 이룰 때의 gossip 부분을 발췌하면 아래와 같다.

• 노드는 현재 round의 proposer가 제안한 블록의 PartSet 부분을 gossip 한다. (블록을 빠르게 broadcast 하는데 사용)
• 노드는 prevote/precommit 투표를 gossip한다. NodeB보다 앞서 있는 NodeA는 NodeB의 현재(or 미래) 라운드에 대해 NodeB의 prevote or precommit을 전달하여 다음 단계로 진행될 수 있다.
• 노드 gossip은 제안된 PoLC(Proof of Lock Change) 라운드가 제안된 경우 해당 라운드에 대해 우선 투표한다.
• 노드는 오래된 블록에 대한 블록 commits로 블록 체인 높이가 뒤처진 노드에 대해 gossip 한다.
• 노드는 ReceiveVote 메시지를 gossip 하여 피어에게 이미 투표한 내용에 대해 힌트를 준다.
• 노드는 현재 상태를 모든 이웃 피어에게 브로드캐스트하며 더 이상 gossip 하지 않는다.

이러한 Background Gossip을 처리하는 부분은 tendermint 노드 내에 정의 되어 있는 reactor에서 담당한다. (tendermint의 P2P business는 링크에서 확인할 수 있다.)

Reactor

// tendermint/p2p/base_reactor.go
Reactor는 하나 이상의 channel에서 들어오는 메시지를 처리한다. 새로운 피어가 나의 노드로 join할 때 InitPeer와 AddPeer가 호출되며, 피어가 정지할 시 RemovePeer가 호출된다. Receive는 이 리액터와 연결된 채널에서 메시지가 수신될 때 호출된다.

피어가 추가되면 switch의 로직을 거쳐 reactor의 AddPeer가 실행된다. AddPeer에서는 연결된 peer와의 routine을 go-routine을 통해 병렬 처리한다. (아래의 코드는 tendermint@v0.37.0-rc1 버전이다.)

// AddPeer implements Reactor by spawning multiple gossiping goroutines for the
// peer.
func (conR *Reactor) AddPeer(peer p2p.Peer) {
    if !conR.IsRunning() {
        return
    }

    peerState, ok := peer.Get(types.PeerStateKey).(*PeerState)
    if !ok {
        panic(fmt.Sprintf("peer %v has no state", peer))
    }
    // Begin routines for this peer.
    go conR.gossipDataRoutine(peer, peerState)
    go conR.gossipVotesRoutine(peer, peerState)
    go conR.queryMaj23Routine(peer, peerState)

    // Send our state to peer.
    // If we're block_syncing, broadcast a RoundStepMessage later upon SwitchToConsensus().
    if !conR.WaitSync() {
        conR.sendNewRoundStepMessage(peer)
    }
}

먼저 gossipDataRoutine()에 대해 확인해 본다. 앞서 언급된 것처럼 현재 round의 proposer가 제안한 블록의 PartSet을 gossip 하거나, 해당 피어가 나의 노드보다 이전의 height를 가지고 있을 시 catch up을 도와주거나, 피어에게 proposal 혹은 proposal POL(Proof of Lock)을 전달한다. 해당 function은 chain의 sync를 위하여, 블록 정보를 노드가 가지고 있는 주변 피어에게 gossip을 통해 빠르게 전파하기 위한 함수이다. 이를 통해 주변 노드에게 가장 최근의 합의 상태를 알릴 수 있다.

gossipVotesRoutine()은 PBFT consensus를 이루기 위한 투표 기능들로 구성되어 있다. 각 round 별 preVote, preCommit 등의 투표 루틴을 수행한다. (queryMaj23Routine() 생략)

Gossip은 tendermint 기반 블록체인에서 앞서 확인한 consensus를 위한 용도외에도 transaction mempool에서도 사용이 된다. 특정 tx가 생성되고 validate 검사를 수행하고 통과하면, tx는 mempool에 입력된다. Mempool에 들어온 tx는 주변의 다른 피어에게도 해당 tx를 알리는데 이 때 gossip을 사용하여 다른 노드들에게 전파한다. 수신한 피어도 mempool에 입력하는 똑같은 과정을 거치고 tx를 전파하며, 결국은 gossip 프로토콜을 통해 해당 트랜잭션은 전체 네트워크에 퍼지고 proposer가 mempool에 속한 tx를 포함하여 블록을 생성하게 되면 해당 tx는 효력을 발휘하게 된다.

Gossip on the Hyperledger Fabric

이전에 Hyperledger fabric의 transaction flow에 관해 설명한 글을 가져온다.

1. (User) Transaction 생성 요청
2. (HFC) Proposal 생성, Endorsing peer로 proposal 전달
3. (Endoser) Proposal 검증, 이상없으면 서명인증, HFC로 response
4. (HFC) Orderer로 transaction 전달
5. (Orderer) 수신한 tx를 시간 순서대로 정렬 후 블록 생성, commitment peer로 블록 전달
6. (Commiter) 블록 검증 후 이상없으면 블록체인 연결

위 플로우 중 5.에서 gossip protocol을 사용한다. 앞서 확인했던 tendermint의 block 전파 과정과 비슷한 역할이다. Orderer는 모든 피어와 P2P 연결되지 않고 organize의 리더 피어와 연결되어 있어, 리더 피어에게 생성한 블록을 전달한다(또는 리더 피어가 subscribe한다). 리더 피어는 수신한 블록 정보를 organize내의 다른 피어들에게 gossip을 통해 블록을 전파하게 된다. 다른 피어들은 블록의 유효성을 검증하고 이상이 없을 시 각각 기록된 장부에 블록을 추가/기록한다.

또한 지속적으로 주변 피어들을 발견하고 헬스 체크를 하여 건강한 피어들로 네트워크를 구성하기 위해 gossip 프로토콜을 활용한다. 부트스트랩 피어로 부터 수신한 피어 세트(cosmos의 seed node/persistent peer 역할)에서 부터 시작하여 지속적으로 업데이트 되는 연결 피어 세트들이 각각의 노드에게 존재한다. 이 리스트의 피어들에게 지속적으로 alive 메시지를 전달하여 자신은 건강한 피어임을 증명하고, 반대로 alive 메시지를 수신하여 연결 피어 세트를 업데이트 한다.

Fabric의 gossip protocol 활용 방법이 tendermint와의 다른 점은 transaction 전파는 gossip을 사용하지 않는다는 것이다. 이는 두 블록체인의 구조 차이 떄문에 발생한다. Tendermint 기반 체인은 지분(DPoS)을 보유한 validator가 자신이 보유한 트랜잭션들을 모집하여 블록을 생성한다. 이 때 각 validator는 자신이 보유하고 있는 트랜잭션을 가지고서 블록을 생성하기 때문에 네트워크에 broadcast된 트랜잭션을 validator 노드가 알고 있어야 하며, 때문에 gossip을 통해 빠르게 모든 노드를이 tx를 동기화 해야한다. Fabric의 경우 역할이 다른 여러 피어들의 집합으로 이루어져 있다. tx proposal을 검증하는 endorsing peer, 블록을 저장하여 distributed ledger를 유지하는 commitment peer, consensus를 이루는 orderer peer 등으로 말이다. 그렇기 때문에 tx를 블록에 집어 넣기 위해서는 RAFT 등의 consensus algorithm을 사용하는 orderer에만 전달이 필요하여서 위 플로우처럼 tx 처리에 필요한 로직이 있는 피어들에게 HF client가 직접적으로 전달하게 된다.

Gossip on the Ethereum

Ethereum의 gossip domain에는 네트워크에 빠르게 전파되어야 하는 모든 정보를 포함하고 있다. Beacon의 합의를 이루기 위해 consensus client는 P2P 네트워크, block gossip에 참여하여 다른 피어들로부터 생성된 블록을 수신하고 block proposer가 되면 생성한 block을 broadcast한다. Block을 전파하기 위해 미리 다른 피어들의 discovery가 필요한데, 이는 ethereum의 알고리즘/프로토콜을 정리한 이전 글에서 kademlia와 node discovery 부분과 ethereum의 bootnode 분석 자료에서 참고 할 수 있다.

Gossipsub이라는 이름처럼 subscribe 할 수 있으며 네트워크에 빠르게 전파되어야 하는 정보들은 아래 표와 같다.

Name	Message
beacon_block	SignedBeaconBlock
beacon_aggreate_and_proof	SignedAggregateAndProof
beacon_attestaion_{subnet_id}	Attestation
voluntary_exit	SignedVoluntaryExit
proposer_slashing	ProposerSlashing
attester_slashing	AttesterSlashing

각각의 메시지의 정의와 gossipsub 프로토콜을 깊게 들어가면 너무 길어져서 다음에 기회가 생긴다면 정리를 해볼것이다.

Conclusion

Gossip은 일종의 multicast로써 하나의 노드에서 몇몇의 주변 노드들에게 정보를 전파한다. broadcast를 사용하면 하나의 노드로부터 확실하게 다른 모든 노드에게 전파될 수 있지만 이는 한 노드가 분산 환경의 모든 노드의 정보를 가지고 있어야 하기 때문에 효율성이 매우 낮고, 연결된 노드 관리가 매우 어렵기 때문에 분산 환경에서는 비합리적이다. 한 노드가 multicast로 전파하고 메시지를 수신한 다른 노드가 또다시 multicast로 전파하여 결국은 broadcast와 같은 결과를 노리는 것이 gossip protocol이다. 이 특징을 활용하여 블록체인에서의 gossip은 각각의 플랫폼에서 거의 비슷한 용도로 사용된다. 주변 노드들에게 블록을 전파하거나, 합의를 이루거나, 블록 동기화에 사용되거나, 피어를 식별하고 헬스체크에 활용 하는 등 분산 원장에 동일한 정보를 들고 있기 위한 용도이다. 블록체인 등 분산환경을 다룬다면 gossip protocol을 기억하면 좋을듯 하다.

참고
http://wiki.hash.kr/index.php/%EA%B0%80%EC%8B%AD
https://hyperledger-fabric.readthedocs.io/en/release-2.5/gossip.html?highlight=gossip
https://ethereum.org/en/developers/docs/networking-layer
https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub