github.com/darrenli6/fabric-sdk-example@v0.0.0-20220109053535-94b13b56df8c/docs/source/gossip.rst (about) 1 Gossip data dissemination protocol 2 ================================== 3 4 Hyperledger Fabric optimizes blockchain network performance, security 5 and scalability by dividing workload across transaction execution 6 (endorsing and committing) peers and transaction ordering nodes. This 7 decoupling of network operations requires a secure, reliable and 8 scalable data dissemination protocol to ensure data integrity and 9 consistency. To meet these requirements, Hyperledger Fabric implements a 10 **gossip data dissemination protocol**. 11 12 Gossip protocol 13 --------------- 14 15 Peers leverage gossip to broadcast ledger and channel data in a scalable fashion. 16 Gossip messaging is continuous, and each peer on a channel is 17 constantly receiving current and consistent ledger data, from multiple 18 peers. Each gossiped message is signed, thereby allowing Byzantine participants 19 sending faked messages to be easily identified and the distribution of the 20 message(s) to unwanted targets to be prevented. Peers affected by delays, network 21 partitions or other causations resulting in missed blocks, will eventually be 22 synced up to the current ledger state by contacting peers in possession of these 23 missing blocks. 24 25 The gossip-based data dissemination protocol performs three primary functions on 26 a Hyperledger Fabric network: 27 28 1. Manages peer discovery and channel membership, by continually 29 identifying available member peers, and eventually detecting peers that have 30 gone offline. 31 2. Disseminates ledger data across all peers on a channel. Any peer with data 32 that is out of sync with the rest of the channel identifies the 33 missing blocks and syncs itself by copying the correct data. 34 3. Bring newly connected peers up to speed by allowing peer-to-peer state 35 transfer update of ledger data. 36 37 Gossip-based broadcasting operates by peers receiving messages from 38 other peers on the channel, and then forwarding these messages to a number of 39 randomly-selected peers on the channel, where this number is a configurable 40 constant. Peers can also exercise a pull mechanism, rather than waiting for 41 delivery of a message. This cycle repeats, with the result of channel 42 membership, ledger and state information continually being kept current and in 43 sync. For dissemination of new blocks, the **leader** peer on the channel pulls 44 the data from the ordering service and initiates gossip dissemination to peers. 45 46 Gossip messaging 47 ---------------- 48 49 Online peers indicate their availability by continually broadcasting "alive" 50 messages, with each containing the **public key infrastructure (PKI)** ID and the 51 signature of the sender over the message. Peers maintain channel membership by collecting 52 these alive messages; if no peer receives an alive message from a specific peer, 53 this "dead" peer is eventually purged from channel membership. Because "alive" 54 messages are cryptographically signed, malicious peers can never impersonate 55 other peers, as they lack a signing key authorized by a root certificate 56 authority (CA). 57 58 In addition to the automatic forwarding of received messages, a state 59 reconciliation process synchronizes **world state** across peers on each 60 channel. Each peer continually pulls blocks from other peers on the channel, 61 in order to repair its own state if discrepancies are identified. Because fixed 62 connectivity is not required to maintain gossip-based data dissemination, the 63 process reliably provides data consistency and integrity to the shared ledger, 64 including tolerance for node crashes. 65 66 Because channels are segregated, peers on one channel cannot message or 67 share information on any other channel. Though any peer can belong 68 to multiple channels, partitioned messaging prevents blocks from being disseminated 69 to peers that are not in the channel by applying message routing policies based 70 on peers' channel subscriptions. 71 72 | **Notes:** 73 | 1. Security of point-to-point messages are handled by the peer TLS layer, and do 74 not require signatures. Peers are authenticated by their certificates, 75 which are assigned by a CA. Although TLS certs are also used, it is 76 the peer certificates that are authenticated in the gossip layer. Ledger blocks 77 are signed by the ordering service, and then delivered to the leader peers on a channel. 78 2. Authentication is governed by the membership service provider for the 79 peer. When the peer connects to the channel for the first time, the 80 TLS session binds with the membership identity. This essentially 81 authenticates each peer to the connecting peer, with respect to 82 membership in the network and channel. 83 84 .. Licensed under Creative Commons Attribution 4.0 International License 85 https://creativecommons.org/licenses/by/4.0/ 86