diff --git a/chain/chunks/README.md b/chain/chunks/README.md index 848bac944ce..f9ad04cbf33 100644 --- a/chain/chunks/README.md +++ b/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). diff --git a/chain/epoch-manager/README.md b/chain/epoch-manager/README.md index 0be415e9c97..0d278111add 100644 --- a/chain/epoch-manager/README.md +++ b/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). diff --git a/chain/indexer/CHANGELOG.md b/chain/indexer/CHANGELOG.md index 9ca6fca53f1..7a2a52312ec 100644 --- a/chain/indexer/CHANGELOG.md +++ b/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 diff --git a/chain/jsonrpc/README.md b/chain/jsonrpc/README.md index 54b1b228592..18d93fd59eb 100644 --- a/chain/jsonrpc/README.md +++ b/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) diff --git a/docs/practices/workflows/otel_traces.md b/docs/practices/workflows/otel_traces.md index 3ce9a8925bf..6e6f2a34d88 100644 --- a/docs/practices/workflows/otel_traces.md +++ b/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. diff --git a/docs/practices/workflows/profiling.md b/docs/practices/workflows/profiling.md index 4187d378cdb..97cacbd1a8c 100755 --- a/docs/practices/workflows/profiling.md +++ b/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