Docs: fix typos

chain/chunks/README.md

@@ -5,12 +5,12 @@ This crate contains functions to handle chunks. In NEAR - the block consists of
 When a chunk is created, the creator encodes its contents using Reed Solomon encoding (ErasureCoding) and adds cross-shard receipts - creating PartialEncodedChunks that are later sent to all the validators (each validator gets a subset of them). This is done for data availability reasons (so that we need only a part of the validators to reconstruct the whole chunk). You can read more about it in [the Nightshade paper](https://near.org/papers/nightshade).
 
 
-A honest validator will only approve a block if it receives its assigned parts for all chunks in the block - which means that for each chunk, it has `has_all_parts()` returning true.
+An honest validator will only approve a block if it receives its assigned parts for all chunks in the block - which means that for each chunk, it has `has_all_parts()` returning true.
 
 For all nodes (validators and non-validators), they will only accept/process a block if the following requirements are satisfied:
 
 * for every shard it tracks, a node has to have the full chunk,
-* for every shard it doesn't track, a node has have the receipts from this shard to all shards
+* for every shard it doesn't track, a node has the receipts from this shard to all shards
 
 
 If node tracks given shard (that is - it wants to have a whole content of the shard present in the local memory) - it will want to receive the necessary amount of PartialChunks to be able to reconstruct the whole chunk. As we use ReedSolomon, this means that they need `data_shard_count` PartialChunks (which is lower than `total_shard_count`). Afterwards, it will reconstruct the chunk and persist it in the local storage (via chain/client).

chain/epoch-manager/README.md

@@ -16,7 +16,7 @@ Main class that has two main functions:
 When 'finalize_epoch' is called, the EpochManager will do all the necessary processing (like computing validator rewards for the current epoch (T), selecting validators for the next next epoch (T+2) etc) and create the new EpochId/EpochInfo.
 
 ### Accessing epoch information
-EpochManager has also a lot of methords that allows you to fetch information from different past and present epochs (like who is the chunk/block producer for a given chunk/block, whether the block is at the end of epoch boundary and requires more signatures etc)
+EpochManager has also a lot of methods that allows you to fetch information from different past and present epochs (like who is the chunk/block producer for a given chunk/block, whether the block is at the end of epoch boundary and requires more signatures etc)
 
 
 ## RewardCalculator
@@ -31,7 +31,7 @@ and the new implementation present in the code - with new code existing in `vali
 
 
 ## Shard assignments
-This code is responsible for assigning validators (and chunk producers) to shards (chunks). This wil be used only once we enable `chunk_only_producers` feature (as before, we're simply assigning all the validators to validate each chunk).
+This code is responsible for assigning validators (and chunk producers) to shards (chunks). This will be used only once we enable `chunk_only_producers` feature (as before, we're simply assigning all the validators to validate each chunk).
 
 
 

chain/indexer/CHANGELOG.md

@@ -10,7 +10,7 @@
 
 ## 1.32.x
 
-* Add `nightly` feature to NEAR Indexer Framework to respect this feature for `nearcore` lib (requried for `betanet`)
+* Add `nightly` feature to NEAR Indexer Framework to respect this feature for `nearcore` lib (required for `betanet`)
 
 ## 1.26.0
 

chain/jsonrpc/README.md

@@ -19,7 +19,7 @@ communicated through the CHANGELOG next to this file.
 
 1. We only add the APIs to the data that is already available in nearcore
    storage.
-2. We don't violate the guaranties described in the section above.
+2. We don't violate the guarantees described in the section above.
 3. We prefix new APIs with `EXPERIMENTAL_` (see the Experimental API Policies
    below).
 4. We document the API change on [NEAR Docs](https://docs.near.org/api/rpc/introduction)

docs/practices/workflows/otel_traces.md

@@ -3,7 +3,7 @@
 `neard` is instrumented in a few different ways. From the code perspective we have two major ways
 of instrumenting code:
 
-* Prometheus metrics – by computing various metrics in code and expoding them via the `prometheus`
+* Prometheus metrics – by computing various metrics in code and exposing them via the `prometheus`
   crate.
 * Execution tracing – this shows up in the code as invocations of functionality provided by the
   `tracing` crate.

docs/practices/workflows/profiling.md

@@ -136,7 +136,7 @@ $ cargo build --release -p bytehound-preload
 $ cargo build --release -p bytehound-cli
 ```
 
-You will also need a build of your `neard`, once you have that, give it some ambient cabapilities
+You will also need a build of your `neard`, once you have that, give it some ambient capabilities
 necessary for profiling:
 
 ```command