Docs fix spelling issues

Docs/articles/design.md

@@ -4,7 +4,7 @@ Libplanet design
 Libplanet is a network/storage library for [peer-to-peer][P2P] distributed
 multiplayer games.  From the perspective of this library's user,
 it can be similar to a client library of a [PaaS] for games,
-except that autonomous nodes run by gamers communicate with
+except those autonomous nodes run by gamers communicate with
 each other without any authority of the centralized server.
 
 Under the hood, because we need to prevent malicious nodes in the network from
@@ -15,7 +15,7 @@ Implementing blockchain and BFT consensus for peer-to-peer distributed
 multiplayer games is highly complicated, requires a lot of code to
 be written, and is difficult and tedious to test.  For the future of
 decentralized online games, rather than every single game making such redundant
-effort, it will be more cost-efficient to make a high quality open source
+effort, it will be more cost-efficient to make a high-quality open source
 library for commonly performed tasks.
 
 [P2P]: https://en.wikipedia.org/wiki/Peer-to-peer
@@ -55,17 +55,17 @@ For the maximum compatibility and portability, we currently target
 Transactions and actions
 ------------------------
 
-Every action that happened in a game built on Libplanet should be recorded in
+Every action that happens in a game built on Libplanet should be recorded in
 the blockchain.  Although trivial things like chatting between players could be
-an exception as these do not affect rules or incentives of a game, actions such
+an exception as these do not affect the rules or incentives of a game, actions such
 as a character's movement, battle, progression (i.e., exp), item drops,
 reinforcements, breakages, trades, that are non-trivial and affect game states
 should be recorded to the append-only log.  Each log has its own digital
 signature to prove that the corresponding gamer is responsible.
 
 We call the unit of such pair of log and its signature a
 @"Libplanet.Tx.Transaction`1", and it consists of multiple
-@"Libplanet.Tx.Transaction`1.Actions".  How transactions and actions grouped is
+@"Libplanet.Tx.Transaction`1.Actions".  How transactions and actions are grouped is
 left to a game engineer's discretion.  For example, if there are four actions
 like *A* to *D*, these can be grouped altogether (e.g., *{A, B, C, D}*),
 or be into two or three groups (e.g., *{A} & {B, C, D}*), or rather have
@@ -88,7 +88,7 @@ at best to 20 seconds even at worst.
 Does it imply the best practice is to put as many actions as possible into
 as few transactions as possible?  Unfortunately it is not that simple.
 
-Putting many actions into few transactions decreases the immediacy of
+Putting many actions into a few transactions decreases the immediacy of
 each action.  To other nodes (gamers), it looks like there is no change at
 all for a while, and then suddenly many things happening at once.
 Grouping actions into transactions is a balance between throughput and latency,
@@ -120,7 +120,7 @@ Accounts and addresses
 
 Libplanet creates digital signatures to find which player node made each
 transaction, without relying on the authority of a centralized server.
-In the similar fashion to [Bitcoin] and [Ethereum], a transaction is signed
+In a similar fashion to [Bitcoin] and [Ethereum], a transaction is signed
 with [ECDSA], and a pair of each player's sole @"Libplanet.Crypto.PrivateKey"
 and @"Libplanet.Crypto.PublicKey" used to sign transactions construct
 an *account*.  Since a pair of keys for an account is *chosen* at offline,
@@ -129,7 +129,7 @@ the process of so-called "account creation" can be omitted.
 An account can also be identified through the @"Libplanet.Address" which is
 derived from the corresponding @"Libplanet.Crypto.PublicKey".  It is shorter
 than @"Libplanet.Crypto.PublicKey" and follows the same form to Ethereum's.
-This means key pairs that have used for Ethereum can be reused for
+This means key pairs that have been used for Ethereum can be reused for
 Libplanet-backed games too.  For example, a game can raise funding or receive
 donations through Ethereum and then reward people when the game is released.
 

Docs/articles/overview.md

