Fix typos in document files (#3622)

RELEASES.md

@@ -2060,7 +2060,7 @@ The plugin version is unchanged at `27` and compatible with versions `v1.10.5 -
 
 ### APIs
 
-- Modifed `platform.getValidatorsAt` to also return BLS public keys
+- Modified `platform.getValidatorsAt` to also return BLS public keys
 
 ### Configs
 

snow/README.md

@@ -39,7 +39,7 @@ All messaging functions in `OutboundMsgBuilder` can be categorized as follows:
 - **Bootstrapping**
   - Nodes can ask other nodes for blocks to build their own copy of the chain. A node can fetch all blocks from the locally last accepted block to the current last accepted block in the network.
 - **Consensus**
-  - Once a node is up to tip they can participate in consensus! During consensus, a node conducts a poll to several different small random samples of the validator set. They can communicate decisons on whether or not they have accepted/rejected a block.
+  - Once a node is up to tip they can participate in consensus! During consensus, a node conducts a poll to several different small random samples of the validator set. They can communicate decisions on whether or not they have accepted/rejected a block.
 - **App**
   - VMs communicate application-specific messages to other nodes through app messages. A common example is mempool gossiping.
 

tests/antithesis/README.md

@@ -147,7 +147,7 @@ can be performed against master or an arbitrary branch:
  - Find the 'Run workflow' drop-down on the right and trigger the
    workflow against the desired branch. The default value for
    `image_tag` (`latest`) is used by scheduled test runs, so consider
-   supplying a different value to avoid interferring with the results
+   supplying a different value to avoid interfering with the results
    of the scheduled runs.
  - Wait for the publication job to complete successfully so that the
    images are available to be tested against.

tests/fixture/bootstrapmonitor/README.md

@@ -1,7 +1,7 @@
 # bootstrap-monitor
 
 Code rooted at this package implements a `bootstrap-monitor` binary
-intended to enable continous bootstrap testing for avalanchego
+intended to enable continuous bootstrap testing for avalanchego
 networks.
 
 ## Bootstrap testing
@@ -41,7 +41,7 @@ processed. This is configured by including
 
 The intention of `bootstrap-monitor` is to enable a Kubernetes
 [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
-to perform continous bootstrap testing for a given avalanchego
+to perform continuous bootstrap testing for a given avalanchego
 configuration. It ensures that a testing pod either starts or resumes
 a test, and upon completion of a test, polls for a new image to test
 and initiates a new test when one is found.
@@ -178,7 +178,7 @@ sync bootstrap usually takes much longer.
 
 If avalanchego supported a `--bootstrap-mode` flag that exited on
 successful bootstrap, and a pod configured with this flag used an
-image with a `latest` tag, the pod would continously bootstrap, exit,
+image with a `latest` tag, the pod would continuously bootstrap, exit,
 and restart with the current latest image. While appealingly simple,
 this approach doesn't directly support:
 

tests/fixture/tmpnet/README.md

@@ -199,7 +199,7 @@ The chain configuration for a temporary network is stored at
 by all nodes in the network. The C-Chain config will be generated with
 reasonable defaults if not supplied. X-Chain and P-Chain will use
 implicit defaults. The configuration for custom chains can be provided
-with subnet configuration and will be writen to the appropriate path.
+with subnet configuration and will be written to the appropriate path.
 
 Each node in the network can override network-level chain
 configuration by setting `--chain-config-dir` to an explicit value and

x/merkledb/README.md

@@ -69,7 +69,7 @@ In the diagram above, if `view1` were committed, `view2` would be invalidated. I
 
 MerkleDB instances can produce _merkle proofs_, sometimes just called "proofs." A merkle proof uses cryptography to prove that a given key-value pair is or isn't in the key-value store with a given root. That is, a MerkleDB instance with root ID `r` can create a proof that shows that it has a key-value pair `(k,v)`, or that `k` is not present.
 
-Proofs can be useful as a client fetching data in a Byzantine environment. Suppose there are one or more servers, which may be Byzantine, serving a distirbuted key-value store using MerkleDB, and a client that wants to retrieve key-value pairs. Suppose also that the client can learn a "trusted" root ID, perhaps because it's posted on a blockchain. The client can request a key-value pair from a server, and use the returned proof to verify that the returned key-value pair is actually in the key-value store with (or isn't, as it were.)
+Proofs can be useful as a client fetching data in a Byzantine environment. Suppose there are one or more servers, which may be Byzantine, serving a distributed key-value store using MerkleDB, and a client that wants to retrieve key-value pairs. Suppose also that the client can learn a "trusted" root ID, perhaps because it's posted on a blockchain. The client can request a key-value pair from a server, and use the returned proof to verify that the returned key-value pair is actually in the key-value store with (or isn't, as it were.)
 
 ```mermaid
 flowchart TD