ci: enable markdownlint (#583)

.github/workflows/markdown-lint.yml

@@ -0,0 +1,22 @@
+name: Markdown Lint
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+  release:
+    types: [published]
+
+jobs:
+  markdown-lint:
+    name: Markdown Lint
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 18
+      - run: |
+          npm install -g [email protected]
+          markdownlint --config .markdownlint.yaml **/*.md

.markdownlint.yaml

@@ -0,0 +1,3 @@
+"default": true # Default state for all rules
+"MD013": false # Disable rule for line length
+"MD033": false # Disable rule banning inline HTML

contrib/githooks/README.md

@@ -2,8 +2,8 @@
 
 Installation:
 
-```
-$ git config core.hooksPath contrib/githooks
+```shell
+git config core.hooksPath contrib/githooks
 ```
 
 ## pre-commit
@@ -13,9 +13,9 @@ to correctly format the `.go` files included in the commit, provided
 that all the aforementioned commands are installed and available
 in the user's search `$PATH` environment variable:
 
-```
-$ go get golang.org/x/tools/cmd/goimports
-$ go get github.com/golangci/misspell/cmd/misspell@master
+```shell
+go get golang.org/x/tools/cmd/goimports
+go get github.com/golangci/misspell/cmd/misspell@master
 ```
 
 It also runs `go mod tidy` and `golangci-lint` if available.

docs/architecture/ADR-001-ABCI++.md

@@ -41,6 +41,7 @@ Proposed and initial implementation is complete.
 ### [#631](https://github.com/celestiaorg/celestia-core/pull/631) Simplified version of ABCI++ (`celestia-core`)
 
 Here we are adding only the two new methods that are necessary for the features that we need.  
+
 ```go
 // Application is an interface that enables any finite, deterministic state machine
 // to be driven by a blockchain-based replication engine via the ABCI.
@@ -53,6 +54,7 @@ type Application interface {
 ```
 
 It's also important to note the changes made to the request types for both methods. In upstream, they are only passing the transactions to the applications. This has been modified to pass the entire block data. This is because Celestia separates some block data that cannot modify state (messages), and the application has to have access to both normal transaction data and messages to perform the necessary processing and checks.
+
 ```protobuf
 message RequestPrepareProposal {
  // block_data is an array of transactions that will be included in a block,
@@ -375,11 +377,13 @@ Proposed and initial implementation is complete.
 ## Consequences
 
 ### Positive
+
 - Don't have to wait for the cosmos-sdk or tendermint teams to finish ABCI++
 - Get to test important features in the upcoming testnet
 - We won't have to implement hacky temporary versions of important features.
 
 ### Negative
+
 - We will still have to slightly refactor the code here after ABCI++ comes out
 
 ## References

x/payment/spec/docs.md

@@ -1,23 +1,29 @@
-## Abstract
+# Abstract
 
-The payment module is responsible for paying for arbitrary data that will be added to the Celestia blockchain. While the data being submitted can be arbitrary, the exact placement of that data is important for the transaction to be valid. This is why the payment module utilizes a malleated transaction scheme. Malleated transactions allow for users to create a single transaction, that can later be malleated by the block producer to create a variety of different valid transactions that are still signed over by the user. To accomplish this, users create a single `MsgWirePayForData` transaction, which is composed of metadata and signatures for multiple variations of the transaction that will be included onchain. After the transaction is submitted to the network, the block producer selects the appropriate signature and creates a valid `MsgPayForData` transaction depending on the square size for that block. This new malleated `MsgPayForData` transaction is what ends up onchain. 
+The payment module is responsible for paying for arbitrary data that will be added to the Celestia blockchain. While the data being submitted can be arbitrary, the exact placement of that data is important for the transaction to be valid. This is why the payment module utilizes a malleated transaction scheme. Malleated transactions allow for users to create a single transaction, that can later be malleated by the block producer to create a variety of different valid transactions that are still signed over by the user. To accomplish this, users create a single `MsgWirePayForData` transaction, which is composed of metadata and signatures for multiple variations of the transaction that will be included onchain. After the transaction is submitted to the network, the block producer selects the appropriate signature and creates a valid `MsgPayForData` transaction depending on the square size for that block. This new malleated `MsgPayForData` transaction is what ends up onchain.
 
 Further reading: [Message Block Layout](https://github.com/celestiaorg/celestia-specs/blob/master/src/rationale/message_block_layout.md)
 
 ## State
+
 - The sender’s account balance, via the bank keeper’s [`Burn`](https://github.com/cosmos/cosmos-sdk/blob/531bf5084516425e8e3d24bae637601b4d36a191/x/bank/spec/01_state.md) method.
 - The standard incrememnt of the sender's account number via the [auth module](https://github.com/cosmos/cosmos-sdk/blob/531bf5084516425e8e3d24bae637601b4d36a191/x/auth/spec/02_state.md).
 
 ## Messages
+
 - [`MsgWirePayForData`](https://github.com/celestiaorg/celestia-app/blob/b4c8ebdf35db200a9b99d295a13de01110802af4/x/payment/types/tx.pb.go#L32-L40)
 
 While this transaction is created and signed by the user, it never actually ends up onchain. Instead, it is used to create a new "malleated" transaction that does get included onchain.
+
 - [`MsgPayForData`](https://github.com/celestiaorg/celestia-app/blob/b4c8ebdf35db200a9b99d295a13de01110802af4/x/payment/types/tx.pb.go#L208-L216)
 
 The malleated transaction that is created from metadata contained in the original `MsgWirePayForData`. It also burns some of the sender’s funds.
 
 ## PrepareProposal
+
 The malleation process occurs during the PrepareProposal step.
+
+<!-- markdownlint-disable MD010 -->
 ```go
 // ProcessWirePayForData will perform the processing required by PrepareProposal.
 // It parses the MsgWirePayForData to produce the components needed to create a
@@ -84,30 +90,38 @@ func (app *App) PrepareProposal(req abci.RequestPrepareProposal) abci.ResponsePr
 	}
 }
 ```
+<!-- markdownlint-enable MD010 -->
 
 ## Events
+
 - [`NewPayForDataEvent`](https://github.com/celestiaorg/celestia-app/pull/213/files#diff-1ce55bda42cf160deca2e5ea1f4382b65f3b689c7e00c88085d7ce219e77303dR17-R21)
 Emit an event that has the signer's address and size of the message that is paid for.
 
 ## Parameters
+
 There are no parameters yet, but we might add
+
 - BaseFee
 - SquareSize
 - ShareSize
 
-### Usage 
+### Usage
+
 `celestia-app tx payment payForData <hex encoded namespace> <hex encoded data> [flags]`
 
 ### Programmatic Usage
+
 There are tools to programmatically create, sign, and broadcast `MsgWirePayForDatas`
+
+<!-- markdownlint-disable MD010 -->
 ```go
 // create the raw WirePayForData transaction
 wpfdMsg, err := apptypes.NewWirePayForData(block.Header.NamespaceId, message, 16, 32, 64, 128)
 if err != nil {
     return err
 }
 
-// we need to create a signature for each `MsgPayForData`s that 
+// we need to create a signature for each `MsgPayForData`s that
 // could be generated by the block producer
 // to do this, we create a custom `KeyringSigner` to sign messages programmatically
 // which uses the standard cosmos-sdk `Keyring` to sign each `MsgPayForData`
@@ -122,8 +136,8 @@ if err != nil {
     return err
 }
 
-// generate the signatures for each `MsgPayForData` using the `KeyringSigner`, 
-// then set the gas limit for the tx 
+// generate the signatures for each `MsgPayForData` using the `KeyringSigner`,
+// then set the gas limit for the tx
 gasLimOption := types.SetGasLimit(200000)
 err = pfdMsg.SignShareCommitments(keyringSigner, gasLimOption)
 if err != nil {
@@ -140,13 +154,17 @@ if err != nil {
     return err
 }
 ```
+<!-- markdownlint-enable MD010 -->
 
 ### How the commitments are generated
-1) create the final version of the message by adding the length delimiter, the namespace, and then the message together into a single string of bytes
-```
-finalMessage = [length delimiter] + [namespace] + [message]
-```
-2) chunk the finalMessage into shares of size `consts.ShareSize`
-3) pad until number of shares is a power of two
-4) create the commitment by aranging the shares into a merkle mountain range
-5) create a merkle root of the subtree roots
+
+1. create the final version of the message by adding the length delimiter, the namespace, and then the message together into a single string of bytes
+
+    ```python
+    finalMessage = [length delimiter] + [namespace] + [message]
+    ```
+
+2. chunk the finalMessage into shares of size `consts.ShareSize`
+3. pad until number of shares is a power of two
+4. create the commitment by aranging the shares into a merkle mountain range
+5. create a merkle root of the subtree roots