Fix docs typos (#32364)

fix docs typos

docs/src/cli/transfer-tokens.md

@@ -2,7 +2,7 @@
 title: Send and Receive Tokens
 ---
 
-This page decribes how to receive and send SOL tokens using the command line
+This page describes how to receive and send SOL tokens using the command line
 tools with a command line wallet such as a [paper wallet](../wallet-guide/paper-wallet.md),
 a [file system wallet](../wallet-guide/file-system-wallet.md), or a
 [hardware wallet](../wallet-guide/hardware-wallets.md). Before you begin, make sure

docs/src/cluster/managing-forks.md

@@ -4,7 +4,7 @@ title: Managing Forks
 
 The ledger is permitted to fork at slot boundaries. The resulting data structure forms a tree called a _blockstore_. When the validator interprets the blockstore, it must maintain state for each fork in the chain. We call each instance an _active fork_. It is the responsibility of a validator to weigh those forks, such that it may eventually select a fork.
 
-A validator selects a fork by submiting a vote to a slot leader on that fork. The vote commits the validator for a duration of time called a _lockout period_. The validator is not permitted to vote on a different fork until that lockout period expires. Each subsequent vote on the same fork doubles the length of the lockout period. After some cluster-configured number of votes \(currently 32\), the length of the lockout period reaches what's called _max lockout_. Until the max lockout is reached, the validator has the option to wait until the lockout period is over and then vote on another fork. When it votes on another fork, it performs an operation called _rollback_, whereby the state rolls back in time to a shared checkpoint and then jumps forward to the tip of the fork that it just voted on. The maximum distance that a fork may roll back is called the _rollback depth_. Rollback depth is the number of votes required to achieve max lockout. Whenever a validator votes, any checkpoints beyond the rollback depth become unreachable. That is, there is no scenario in which the validator will need to roll back beyond rollback depth. It therefore may safely _prune_ unreachable forks and _squash_ all checkpoints beyond rollback depth into the root checkpoint.
+A validator selects a fork by submitting a vote to a slot leader on that fork. The vote commits the validator for a duration of time called a _lockout period_. The validator is not permitted to vote on a different fork until that lockout period expires. Each subsequent vote on the same fork doubles the length of the lockout period. After some cluster-configured number of votes \(currently 32\), the length of the lockout period reaches what's called _max lockout_. Until the max lockout is reached, the validator has the option to wait until the lockout period is over and then vote on another fork. When it votes on another fork, it performs an operation called _rollback_, whereby the state rolls back in time to a shared checkpoint and then jumps forward to the tip of the fork that it just voted on. The maximum distance that a fork may roll back is called the _rollback depth_. Rollback depth is the number of votes required to achieve max lockout. Whenever a validator votes, any checkpoints beyond the rollback depth become unreachable. That is, there is no scenario in which the validator will need to roll back beyond rollback depth. It therefore may safely _prune_ unreachable forks and _squash_ all checkpoints beyond rollback depth into the root checkpoint.
 
 ## Active Forks
 

docs/src/cluster/synchronization.md

@@ -8,7 +8,7 @@ Solana takes a very different approach, which it calls _Proof of History_ or _Po
 
 Solana technically never sends a _block_, but uses the term to describe the sequence of entries that validators vote on to achieve _confirmation_. In that way, Solana's confirmation times can be compared apples to apples to block-based systems. The current implementation sets block time to 800ms.
 
-What's happening under the hood is that entries are streamed to validators as quickly as a leader node can batch a set of valid transactions into an entry. Validators process those entries long before it is time to vote on their validity. By processing the transactions optimistically, there is effectively no delay between the time the last entry is received and the time when the node can vote. In the event consensus is **not** achieved, a node simply rolls back its state. This optimisic processing technique was introduced in 1981 and called [Optimistic Concurrency Control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control). It can be applied to blockchain architecture where a cluster votes on a hash that represents the full ledger up to some _block height_. In Solana, it is implemented trivially using the last entry's PoH hash.
+What's happening under the hood is that entries are streamed to validators as quickly as a leader node can batch a set of valid transactions into an entry. Validators process those entries long before it is time to vote on their validity. By processing the transactions optimistically, there is effectively no delay between the time the last entry is received and the time when the node can vote. In the event consensus is **not** achieved, a node simply rolls back its state. This optimistic processing technique was introduced in 1981 and called [Optimistic Concurrency Control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control). It can be applied to blockchain architecture where a cluster votes on a hash that represents the full ledger up to some _block height_. In Solana, it is implemented trivially using the last entry's PoH hash.
 
 ## Relationship to VDFs
 

docs/src/cluster/turbine-block-propagation.md

@@ -79,7 +79,7 @@ propagation depth.
 
 A shred group is the set of data and coding packets that can be used to
 reconstruct each other. Each shred group has a chance of failure, based on the
-likelyhood of the number of packets failing that exceeds the FEC rate. If a
+likelihood of the number of packets failing that exceeds the FEC rate. If a
 validator fails to reconstruct the shred group, then the block cannot be
 reconstructed, and the validator has to rely on repair to fixup the blocks.
 

docs/src/developing/clients/javascript-reference.md

@@ -116,7 +116,7 @@ let signature = nacl.sign.detached(transactionBuffer, payer.secretKey);
 manualTransaction.addSignature(payer.publicKey, signature);
 
 let isVerifiedSignature = manualTransaction.verifySignatures();
-console.log(`The signatures were verifed: ${isVerifiedSignature}`);
+console.log(`The signatures were verified: ${isVerifiedSignature}`);
 
 // The signatures were verified: true
 

docs/src/developing/on-chain-programs/debugging.md

@@ -114,7 +114,7 @@ To turn on SBF interpreter trace messages in a local cluster configure the
 
 Source level debugging of on-chain programs written in Rust or C can
 be done using the `program run` subcommand of `solana-ledger-tool`,
-and lldb, distrubuted with Solana Rust and Clang compiler binary
+and lldb, distributed with Solana Rust and Clang compiler binary
 package platform-tools.
 
 The `solana-ledger-tool program run` subcommand loads a compiled
@@ -137,7 +137,7 @@ with `-e debugger` command line option. For example, a crate named
 `target/deploy` directory. There should be three files in that
 directory
 - helloworld-keypair.json -- a keypair for deploying the program,
-- helloworld.debug -- a binary file containg debug information,
+- helloworld.debug -- a binary file containing debug information,
 - helloworld.so -- an executable file loadable into the virtual machine.
 The command line for running `solana-ledger-tool` would be something like this
 ```
@@ -146,7 +146,7 @@ solana-ledger-tool program run -l test-ledger -e debugger target/deploy/hellowor
 Note that `solana-ledger-tool` always loads a ledger database. Most
 on-chain programs interact with a ledger in some manner. Even if for
 debugging purpose a ledger is not needed, it has to be provided to
-`solana-ledger-tool`. A minimal ladger database can be created by
+`solana-ledger-tool`. A minimal ledger database can be created by
 running `solana-test-validator`, which creates a ledger in
 `test-ledger` subdirectory.
 
@@ -262,5 +262,5 @@ task. The next step is to run `solana-debugger` task. The tasks specified in
 VSCode. When `solana-ledger-tool` is running and listening from incoming
 connections, it's time to start the debugger.  Launch it from VSCode
 `Run and Debug` menu.  If everything is set up correctly, VSCode will
-start a debugging session and the porogram execution should stop on
+start a debugging session and the program execution should stop on
 the entrance into the `entrypoint` function.

docs/src/developing/plugins/geyser-plugins.md

@@ -443,7 +443,7 @@ accounts or a large number of accounts are selected. The node hosting the
 PostgreSQL database need to be powerful enough to handle the database loads
 as well. It has been found using GCP n2-standard-64 machine type for the
 validator and n2-highmem-32 for the PostgreSQL node is adequate for handling
-transmiting all accounts while keeping up with the network. In addition, it is
+transmitting all accounts while keeping up with the network. In addition, it is
 best to keep the validator and the PostgreSQL in the same local network to
 reduce latency. You may need to size the validator and database nodes
 differently if serving other loads.

docs/src/running-validator/validator-info.md

@@ -46,4 +46,4 @@ For older accounts instead of `iconUrl` you might see `keybaseUsername` as those
 
 ## Keybase
 
-Previously Keybase was used by validators to provide their validator icon, however Keybase has sunset its service and thus is no longer supported. Some old validator info accounts will still contain keybase usernames this is reflected in the serialized data returend when querying these validator info accounts.
+Previously Keybase was used by validators to provide their validator icon, however Keybase has sunset its service and thus is no longer supported. Some old validator info accounts will still contain keybase usernames this is reflected in the serialized data returned when querying these validator info accounts.

docs/src/running-validator/validator-reqs.md

@@ -79,7 +79,7 @@ especially for the case of running staked validators.
 
 Running validator for live clusters (including mainnet-beta) inside Docker is
 not recommended and generally not supported. This is due to concerns of general
-Docker's containerzation overhead and resultant performance degradation unless
+Docker's containerization overhead and resultant performance degradation unless
 specially configured.
 
 We use Docker only for development purposes. Docker Hub contains images for all

docs/src/running-validator/validator-start.md

@@ -446,7 +446,7 @@ partition.
 Example configuration:
 
 1. `sudo mkdir /mnt/solana-accounts`
-2. Add a 300GB tmpfs parition by adding a new line containing `tmpfs /mnt/solana-accounts tmpfs rw,size=300G,user=sol 0 0` to `/etc/fstab`
+2. Add a 300GB tmpfs partition by adding a new line containing `tmpfs /mnt/solana-accounts tmpfs rw,size=300G,user=sol 0 0` to `/etc/fstab`
    (assuming your validator is running under the user "sol"). **CAREFUL: If you
    incorrectly edit /etc/fstab your machine may no longer boot**
 3. Create at least 250GB of swap space

docs/src/validator/best-practices/security.md

@@ -18,7 +18,7 @@ sudo apt upgrade
 
 Your withdrawer key gives the operator full control of the vote account. It is highly sensitive information and should not be stored on the validator itself.
 
-There are a number of options for withdrawer key management.  Some operators choose to use hardware wallets or paper wallets for the withdrawer keypair.  Another option is a multisig where each key of the miltisig is a hardware wallet or paper wallet. Whichever option you choose, make sure the authorized withdrawer key is stored securely and that it has been generated on a trusted computer (other than your validator computer).
+There are a number of options for withdrawer key management.  Some operators choose to use hardware wallets or paper wallets for the withdrawer keypair.  Another option is a multisig where each key of the multisig is a hardware wallet or paper wallet. Whichever option you choose, make sure the authorized withdrawer key is stored securely and that it has been generated on a trusted computer (other than your validator computer).
 
 To reiterate, the withdrawer keypair should never be stored on your validator at any time.
 

docs/src/validator/get-started/setup-a-validator.md

@@ -69,7 +69,7 @@ solana-keygen new -o vote-account-keypair.json
 solana-keygen new -o authorized-withdrawer-keypair.json
 ```
 
-> **IMPORTANT** the `authorized-withdrawer-keypair.json` should be considered very sensitive information.  Many operators choose to use a multisig, hardware wallet, or paper wallet for the authorized withdrawer keypair.  A keypair is created on disk in this example for simplicity. Additionally, the withdrawer keypair should always be stored safely. The authorized withdrawer keypair should **never** be stored on the remote machine that the validator software runs on.  For more information, see [validator secuirty best practices](../best-practices/security.md#do-not-store-your-withdrawer-key-on-your-validator)
+> **IMPORTANT** the `authorized-withdrawer-keypair.json` should be considered very sensitive information.  Many operators choose to use a multisig, hardware wallet, or paper wallet for the authorized withdrawer keypair.  A keypair is created on disk in this example for simplicity. Additionally, the withdrawer keypair should always be stored safely. The authorized withdrawer keypair should **never** be stored on the remote machine that the validator software runs on.  For more information, see [validator security best practices](../best-practices/security.md#do-not-store-your-withdrawer-key-on-your-validator)
 
 ## Create a Vote Account
 

docs/src/validator/tvu.md

@@ -3,7 +3,7 @@ title: TVU
 ---
 
 TVU (Transaction Validation Unit) is the logic of the validator
-responsible for validating and propogating blocks and processing
+responsible for validating and propagating blocks and processing
 those blocks' transactions through the runtime.
 
 ![TVU Block Diagram](/img/tvu.svg)

docs/src/wallet-guide/paper-wallet.md

@@ -70,7 +70,7 @@ pubkey: 9ZNTfG4NyQgxy2SWjSiQoUyBPEvXT2xo7fKc5hPYYJ7b
 The value shown after `pubkey:` is your _wallet address_.
 
 **Note:** In working with paper wallets and file system wallets, the terms "pubkey"
-and "wallet address" are sometimes used interchangably.
+and "wallet address" are sometimes used interchangeably.
 
 > For added security, increase the seed phrase word count using the `--word-count` argument