Update docs with additional information on CCF Raft (#3778)

doc/architecture/consensus/index.rst

@@ -8,7 +8,12 @@ Below, we give an overview over the nodes state machine in both settings and the
 CFT Consensus Protocol
 ----------------------
 
-The crash fault tolerant implementation in CCF is based on Raft. You can find more information on the Raft implementation of reconfiguration in CCF :doc:`here <1tx-reconfig>`.
+The crash fault tolerant implementation in CCF is based on `Raft <https://raft.github.io/>`_. The key differences between the original Raft protocol (as described in the `Raft paper <https://raft.github.io/raft.pdf>`_), and CCF Raft are as follows:
+
+* Transactions in CCF Raft are not considered to be committed until a subsequent signed transaction has been committed. More information can be found :doc:`here </consensus/merkle_tree>`. Transactions in the ledger before the last signed transactions are discarded during leader election.
+* By default, CCF supports one-phase reconfiguration and you can find more information :doc:`here <1tx-reconfig>`. CCF also supports Raft's two-phase reconfiguration protocol, as described :doc:`here <2tx-reconfig>`. Note that CCF Raft does not support node restart as the unique identity of each node is tied to the node process launch. If a node fails and is replaced, it must rejoin Raft via reconfiguration.
+* In CCF Raft, clients receive an early response with a :term:`Transaction ID` (view and sequence number) before the transaction has been replicated to Raft's ledger. The client can later use this transaction ID to verify that the transaction has been committed by Raft.
+* CCF Raft uses an additional mechanism so a newly elected leader can more efficiently determine the current state of a follower's ledger when the two ledgers have diverged. This enables the leader to bring the follower up to date more quickly. CCF Raft also batches appendEntries messages.
 
 CFT parameters can be configured when starting up a network (see :doc:`here </operations/start_network>`). The parameters that can be set via the CCF node JSON configuration:
 

doc/host_config_schema/cchost_config.json

@@ -331,7 +331,7 @@
         "election_timeout": {
           "type": "string",
           "default": "5000ms",
-          "description": "Timeout value after which backup nodes that have not received any message from the primary node will trigger a new election. This should be set to a significantly greater value than 'message_timeout'"
+          "description": "Maximum timeout (time string) after which backup nodes that have not received any message from the primary node (or voted for a candidate) will trigger a new election. This timeout is also used by candidates to restart unsuccessful elections. This should be set to a significantly greater value than 'message_timeout' plus the expected network delay."
         }
       },
       "description": "This section includes configuration for the consensus protocol (note: should be the same for all other nodes in the service)"