Disable peer.deliveryclient.blockGossipEnabled in sample core.yaml (#…

…4911)

Since v2.2 it has been recommended to configure all peers to be orgLeaders
so that they pull blocks from ordering service.

In v2.4 peer.deliveryclient.blockGossipEnabled was added and recommended
to be set to false so that peers don't gossip pulled blocks.

These settings simplify peer behavior and reduce communication between peers
(at the expense of more connections to ordering service).

Finally in v3.0 peer.deliveryclient.blockGossipEnabled is set to false by default.

This change also updates core.yaml and documentation to make these
recommendations clear and consistent.

Closes #3961

Signed-off-by: David Enyeart <enyeart@us.ibm.com>

core/deliverservice/testdata/core.yaml

@@ -114,10 +114,12 @@ peer:
     # connection with ordering service and use delivery protocol
     # to pull ledger blocks from ordering service.
     useLeaderElection: false
-    # Statically defines peer to be an organization "leader",
-    # where this means that current peer will maintain connection
-    # with ordering service and disseminate block across peers in
-    # its own organization. Multiple peers or all peers in an organization
+    # Statically defines peer to be an organization "leader".
+    # Organization leaders maintain connection with ordering service
+    # and pulls blocks as they are created. Optionally, leader peers
+    # may disseminate pulled blocks to peers in its own organization
+    # based on the peer.deliveryclient.blockGossipEnabled setting below.
+    # Multiple peers or all peers in an organization
     # may be configured as org leaders, so that they all pull
     # blocks directly from ordering service.
     orgLeader: true
@@ -242,10 +244,10 @@ peer:
 
     # Gossip state transfer related configuration
     state:
-      # indicates whenever state transfer is enabled or not
-      # default value is false, i.e. state transfer is active
-      # and takes care to sync up missing blocks allowing
-      # lagging peer to catch up to speed with rest network.
+      # Indicates whether state transfer is enabled.
+      # State transfer enabled allows a peer that is not a leader
+      # to sync up missed blocks from other peers.
+      # Default value is false since the recommended value of peer.gossip.orgleader is true.
       # Keep in mind that when peer.gossip.useLeaderElection is true
       # and there are several peers in the organization,
       # or peer.gossip.useLeaderElection is false alongside with
@@ -369,8 +371,8 @@ peer:
 
   # Delivery service related config
   deliveryclient:
-    # Enables this peer to disseminate blocks it pulled from the ordering service
-    # via gossip.
+    # Enables this peer to disseminate blocks it pulls from the ordering service
+    # to other peers in the same organization via gossip.
     # Note that 'gossip.state.enabled' controls point to point block replication
     # of blocks committed in the past.
     blockGossipEnabled: true

docs/source/deploypeer/peerchecklist.md

@@ -146,10 +146,12 @@ gossip:
     # to pull ledger blocks from ordering service.
     useLeaderElection: false
 
-    # Statically defines peer to be an organization "leader",
-    # where this means that current peer will maintain connection
-    # with ordering service and disseminate block across peers in
-    # its own organization. Multiple peers or all peers in an organization
+    # Statically defines peer to be an organization "leader".
+    # Organization leaders maintain connection with ordering service
+    # and pulls blocks as they are created. Optionally, leader peers
+    # may disseminate pulled blocks to peers in its own organization
+    # based on the peer.deliveryclient.blockGossipEnabled setting.
+    # Multiple peers or all peers in an organization
     # may be configured as org leaders, so that they all pull
     # blocks directly from ordering service.
     orgLeader: true
@@ -187,7 +189,7 @@ Peers leverage the Gossip data dissemination protocol to broadcast ledger and ch
 
   - **`useLeaderElection:`** (Defaults to `false` as of v2.2, which is recommended so that peers get blocks from ordering service.) When `useLeaderElection` is set to false, you must configure at least one peer to be the org leader by setting `peer.gossip.orgLeader` to true. Set `useLeaderElection` to true if you prefer that peers use Gossip for block dissemination among peers in the organization.
 
-  - **`orgLeader:`** (Defaults to `true` as of v2.2, which is recommended so that peers get blocks from ordering service.) Set this value to `false` if you want to use Gossip for block dissemination among peers in the organization.
+  - **`orgLeader:`** (Defaults to `true` as of v2.2, which is recommended so that peers get blocks from ordering service.) Set this value to `true` so that the peer retrieves blocks from the ordering service.
 
   - **`state.enabled:`** (Defaults to `false` as of v2.2 which is recommended so that peers get blocks from ordering service.) Set this value to `true` when you want to use Gossip to sync up missing blocks, which allows a lagging peer to catch up with other peers on the network.
 