@@ -11,7 +11,7 @@ This document describes the structure and usage of [Libplanet] designed to be ea
 Libplanet
 ---------
 
-Libplanet is a network/storage library for games that run in distributed P2P network. In many traditional multiplayer games, it was up to the game server to manage the network and the state of games.
+Libplanet is a network/storage library for games that run in a distributed P2P network. In many traditional multiplayer games, it was up to the game server to manage the network and the state of games.
 
 ```text
                        Traditional multiplayer game
@@ -80,7 +80,7 @@ As mentioned above, games using Libplanet can manage their state from each clien
 
 ```
 
-- Because the way of transitioning the State through an Action depends on each game, Libplanet does not directly provide implementation of the Action and only provides the interface @"Libplanet.Action.IAction".
+- Because the way of transitioning the State through an Action depends on each game, Libplanet does not directly provide an implementation of the Action and only provides the interface @"Libplanet.Action.IAction".
 - The State is expressed in key-value pairs, and you can set appropriate values for each game.
 - The State is readable at any point, but transitioning it is only possible through an Action.
 - Libplanet does not directly share the transitioned State, but only shares the Action that will transition the State. Also, because State transitioned by an Action occurs on all nodes in the network, the Action must be written deterministically to return the same result from all nodes.
@@ -243,7 +243,7 @@ Consensus
 
 Libplanet is a library that enables game developers to create "centralized server"-less multiplayer games. “Centralized server-less” means that not only one entity is responsible for the state of the game, but every node in the network has the state of the game and synchronizes it accordingly. To synchronize, it should maintain a consistent state even in the event of a failure or tampering. The way of choosing which state is canonical is also called [consensus] in distributed computing and multi-agent environments.
 
-The algorithms used for consensus are various, with many different characteristics and pros and cons. For example, [Proof of Work (PoW)][PoW] allows anyone with computing power to participate in the network, but that cannot guarantee the state of the game at a specific time. In contrast, [Proof of Authority (PoA)][PoA] can guarantee that a game's state is established after a certain time, but only authorized users can join the network. These characteristics may work for some games, but won't for others, making the consensus algorithm also unusable for a general purpose network.
+The algorithms used for consensus are various, with many different characteristics and pros and cons. For example, [Proof of Work (PoW)][PoW] allows anyone with computing power to participate in the network, but that cannot guarantee the state of the game at a specific time. In contrast, [Proof of Authority (PoA)][PoA] can guarantee that a game's state is established after a certain time, but only authorized users can join the network. These characteristics may work for some games, but won't for others, making the consensus algorithm also unusable for a general-purpose network.
 
 Libplanet isn't a tool for creating games of any particular genre, but rather a tool for creating varied types of games. Also it assumes that each game has a different network and consensus algorithm. Nor is Libplanet itself a project that focuses on developing and testing any particular consensus algorithm or mechanism. That's why Libplanet aims to allow game developers to choose a consensus algorithm at implementation time to suit their game's characteristics.
 

RELEASE.md

