LaconicNetwork/cosmos-sdk
7
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

chore: rename develop to learn (#17821)

Browse Source
This commit is contained in:
Marko
2023-09-21 09:15:41 +00:00
committed by GitHub
parent 7c0c0f5b8d
commit 2efafee656
61 changed files with 90 additions and 230 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/user/run-node/00-keyring.md
+1 -1
View File
@@ -5,7 +5,7 @@ sidebar_position: 1
# Setting up the keyring
:::note Synopsis
This document describes how to configure and use the keyring and its various backends for an [**application**](../../develop/beginner/00-app-anatomy.md).
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.
docs/user/run-node/01-run-node.md
+2 -2
View File
@@ -10,7 +10,7 @@ Now that the application is ready and the keyring populated, it's time to see ho
:::note Pre-requisite Readings
* [Anatomy of a Cosmos SDK Application](../../develop/beginner/00-app-anatomy.md)
* [Anatomy of a Cosmos SDK Application](../../learn/beginner/00-app-anatomy.md)
* [Setting up the keyring](./00-keyring.md)
:::
@@ -87,7 +87,7 @@ simd genesis add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000stake
Recall that `$MY_VALIDATOR_ADDRESS` is a variable that holds the address of the `my_validator` key in the [keyring](./00-keyring.md#adding-keys-to-the-keyring). Also note that the tokens in the Cosmos SDK have the `{amount}{denom}` format: `amount` is is a 18-digit-precision decimal number, and `denom` is the unique token identifier with its denomination key (e.g. `atom` or `uatom`). Here, we are granting `stake` tokens, as `stake` is the token identifier used for staking in [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/main/simapp). For your own chain with its own staking denom, that token identifier should be used instead.
Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](../../develop/intro/02-sdk-app-architecture.md#cometbft)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`:
Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](../../learn/intro/02-sdk-app-architecture.md#cometbft)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`:
```bash
# Create a gentx.
docs/user/run-node/02-interact-node.md
+3 -3
View File
@@ -10,7 +10,7 @@ There are multiple ways to interact with a node: using the CLI, using gRPC or us
:::note Pre-requisite Readings
* [gRPC, REST and CometBFT Endpoints](../../develop/advanced/06-grpc_rest.md)
* [gRPC, REST and CometBFT Endpoints](../../learn/advanced/06-grpc_rest.md)
* [Running a Node](./01-run-node.md)
:::
@@ -54,7 +54,7 @@ You should see two delegations, the first one made from the `gentx`, and the sec
## Using gRPC
The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow the building of clients easily. Often, the client connection (i.e. the transport) can be plugged and replaced very easily. Let's explore one of the most popular transport: [gRPC](../../develop/advanced/06-grpc_rest.md).
The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow the building of clients easily. Often, the client connection (i.e. the transport) can be plugged and replaced very easily. Let's explore one of the most popular transport: [gRPC](../../learn/advanced/06-grpc_rest.md).
Since the code generation library largely depends on your own tech stack, we will only present three alternatives:
@@ -248,7 +248,7 @@ CosmJS documentation can be found at [https://cosmos.github.io/cosmjs](https://c
## Using the REST Endpoints
As described in the [gRPC guide](../../develop/advanced/06-grpc_rest.md), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters.
As described in the [gRPC guide](../../learn/advanced/06-grpc_rest.md), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters.
Note that the REST endpoints are not enabled by default. To enable them, edit the `api` section of your `~/.simapp/config/app.toml` file:
docs/user/run-node/03-txs.md
+1 -1
View File
@@ -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](../../develop/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 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.
```go
import (
docs/user/run-node/04-rosetta.md
-144
View File
@@ -1,144 +0,0 @@
# Rosetta
The `rosetta` project implements Coinbase's [Rosetta API](https://www.rosetta-api.org). This document provides instructions on how to use the Rosetta API integration. For information about the motivation and design choices, refer to [ADR 035](https://docs.cosmos.network/main/architecture/adr-035-rosetta-api-support).
## Installing Rosetta
The Rosetta API server is a stand-alone server that connects to a node of a chain developed with Cosmos SDK.
Rosetta can be added to any cosmos chain node. standalone or natively.
### Standalone
Rosetta can be executed as a standalone service, it connects to the node endpoints and expose the required endpoints.
Install Rosetta standalone server with the following command:
```bash
go install github.com/cosmos/rosetta
```
Alternatively, for building from source, simply run `make rosetta`. The binary will be located in the root folder.
### Native - As a node command
To enable Native Rosetta API support, it's required to add the `RosettaCommand` to your application's root command file (e.g. `simd/cmd/root.go`).
Import the `rosettaCmd` package:
```go
import "github.com/cosmos/rosetta/cmd"
```
Find the following line:
```go
initRootCmd(rootCmd, encodingConfig)
```
After that line, add the following:
```go
rootCmd.AddCommand(
rosettaCmd.RosettaCommand(encodingConfig.InterfaceRegistry, encodingConfig.Codec)
)
```
The `RosettaCommand` function builds the `rosetta` root command and is defined in the `rosettaCmd` package (`github.com/cosmos/rosetta/cmd`).
Since we’ve updated the Cosmos SDK to work with the Rosetta API, updating the application's root command file is all you need to do.
An implementation example can be found in `simapp` package.
## Use Rosetta Command
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.
```shell
rosetta --help
```
To test and run Rosetta API endpoints for applications that are running and exposed, use the following command:
```shell
rosetta
--blockchain "your application name (ex: gaia)"
--network "your chain identifier (ex: testnet-1)"
--tendermint "tendermint endpoint (ex: localhost:26657)"
--grpc "gRPC endpoint (ex: localhost:9090)"
--addr "rosetta binding address (ex: :8080)"
--grpc-types-server (optional) "gRPC endpoint for message descriptor types"
```
## 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.
To use Rosetta over any chain, it is required to set up prefixes and registering zone specific interfaces through plugins.
Each plugin is a minimalist implementation of `InitZone` and `RegisterInterfaces` which allow Rosetta to parse chain specific data. There is an example for cosmos-hub chain under `plugins/cosmos-hun/` folder
- **InitZone**: An empty method that is executed first and defines prefixes, parameters and other settings.
- **RegisterInterfaces**: This method receives an interface registry which is were the zone specific types and interfaces will be loaded
In order to add a new plugin:
1. Create a folder over `plugins` folder with the name of the desired zone
2. Add a `main.go` file with the mentioned methods above.
3. Build the code binary through `go build -buildmode=plugin -o main.so main.go`
The plugin folder is selected through the cli `--plugin` flag and loaded into the Rosetta server.
## Extensions
There are two ways in which you can customize and extend the implementation with your custom settings.
### Message extension
In order to make an `sdk.Msg` understandable by rosetta the only thing which is required is adding the methods to your messages that satisfy the `rosetta.Msg` interface. Examples on how to do so can be found in the staking types such as `MsgDelegate`, or in bank types such as `MsgSend`.
### Client interface override
In case more customization is required, it's possible to embed the Client type and override the methods which require customizations.
Example:
```go
package custom_client
import (
"context"
"github.com/coinbase/rosetta-sdk-go/types"
"github.com/cosmos/rosetta/lib"
)
// CustomClient embeds the standard cosmos client
// which means that it implements the cosmos-rosetta-gateway Client
// interface while at the same time allowing to customize certain methods
type CustomClient struct {
*rosetta.Client
}
func (c *CustomClient) ConstructionPayload(_ context.Context, request *types.ConstructionPayloadsRequest) (resp *types.ConstructionPayloadsResponse, err error) {
// provide custom signature bytes
panic("implement me")
}
```
NOTE: when using a customized client, the command cannot be used as the constructors required **may** differ, so it's required to create a new one. We intend to provide a way to init a customized client without writing extra code in the future.
### Error extension
Since rosetta requires to provide 'returned' errors to network options. In order to declare a new rosetta error, we use the `errors` package in cosmos-rosetta-gateway.
Example:
```go
package custom_errors
import crgerrs "github.com/cosmos/rosetta/lib/errors"
var customErrRetriable = true
var CustomError = crgerrs.RegisterError(100, "custom message", customErrRetriable, "description")
```
Note: errors must be registered before cosmos-rosetta-gateway's `Server`.`Start` method is called. Otherwise the registration will be ignored. Errors with same code will be ignored too.