docs: fix typos and link error (#2776)

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.
 

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.

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
 

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 |

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)

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`