book/ consensus.md: fmt and clarify language concerning block proposals.

doc/src/architecture/consensus.md

@@ -1,6 +1,7 @@
 # Consensus
 
-This section of the book describes how nodes participating in the DarkFi blockchain achieve consensus.
+This section of the book describes how nodes participating in the DarkFi
+blockchain achieve consensus.
 
 ## Glossary
 
@@ -15,16 +16,22 @@ This section of the book describes how nodes participating in the DarkFi blockch
 | Block proposal         | Block that has not yet been appended onto the canonical blockchain                        |
 | P2P network            | Peer-to-peer network on which nodes communicate with eachother                            |
 | Finalization           | State achieved when a block and its contents are appended to the canonical blockchain     |
-| Fork                   | Chain of unfinalized blocks that begins with the last block of the canonical blockchain   |
+| Fork                   | Chain of block proposals that begins with the last block of the canonical blockchain      |
 
 ## Node main loop
 
-As described in previous chapter, DarkFi is based on Ouroboros Crypsinous. Therefore, block production involves the following steps:
+As described in previous chapter, DarkFi is based on Ouroboros
+Crypsinous. Therefore, block production involves the following steps:
 
-At the start of every slot, each node runs a leader selection algorithm to determine if they are the slot's leader. If successful, they can produce a block containing unproposed transactions. This block is then appended to the largest known fork
-and shared with rest of the nodes on the P2P network. 
-Right before the end of every slot each node triggers a _finalization check_, to verify which blocks can be finalized.
-This is also known as the finalization sync period.
+At the start of every slot, each node runs a leader selection algorithm
+to determine if they are the slot's leader. If successful, they can
+produce a block containing unproposed transactions. This block is then
+appended to the largest known fork and shared with rest of the nodes on
+the P2P network as a block proposal.
+
+Before the end of every slot each node triggers a _finalization check_,
+to verify which block proposals can be finalized onto the canonical
+blockchain. This is also known as the finalization sync period.
 
 Pseudocode:
 ```
@@ -48,13 +55,17 @@ loop {
 
 ## Listening for blocks
 
-Each node listens to new block proposals concurrently with the main loop. Upon receiving block proposals,
-nodes try to extend the proposals onto a fork that they hold in memory. This process is described in the next section.
+Each node listens to new block proposals concurrently with the main
+loop. Upon receiving block proposals, nodes try to extend the proposals
+onto a fork that they hold in memory. This process is described in the
+next section.
 
 ## Fork extension
 
-Since there can be more than one slot leader, each node holds a set of known forks in memory.
-When a node becomes a leader, they extend the longest fork they hold.
+Since there can be more than one slot leader, each node holds a set of
+known forks in memory.  When a node becomes a leader, they extend the
+longest fork they hold. 
+
 Upon receiving a block, one of the following cases may occur:
 
 | Description                               | Handling                                                            |
@@ -113,13 +124,20 @@ Extending the canonical blockchain with a new block proposal:
 
 ## Finalization
 
-When the finalization sync period kicks in, each node looks up the longest fork chain it holds. This must be at least 3 blocks long and there must be no other fork chain with same length.
-If such a fork chain exists, nodes finalize all proposed blocks up to the last one by appending them to the canonical blockchain.
+When the finalization sync period kicks in, each node looks up the longest
+fork chain it holds. This must be at least 3 blocks long and there must
+be no other fork chain with same length.  If such a fork chain exists,
+nodes finalize all block proposals up to the last one by appending them
+to the canonical blockchain.
+
 Once finalized, all other fork chains are removed from the memory pool.
-Practically this means that no finalization can occur while we have competing fork chains of the same length. In such a case, finalization can only occur when we have a a slot with a single leader.
+Practically this means that no finalization can occur while there are
+competing fork chains of the same length. In such a case, finalization
+can only occur when we have a a slot with a single leader.
 
 We continue Case 3 from the previous section to visualize this logic.
-On slot 5, a node observes 2 proposals. One extends the L0L2 fork, and the other extends the L0L3 fork:
+On slot 5, a node observes 2 proposals. One extends the L0L2 fork,
+and the other extends the L0L3 fork:
 
                    |--[L0]--[L2]+--[L5a] <-- L0L2L5a fork
     [C]--...--[C]--|
@@ -130,7 +148,9 @@ On slot 5, a node observes 2 proposals. One extends the L0L2 fork, and the other
                    |--[L4]               <-- L4 fork
 
 Since we have two competing fork chains finalization cannot occur.
-On next slot, a node only observes 1 proposal. So it extends the L0L3L5b fork:
+
+On next slot, a node only observes 1 proposal. So it extends the
+L0L3L5b fork:
 
                    |--[L0]--[L2]--[L5a]        <-- L0L2L5a fork
     [C]--...--[C]--|
@@ -140,7 +160,8 @@ On next slot, a node only observes 1 proposal. So it extends the L0L3L5b fork:
                    |
                    |--[L4]                     <-- L4 fork
 
-When the finalization sync period starts, the node finalizes the fork L0L3L5bL6 and all other forks get dropped:
+When the finalization sync period starts, the node finalizes the fork
+L0L3L5bL6 and all other forks get dropped:
 
                    |/--[L0]--[L2]--[L5a]      <-- L0L2L5a fork
     [C]--...--[C]--|
@@ -155,5 +176,6 @@ This results in the following state:
 
     [C]--...--[C]--|--[L6]
 
-The canonical blockchain contains blocks L0, L3 and L5b from the L0L3L56L6 fork.
+The canonical blockchain contains blocks L0, L3 and L5b from the
+L0L3L56L6 fork.