docs: Improve markdownlint configuration (#11104)
## Description Closes: #9404 --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting)) - [x] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [x] reviewed "Files changed" and left comments if necessary - [x] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable)
This commit is contained in:
Julien Robert
@@ -8,8 +8,8 @@ There are multiple ways to interact with a node: using the CLI, using gRPC or us
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [gRPC, REST and Tendermint Endpoints](../core/grpc_rest.md) {prereq}
|
||||
- [Running a Node](./run-node.md) {prereq}
|
||||
* [gRPC, REST and Tendermint Endpoints](../core/grpc_rest.md) {prereq}
|
||||
* [Running a Node](./run-node.md) {prereq}
|
||||
|
||||
## Using the CLI
|
||||
|
||||
@@ -54,9 +54,9 @@ The Protobuf ecosystem developed tools for different use cases, including code-g
|
||||
|
||||
Since the code generation library largely depends on your own tech stack, we will only present three alternatives:
|
||||
|
||||
- `grpcurl` for generic debugging and testing,
|
||||
- programmatically via Go,
|
||||
- CosmJS for JavaScript/TypeScript developers.
|
||||
* `grpcurl` for generic debugging and testing,
|
||||
* programmatically via Go,
|
||||
* CosmJS for JavaScript/TypeScript developers.
|
||||
|
||||
### grpcurl
|
||||
|
||||
|
||||
@@ -22,11 +22,11 @@ securely. Typically, an operating system's credential sub-system handles passwor
|
||||
private keys storage, and user sessions according to the user's password policies. Here
|
||||
is a list of the most popular operating systems and their respective passwords manager:
|
||||
|
||||
- macOS (since Mac OS 8.6): [Keychain](https://support.apple.com/en-gb/guide/keychain-access/welcome/mac)
|
||||
- Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management)
|
||||
- GNU/Linux:
|
||||
- [libsecret](https://gitlab.gnome.org/GNOME/libsecret)
|
||||
- [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html)
|
||||
* macOS (since Mac OS 8.6): [Keychain](https://support.apple.com/en-gb/guide/keychain-access/welcome/mac)
|
||||
* Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management)
|
||||
* GNU/Linux:
|
||||
* [libsecret](https://gitlab.gnome.org/GNOME/libsecret)
|
||||
* [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html)
|
||||
|
||||
GNU/Linux distributions that use GNOME as default desktop environment typically come with
|
||||
[Seahorse](https://wiki.gnome.org/Apps/Seahorse). Users of KDE based distributions are
|
||||
|
||||
@@ -42,13 +42,13 @@ An implementation example can be found in `simapp` package.
|
||||
|
||||
To run Rosetta in your application CLI, use the following command:
|
||||
|
||||
```
|
||||
```sh
|
||||
appd rosetta --help
|
||||
```
|
||||
|
||||
To test and run Rosetta API endpoints for applications that are running and exposed, use the following command:
|
||||
|
||||
```
|
||||
```sh
|
||||
appd rosetta
|
||||
--blockchain "your application name (ex: gaia)"
|
||||
--network "your chain identifier (ex: testnet-1)"
|
||||
|
||||
@@ -8,8 +8,8 @@ Now that the application is ready and the keyring populated, it's time to see ho
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Anatomy of a Cosmos SDK Application](../basics/app-anatomy.md) {prereq}
|
||||
- [Setting up the keyring](./keyring.md) {prereq}
|
||||
* [Anatomy of a Cosmos SDK Application](../basics/app-anatomy.md) {prereq}
|
||||
* [Setting up the keyring](./keyring.md) {prereq}
|
||||
|
||||
## Initialize the Chain
|
||||
|
||||
@@ -95,8 +95,8 @@ simd gentx --help
|
||||
|
||||
The Cosmos SDK automatically generates two configuration files inside `~/.simapp/config`:
|
||||
|
||||
- `config.toml`: used to configure the Tendermint, learn more on [Tendermint's documentation](https://docs.tendermint.com/master/nodes/configuration.html),
|
||||
- `app.toml`: generated by the Cosmos SDK, and used to configure your app, such as state pruning strategies, telemetry, gRPC and REST servers configuration, state sync...
|
||||
* `config.toml`: used to configure the Tendermint, learn more on [Tendermint's documentation](https://docs.tendermint.com/master/nodes/configuration.html),
|
||||
* `app.toml`: generated by the Cosmos SDK, and used to configure your app, such as state pruning strategies, telemetry, gRPC and REST servers configuration, state sync...
|
||||
|
||||
Both files are heavily commented, please refer to them directly to tweak your node.
|
||||
|
||||
|
||||
@@ -76,19 +76,19 @@ The first validator node is now running in-process, which means the test network
|
||||
|
||||
Check the status of the first validator node:
|
||||
|
||||
```
|
||||
```sh
|
||||
simd status
|
||||
```
|
||||
|
||||
Import the key from the provided mnemonic:
|
||||
|
||||
```
|
||||
```sh
|
||||
simd keys add test --recover --keyring-backend test
|
||||
```
|
||||
|
||||
Check the balance of the account address:
|
||||
|
||||
```
|
||||
```sh
|
||||
simd q bank balances [address]
|
||||
```
|
||||
|
||||
|
||||
+12
-12
@@ -16,11 +16,11 @@ simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --chain-id my-test-
|
||||
|
||||
will run the following steps:
|
||||
|
||||
- generate a transaction with one `Msg` (`x/bank`'s `MsgSend`), and print the generated transaction to the console.
|
||||
- ask the user for confirmation to send the transaction from the `$MY_VALIDATOR_ADDRESS` account.
|
||||
- fetch `$MY_VALIDATOR_ADDRESS` from the keyring. This is possible because we have [set up the CLI's keyring](./keyring.md) in a previous step.
|
||||
- sign the generated transaction with the keyring's account.
|
||||
- broadcast the signed transaction to the network. This is possible because the CLI connects to the node's Tendermint RPC endpoint.
|
||||
* generate a transaction with one `Msg` (`x/bank`'s `MsgSend`), and print the generated transaction to the console.
|
||||
* ask the user for confirmation to send the transaction from the `$MY_VALIDATOR_ADDRESS` account.
|
||||
* fetch `$MY_VALIDATOR_ADDRESS` from the keyring. This is possible because we have [set up the CLI's keyring](./keyring.md) in a previous step.
|
||||
* sign the generated transaction with the keyring's account.
|
||||
* broadcast the signed transaction to the network. This is possible because the CLI connects to the node's Tendermint RPC endpoint.
|
||||
|
||||
The CLI bundles all the necessary steps into a simple-to-use user experience. However, it's possible to run all the steps individually too.
|
||||
|
||||
@@ -46,8 +46,8 @@ This command will decode the unsigned transaction and sign it with `SIGN_MODE_DI
|
||||
|
||||
Some useful flags to consider in the `tx sign` command:
|
||||
|
||||
- `--sign-mode`: you may use `amino-json` to sign the transaction using `SIGN_MODE_LEGACY_AMINO_JSON`,
|
||||
- `--offline`: sign in offline mode. This means that the `tx sign` command doesn't connect to the node to retrieve the signer's account number and sequence, both needed for signing. In this case, you must manually supply the `--account-number` and `--sequence` flags. This is useful for offline signing, i.e. signing in a secure environment which doesn't have access to the internet.
|
||||
* `--sign-mode`: you may use `amino-json` to sign the transaction using `SIGN_MODE_LEGACY_AMINO_JSON`,
|
||||
* `--offline`: sign in offline mode. This means that the `tx sign` command doesn't connect to the node to retrieve the signer's account number and sequence, both needed for signing. In this case, you must manually supply the `--account-number` and `--sequence` flags. This is useful for offline signing, i.e. signing in a secure environment which doesn't have access to the internet.
|
||||
|
||||
#### Signing with Multiple Signers
|
||||
|
||||
@@ -79,9 +79,9 @@ simd tx broadcast tx_signed.json
|
||||
|
||||
You may optionally pass the `--broadcast-mode` flag to specify which response to receive from the node:
|
||||
|
||||
- `block`: the CLI waits for the tx to be committed in a block.
|
||||
- `sync`: the CLI waits for a CheckTx execution response only.
|
||||
- `async`: the CLI returns immediately (transaction might fail).
|
||||
* `block`: the CLI waits for the tx to be committed in a block.
|
||||
* `sync`: the CLI waits for a CheckTx execution response only.
|
||||
* `async`: the CLI returns immediately (transaction might fail).
|
||||
|
||||
### Encoding a Transaction
|
||||
|
||||
@@ -179,8 +179,8 @@ At this point, `TxBuilder`'s underlying transaction is ready to be signed.
|
||||
|
||||
We set encoding config to use Protobuf, which will use `SIGN_MODE_DIRECT` by default. As per [ADR-020](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/docs/architecture/adr-020-protobuf-transaction-encoding.md), each signer needs to sign the `SignerInfo`s of all other signers. This means that we need to perform two steps sequentially:
|
||||
|
||||
- for each signer, populate the signer's `SignerInfo` inside `TxBuilder`,
|
||||
- once all `SignerInfo`s are populated, for each signer, sign the `SignDoc` (the payload to be signed).
|
||||
* for each signer, populate the signer's `SignerInfo` inside `TxBuilder`,
|
||||
* once all `SignerInfo`s are populated, for each signer, sign the `SignDoc` (the payload to be signed).
|
||||
|
||||
In the current `TxBuilder`'s API, both steps are done using the same method: `SetSignatures()`. The current API requires us to first perform a round of `SetSignatures()` _with empty signatures_, only to populate `SignerInfo`s, and a second round of `SetSignatures()` to actually sign the correct payload.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user