Docs: fix typos (#4592)

* fix typos

* fix typos

docs/src/proposals/blockstore-rocksdb-compaction.md

@@ -81,7 +81,7 @@ additional write amplification.
 As all the above issues are compaction related, it can be solved with a proper
 compaction style and deletion policy.  Fortunately, shred data column families,
 ShredData and ShredCode, which contribute to 99% of the storage size in shred
-insertion, have an unique write workload where write-keys are mostly
+insertion, have a unique write workload where write-keys are mostly
 monotonically increasing over time.  This allows data to be persisted in sorted
 order naturally without compaction, and the deletion policy can be as simple as
 deleting the oldest file when the storage size reaches the cleanup trigger.
@@ -92,7 +92,7 @@ amplification with no write stalls.
 
 ### Use FIFO Compaction for Shred Data Column Families
 As mentioned above, shred data column families, ShredData and ShredCode, which
-contribute to 99% of the storage size in shred insertion, have an unique write
+contribute to 99% of the storage size in shred insertion, have a unique write
 workload where write-keys are mostly monotonically increasing over time.  As a
 result, after entries are flushed from memory into SST files, the keys are
 naturally sorted across multiple SST files where each SST file might have
@@ -185,7 +185,7 @@ To avoid the start-up write stalls, a more efficient way to perform FIFO
 to level compaction is to do a manual compaction first, then open the DB.
 
 ## Release Plan
-As the migration in either way cannot not be done smoothly in place, the
+As the migration in either way cannot be done smoothly in place, the
 release will be divided into the following steps:
 
 * v0 - merge FIFO compaction implementation with visible args.

docs/src/proposals/fee_transaction_priority.md

@@ -202,7 +202,7 @@ for account_key in unlocked_accounts {
 if let Some(blocked_transaction_queue) = self.blocked_transactions.get(completed_transaction.signature) {
     // Now push the rest of the queue to the head of `all_transaction_queues`, since we know
     // everything in this blocked queue must be of higher priority, (since they were
-    // added to this queue earlier, this means they must have been peopped off the main
+    // added to this queue earlier, this means they must have been popped off the main
     // `transaction_accounts` queue earlier, hence higher priority)
     self.all_transaction_queues.push_front(blocked_transaction_queue.other_blocked_transactions);
     self.blocked_transactions.remove(completed_transaction.signature);

svm/examples/json-rpc/README.md

@@ -2,7 +2,7 @@ This is an example application using SVM to implement a tiny subset of
 Solana RPC protocol for the purpose of simulating transaction
 execution without having to use the entire Solana Runtime.
 
-The exmample consists of two host applications
+The example consists of two host applications
 - json-rpc-server -- the RPC server that accepts incoming RPC requests
   and performs transaction simulation sending back the results,
 - json-rpc-client -- the RPC client program that sends transactions to

svm/examples/paytube/README.md

@@ -6,7 +6,7 @@ built using [Anza's SVM API](https://www.anza.xyz/blog/anzas-new-svm-api).
 With the release of Agave 2.0, we've decoupled the SVM API from the rest of the
 runtime, which means it can be used outside the validator. This unlocks
 SVM-based solutions such as sidecars, channels, rollups, and more. This project
-demonstrates everything you need to know about boostrapping with this new API.
+demonstrates everything you need to know about bootstrapping with this new API.
 
 PayTube is a state channel (more specifically a payment channel), designed to
 allow multiple parties to transact amongst each other in SOL or SPL tokens