lint: add markdown linter (#5254)

2026-08-01 21:06:11 +00:00 · 2020-08-17 16:40:50 +02:00
parent 022b255ed6
commit 42e4e8b58e
52 changed files with 515 additions and 415 deletions
@@ -16,7 +16,7 @@ the parameters set with their default values. It will look something
 like the file below, however, double check by inspecting the
 `config.toml` created with your version of `tendermint` installed:

-```
+```toml
 # This is a TOML config file.
 # For more information, see https://github.com/toml-lang/toml

@@ -351,13 +351,13 @@ namespace = "tendermint"

 ## Empty blocks VS no empty blocks

-**create_empty_blocks = true**
+### create_empty_blocks = true

 If `create_empty_blocks` is set to `true` in your config, blocks will be
 created ~ every second (with default consensus parameters). You can regulate
 the delay between blocks by changing the `timeout_commit`. E.g. `timeout_commit = "10s"` should result in ~ 10 second blocks.

-**create_empty_blocks = false**
+### create_empty_blocks = false

 In this setting, blocks are created when transactions received.

@@ -386,7 +386,7 @@ production](./running-in-production.md)
 You can also find more detailed technical explanation in the spec: [The latest
 gossip on BFT consensus](https://arxiv.org/abs/1807.04938).

-```
+```toml
 [consensus]
 ...

@@ -9,7 +9,7 @@ order: 7
 We first create three connections (mempool, consensus and query) to the
 application (running `kvstore` locally in this case).

-```
+```sh
 I[10-04|13:54:27.364] Starting multiAppConn                        module=proxy impl=multiAppConn
 I[10-04|13:54:27.366] Starting localClient                         module=abci-client connection=query impl=localClient
 I[10-04|13:54:27.366] Starting localClient                         module=abci-client connection=mempool impl=localClient
@@ -18,7 +18,7 @@ I[10-04|13:54:27.367] Starting localClient                         module=abci-c

 Then Tendermint Core and the application perform a handshake.

-```
+```sh
 I[10-04|13:54:27.367] ABCI Handshake                               module=consensus appHeight=90 appHash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
 I[10-04|13:54:27.368] ABCI Replay Blocks                           module=consensus appHeight=90 storeHeight=90 stateHeight=90
 I[10-04|13:54:27.368] Completed ABCI Handshake - Tendermint and App are synced module=consensus appHeight=90 appHash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
@@ -27,7 +27,7 @@ I[10-04|13:54:27.368] Completed ABCI Handshake - Tendermint and App are synced m
 After that, we start a few more things like the event switch, reactors,
 and perform UPNP discover in order to detect the IP address.

-```
+```sh
 I[10-04|13:54:27.374] Starting EventSwitch                         module=types impl=EventSwitch
 I[10-04|13:54:27.375] This node is a validator                     module=consensus
 I[10-04|13:54:27.379] Starting Node                                module=main impl=Node
@@ -50,7 +50,7 @@ validator". It also could be just an observer (regular node).

 Next we replay all the messages from the WAL.

-```
+```sh
 I[10-04|13:54:30.390] Catchup by replaying consensus messages      module=consensus height=91
 I[10-04|13:54:30.390] Replay: New Step                             module=consensus height=91 round=0 step=RoundStepNewHeight
 I[10-04|13:54:30.390] Replay: Done                                 module=consensus
@@ -58,7 +58,7 @@ I[10-04|13:54:30.390] Replay: Done                                 module=consen

 "Started node" message signals that everything is ready for work.

-```
+```sh
 I[10-04|13:54:30.391] Starting RPC HTTP server on tcp socket 0.0.0.0:26657 module=rpc-server
 I[10-04|13:54:30.392] Started node                                 module=main nodeInfo="NodeInfo{id: DF22D7C92C91082324A1312F092AA1DA197FA598DBBFB6526E, moniker: anonymous, network: test-chain-3MNw2N [remote , listen 10.0.2.15:26656], version: 0.11.0-10f361fc ([wire_version=0.6.2 p2p_version=0.5.0 consensus_version=v1/0.2.2 rpc_version=0.7.0/3 tx_index=on rpc_addr=tcp://0.0.0.0:26657])}"
 ```
@@ -69,7 +69,7 @@ precommits and finally have a chance to commit a block. For details,
 please refer to [Byzantine Consensus
 Algorithm](https://github.com/tendermint/spec/blob/master/spec/consensus/consensus.md).

-```
+```sh
 I[10-04|13:54:30.393] enterNewRound(91/0). Current: 91/0/RoundStepNewHeight module=consensus
 I[10-04|13:54:30.393] enterPropose(91/0). Current: 91/0/RoundStepNewRound module=consensus
 I[10-04|13:54:30.393] enterPropose: Our turn to propose            module=consensus proposer=125B0E3C5512F5C2B0E1109E31885C4511570C42 privValidator="PrivValidator{125B0E3C5512F5C2B0E1109E31885C4511570C42 LH:90, LR:0, LS:3}"
@@ -31,9 +31,9 @@ proofs](https://github.com/tendermint/spec/blob/953523c3cb99fdb8c8f7a2d21e3a9909
  name-registry without worrying about fork censorship attacks, without posting
  a commit and waiting for confirmations. It's fast, secure, and free!

-## Where to obtain trusted height & hash?
+## Where to obtain trusted height & hash

-https://pkg.go.dev/github.com/tendermint/tendermint/light?tab=doc#TrustOptions
+<https://pkg.go.dev/github.com/tendermint/tendermint/light?tab=doc#TrustOptions>

 One way to obtain semi-trusted hash & height is to query multiple full nodes
 and compare their hashes:
@@ -12,31 +12,34 @@ arrived (via RPC or from other nodes).
 So the only way to specify the order is to send them to a single node.

 valA:
-  - tx1
-  - tx2
-  - tx3
+
+- tx1
+- tx2
+- tx3

 If the transactions are split up across different nodes, there's no way to
 ensure they are processed in the expected order.

 valA:
-  - tx1
-  - tx2
+
+- tx1
+- tx2

 valB:
-  - tx3
+
+- tx3

 If valB is the proposer, the order might be:

-  - tx3
-  - tx1
-  - tx2
+- tx3
+- tx1
+- tx2

 If valA is the proposer, the order might be:

-  - tx1
-  - tx2
-  - tx3
+- tx1
+- tx2
+- tx3

 That said, if the transactions contain some internal value, like an
 order/nonce/sequence number, the application can reject transactions that are
@@ -54,6 +54,6 @@ The following metrics are available:

 Percentage of missing + byzantine validators:

-```
+```md
 ((consensus\_byzantine\_validators\_power + consensus\_missing\_validators\_power) / consensus\_validators\_power) * 100
 ```
@@ -165,7 +165,7 @@ Tendermint also can report and serve Prometheus metrics. See
 information into an archive. See [Debugging](../tools/debugging.md) for more
 information.

-## What happens when my app dies?
+## What happens when my app dies

 You are supposed to run Tendermint under a [process
 supervisor](https://en.wikipedia.org/wiki/Process_supervision) (like
@@ -180,7 +180,7 @@ order of restart does not matter for it.
 ## Signal handling

 We catch SIGINT and SIGTERM and try to clean up nicely. For other
-signals we use the default behaviour in Go: [Default behavior of signals
+signals we use the default behavior in Go: [Default behavior of signals
 in Go
 programs](https://golang.org/pkg/os/signal/#hdr-Default_behavior_of_signals_in_Go_programs).

@@ -206,11 +206,11 @@ Other causes can be:
 - Operating system bugs
 - Admin error (e.g., directly modifying Tendermint data-directory contents)

-(Source: https://wiki.postgresql.org/wiki/Corruption)
+(Source: <https://wiki.postgresql.org/wiki/Corruption>)

 ### WAL Corruption

-If consensus WAL is corrupted at the lastest height and you are trying to start
+If consensus WAL is corrupted at the latest height and you are trying to start
 Tendermint, replay will fail with panic.

 Recovering from data corruption can be hard and time-consuming. Here are two approaches you can take:
@@ -220,33 +220,33 @@ Recovering from data corruption can be hard and time-consuming. Here are two app

 1) Create a backup of the corrupted WAL file:

-```
-cp "$TMHOME/data/cs.wal/wal" > /tmp/corrupted_wal_backup
-```
+    ```sh
+    cp "$TMHOME/data/cs.wal/wal" > /tmp/corrupted_wal_backup
+    ```

-2. Use `./scripts/wal2json` to create a human-readable version
+2) Use `./scripts/wal2json` to create a human-readable version:

-```
-./scripts/wal2json/wal2json "$TMHOME/data/cs.wal/wal" > /tmp/corrupted_wal
-```
+    ```sh
+    ./scripts/wal2json/wal2json "$TMHOME/data/cs.wal/wal" > /tmp/corrupted_wal
+    ```

-3. Search for a "CORRUPTED MESSAGE" line.
-4. By looking at the previous message and the message after the corrupted one
+3)  Search for a "CORRUPTED MESSAGE" line.
+4)  By looking at the previous message and the message after the corrupted one
   and looking at the logs, try to rebuild the message. If the consequent
   messages are marked as corrupted too (this may happen if length header
   got corrupted or some writes did not make it to the WAL ~ truncation),
   then remove all the lines starting from the corrupted one and restart
   Tendermint.

-```
-$EDITOR /tmp/corrupted_wal
-```
+    ```sh
+    $EDITOR /tmp/corrupted_wal
+    ```

-5. After editing, convert this file back into binary form by running:
+5)  After editing, convert this file back into binary form by running:

-```
-./scripts/json2wal/json2wal /tmp/corrupted_wal  $TMHOME/data/cs.wal/wal
-```
+    ```sh
+    ./scripts/json2wal/json2wal /tmp/corrupted_wal  $TMHOME/data/cs.wal/wal
+    ```

 ## Hardware

@@ -313,7 +313,7 @@ If you are going to use Tendermint in a private domain and you have a
 private high-speed network among your peers, it makes sense to lower
 flush throttle timeout and increase other params.

-```
+```toml
 [p2p]

 send_rate=20000000 # 2MB/s
@@ -380,7 +380,7 @@ The process file limits must also be increased, e.g. via `ulimit -n 8192`.

 ...for N connections, such as 50k:

-```
+```md
 kern.maxfiles=10000+2*N         # BSD
 kern.maxfilesperproc=100+2*N    # BSD
 kern.ipc.maxsockets=10000+2*N   # BSD
@@ -48,43 +48,43 @@ definition](https://github.com/tendermint/tendermint/blob/master/types/genesis.g
  every blockchain.** If your testnet blockchains do not have unique
  chain IDs, you will have a bad time. The ChainID must be less than 50 symbols.
 - `consensus_params` [spec](https://github.com/tendermint/spec/blob/master/spec/core/state.md#consensusparams)
-  - `block`
-    - `max_bytes`: Max block size, in bytes.
-    - `max_gas`: Max gas per block.
-    - `time_iota_ms`: Minimum time increment between consecutive blocks (in
+    - `block`
+        - `max_bytes`: Max block size, in bytes.
+        - `max_gas`: Max gas per block.
+        - `time_iota_ms`: Minimum time increment between consecutive blocks (in
      milliseconds). If the block header timestamp is ahead of the system clock,
      decrease this value.
-  - `evidence`
-    - `max_age_num_blocks`: Max age of evidence, in blocks. The basic formula
+    - `evidence`
+        - `max_age_num_blocks`: Max age of evidence, in blocks. The basic formula
      for calculating this is: MaxAgeDuration / {average block time}.
-    - `max_age_duration`: Max age of evidence, in time. It should correspond
+        - `max_age_duration`: Max age of evidence, in time. It should correspond
      with an app's "unbonding period" or other similar mechanism for handling
      [Nothing-At-Stake
      attacks](https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed).
-    - `max_num`: This sets the maximum number of evidence that can be committed
+        - `max_num`: This sets the maximum number of evidence that can be committed
      in a single block. and should fall comfortably under the max block
      bytes when we consider the size of each evidence.
-    - `proof_trial_period`: Proof trial period dictates the time given for
+        - `proof_trial_period`: Proof trial period dictates the time given for
      nodes accused of amnesia evidence, incorrectly voting twice in two
      different rounds to respond with their respective proofs.
-  - `validator`
-    - `pub_key_types`: Public key types validators can use.
-  - `version`
-    - `app_version`: ABCI application version.
+    - `validator`
+        - `pub_key_types`: Public key types validators can use.
+    - `version`
+        - `app_version`: ABCI application version.
 - `validators`: List of initial validators. Note this may be overridden entirely by the
  application, and may be left empty to make explicit that the
  application will initialize the validator set with ResponseInitChain.
-  - `pub_key`: The first element specifies the `pub_key` type. 1
+    - `pub_key`: The first element specifies the `pub_key` type. 1
    == Ed25519. The second element are the pubkey bytes.
-  - `power`: The validator's voting power.
-  - `name`: Name of the validator (optional).
+    - `power`: The validator's voting power.
+    - `name`: Name of the validator (optional).
 - `app_hash`: The expected application hash (as returned by the
  `ResponseInfo` ABCI message) upon genesis. If the app's hash does
  not match, Tendermint will panic.
 - `app_state`: The application state (e.g. initial distribution
  of tokens).

-**WARNING: ChainID must be unique to every blockchain. Reusing old chainID can cause issues**
+> :warning: **ChainID must be unique to every blockchain. Reusing old chainID can cause issues**

 #### Sample genesis.json

@@ -179,7 +179,7 @@ curl http://localhost:26657/status | json_pp | grep latest_app_hash

 <!-- markdown-link-check-disable -->

-Visit http://localhost:26657 in your browser to see the list of other
+Visit <http://localhost:26657> in your browser to see the list of other
 endpoints. Some take no arguments (like `/status`), while others specify
 the argument name and use `_` as a placeholder.

@@ -86,8 +86,8 @@ The sentry nodes should be able to talk to the entire network hence why `pex=tru

 More Information can be found at these links:

- https://kb.certus.one/
- https://forum.cosmos.network/t/sentry-node-architecture-overview/454
+- <https://kb.certus.one/>
+- <https://forum.cosmos.network/t/sentry-node-architecture-overview/454>

 ### Validator keys

@@ -97,7 +97,7 @@ Currently Tendermint uses [Ed25519](https://ed25519.cr.yp.to/) keys which are wi

 ## Committing a Block

-_+2/3 is short for "more than 2/3"_
+> **+2/3 is short for "more than 2/3"**

 A block is committed when +2/3 of the validator set sign [precommit
 votes](https://github.com/tendermint/spec/blob/953523c3cb99fdb8c8f7a2d21e3a99094279e9de/spec/blockchain/blockchain.md#vote) for that block at the same `round`.