book: grammar edit, consensus.md

doc/src/architecture/consensus.md

@@ -6,24 +6,25 @@ This section of the book describes how nodes participating in the DarkFi blockch
 
 | Name                   | Description                                                                               |
 |------------------------|-------------------------------------------------------------------------------------------|
-| Consensus              | Algorithm for reaching Blockchain consensus between participating nodes                   |
+| Consensus              | Algorithm for reaching blockchain consensus between participating nodes                   |
 | Node                   | darkfid daemon participating in the network                                               |
 | Slot                   | Specified timeframe for block production, measured in seconds(default=20)                 |
 | Epoch                  | Specified timeframe for blockchain events, measured in slots(default=10)                  |
 | Leader                 | Block producer                                                                            |
-| Unproposed Transaction | A transaction that exists in nodes memory pool, but have not yet been included in a block |
-| P2P network            | Peer-To-Peer network all nodes communicate with each other                                |
-| Finalization           | Append a Block and its content to canonical blockchain                                    |
-| Fork                   | Chain of unfinalized blocks, starting by the last canonical block of blockchain           |
+| Unproposed Transaction | Transaction that exists in the memory pool but has not yet been included in a block       |
+| 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   |
 
 ## Node main loop
 
-As described in previous chapter, DarkFi is based on Ouroboros Crypsinous, therefore, to be able to produce a block,
-at slot start each node checks if they are the slots' leader, based on the leader selection algorithm. 
-If they succeed, they can produce a block containing unproposed transactions, by extending the largest known fork, 
-and share it with rest nodes, by broadcasting it in the P2P network. 
-Right before slot end, each node triggers the finalization check, to verify which blocks can be finalized,
-also known as finalization sync period.
+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.
 
 Pseudocode:
 ```
@@ -47,21 +48,21 @@ loop {
 
 ## Listening for blocks
 
-Concurently with the main loop, each node listens to new block proposals, and upon receiving them,
-they try to extend a known fork, as described in 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 leaders, each node holds a set of known forks in memory.
-When a node becomes leader, they extend the longest fork they hold.
-Upon receiving a block, one of the following cases occur:
+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                                                            |
 |-------------------------------------------|---------------------------------------------------------------------|
 | Block extends a known fork at its end     | Append block to fork                                                |
 | Block extends a known fork not at its end | Create a new fork up to the extended block and append the new block |
 | Block extends canonical blockchain        | Create a new fork containing the new block                          |
-| Block doesn't extends any known chains    | Ignore block                                                        |
+| Block doesn't extend any known chain      | Ignore block                                                        |
 
 ### Visual Examples
 
@@ -81,7 +82,7 @@ Starting state:
 
 #### Case 1
 
-New proposal received extending L0 fork:
+Extending L0 fork with a new block proposal:
 
                    |--[L0]+--[L2] <-- L0L2 fork
     [C]--...--[C]--|
@@ -89,7 +90,7 @@ New proposal received extending L0 fork:
 
 #### Case 2
 
-New proposal received extending L0L2 fork at [L0] slot:
+Extending L0L2 fork at [L0] slot with a new block proposal:
 
                    |--[L0]--[L2]  <-- L0L2 fork
     [C]--...--[C]--|
@@ -99,7 +100,7 @@ New proposal received extending L0L2 fork at [L0] slot:
 
 ##### Case 3
 
-New proposal received extending canonical:
+Extending the canonical blockchain with a new block proposal:
 
                    |--[L0]--[L2] <-- L0L2 fork
     [C]--...--[C]--|
@@ -112,15 +113,13 @@ New proposal received extending canonical:
 
 ## Finalization
 
-When finalization sync period kicks in, each node finds the longest fork chain it holds, that is at least 3 blocks long,
-without any other fock chain with same length.
-If such a fork chain exists, nodes finalizes(appends to canonical blockchain) all proposed blocks up to the last one.
-When a fork chain gets finalized, rest fork chains are removed from nodes memory pool.
-This practically means, that while we have competting(same length) fork chains,
-no finalization occurs until a slot with a single leader happens.
+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.
+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.
 
-We continue Case 3 from previous sector to visualize this logic.
-On slot 5, node observes 2 proposals, one extending L0L2 fork and one extending L0L3 fork:
+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:
 
                    |--[L0]--[L2]+--[L5a] <-- L0L2L5a fork
     [C]--...--[C]--|
@@ -130,8 +129,8 @@ On slot 5, node observes 2 proposals, one extending L0L2 fork and one extending
                    |
                    |--[L4]               <-- L4 fork
 
-Finalization cannot occur, since we have two competting fork chains.
-On next slot, node only observers 1 proposal, extending L0L3L5b 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:
 
                    |--[L0]--[L2]--[L5a]        <-- L0L2L5a fork
     [C]--...--[C]--|
@@ -141,7 +140,7 @@ On next slot, node only observers 1 proposal, extending L0L3L5b fork:
                    |
                    |--[L4]                     <-- L4 fork
 
-When finalization sync period starts, node sees that it can finalize fork L0L3L5bL6 and drop rest forks:
+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]--|
@@ -152,9 +151,9 @@ When finalization sync period starts, node sees that it can finalize fork L0L3L5
                    |/--[L4]                   <-- L4 fork
 
 
-resulting in the following state:
+This results in the following state:
 
     [C]--...--[C]--|--[L6]
 
-where canonical contains blocks L0, L3 and L5b from L0L3L56L6 fork.
+The canonical blockchain contains blocks L0, L3 and L5b from the L0L3L56L6 fork.