chore: fix spelling errors (#22802)
Co-authored-by: github-merge-queue <118344674+github-merge-queue@users.noreply.github.com> Co-authored-by: Julien Robert <julien@rbrt.fr>
This commit is contained in:
co-authored by
github-merge-queue
Julien Robert
parent
f995d0a219
commit
13e3e211a6
@@ -8,7 +8,7 @@ sidebar_position: 1
|
||||
This document describes how to configure and use the keyring and its various backends for an [**application**](../../learn/beginner/00-app-anatomy.md).
|
||||
:::
|
||||
|
||||
The keyring holds the private/public keypairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage.
|
||||
The keyring holds the private/public key pairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage.
|
||||
|
||||
## Available backends for the keyring
|
||||
|
||||
|
||||
@@ -269,7 +269,7 @@ func sendTx() error {
|
||||
|
||||
### Broadcasting a Transaction
|
||||
|
||||
The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also posible. An overview of the differences between these methods is exposed [here](../../learn/advanced/06-grpc_rest.md). For this tutorial, we will only describe the gRPC method.
|
||||
The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the CometBFT RPC is also possible. An overview of the differences between these methods is exposed [here](../../learn/advanced/06-grpc_rest.md). For this tutorial, we will only describe the gRPC method.
|
||||
|
||||
```go
|
||||
import (
|
||||
|
||||
@@ -54,7 +54,7 @@ An implementation example can be found in `simapp` package.
|
||||
|
||||
To run Rosetta in your application CLI, use the following command:
|
||||
|
||||
> **Note:** if using the native approach, add your node name before any rosetta comand.
|
||||
> **Note:** if using the native approach, add your node name before any rosetta command.
|
||||
|
||||
```shell
|
||||
rosetta --help
|
||||
@@ -74,7 +74,7 @@ rosetta
|
||||
|
||||
## Plugins - Multi chain connections
|
||||
|
||||
Rosetta will try to reflect the node types trough reflection over the node gRPC endpoints, there may be cases were this approach is not enough. It is possible to extend or implement the required types easily trough plugins.
|
||||
Rosetta will try to reflect the node types through reflection over the node gRPC endpoints, there may be cases were this approach is not enough. It is possible to extend or implement the required types easily through plugins.
|
||||
|
||||
To use Rosetta over any chain, it is required to set up prefixes and registering zone specific interfaces through plugins.
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ The default output directory is a relative `.testnets` directory. Let's take a l
|
||||
|
||||
### gentxs
|
||||
|
||||
The `gentxs` directory includes a genesis transaction for each validator node. Each file includes a JSON encoded genesis transaction used to register a validator node at the time of genesis. The genesis transactions are added to the `genesis.json` file within each node directory during the initilization process.
|
||||
The `gentxs` directory includes a genesis transaction for each validator node. Each file includes a JSON encoded genesis transaction used to register a validator node at the time of genesis. The genesis transactions are added to the `genesis.json` file within each node directory during the initialization process.
|
||||
|
||||
### nodes
|
||||
|
||||
|
||||
@@ -196,7 +196,7 @@ tmkms softsign import $HOME/tmkms/config/secrets/priv_validator_key.json $HOME/t
|
||||
|
||||
At this point, it is necessary to delete the `priv_validator_key.json` from the validator node and the tmkms node. Since the key has been imported into tmkms (above) it is no longer necessary on the nodes. The key can be safely stored offline.
|
||||
|
||||
4. Modifiy the `tmkms.toml`.
|
||||
4. Modify the `tmkms.toml`.
|
||||
|
||||
```bash
|
||||
vim $HOME/tmkms/config/tmkms.toml
|
||||
|
||||
Reference in New Issue
Block a user