mdlint and vale editorial updates in Concepts/Consensus-Protocols directory

docs/Concepts/Consensus-Protocols/Comparing-PoA.md

@@ -1,67 +1,66 @@
-*[Byzantine fault tolerant]: Ability to function correctly and reach consensus despite nodes failing or propagating incorrect information to peers.
+*[Byzantine fault tolerant]: The ability to function correctly and reach consensus despite nodes
+failing or propagating incorrect information to peers.
 
-# Comparing Proof of Authority Consensus Protocols  
+# Comparing Proof of Authority consensus protocols
 
-Besu implements the Clique and IBFT 2.0 Proof of Authority consensus protocols. Proof of Authority 
-consensus protocols are used when participants are known to each other and there is a level of trust between them. 
-For example, in a permissioned consortium network. 
+Besu implements the Clique and IBFT 2.0 Proof of Authority consensus protocols. Proof of Authority
+consensus protocols work when participants know each other and there is a level of trust between
+them. For example, in a permissioned consortium network.
 
-Proof of Authority consensus protocols allow faster block times and have a much greater throughput of transactions 
-than the Ethash Proof of Work consensus protocol used on the Ethereum MainNet. 
+Proof of Authority consensus protocols have faster block times and a much greater transaction
+throughput than the Ethash Proof of Work consensus protocol used on the Ethereum MainNet.
 
-In Clique and IBFT 2.0, a group of nodes in the network act as signers (Clique) or validators (IBFT 2.0). These nodes propose, validate, 
-and add blocks to the blockchain. Nodes are added to or removed from the signer/validator pool by the existing group of nodes voting. 
+In Clique and IBFT 2.0, a group of nodes in the network act as signers (Clique) or validators
+(IBFT 2.0). The existing nodes in the signer/validator pool vote to add nodes to or remove nodes
+from the pool.
 
 !!! note
-     For the rest of this page, the term validator is used to refer to signers and validators. 
 
-## Properties 
-
-Properties to consider when comparing Clique and IBFT 2.0 are: 
-
-* Immediate finality 
-* Minimum number of validators 
-* Liveness 
-* Speed 
-
-### Immediate Finality 
-
-IBFT 2.0 has immediate finality. When using IBFT 2.0 there are no forks and all valid blocks are included in the main chain.
+    For the rest of this page, the term validator is used to refer to signers and validators.
 
-Clique does not have immediate finality. Implementations using Clique must be aware of forks and chain reorganizations occurring. 
-
-### Minimum Number of Validators 
-
-IBFT 2.0 requires 4 validators to be Byzantine fault tolerant. 
-
-Clique can operate with a single validator but operating with a single validator offers no redundancy if
-the validator fails. 
+## Properties
+
+Properties to consider when comparing Clique and IBFT 2.0 are:
 
-### Liveness 
+* Immediate finality
+* Minimum number of validators
+* Liveness
+* Speed.
 
-Clique is more fault tolerant than IBFT 2.0. Clique tolerates up to half to the validators failing. IBFT 2.0 networks 
-require greater than or equal to 2/3 of validators to be operating to create blocks. For example, in an IBFT 2.0 network of:
+### Immediate finality
 
-* 4-5, 1 unresponsive node is tolerated 
-* 6-8, 2 unresponsive nodes are tolerated 
+IBFT 2.0 has immediate finality. When using IBFT 2.0 there are no forks and all valid blocks get
+included in the main chain.
 
-Networks with 3 or less validators are able to produce blocks but do not guarantee finality when operating 
-in adversarial environments.
+Clique does not have immediate finality. Implementations using Clique must be aware of forks and
+chain reorganizations occurring.
 
-!!! important 
-    We recommend not using IBFT 2.0 networks with 3 nodes for production purposes.  
+### Minimum number of validators
 
-### Speed 
+To be Byzantine fault tolerant, IBFT 2.0 requires a minimum of four validators.
 
-Reaching consensus and adding blocks is faster in Clique networks. For Clique, the probability of a fork 
-increases number as the of validators increases. 
+Clique can operate with a single validator but operating with a single validator offers no
+redundancy if the validator fails.
 
-For IBFT 2.0, the time to add new blocks increases as the number of validators increases.   
+### Liveness
 
+Clique is more fault tolerant than IBFT 2.0. Clique tolerates up to half of the validators failing.
+IBFT 2.0 networks require greater than or equal to two-thirds of validators to be operating to
+create blocks. For example, an IBFT 2.0 network of:
 
+* Four to five validators tolerates one unresponsive validator
+* Six to eight validators tolerates two unresponsive validators.
 
+Networks with three or less validators can produce blocks but do not guarantee finality when
+operating in adversarial environments.
 
+!!! important
 
+    Using IBFT 2.0 networks with three nodes for production purposes is not recommended.
 
+### Speed
 
+Reaching consensus and adding blocks is faster in Clique networks. For Clique, the probability of a
+fork increases number as the of validators increases.
 
+For IBFT 2.0, the time to add new blocks increases as the number of validators increases.

docs/Concepts/Consensus-Protocols/Overview-Consensus.md

@@ -1,50 +1,48 @@
 description: Besu consensus protocols
 <!--- END of page meta data -->
 
-# Consensus Protocols 
+# Consensus protocols
 
-Besu implements a number of consensus protocols: 
+Besu implements a number of consensus protocols, including:
 
 * Ethash (Proof of Work)
-
 * [Clique](../../HowTo/Configure/Consensus-Protocols/Clique.md) (Proof of Authority)
-  
-* [IBFT 2.0](../../HowTo/Configure/Consensus-Protocols/IBFT.md) (Proof of Authority) 
+* [IBFT 2.0](../../HowTo/Configure/Consensus-Protocols/IBFT.md) (Proof of Authority)
+* [Quorum IBFT 1.0](../../HowTo/Configure/Consensus-Protocols/QuorumIBFT.md) (Proof of Authority).
 
-* [Quorum IBFT 1.0](../../HowTo/Configure/Consensus-Protocols/QuorumIBFT.md) (Proof of Authority) 
-
-The genesis file specifies the consensus protocol for a chain in the `config` property: 
+The `config` property in the genesis file specifies the consensus protocol for a chain. For
+example:
 
 ```json tab="Ethash"
 {
    "config": {
-     ...
+    ...
      "ethash": {
-
+      ...
    } 
   },
   ...  
 }
 ```
-    
+
 ```json tab="Clique"
 {
   "config": {
-    ....
+   ...
     "clique": {
-      ... 
+     ...
    }
   },
   ...
 }
 ```
-    
+
 ```json tab="IBFT 2.0" 
 {
   "config": {
-    ....
+   ...
     "ibft2": {
-      ...     
+     ...
    }
   },
   ...
@@ -54,12 +52,11 @@ The genesis file specifies the consensus protocol for a chain in the `config` pr
 ```json tab="IBFT 1.0" 
 {
   "config": {
-    ....
+   ...
     "ibft": {
-      ...     
+     ...
    }
   },
   ...
 }
 ```
-