docs/source/deploypeer/peerplan.md

@@ -81,6 +81,7 @@ To reduce network traffic, in Fabric v2.2 the default core.yaml is configured fo
 * `peer.gossip.useLeaderElection = false`
 * `peer.gossip.orgLeader = true`
 * `peer.gossip.state.enabled = false`
+* `peer.deliveryclient.blockGossipEnabled = false`
 
 If all peers have `orgLeader=true` (recommended), then each peer will get blocks from the ordering service.
 

docs/source/gossip.rst

@@ -12,59 +12,50 @@ consistency. To meet these requirements, Fabric implements a
 Gossip protocol
 ---------------
 
-Peers leverage gossip to broadcast ledger and channel data in a scalable fashion.
-Gossip messaging is continuous, and each peer on a channel is
-constantly receiving current and consistent ledger data from multiple
-peers. Each gossiped message is signed, thereby allowing Byzantine participants
+Peers leverage gossip to establish a network of known available peers and
+optionally broadcast ledger and channel data in a scalable fashion.
+Each gossiped message is signed, thereby allowing Byzantine participants
 sending faked messages to be easily identified and the distribution of the
-message(s) to unwanted targets to be prevented. Peers affected by delays, network
-partitions, or other causes resulting in missed blocks will eventually be
-synced up to the current ledger state by contacting peers in possession of these
-missing blocks.
+message(s) to unwanted targets to be prevented.
 
-The gossip-based data dissemination protocol performs three primary functions on
+The gossip-based data dissemination protocol performs several functions on
 a Fabric network:
 
 1. Manages peer discovery and channel membership, by continually
    identifying available member peers, and eventually detecting peers that have
    gone offline.
-2. Disseminates ledger data across all peers on a channel. Any peer with data
-   that is out of sync with the rest of the channel identifies the
-   missing blocks and syncs itself by copying the correct data.
-3. Bring newly connected peers up to speed by allowing peer-to-peer state
-   transfer update of ledger data.
+2. Disseminates private data between authorized peers on a channel.
+3. Optionally disseminates pulled blocks across all peers on a channel, based on peer.deliveryclient.blockGossipEnabled setting
+4. Optionally bring newly connected peers up to current block height by allowing peer-to-peer state
+   transfer of blocks from other peers, based on peer.gossip.state.enabled setting.
 
 Gossip-based broadcasting operates by peers receiving messages from
 other peers on the channel, and then forwarding these messages to a number of
 randomly selected peers on the channel, where this number is a configurable
 constant. Peers can also exercise a pull mechanism rather than waiting for
 delivery of a message. This cycle repeats, with the result of channel
 membership, ledger and state information continually being kept current and in
-sync. For dissemination of new blocks, the **leader** peer on the channel pulls
-the data from the ordering service and initiates gossip dissemination to peers
+sync. For new blocks, all **leader** peers on the channel pull
+blocks from the ordering service and optionally initiate gossip dissemination to peers
 in its own organization.
 
 Leader election
 ---------------
 
-The leader election mechanism is used to **elect** one peer per organization
-which will maintain connection with the ordering service and initiate distribution of
+The leader election mechanism is used to **elect** which peers per organization
+will pull blocks from the ordering service and optionally initiate distribution of
 newly arrived blocks across the peers of its own organization. Leveraging leader election
 provides the system with the ability to efficiently utilize the bandwidth of the ordering
 service. There are two possible modes of operation for a leader election module:
 
-1. **Static** --- a system administrator manually configures a peer in an organization to
-   be the leader.
-2. **Dynamic** --- peers execute a leader election procedure to select one peer in an
-   organization to become leader.
+1. **Static** --- peer is statically configured to be a leader. Since v2.2 every peer is configured to be a static leader by default.
+2. **Dynamic** --- peers execute a leader election procedure to select one peer in an organization to become leader.
 
 Static leader election
 ~~~~~~~~~~~~~~~~~~~~~~
 
-Static leader election allows you to manually define one or more peers within an
-organization as leader peers.  Please note, however, that having too many peers connect
-to the ordering service may result in inefficient use of bandwidth. To enable static
-leader election mode, configure the following parameters within the section of ``core.yaml``:
+Static leader election allows you to manually define one or more peers within an organization as leader peers.
+To enable static leader election mode, configure the following parameters within the section of ``core.yaml``:
 
 ::
 
@@ -215,14 +206,6 @@ messages are cryptographically signed, malicious peers can never impersonate
 other peers, as they lack a signing key authorized by a root certificate
 authority (CA).
 
