From c1905b643f5070f807e75324474bd757b9837533 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 10 Jan 2025 17:08:29 +0200 Subject: [PATCH 1/5] Update design.md --- Docs/articles/design.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Docs/articles/design.md b/Docs/articles/design.md index ef3a681ab31..a5971eba54d 100644 --- a/Docs/articles/design.md +++ b/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,9 +55,9 @@ 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 @@ -65,7 +65,7 @@ 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. From 8ece69bfd703166a278e57aab6576c7d420af7fa Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 10 Jan 2025 17:09:15 +0200 Subject: [PATCH 2/5] Update overview.md --- Docs/articles/overview.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Docs/articles/overview.md b/Docs/articles/overview.md index d4b89b2d94d..aa8808bfd87 100644 --- a/Docs/articles/overview.md +++ b/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. From bda18a91361554ee78a31c2d2f3faf63feab6ff4 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 10 Jan 2025 17:11:19 +0200 Subject: [PATCH 3/5] Update v0.md --- changes/v0.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/changes/v0.md b/changes/v0.md index 449b878124e..6918d979466 100644 --- a/changes/v0.md +++ b/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`. 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()` constructor not to take @@ -429,7 +429,7 @@ and the specification might change in the near future. `InvalidBlockLastCommitException` when its metadata's `LastCommit` is invalid. [[#2872]] - `BlockChain.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.Append()` method became to throw `InvalidBlockCommitException` when the given `BlockCommit` is invalid with @@ -437,7 +437,7 @@ and the specification might change in the near future. ### 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.CreateGenesisBlock()` where sometimes block data is in undefined state due to data corruption. [[#2761]] From d412d1da5e095daaa3dbcee9613f32d8a6e3861e Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 10 Jan 2025 17:12:17 +0200 Subject: [PATCH 4/5] Update v4.md --- changes/v4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/changes/v4.md b/changes/v4.md index 9a192c7a95f..b5ae210d2e2 100644 --- a/changes/v4.md +++ b/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()`. From 358959f366da0b8df467b247f527a6d29fb5487a Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 10 Jan 2025 17:14:57 +0200 Subject: [PATCH 5/5] Update RELEASE.md --- RELEASE.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 763ea1ee58a..83a77aab2be 100644 --- a/RELEASE.md +++ b/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 `` field of the *Directory.Build.props* file also needs to be updated: @@ -267,7 +267,7 @@ See also the below commit for example: -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