Fix some typo in the documentation

docs/src/cli/deploy-a-program.md

@@ -173,8 +173,8 @@ solana program show --buffers
 To specify a different authority:
 
 ```bash
-solana program show --programs --buffer-authority <AURTHORITY_ADRESS>
-solana program show --buffers --buffer-authority <AURTHORITY_ADRESS>
+solana program show --programs --buffer-authority <AUTHORITY_ADDRESS>
+solana program show --buffers --buffer-authority <AUTHORITY_ADDRESS>
 ```
 
 To close a single account:

docs/src/implemented-proposals/reliable-vote-transmission.md

@@ -20,7 +20,7 @@ Validator votes are messages that have a critical function for consensus and con
 
 Each vote transaction should maintain a `wallclock` in its data. The merge strategy for Votes will keep the last N set of votes as configured by the local client. For push/pull the vector is traversed recursively and each Transaction is treated as an individual CrdsValue with its own local wallclock and signature.
 
-Gossip is designed for efficient propagation of state. Messages that are sent through gossip-push are batched and propagated with a minimum spanning tree to the rest of the network. Any partial failures in the tree are actively repaired with the gossip-pull protocol while minimizing the amount of data transfered between any nodes.
+Gossip is designed for efficient propagation of state. Messages that are sent through gossip-push are batched and propagated with a minimum spanning tree to the rest of the network. Any partial failures in the tree are actively repaired with the gossip-pull protocol while minimizing the amount of data transferred between any nodes.
 
 ## How this design solves the Challenges
 

docs/src/proposals/accounts-db-replication.md

@@ -72,7 +72,7 @@ slot for which it has not completed accounts db replication. The `ReplicaAccount
 the `ReplicaAccountMeta`, Hash and the AccountData. The `ReplicaAccountMeta` contains info about
 the existing `AccountMeta` in addition to the account data length in bytes.
 
-The `ReplicaAccountsServer`: this service is reponsible for serving the `ReplicaAccountsRequest`
+The `ReplicaAccountsServer`: this service is responsible for serving the `ReplicaAccountsRequest`
 and sends `ReplicaAccountsResponse` to the requestor. The response contains the count of the
 ReplAccountInfo and the vector of ReplAccountInfo. This service runs both in the validator
 and the replica relaying replication information. The server can stream the account information

docs/src/proposals/handle-duplicate-block.md

@@ -18,7 +18,7 @@ potential forks that the cluster has to resolve.
 ## Protocol
 1. When WindowStage detects a duplicate slot proof `P`, it checks the new `gossip_root` to see if `<= 1/3` of the nodes have rooted a slot `S >= P`. If so, it pushes a proof to `gossip_duplicate_slots` to gossip. WindowStage then signals ReplayStage about this duplicate slot `S`. These proofs can be purged from gossip once the validator sees > 2/3 of people gossiping roots `R > S`.
 
-2. When ReplayStage receives the signal for a duplicate slot `S` from `1)` above, the validator monitors gossip and replay waiting for`>= DUPLICATE_THRESHOLD` votes for the same hash which implies the same version of the slot. If this conditon is met for some version with hash `H` of slot `S`, this is then known as the `duplicate_confirmed` version of the slot.
+2. When ReplayStage receives the signal for a duplicate slot `S` from `1)` above, the validator monitors gossip and replay waiting for`>= DUPLICATE_THRESHOLD` votes for the same hash which implies the same version of the slot. If this condition is met for some version with hash `H` of slot `S`, this is then known as the `duplicate_confirmed` version of the slot.
 
 Before a duplicate slot `S` is `duplicate_confirmed`, it's first excluded from the vote candidate set in the fork choice rules. In addition, ReplayStage also resets PoH to the *latest* ancestor of the *earliest* `non-duplicate/confirmed_duplicate_slot`, so that block generation can start happening on the earliest known *safe* block.
 

docs/src/proposals/timely-vote-credits.md

@@ -10,7 +10,7 @@ vote credits earned by validator votes.
 Vote credits are the accounting method used to determine what percentage of
 inflation rewards a validator earns on behalf of its stakers.  Currently, when
 a slot that a validator has previously voted on is "rooted", it earns 1 vote
-credit.  A "rooted" slot is one which has received full committment by the
+credit.  A "rooted" slot is one which has received full commitment by the
 validator (i.e. has been finalized).
 
 One problem with this simple accounting method is that it awards one credit