Documentation Fixes: Grammatical Corrections and Typo Fixes Across Mu…

…ltiple Files (#2550)

CONTRIBUTING.md

@@ -25,7 +25,7 @@ To start developing on AvalancheGo, you'll need a few things installed.
 
 ## Features
 
-- If you want to start a discussion about the development of a new feature or the modfiication of an existing one, start a thread under GitHub [discussions](https://github.com/ava-labs/avalanchego/discussions/categories/ideas).
+- If you want to start a discussion about the development of a new feature or the modification of an existing one, start a thread under GitHub [discussions](https://github.com/ava-labs/avalanchego/discussions/categories/ideas).
 - Post a thread about your idea and why it should be added to AvalancheGo.
 - Don't start working on a pull request until you've received positive feedback from the maintainers.
 

network/README.md

@@ -128,7 +128,7 @@ To optimize bandwidth usage, each node tracks which peers are guaranteed to know
 
 To efficiently track which peers know of which peers, the peers that each peer is aware of is represented in a [bit set](https://en.wikipedia.org/wiki/Bit_array). A peer is represented by either a `0` if it isn't known by the peer yet, or a `1` if it is known by the peer.
 
-An node follows the following steps for every cycle of `PeerList` gossip:
+A node follows the following steps for every cycle of `PeerList` gossip:
 
 1. Get a sample of peers in the network that the node is connected to
 2. For each peer:

tests/e2e/README.md

@@ -66,7 +66,7 @@ across multiple test runs. This can increase the speed of iteration by
 removing the requirement to start a new network for every invocation
 of the test under development.
 
-To create an temporary network for use across test runs:
+To create a temporary network for use across test runs:
 
 ```bash
 # From the root of the avalanchego repo

vms/example/xsvm/README.md

@@ -18,7 +18,7 @@ Avalanche is a network composed of multiple sub-networks (called [subnets][Subne
 
 ## Introduction
 
-Just as [Coreth] powers the [C-Chain], XSVM can be used to power its own blockchain in an Avalanche [Subnet]. Instead of providing a place to execute Solidity smart contracts, however, XSVM enables asset transfers for assets originating on it's own chain or other XSVM chains on other subnets.
+Just as [Coreth] powers the [C-Chain], XSVM can be used to power its own blockchain in an Avalanche [Subnet]. Instead of providing a place to execute Solidity smart contracts, however, XSVM enables asset transfers for assets originating on its own chain or other XSVM chains on other subnets.
 
 ## How it Works
 

vms/platformvm/docs/validators_versioning.md

@@ -18,7 +18,7 @@ GetValidatorSet(ctx context.Context, height uint64, subnetID ids.ID) (map[ids.No
 
 Validator data are collected in a struct named `validators.GetValidatorOutput` which holds for each active validator, its `NodeID`, its `Weight` and its `BLS Public Key` if it was registered.
 
-Note that a validator `Weight` is not just its stake; its the aggregate value of the validator's own stake and all of its delegators' stake. A validator's `Weight` gauges how relevant its preference should be in consensus or Warp operations.
+Note that a validator `Weight` is not just its stake; it's the aggregate value of the validator's own stake and all of its delegators' stake. A validator's `Weight` gauges how relevant its preference should be in consensus or Warp operations.
 
 We will see in the next section how the P-chain keeps track of this information over time as the validator set changes.
 
@@ -35,7 +35,7 @@ These diffs are key to rebuilding the validator set at a given past height. In t
 
 The validators diffs track changes in a validator's `Weight` and `BLS Public key`. Along with the `NodeID` this is the data exposed by the `GetValidatorSet` method.
 
-Note that `Weight` and `BLS Public key` behave differently throughout the validator lifetime:
+Note that `Weight` and `BLS Public key` behave differently throughout the validator's lifetime:
 
 1. `BLS Public key` cannot change through a validator's lifetime. It can only change when a validator is added/re-added and removed.
 2. `Weight` can change throughout a validator's lifetime by the creation and removal of its delegators as well as by validator's own creation and removal.

vms/proposervm/README.md

@@ -47,7 +47,7 @@ A proposer in position `i` in the proposers list has its submission windows star
 The following validation rules are enforced:
 
 - Given a `proposervm.Block` **C** and its parent block **P**, **P**'s inner block must be **C**'s inner block's parent.
-- A block must have a `PChainHeight` is larger or equal to its parent's `PChainHeight` (`PChainHeight` is monotonic).
+- A block must have a `PChainHeight` that is larger or equal to its parent's `PChainHeight` (`PChainHeight` is monotonic).
 - A block must have a `PChainHeight` that is less or equal to current P-Chain height.
 - A block must have a `Timestamp` larger or equal to its parent's `Timestamp` (`Timestamp` is monotonic)
 - A block received by a node at time `t_local` must have a `Timestamp` such that `Timestamp < t_local + maxSkew` (a block too far in the future is invalid). `maxSkew` is currently set to `10 seconds`.

vms/rpcchainvm/runtime/README.md

@@ -17,7 +17,7 @@ It works by starting the VM's as a subprocess of AvalancheGo by `os.Exec`.
 ## Workflow
 
 - `VMRegistry` calls the RPC Chain VM `Factory`.
-- Factory Starts an instanace of a `VMRE` server that consumes a `runtime.Initializer` interface implementation.
+- Factory Starts an instance of a `VMRE` server that consumes a `runtime.Initializer` interface implementation.
 - The address of this server is passed as a ENV variable `AVALANCHE_VM_RUNTIME_ENGINE_ADDR` via `os.Exec` which starts the VM binary.
 - The VM uses the address of the `VMRE` server to create a client.
 - Client sends a `Initialize` RPC informing the server of the `Protocol Version` and future `Address` of the RPC Chain VM server allowing it to perform a validation `Handshake`.