Fix: typos (#30141)

docs/src/developing/intro/rent.md

@@ -3,19 +3,19 @@ title: What is rent?
 description: "Rent: the small fee Solana accounts incur to store data on the blockchain. Accounts with >2 years of rent are rent exempt and do not pay the periodic fee."
 ---
 
-The fee every Solana Account to store data on the blockchain is called "_rent_". This _time and space_ based fee is required to keep an account, and its therefore its data, alive on the blockchain since [clusters](../../cluster/overview.md) must actively maintain this data.
+The fee for every Solana Account to store data on the blockchain is called "_rent_". This _time and space_ based fee is required to keep an account, and therefore its data, alive on the blockchain since [clusters](../../cluster/overview.md) must actively maintain this data.
 
 All Solana Accounts (and therefore Programs) are required to maintain a high enough LAMPORT balance to become [rent exempt](#rent-exempt) and remain on the Solana blockchain.
 
 When an Account no longer has enough LAMPORTS to pay its rent, it will be removed from the network in a process known as [Garbage Collection](#garbage-collection).
 
-> **Note:** Rent is different from [transactions fees](../../transaction_fees.md). Rent is paid (or held in an Account) to keep data stored on the Solana blockchain. Where as transaction fees are paid to process [instructions](../developing/../programming-model/transactions.md#instructions) on the network.
+> **Note:** Rent is different from [transactions fees](../../transaction_fees.md). Rent is paid (or held in an Account) to keep data stored on the Solana blockchain. Whereas transaction fees are paid to process [instructions](../developing/../programming-model/transactions.md#instructions) on the network.
 
 ### Rent rate
 
 The Solana rent rate is set on a network wide basis, primarily based on the set LAMPORTS _per_ byte _per_ year.
 
-Currently, the rent rate is a static amount and stored in the the [Rent sysvar](../runtime-facilities/sysvars.md#rent).
+Currently, the rent rate is a static amount and stored in the [Rent sysvar](../runtime-facilities/sysvars.md#rent).
 
 ## Rent exempt
 

docs/src/developing/lookup-tables.md

@@ -5,13 +5,13 @@ description: ""
 
 Address Lookup Tables, commonly referred to as "_lookup tables_" or "_ALTs_" for short, allow developers to create a collection of related addresses to efficiently load more addresses in a single transaction.
 
-Since each transaction on the Solana blockchain requires a listing of every address that is interacted with as part of the transaction, this listing would be effectively be capped at 32 address per transaction. With the help of [Address Lookup Tables](./lookup-tables.md), a transaction would be now be able to raise that limit to 256 addresses per transaction.
+Since each transaction on the Solana blockchain requires a listing of every address that is interacted with as part of the transaction, this listing would effectively be capped at 32 addresses per transaction. With the help of [Address Lookup Tables](./lookup-tables.md), a transaction would now be able to raise that limit to 256 addresses per transaction.
 
 ## Compressing on chain addresses
 
-After all the desired address have been stored on chain in an Address Lookup Table, each address can be referenced inside a transaction by its 1-byte index within the table (instead of their full 32-byte address). This lookup method effectively "_compresses_" a 32-byte address into a 1-byte index value.
+After all the desired addresses have been stored on chain in an Address Lookup Table, each address can be referenced inside a transaction by its 1-byte index within the table (instead of their full 32-byte address). This lookup method effectively "_compresses_" a 32-byte address into a 1-byte index value.
 
-This "_compression_" enables storing up to 256 address in a single lookup table for use inside any given transaction.
+This "_compression_" enables storing up to 256 addresses in a single lookup table for use inside any given transaction.
 
 ## Versioned Transactions
 
@@ -51,7 +51,7 @@ console.log("lookup table address:", lookupTableAddress.toBase58());
 
 ## Add addresses to a lookup table
 
-Adding addresses to a lookup table is known as "_extending_". Using the the `@solana/web3.js` library, you can create a new _extend_ instruction using the [`extendLookupTable`](https://solana-labs.github.io/solana-web3.js/classes/AddressLookupTableProgram.html#extendLookupTable) method:
+Adding addresses to a lookup table is known as "_extending_". Using the `@solana/web3.js` library, you can create a new _extend_ instruction using the [`extendLookupTable`](https://solana-labs.github.io/solana-web3.js/classes/AddressLookupTableProgram.html#extendLookupTable) method:
 
 ```js
 // add addresses to the `lookupTableAddress` table via an `extend` instruction
@@ -71,9 +71,9 @@ const extendInstruction = web3.AddressLookupTableProgram.extendLookupTable({
 ```
 
 > NOTE:
-> Due to the same memory limits of `legacy` transactions, any transaction used to _extend_ an Address Lookup Table is also limited in how many addresses can be added at a time. Because of this, you will need to use multiple transactions to _extend_ any table with more addresses (~20) that can fit withing a single transaction's memory limits.
+> Due to the same memory limits of `legacy` transactions, any transaction used to _extend_ an Address Lookup Table is also limited in how many addresses can be added at a time. Because of this, you will need to use multiple transactions to _extend_ any table with more addresses (~20) that can fit within a single transaction's memory limits.
 
-Once these address have been inserted into the table, and stored on chain, you will be able to utilize the Address Lookup Table in future transactions. Enabling up to 256 address in those future transactions.
+Once these addresses have been inserted into the table, and stored on chain, you will be able to utilize the Address Lookup Table in future transactions. Enabling up to 256 addresses in those future transactions.
 
 ## Fetch an Address Lookup Table
 
@@ -96,7 +96,7 @@ console.log("Table address from cluster:", lookupTableAccount.key.toBase58());
 Our `lookupTableAccount` variable will now be a `AddressLookupTableAccount` object which we can parse to read the listing of all the addresses stored on chain in the lookup table:
 
 ```js
-// loop through and parse all the address stored in the table
+// loop through and parse all the addresses stored in the table
 for (let i = 0; i < lookupTableAccount.state.addresses.length; i++) {
   const address = lookupTableAccount.state.addresses[i];
   console.log(i, address.toBase58());
@@ -115,7 +115,7 @@ Just like older `legacy` transactions, you can create all the [instructions](./.
 ```js
 // Assumptions:
 // - `arrayOfInstructions` has been created as an `array` of `TransactionInstruction`
-// - we are are using the `lookupTableAccount` obtained above
+// - we are using the `lookupTableAccount` obtained above
 
 // construct a v0 compatible transaction `Message`
 const messageV0 = new web3.TransactionMessage({

docs/src/developing/test-validator.md

@@ -147,7 +147,7 @@ JSON RPC URL: http://127.0.0.1:8899
 ⠈ 00:36:02 | Processed Slot: 5142 | Confirmed Slot: 5142 | Finalized Slot: 5110 | Snapshot Slot: 5100 | Transactions: 5142 | ◎499.974295000
 ```
 
-- Session running time, current slot of the the three block
+- Session running time, current slot of the three block
   [commitment levels](../api/http#configuring-state-commitment),
   slot height of the last snapshot, transaction count,
   [voting authority](/running-validator/vote-accounts#vote-authority) balance

docs/src/proposals/ledger-replication-to-implement.md

@@ -136,7 +136,7 @@ We have the following constraints:
 
    replicate.
 
-4. The archiver retrives the ledger by asking peer validators and
+4. The archiver retrieves the ledger by asking peer validators and
 
    archivers. See 6.5.
 
@@ -207,7 +207,7 @@ For each turn of the PoRep game, both Validators and Archivers evaluate each sta
 
    The map is updated when a Validator processes an archiver's proofs for a segment.
 
-   The validator provides an RPC interface to access the this map. Using this API, clients
+   The validator provides an RPC interface to access this map. Using this API, clients
 
    can map a segment to an archiver's network address \(correlating it via cluster_info table\).
 
@@ -343,7 +343,7 @@ The storage epoch should be the number of slots which results in around 100GB-1T
 
    creates a challenge transaction and submits it to the current leader. The
 
-   transacation proves the validator incorrectly validated a fake storage proof.
+   transaction proves the validator incorrectly validated a fake storage proof.
 
    The archiver is rewarded and the validator's staking balance is slashed or
 
@@ -351,7 +351,7 @@ The storage epoch should be the number of slots which results in around 100GB-1T
 
 ## Storage proof contract logic
 
-Each archiver and validator will have their own storage account. The validator's account would be separate from their gossip id similiar to their vote account. These should be implemented as two programs one which handles the validator as the keysigner and one for the archiver. In that way when the programs reference other accounts, they can check the program id to ensure it is a validator or archiver account they are referencing.
+Each archiver and validator will have their own storage account. The validator's account would be separate from their gossip id similar to their vote account. These should be implemented as two programs one which handles the validator as the keysigner and one for the archiver. In that way when the programs reference other accounts, they can check the program id to ensure it is a validator or archiver account they are referencing.
 
 ### SubmitMiningProof
 
@@ -364,7 +364,7 @@ SubmitMiningProof {
 keys = [archiver_keypair]
 ```
 
-Archivers create these after mining their stored ledger data for a certain hash value. The slot is the end slot of the segment of ledger they are storing, the sha_state the result of the archiver using the hash function to sample their encrypted ledger segment. The signature is the signature that was created when they signed a PoH value for the current storage epoch. The list of proofs from the current storage epoch should be saved in the account state, and then transfered to a list of proofs for the previous epoch when the epoch passes. In a given storage epoch a given archiver should only submit proofs for one segment.
+Archivers create these after mining their stored ledger data for a certain hash value. The slot is the end slot of the segment of ledger they are storing, the sha_state the result of the archiver using the hash function to sample their encrypted ledger segment. The signature is the signature that was created when they signed a PoH value for the current storage epoch. The list of proofs from the current storage epoch should be saved in the account state, and then transferred to a list of proofs for the previous epoch when the epoch passes. In a given storage epoch a given archiver should only submit proofs for one segment.
 
 The program should have a list of slots which are valid storage mining slots. This list should be maintained by keeping track of slots which are rooted slots in which a significant portion of the network has voted on with a high lockout value, maybe 32-votes old. Every SLOTS_PER_SEGMENT number of slots would be added to this set. The program should check that the slot is in this set. The set can be maintained by receiving a AdvertiseStorageRecentBlockHash and checking with its bank/Tower BFT state.
 
@@ -381,7 +381,7 @@ keys = [validator_keypair, archiver_keypair(s) (unsigned)]
 
 A validator will submit this transaction to indicate that a set of proofs for a given segment are valid/not-valid or skipped where the validator did not look at it. The keypairs for the archivers that it looked at should be referenced in the keys so the program logic can go to those accounts and see that the proofs are generated in the previous epoch. The sampling of the storage proofs should be verified ensuring that the correct proofs are skipped by the validator according to the logic outlined in the validator behavior of sampling.
 
-The included archiver keys will indicate the the storage samples which are being referenced; the length of the proof_mask should be verified against the set of storage proofs in the referenced archiver account\(s\), and should match with the number of proofs submitted in the previous storage epoch in the state of said archiver account.
+The included archiver keys will indicate the storage samples which are being referenced; the length of the proof_mask should be verified against the set of storage proofs in the referenced archiver account\(s\), and should match with the number of proofs submitted in the previous storage epoch in the state of said archiver account.
 
 ### ClaimStorageReward
 

docs/src/running-validator/vote-accounts.md

@@ -106,8 +106,8 @@ The authorized withdrawer is also required to sign any transaction to change
 a vote account's [commission](#commission), and to change the validator
 identity on a vote account.
 
-Because theft of a authorized withdrawer keypair can give complete control over
-the operation of a validator to an attacker, is is advised to keep the withdraw
+Because theft of an authorized withdrawer keypair can give complete control over
+the operation of a validator to an attacker, it is advised to keep the withdraw
 authority keypair in an offline/cold wallet in a secure location.  The withdraw
 authority keypair is not needed during operation of a validator and should not
 stored on the validator itself.
@@ -152,7 +152,7 @@ creating an account with `--commission 10` will set a 10% commission.
 
 ## Key Rotation
 
-Rotating the vote account authority keys require special handling when dealing
+Rotating the vote account authority keys requires special handling when dealing
 with a live validator.
 
 Note that vote account key rotation has no effect on the stake accounts that
@@ -163,7 +163,7 @@ without any impact to staking rewards.
 ### Vote Account Validator Identity
 
 You will need access to the _authorized withdrawer_ keypair for the vote account to
-change the validator identity. The follow steps assume that
+change the validator identity. The following steps assume that
 `~/authorized_withdrawer.json` is that keypair.
 
 1. Create the new validator identity keypair, `solana-keygen new -o ~/new-validator-keypair.json`.
@@ -230,7 +230,7 @@ then a two-stage signing process using a [Durable Nonce](../offline-signing/dura
 3. When the `solana vote-authorize-...-checked` command successfully executes, it will output transaction signatures that Entity B must share with Entity A
 4. Entity A then runs a similar `solana vote-authorize-voter-checked` or `solana vote-authorize-withdrawer-checked` command with the following changes:
   - the `--sign-only` argument is removed, and replaced with a `--signer` argument for each of the signatures provided by Entity B
-  - the address of Entity A's existing authority is replaced with the corresponding keypair, and the the keypair for Entity B's new authority is replaced with the correponding address
+  - the address of Entity A's existing authority is replaced with the corresponding keypair, and the keypair for Entity B's new authority is replaced with the corresponding address
 
 On success the authority is now changed without Entity A or B having to reveal keypairs to the other even though both entities signed the transaction.