From 614b5ea4a7a9f3a09d80c7365ef3782ea551050b Mon Sep 17 00:00:00 2001 From: taozui472 Date: Thu, 26 Dec 2024 23:57:13 +0800 Subject: [PATCH] Fix typos in document files (#3622) --- RELEASES.md | 2 +- snow/README.md | 2 +- tests/antithesis/README.md | 2 +- tests/fixture/bootstrapmonitor/README.md | 6 +++--- tests/fixture/tmpnet/README.md | 2 +- x/merkledb/README.md | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index ead7979ee779..e655fbd15d84 100644 --- a/RELEASES.md +++ b/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 diff --git a/snow/README.md b/snow/README.md index 99cfc5351356..1f151024f5bb 100644 --- a/snow/README.md +++ b/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. diff --git a/tests/antithesis/README.md b/tests/antithesis/README.md index 02dd64d402ca..43c437a68594 100644 --- a/tests/antithesis/README.md +++ b/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. diff --git a/tests/fixture/bootstrapmonitor/README.md b/tests/fixture/bootstrapmonitor/README.md index a772ae0f57d0..6bcf1c92a1da 100644 --- a/tests/fixture/bootstrapmonitor/README.md +++ b/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: diff --git a/tests/fixture/tmpnet/README.md b/tests/fixture/tmpnet/README.md index 718ae065a812..17b3ef2600b2 100644 --- a/tests/fixture/tmpnet/README.md +++ b/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 diff --git a/x/merkledb/README.md b/x/merkledb/README.md index 9f840c343776..48083bc6260c 100644 --- a/x/merkledb/README.md +++ b/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