@@ -9,7 +9,7 @@ process is half automated, this covers the other half that humans should
 manually conduct.
 
 Note that there is the [quick summary](#quick-summary) to remind those who have
-already read this document of checklist on the bottom.  If it is your first
+already read this document of checklist at the bottom.  If it is your first
 time to this, you should read the whole document first.
 
 
@@ -158,7 +158,7 @@ If what you have just released is a patch release, there are two manual tasks
 to do:
 
  -  Port the released code to the *main* branch, so that the next major/minor
-    release does not miss bugfixes from the previous patch release.
+    release does not miss bug fixes from the previous patch release.
  -  Prepare the next patch release.
 
 First of all, your last release should be ported to the *main* branch.
@@ -235,7 +235,7 @@ git switch --create=1.2-maintenance  # Or: git checkout -b 1.2-maintenance
 git reset --hard upstream/main
 ~~~~
 
-Since this maintenance branch purposes to prepare the next patch release, e.g.,
+Since this maintenance branch's purpose is to prepare the next patch release, e.g.,
 *1.2.1*, the `<VersionPrefix>` field of the *Directory.Build.props*
 file also needs to be updated:
 
@@ -267,7 +267,7 @@ See also the below commit for example:
 
 <https://github.com/planetarium/libplanet/commit/836949f72700cf49f56396be05b92d4d7c994abd>
 
-To prepare the next *major* or *minor* release, you need to do the similar task
+To prepare for the next *major* or *minor* release, you need to do the similar task
 again.  Whether to release a new *major* version or a new *minor* version next
 depends on the roadmap (it should be discussed in advance).  Suppose we plan
 to release *1.3.0* next time here.
@@ -314,7 +314,7 @@ The checklist to release a new version:
  4. Send a pull request and wait until it is merged.
  5. `git tag --sign -m "Libplanet X.Y.Z" X.Y.Z`
  6. `git push upstream X.Y.Z`
- 7. Check if the all automated processes are successful.
+ 7. Check if all automated processes are successful.
      - GitHub Releases
      - NuGet
      - npm

changes/v0.md

@@ -358,7 +358,7 @@ and the specification might change in the near future.
  -  Added `IStore.GetBlockCommitHashes()` method.  [[#2872]]
  -  `BlockMetadata.MakeCandidateData()` now uses a SHA256 hash of `LastCommit`
     for creating a candidate data for `PreEvaluationBlockHeader<T>`. Due to this
-    change, `PreEvaluationHash` results different with previous block hash
+    change, `PreEvaluationHash` results are different from previous block hash
     computation if the `BlockMetadata.LastCommit` is not null.  [[#2872]]
  -  (Libplanet.Net) Removed `SwarmOptions.StaticPeers`.  [[#2872]]
  -  Changed `BlockPolicy<T>()` constructor not to take
@@ -429,15 +429,15 @@ and the specification might change in the near future.
     `InvalidBlockLastCommitException` when its metadata's `LastCommit` is
     invalid.  [[#2872]]
  -  `BlockChain<T>.Append()` has new parameter `BlockCommit blockCommit`, which
-    is a set of commits for given block. `BlockCommit` is used for checks
+    is a set of commits for a given block. `BlockCommit` is used for checks
     whether a block is committed in consensus.  [[#2872]]
  -  `BlockChain<T>.Append()` method became to throw
     `InvalidBlockCommitException` when the given `BlockCommit` is invalid with
     given block.  [[#2872]]
 
 ### Bug fixes
 
- -  (Libplanet.Explorer) Fixed a bug where `stateQuery` hadn't work
+ -  (Libplanet.Explorer) Fixed a bug where `stateQuery` hadn't worked
     correctly in some situations.  [[#2872]]
 
 ### Dependencies
@@ -777,7 +777,7 @@ Released on February 6, 2023.
  -  (Libplanet.Explorer) Fixed a bug where the query `stateQuery` hadn't work
     correctly.  [[#2757]]
  -  Fixed a bug of `DefaultStore.PutTxExecution()` where sometimes `TxExecution`
-    data is in undefined state due to data corruption.  [[#2761]]
+    data is in an undefined state due to data corruption.  [[#2761]]
  -  (Libplanet.Node) Fixed a bug of `NodeUtils<T>.CreateGenesisBlock()` where
     sometimes block data is in undefined state due to data corruption.
     [[#2761]]

changes/v4.md

@@ -120,7 +120,7 @@ may not be compatible.
  -  (Libplanet.Action) `IWorldState.GetTotalSupply()` no longer throws
     a `TotalSupplyNotTrackableException` but returns a zero amount of
     corresponding `FungibleAssetValue`.  [[#3780]]
- -  (Libplanet.Action) Changed the precednce for the types of `Exception`s
+ -  (Libplanet.Action) Changed the precedence for the types of `Exception`s
     that may be thrown by `IWorld.MintAsset()` and
     `IWorld.BurnAsset()`.