Correction of Grammatical Errors (#3853)

* Update QuorumProposalRecv.md

* Update README.md

* Update CHANGELOG.md

---------

Co-authored-by: Phil <[email protected]>

CHANGELOG.md

@@ -23,7 +23,7 @@ Adds new type parameter, corresponding to the state type, to Message
 ### Features
 - StatefulHandler trait
 - Reexport traits from traits module
-- State Machine + NodeImplementation
+- State Machine + Node Implementation
 - state machine mvp megasquash
 - Replace tokio broadcast queue with unbounded equivalent
 

crates/libp2p-networking/README.md

@@ -55,11 +55,11 @@ ulimit -n 4096
 
 In these tests, there are three types of nodes. `Regular` nodes that limit the number of incoming connections, `Bootstrap` nodes that allow all connections, and `Conductor` nodes that all nodes (bootstrap and regular) connect to and periodically ping with their state. This "conductor" node instructs nodes in the swarm to increment their state either via broadcast or direct messages in the same fashion as the single machine tests.
 
-In the direct message case, the conductor will increment the state of a randomly chosen node, `i`. Then the conductor will direct message all other nodes to request node `i`'s counter and increment their counter to the value in `i`'s node. In the broadcast case, the conductor will increment the state of a randomly chose node, `i`, and tell `i` to broadcast this incremented state.
+In the direct message case, the conductor will increment the state of a randomly chosen node, `i`. Then the conductor will direct message all other nodes to request node `i`'s counter and increment their counter to the value in `i`'s node. In the broadcast case, the conductor will increment the state of a randomly chosen node, `i`, and tell `i` to broadcast this incremented state.
 
 In both cases, the test terminates as successful when the conductor receives the incremented state from all other nodes. Then, the conductor sends a special "kill" message to all known nodes and waits for them to disconnect.
 
-Metadata about the toplogy is currently read from an `identity_mapping.json` file that manually labels the type of node (bootstrap, regular, conductor). The conductor uses this to figure out information about all nodes in the network. The regular nodes use this to learn about their ip address and the addresses necessary to bootstrap onto the network. The boostrap nodes only use this to learn about their ip addresses.
+Metadata about the topology is currently read from an `identity_mapping.json` file that manually labels the type of node (bootstrap, regular, conductor). The conductor uses this to figure out information about all nodes in the network. The regular nodes use this to learn about their ip address and the addresses necessary to bootstrap onto the network. The bootstrap nodes only use this to learn about their ip addresses.
 
 ### Running counter multi-machine tests
 
@@ -75,7 +75,7 @@ nix develop -c cargo run --features webui,async-std-executor --release --example
 ```
 
 ### Network Emulation
-One may introduce simulated network latency via the network emulationn queueing discipline. This is implemented in two ways: on what is assumed to be a AWS EC2 instance, and in a docker container. Example usage on AWS EC2 instance:
+One may introduce simulated network latency via the network emulation queueing discipline. This is implemented in two ways: on what is assumed to be a AWS EC2 instance, and in a docker container. Example usage on AWS EC2 instance:
 
 ```bash
 # run each line in a separate AWS instance

docs/diagrams/event_discriptions/QuorumProposalRecv.md

@@ -15,7 +15,7 @@
   * If `ViewSyncCommitCertificate`s are not included in the `QuorumProposal` it is possible for honest nodes to reject valid proposals.  For example, a view leader may receive the `ViewSyncCommitCertificate` from the view sync relay, update its local view, and send a `QuorumProposal` for the new view.  But other nodes may not have received the `ViewSyncCommitCertificate` yet (either through genuine network delays or Byzantine behavior by the view sync relay).  Thus, the other nodes will not be able to process the `QuorumProposal` since they do not have evidence the network has advanced to the view in the `ViewSyncCommitCertificate`.  These nodes would either need to reject the proposal outright, or wait to process the proposal until they receive the `ViewSyncCommitCertificate`. The former behavior would cause unnecessary view failures, and the latter would add complexity to the code.  Including the `ViewSyncCommitCertificate` in the `QuorumProposal` addresses both these concerns. 
 * It is possible for a node to receive multiple `ViewSyncCommitCertificate`s: one from the view sync relay and one from the view leader.  Therefore processing this certificate must be idempotent. 
 * It is possible (and valid) for a node to receive valid view change evidence but an invalid `QuorumProposal`.  There are several ways to handle this scenario, but we choose to allow nodes to update their `latest_known_view` even if other validation of the proposal fails.  This helps the network maintain view synchronization in spite of invalid proposals. 
-* It is possible for a `QuorumProposal` to have valid view change evidence from a `TimeoutCertificate` or `ViewSyncCommitCertificate`, but to have an invalid `QurorumCertificate`.  It would be valid to update the view in this case, since there exists valid view change evidence.  But for simplicity, we choose not to.  If view change evidence is valid but the `QuorumCertificate` associated with the proposal is invalid nodes will not update their view. 
+* It is possible for a `QuorumProposal` to have valid view change evidence from a `TimeoutCertificate` or `ViewSyncCommitCertificate`, but to have an invalid `QuorumCertificate`.  It would be valid to update the view in this case, since there exists valid view change evidence.  But for simplicity, we choose not to.  If view change evidence is valid but the `QuorumCertificate` associated with the proposal is invalid nodes will not update their view. 
 
 ## Proposal Validation
 * This proposal validation represents the [HotStuff-2](https://eprint.iacr.org/2023/397.pdf) protocol.