Fix typos and add missing hyphens in README files

tests/fixture/bootstrapmonitor/README.md

@@ -170,7 +170,7 @@ and initiates a new test when one is found.
 to the available storage of 30GB being insufficient for even state
 sync bootstrap.
  - Self-hosted github workers are not compatible with bootstrap testing
-due to the 5 day maximum duration for a job running on a self-hosted
+due to the 5-day maximum duration for a job running on a self-hosted
 runner. State sync bootstrap usually completes within 5 days, but full
 sync bootstrap usually takes much longer.
 

vms/platformvm/docs/mempool_gossiping.md

@@ -8,7 +8,7 @@ In conjunction with the introduction of [Snowman++](../../proposervm), the mempo
 
 The PlatformVM's mempool performs the following workflow:
 
-- An unconfirmed transaction is provided to `node A`, either through mempool gossiping or direct issuance over a RPC. If this transaction isn't already in the local mempool, the transaction is issued into the mempool.
+- An unconfirmed transaction is provided to `node A`, either through mempool gossiping or direct issuance over an RPC. If this transaction isn't already in the local mempool, the transaction is issued into the mempool.
 - When `node A` issues a new transaction into its mempool, it will gossip the transaction ID by sending an `AppGossip` message. The node's engine will randomly select peers (currently defaulting to `6` nodes) to send the `AppGossip` message to.
 - When `node B` learns about the existence of a remote transaction ID, it will check if its mempool contains the transaction or if it has been recently dropped. If the transaction ID is not known, `node B` will generate a new `requestID` and respond with an `AppRequest` message with the unknown transaction's ID. `node B` will track the content of the request issued with `requestID` for response verification.
 - Upon reception of an `AppRequest` message, `node A` will attempt to fetch the transaction requested in the `AppRequest` message from its mempool. Note that a transaction advertised in an `AppGossip` message may no longer be in the mempool, because they may have been included into a block, rejected, or dropped. If the transaction is retrieved, it is encoded into an `AppResponse` message. The `AppResponse` message will carry the same `requestID` of the originating `AppRequest` message and it will be sent back to `node B`.

vms/proposervm/README.md

@@ -71,7 +71,7 @@ Generally speaking the `proposerVM` wraps an inner block generated by the inner
 There are three kinds of `proposervm.Blocks`:
 
 - `preForkBlock` is a simple wrapper of an inner block. A `preForkBlock` does not change the ID or serialization of an inner block; it's simply an in-memory object allowing correct verification of `preForkBlocks` (see [Execution modes](#execution-modes) section below for further details of why this is required).
-- `postForkBlock` adds congestion-control related fields to an inner block, resulting in a different ID and serialization than the inner block. Note that for such blocks, serialization is a two step process: the header is serialized at the `proposerVM` level, while the inner block serialization is deferred to the inner VM.
+- `postForkBlock` adds congestion-control related fields to an inner block, resulting in a different ID and serialization than the inner block. Note that for such blocks, serialization is a two-step process: the header is serialized at the `proposerVM` level, while the inner block serialization is deferred to the inner VM.
 - `postForkOption` wraps inner blocks that are associated with an Oracle Block. This enables oracle blocks to be issued without enforcing the congestion control mechanism. Similarly to `postForkBlocks`, this changes the block's ID and serialization.
 
 ### Execution modes

x/sync/README.md

@@ -3,7 +3,7 @@
 ## Overview
 
 This package implements a client and server that allows for the syncing of a [MerkleDB](../merkledb/README.md).
-The servers have an up to date version of the database, and the clients have an out of date version of the database or an empty database.
+The servers have an up-to-date version of the database, and the clients have an out of date version of the database or an empty database.
 
 It's planned that these client and server implementations will eventually be compatible with Firewood.
 
@@ -62,7 +62,7 @@ are in range [`start`, `end`] for the revision with root `root_hash`" for some k
 Note that `root_hash` is the root hash of the revision that the client is trying to sync to, not the 
 root hash of its own (incomplete) database.
 Tracking the revision associated with each downloaded key range, as well as using data in its own 
-(incomplete) database, allows the client to figure out which key ranges are not up to date and need to be synced.
+(incomplete) database, allows the client to figure out which key ranges are not up-to-date and need to be synced.
 The hash of the incomplete database on a client is never sent anywhere because it does not represent a root hash of any revision.
 
 When the client is created, it is given the root hash of the revision to sync to.
@@ -94,7 +94,7 @@ The sync client can be notified that the root hash of the database it's trying t
 Detecting that the root hash to sync to has changed is done outside this package.
 For example, if the database is being used to store blockchain state then the sync client would be 
 notified when a new block is accepted because that implies a commit to the database.
-If this occurs, the key-value pairs the client has learned about via range proofs may no longer be up to date.
+If this occurs, the key-value pairs the client has learned about via range proofs may no longer be up-to-date.
 
 We use change proofs as an optimization to correct the out of date key-value pairs.
 When the sync client is notified that the root hash to sync to has changed, it requests a change proof