-In addition to the automatic forwarding of received messages, a state
-reconciliation process synchronizes **world state** across peers on each
-channel. Each peer continually pulls blocks from other peers on the channel,
-in order to repair its own state if discrepancies are identified. Because fixed
-connectivity is not required to maintain gossip-based data dissemination, the
-process reliably provides data consistency and integrity to the shared ledger,
-including tolerance for node crashes.
-
 Because channels are segregated, peers on one channel cannot message or
 share information on any other channel. Though any peer can belong
 to multiple channels, partitioned messaging prevents blocks from being disseminated

orderer/common/cluster/testdata/blockverification/core.yaml

@@ -114,10 +114,12 @@ peer:
         # connection with ordering service and use delivery protocol
         # to pull ledger blocks from ordering service.
         useLeaderElection: false
-        # Statically defines peer to be an organization "leader",
-        # where this means that current peer will maintain connection
-        # with ordering service and disseminate block across peers in
-        # its own organization. Multiple peers or all peers in an organization
+        # Statically defines peer to be an organization "leader".
+        # Organization leaders maintain connection with ordering service
+        # and pulls blocks as they are created. Optionally, leader peers
+        # may disseminate pulled blocks to peers in its own organization
+        # based on the peer.deliveryclient.blockGossipEnabled setting below.
+        # Multiple peers or all peers in an organization
         # may be configured as org leaders, so that they all pull
         # blocks directly from ordering service.
         orgLeader: true
@@ -242,10 +244,10 @@ peer:
 
         # Gossip state transfer related configuration
         state:
-            # indicates whenever state transfer is enabled or not
-            # default value is false, i.e. state transfer is active
-            # and takes care to sync up missing blocks allowing
-            # lagging peer to catch up to speed with rest network.
+            # Indicates whether state transfer is enabled.
+            # State transfer enabled allows a peer that is not a leader
+            # to sync up missed blocks from other peers.
+            # Default value is false since the recommended value of peer.gossip.orgleader is true.
             # Keep in mind that when peer.gossip.useLeaderElection is true
             # and there are several peers in the organization,
             # or peer.gossip.useLeaderElection is false alongside with
@@ -369,8 +371,8 @@ peer:
 
     # Delivery service related config
     deliveryclient:
-        # Enables this peer to disseminate blocks it pulled from the ordering service
-        # via gossip.
+        # Enables this peer to disseminate blocks it pulls from the ordering service
+        # to other peers in the same organization via gossip.
         # Note that 'gossip.state.enabled' controls point to point block replication
         # of blocks committed in the past.
         blockGossipEnabled: true

sampleconfig/core.yaml

@@ -114,10 +114,12 @@ peer:
         # connection with ordering service and use delivery protocol
         # to pull ledger blocks from ordering service.
         useLeaderElection: false
-        # Statically defines peer to be an organization "leader",
-        # where this means that current peer will maintain connection
-        # with ordering service and disseminate block across peers in
-        # its own organization. Multiple peers or all peers in an organization
+        # Statically defines peer to be an organization "leader".
+        # Organization leaders maintain connection with ordering service
+        # and pulls blocks as they are created. Optionally, leader peers
+        # may disseminate pulled blocks to peers in its own organization
+        # based on the peer.deliveryclient.blockGossipEnabled setting below.
+        # Multiple peers or all peers in an organization
         # may be configured as org leaders, so that they all pull
         # blocks directly from ordering service.
         orgLeader: true
@@ -242,10 +244,10 @@ peer:
 
         # Gossip state transfer related configuration
         state:
-            # indicates whenever state transfer is enabled or not
-            # default value is false, i.e. state transfer is active
-            # and takes care to sync up missing blocks allowing
-            # lagging peer to catch up to speed with rest network.
+            # Indicates whether state transfer is enabled.
+            # State transfer enabled allows a peer that is not a leader
+            # to sync up missed blocks from other peers.
+            # Default value is false since the recommended value of peer.gossip.orgleader is true.
             # Keep in mind that when peer.gossip.useLeaderElection is true
             # and there are several peers in the organization,
             # or peer.gossip.useLeaderElection is false alongside with
@@ -369,11 +371,11 @@ peer:
 
     # Delivery service related config
     deliveryclient:
-        # Enables this peer to disseminate blocks it pulled from the ordering service
-        # via gossip.
+        # Enables this peer to disseminate blocks it pulls from the ordering service
+        # to other peers in the same organization via gossip.
         # Note that 'gossip.state.enabled' controls point to point block replication
         # of blocks committed in the past.
-        blockGossipEnabled: true
+        blockGossipEnabled: false
         # It sets the total time the delivery service may spend in reconnection
         # attempts until its retry logic gives up and returns an error,
         # ignored if peer is a static leader