From a856af5c0c7ccd4129a9a27fe6686905485324ed Mon Sep 17 00:00:00 2001 From: vuittont60 <81072379+vuittont60@users.noreply.github.com> Date: Sun, 29 Oct 2023 20:53:02 +0800 Subject: [PATCH] docs: fix typos and link error (#2776) --- specs/src/specs/block_validity_rules.md | 2 +- specs/src/specs/cat_pool.md | 4 ++-- specs/src/specs/data_square_layout.md | 4 ++-- specs/src/specs/params.md | 4 ++-- specs/src/specs/resource_pricing.md | 2 +- x/blob/README.md | 2 +- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/specs/src/specs/block_validity_rules.md b/specs/src/specs/block_validity_rules.md index 6a620c95dd..37f1360942 100644 --- a/specs/src/specs/block_validity_rules.md +++ b/specs/src/specs/block_validity_rules.md @@ -7,7 +7,7 @@ stateless commitments to data rather than stateful transitions. This means that the protocol relies heavily on block validity rules. Notably, resource constrained light clients must be able to detect when a subset of these validity rules have not been followed in order to avoid making an honest majority -assumption on the consensus network. This has a significant impact on thier +assumption on the consensus network. This has a significant impact on their design. More information on how light clients can check the invalidity of a block can be foud in the [Fraud Proofs](./fraud_proofs.md) spec. diff --git a/specs/src/specs/cat_pool.md b/specs/src/specs/cat_pool.md index 2d329ed44f..22ad999aec 100644 --- a/specs/src/specs/cat_pool.md +++ b/specs/src/specs/cat_pool.md @@ -36,7 +36,7 @@ message WantTx { } ``` -Both `SeenTx` and `WantTx` contain the sha256 hash of the raw transaction bytes. `SeenTx` also contains an optional `p2p.ID` that corresponds to the peer that the node recieved the tx from. The only validation for both is that the byte slice of the `tx_key` MUST have a length of 32. +Both `SeenTx` and `WantTx` contain the sha256 hash of the raw transaction bytes. `SeenTx` also contains an optional `p2p.ID` that corresponds to the peer that the node received the tx from. The only validation for both is that the byte slice of the `tx_key` MUST have a length of 32. Both messages are sent across a new channel with the ID: `byte(0x31)`. This enables cross compatibility as discussed in greater detail below. @@ -75,7 +75,7 @@ Transaction pools are solely run in-memory; thus when a node stops, all transact Upon receiving a `Txs` message: -- Check whether it is in reponse to a request or simply an unsolicited broadcast +- Check whether it is in response to a request or simply an unsolicited broadcast - Validate the tx against current resources and the applications `CheckTx` - If rejected or evicted, mark accordingly - If successful, send a `SeenTx` message to all connected peers excluding the original sender. If it was from an initial broadcast, the `SeenTx` should populate the `From` field with the `p2p.ID` of the recipient else if it is in response to a request `From` should remain empty. diff --git a/specs/src/specs/data_square_layout.md b/specs/src/specs/data_square_layout.md index d2c966994c..7960e6e88c 100644 --- a/specs/src/specs/data_square_layout.md +++ b/specs/src/specs/data_square_layout.md @@ -21,7 +21,7 @@ The simplest way we can imagine arranging block data is to simply serialize it a First, we impose some ground rules: 1. Data must be ordered by namespace. This makes queries into a NMT commitment of that data more efficient. -1. Since non-blob data are not naturally intended for particular namespaces, we assign [reserved namespaces](./consensus.md#Reservered-Namespaces) for them. A range of namespaces is reserved for this purpose, starting from the lowest possible namespace. +1. Since non-blob data are not naturally intended for particular namespaces, we assign [reserved namespaces](./namespace.md#Reserved-Namespaces) for them. A range of namespaces is reserved for this purpose, starting from the lowest possible namespace. 1. By construction, the above two rules mean that non-blob data always precedes blob data in the row-major matrix, even when considering single rows or columns. 1. Data with different namespaces must not be in the same share. This might cause a small amount of wasted block space, but makes the NMT easier to reason about in general since leaves are guaranteed to belong to a single namespace. @@ -33,7 +33,7 @@ Padding is addressed in the [padding section](#padding). Namespace C contains tw ### Ordering -The order of blobs in a namespace is dictated by the priority of the PFBs that payed for the blob. A PFB with greater priority will have all blobs in that namespace strictly before a PFB with less priority. Priority is determined by the `gas-price` of the transaction (`fee`/`gas`). +The order of blobs in a namespace is dictated by the priority of the PFBs that paid for the blob. A PFB with greater priority will have all blobs in that namespace strictly before a PFB with less priority. Priority is determined by the `gas-price` of the transaction (`fee`/`gas`). ## Blob Share Commitment Rules diff --git a/specs/src/specs/params.md b/specs/src/specs/params.md index 17ab719485..c1d9e27c34 100644 --- a/specs/src/specs/params.md +++ b/specs/src/specs/params.md @@ -1,7 +1,7 @@ # Celestia Governance Params These are the parameters for mainnet. Note that not all of these parameters are -changable via governance. This list also includes parameter that require a +changeable via governance. This list also includes parameter that require a hardfork to change due to being manually hardcoded in the application or they are blocked by the `x/paramfilter` module. @@ -29,7 +29,7 @@ are blocked by the `x/paramfilter` module. | consensus.Version.AppVersion | 1 | Determines protocol rules used for a given height. Incremented by the application upon an upgrade. | False | | distribution.CommunityTax | 0.02 (2%) | Percentage of the inflation sent to the community pool. | True | | distribution.WithdrawAddrEnabled | true | Enables delegators to withdraw funds to a different address. | True | -| distribution.BaseProposerReward | 0 | Reward in the mint demonination for proposing a block. | True | +| distribution.BaseProposerReward | 0 | Reward in the mint denomination for proposing a block. | True | | distribution.BonusProposerReward | 0 | Extra reward in the mint denomination for proposers based on the voting power included in the commit. | True | | gov.DepositParams.MinDeposit | 10_000_000_000 utia (10,000 TIA) | Minimum deposit for a proposal to enter voting period. | True | | gov.DepositParams.MaxDepositPeriod | 604800000000000 (1 week) | Maximum period for token holders to deposit on a proposal in nanoseconds. | True | diff --git a/specs/src/specs/resource_pricing.md b/specs/src/specs/resource_pricing.md index ff53a41d01..e41d5b7135 100644 --- a/specs/src/specs/resource_pricing.md +++ b/specs/src/specs/resource_pricing.md @@ -236,7 +236,7 @@ Share](./figures/gas_consumption/single_share_pfb_trace.png) This PFB transaction contains two single share blobs. Notice the gas cost for `pay for blob` is double what it is above due to two shares being used, and there is also additional cost from `txSize` since the transaction itself is -larger to accomodate the second set of metadata in the PFB. +larger to accommodate the second set of metadata in the PFB. ![MsgPayForBlobs with Two Blobs](./figures/gas_consumption/pfb_with_two_single_share_blobs_trace.png) diff --git a/x/blob/README.md b/x/blob/README.md index f80adda478..a1646dc4c3 100644 --- a/x/blob/README.md +++ b/x/blob/README.md @@ -101,7 +101,7 @@ following fields: details on how this effects the share encoding and when it is updated. Note that while the shares version in each protobuf encoded PFB are uint32s, the -internal represantation of shares versions is always uint8s. This is because +internal representation of shares versions is always uint8s. This is because protobuf doesn't support uint8s. ### Generating the `ShareCommitment`