Merge branch 'master' into bez/tx-client-proto-i
This commit is contained in:
Alexander Bezobchuk
@@ -1,11 +1,6 @@
|
||||
module.exports = {
|
||||
theme: "cosmos",
|
||||
title: "Cosmos SDK",
|
||||
markdown: {
|
||||
anchor: {
|
||||
permalinkSymbol: ""
|
||||
}
|
||||
},
|
||||
head: [
|
||||
[
|
||||
"link",
|
||||
@@ -23,9 +18,6 @@ module.exports = {
|
||||
kr: {
|
||||
lang: "kr"
|
||||
},
|
||||
kr: {
|
||||
lang: "kr"
|
||||
},
|
||||
cn: {
|
||||
lang: "cn"
|
||||
},
|
||||
@@ -40,6 +32,11 @@ module.exports = {
|
||||
docsDir: "docs",
|
||||
editLinks: true,
|
||||
label: "sdk",
|
||||
algolia: {
|
||||
id: "BH4D9OD16A",
|
||||
key: "ac317234e6a42074175369b2f42e9754",
|
||||
index: "cosmos-sdk"
|
||||
},
|
||||
sidebar: [
|
||||
{
|
||||
title: "Using the SDK",
|
||||
@@ -91,10 +88,11 @@ module.exports = {
|
||||
}
|
||||
},
|
||||
footer: {
|
||||
questionsText: "Chat with Cosmos developers on [Discord](https://discord.gg/W8trcGV) or reach out on the [SDK Developer Forum](https://forum.cosmos.network/) to learn more.",
|
||||
logo: "/logo-bw.svg",
|
||||
textLink: {
|
||||
text: "cosmos.network",
|
||||
url: "/"
|
||||
url: "https://cosmos.network"
|
||||
},
|
||||
services: [
|
||||
{
|
||||
|
||||
@@ -38,7 +38,7 @@ func (bm BasicManager) RegisterMetrics(appName string, labelsAndValues... string
|
||||
}
|
||||
```
|
||||
|
||||
Each module can define its own `Metrics` type and`CreateMetrics` function in the x/<module>/observability/metrics.go file:
|
||||
Each module can define its own `Metrics` type and`CreateMetrics` function in the x/\<module\>/observability/metrics.go file:
|
||||
|
||||
```go
|
||||
type Metrics struct {
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 3
|
||||
synopsis: This document describes the in-built accounts system of the Cosmos SDK.
|
||||
-->
|
||||
|
||||
# Accounts
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
This document describes the in-built accounts system of the Cosmos SDK. {synopsis}
|
||||
|
||||
### Pre-requisite Readings
|
||||
|
||||
- [Anatomy of an SDK Application](./app-anatomy.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,10 +1,11 @@
|
||||
<!--
|
||||
order: 1
|
||||
synopsis: "This document describes the core parts of a Cosmos SDK application. Throughout the document, a placeholder application named `app` will be used."
|
||||
-->
|
||||
|
||||
# Anatomy of an SDK Application
|
||||
|
||||
This document describes the core parts of a Cosmos SDK application. Throughout the document, a placeholder application named `app` will be used. {synopsis}
|
||||
|
||||
## Node Client
|
||||
|
||||
The Daemon, or [Full-Node Client](../core/node.md), is the core process of an SDK-based blockchain. Participants in the network run this process to initialize their state-machine, connect with other full-nodes and update their state-machine as new blocks come in.
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 4
|
||||
synopsis: This document describes the default strategies to handle gas and fees within a Cosmos SDK application.
|
||||
-->
|
||||
|
||||
# Gas and Fees
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
This document describes the default strategies to handle gas and fees within a Cosmos SDK application. {synopsis}
|
||||
|
||||
### Pre-requisite Readings
|
||||
|
||||
- [Anatomy of an SDK Application](./app-anatomy.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 2
|
||||
synopsis: "This document describes the lifecycle of a transaction from creation to committed state changes. Transaction definition is described in a [different doc](../core/transactions.md). The transaction will be referred to as `Tx`."
|
||||
-->
|
||||
|
||||
# Transaction Lifecycle
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
This document describes the lifecycle of a transaction from creation to committed state changes. Transaction definition is described in a [different doc](../core/transactions.md). The transaction will be referred to as `Tx`. {synopsis}
|
||||
|
||||
### Pre-requisite Readings
|
||||
|
||||
- [Anatomy of an SDK Application](./app-anatomy.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 6
|
||||
synopsis: "`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](../core/baseapp.md#beginblock) and [`EndBlock`](../core/baseapp.md#endblock) ABCI messages are received from the underlying consensus engine."
|
||||
-->
|
||||
|
||||
# BeginBlocker and EndBlocker
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](../core/baseapp.md#beginblock) and [`EndBlock`](../core/baseapp.md#endblock) ABCI messages are received from the underlying consensus engine. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Module Manager](./module-manager.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,10 +1,11 @@
|
||||
<!--
|
||||
order: 13
|
||||
synopsis: This document outlines the recommended usage and APIs for error handling in Cosmos SDK modules.
|
||||
-->
|
||||
|
||||
# Errors
|
||||
|
||||
This document outlines the recommended usage and APIs for error handling in Cosmos SDK modules. {synopsis}
|
||||
|
||||
Modules are encouraged to define and register their own errors to provide better
|
||||
context on failed message or handler execution. Typically, these errors should be
|
||||
common or general errors which can be further wrapped to provide additional specific
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 9
|
||||
synopsis: Modules generally handle a subset of the state and, as such, they need to define the related subset of the genesis file as well as methods to initialize, verify and export it.
|
||||
-->
|
||||
|
||||
# Module Genesis
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
Modules generally handle a subset of the state and, as such, they need to define the related subset of the genesis file as well as methods to initialize, verify and export it. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Module Manager](./module-manager.md) {prereq}
|
||||
- [Keepers](./keeper.md) {prereq}
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 4
|
||||
synopsis: "A `Handler` designates a function that processes [`message`s](./messages-and-queries.md#messages). `Handler`s are specific to the module in which they are defined, and only process `message`s defined within the said module. They are called from `baseapp` during [`DeliverTx`](../core/baseapp.md#delivertx)."
|
||||
-->
|
||||
|
||||
# Handlers
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
A `Handler` designates a function that processes [`message`s](./messages-and-queries.md#messages). `Handler`s are specific to the module in which they are defined, and only process `message`s defined within the said module. They are called from `baseapp` during [`DeliverTx`](../core/baseapp.md#delivertx). {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Module Manager](./module-manager.md) {prereq}
|
||||
- [Messages and Queries](./messages-and-queries.md) {prereq}
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 1
|
||||
synopsis: Modules define most of the logic of SDK applications. Developers compose module together using the Cosmos SDK to build their custom application-specific blockchains. This document outlines the basic concepts behind SDK modules and how to approach module management.
|
||||
order: 1
|
||||
-->
|
||||
|
||||
# Introduction to SDK Modules
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
Modules define most of the logic of SDK applications. Developers compose module together using the Cosmos SDK to build their custom application-specific blockchains. This document outlines the basic concepts behind SDK modules and how to approach module management. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
|
||||
- [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq}
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 8
|
||||
synopsis: "An invariant is a property of the application that should always be true. In the context of the Cosmos SDK, an `Invariant` is a function that checks for a particular invariant. These functions are useful to detect bugs early on and act upon them to limit their potential consequences (e.g. by halting the chain). They are also useful in the development process of the application to detect bugs via simulations."
|
||||
-->
|
||||
|
||||
# Invariants
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
An invariant is a property of the application that should always be true. In the context of the Cosmos SDK, an `Invariant` is a function that checks for a particular invariant. These functions are useful to detect bugs early on and act upon them to limit their potential consequences (e.g. by halting the chain). They are also useful in the development process of the application to detect bugs via simulations. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Keepers](./keeper.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 7
|
||||
synopsis: "`Keeper`s refer to a Cosmos SDK abstraction whose role is to manage access to the subset of the state defined by various modules. `Keeper`s are module-specific, i.e. the subset of state defined by a module can only be accessed by a `keeper` defined in said module. If a module needs to access the subset of state defined by another module, a reference to the second module's internal `keeper` needs to be passed to the first one. This is done in `app.go` during the instantiation of module keepers."
|
||||
-->
|
||||
|
||||
# Keepers
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
`Keeper`s refer to a Cosmos SDK abstraction whose role is to manage access to the subset of the state defined by various modules. `Keeper`s are module-specific, i.e. the subset of state defined by a module can only be accessed by a `keeper` defined in said module. If a module needs to access the subset of state defined by another module, a reference to the second module's internal `keeper` needs to be passed to the first one. This is done in `app.go` during the instantiation of module keepers. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Introduction to SDK Modules](./intro.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 3
|
||||
synopsis: "`Message`s and `Queries` are the two primary objects handled by modules. Most of the core components defined in a module, like `handler`s, `keeper`s and `querier`s, exist to process `message`s and `queries`."
|
||||
-->
|
||||
|
||||
# Messages and Queries
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
`Message`s and `Queries` are the two primary objects handled by modules. Most of the core components defined in a module, like `handler`s, `keeper`s and `querier`s, exist to process `message`s and `queries`. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Introduction to SDK Modules](./intro.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 11
|
||||
synopsis: This document details how to build CLI and REST interfaces for a module. Examples from various SDK modules are included.
|
||||
-->
|
||||
|
||||
# Module Interfaces
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
This document details how to build CLI and REST interfaces for a module. Examples from various SDK modules are included. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
* [Building Modules Intro](./intro.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 2
|
||||
synopsis: "Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../core/baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#begingblocker-and-endblocker)."
|
||||
-->
|
||||
|
||||
# Module Manager
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../core/baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#begingblocker-and-endblocker). {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Introduction to SDK Modules](./intro.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 5
|
||||
synopsis: "A `Querier` designates a function that processes [`queries`](./messages-and-queries.md#queries). `querier`s are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `baseapp`'s [`Query` method](../core/baseapp.md#query)."
|
||||
-->
|
||||
|
||||
# Queriers
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
A `Querier` designates a function that processes [`queries`](./messages-and-queries.md#queries). `querier`s are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `baseapp`'s [`Query` method](../core/baseapp.md#query). {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Module Manager](./module-manager.md) {prereq}
|
||||
- [Messages and Queries](./messages-and-queries.md) {prereq}
|
||||
|
||||
@@ -1,12 +1,11 @@
|
||||
<!--
|
||||
order: 12
|
||||
synopsis: This document outlines the recommended structure of Cosmos SDK modules.These ideas are
|
||||
meant to be applied as suggestions. Application developers are encouraged to improve upon and
|
||||
contribute to module structure and development design.
|
||||
-->
|
||||
|
||||
# Recommended Folder Structure
|
||||
|
||||
This document outlines the recommended structure of Cosmos SDK modules. These ideas are meant to be applied as suggestions. Application developers are encouraged to improve upon and contribute to module structure and development design. {synopsis}
|
||||
|
||||
## Structure
|
||||
|
||||
A typical Cosmos SDK module can be structured as follows:
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 1
|
||||
synopsis: This document describes `BaseApp`, the abstraction that implements the core functionalities of an SDK application.
|
||||
-->
|
||||
|
||||
# Baseapp
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
This document describes `BaseApp`, the abstraction that implements the core functionalities of an SDK application. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
|
||||
- [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq}
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 3
|
||||
synopsis: The `context` is a data structure intended to be passed from function to function that carries information about the current state of the application. It holds a cached copy of the entire state as well as useful objects and information like `gasMeter`, `block height`, `consensus parameters` and more.
|
||||
-->
|
||||
|
||||
# Context
|
||||
|
||||
## Pre-requisites Readings {hide}
|
||||
The `context` is a data structure intended to be passed from function to function that carries information about the current state of the application. It holds a cached copy of the entire state as well as useful objects and information like `gasMeter`, `block height`, `consensus parameters` and more. {synopsis}
|
||||
|
||||
## Pre-requisites Readings
|
||||
|
||||
- [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq}
|
||||
- [Lifecycle of a Transaction](../basics/tx-lifecycle.md) {prereq}
|
||||
|
||||
@@ -1,13 +1,12 @@
|
||||
<!--
|
||||
order: 6
|
||||
synopsis: Amino and Protobuf are the primary binary wire encoding schemes in the Cosmos SDK.
|
||||
-->
|
||||
|
||||
# Encoding
|
||||
|
||||
> NOTE: This document a WIP.
|
||||
The `codec` is used everywhere in the Cosmos SDK to encode and decode structs and interfaces. The specific codec used in the Cosmos SDK is called `go-amino`. {synopsis}
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
|
||||
|
||||
|
||||
+3
-4
@@ -1,13 +1,12 @@
|
||||
<!--
|
||||
order: 7
|
||||
synopsis: "`Event`s are objects that contain information about the execution of the application.
|
||||
They are mainly used by service providers like block explorers and wallet to track the execution of
|
||||
various messages and index transactions."
|
||||
-->
|
||||
|
||||
# Events
|
||||
|
||||
## Pre-Requisite Readings {hide}
|
||||
`Event`s are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
|
||||
|
||||
|
||||
+3
-2
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 4
|
||||
synopsis: The main endpoint of an SDK application is the daemon client, otherwise known as the full-node client. The full-node runs the state-machine, starting from a genesis file. It connects to peers running the same client in order to receive and relay transactions, block proposals and signatures. The full-node is constituted of the application, defined with the Cosmos SDK, and of a consensus engine connected to the application via the ABCI.
|
||||
-->
|
||||
|
||||
# Node Client (Daemon)
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
The main endpoint of an SDK application is the daemon client, otherwise known as the full-node client. The full-node runs the state-machine, starting from a genesis file. It connects to peers running the same client in order to receive and relay transactions, block proposals and signatures. The full-node is constituted of the application, defined with the Cosmos SDK, and of a consensus engine connected to the application via the ABCI. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
|
||||
|
||||
|
||||
+3
-2
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 5
|
||||
synopsis: A store is a data structure that holds the state of the application.
|
||||
-->
|
||||
|
||||
# Store
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
A store is a data structure that holds the state of the application. {synopsis}
|
||||
|
||||
### Pre-requisite Readings
|
||||
|
||||
- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 2
|
||||
synopsis: "`Transactions` are objects created by end-users to trigger state changes in the application."
|
||||
-->
|
||||
|
||||
# Transactions
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
`Transactions` are objects created by end-users to trigger state changes in the application. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
* [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 3
|
||||
synopsis: "This document describes how to create a commmand-line interface (CLI) for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for an SDK [**module**](../building-modules/intro.md) can be found [here](#../building-modules/module-interfaces.md#cli)."
|
||||
-->
|
||||
|
||||
# Command-Line Interface
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
This document describes how to create a commmand-line interface (CLI) for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for an SDK [**module**](../building-modules/intro.md) can be found [here](#../building-modules/module-interfaces.md#cli). {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
* [Lifecycle of a Query](./query-lifecycle.md) {prereq}
|
||||
|
||||
@@ -61,8 +62,7 @@ The root command (called `rootCmd`) is what the user first types into the comman
|
||||
* **Status** command from the SDK rpc client tools, which prints information about the status of the connected [`Node`](../core/node.md). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`.
|
||||
* **Config** [command](https://github.com/cosmos/cosmos-sdk/blob/master/client/config.go) from the SDK client tools, which allows the user to edit a `config.toml` file that sets values for [flags](#flags) such as `--chain-id` and which `--node` they wish to connect to.
|
||||
The `config` command can be invoked by typing `appcli config` with optional arguments `<key> [value]` and a `--get` flag to query configurations or `--home` flag to create a new configuration.
|
||||
* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/master/client/keys) from the SDK client tools, which includes a collection of subcommands for using the key functions in the SDK crypto tools, including adding a new key and saving it to disk, listing all public keys stored in the key manager, and deleting a key.
|
||||
For example, users can type `appcli keys add <name>` to add a new key and save an encrypted copy to disk, using the flag `--recover` to recover a private key from a seed phrase or the flag `--multisig` to group multiple keys together to create a multisig key. For full details on the `add` key command, see the code [here](https://github.com/cosmos/cosmos-sdk/blob/master/client/keys/add.go).
|
||||
* **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/master/client/keys) from the SDK client tools, which includes a collection of subcommands for using the key functions in the SDK crypto tools, including adding a new key and saving it to disk, listing all public keys stored in the key manager, and deleting a key. For example, users can type `appcli keys add <name>` to add a new key and save an encrypted copy to disk, using the flag `--recover` to recover a private key from a seed phrase or the flag `--multisig` to group multiple keys together to create a multisig key. For full details on the `add` key command, see the code [here](https://github.com/cosmos/cosmos-sdk/blob/master/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](/keyring.md).
|
||||
* [**Transaction**](#transaction-commands) commands.
|
||||
* [**Query**](#query-commands) commands.
|
||||
|
||||
@@ -134,4 +134,3 @@ Here is an example of an `initConfig()` function from the [nameservice tutorial
|
||||
And an example of how to add `initConfig` as a `PersistentPreRunE` to the root command:
|
||||
|
||||
+++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/cmd/nscli/main.go#L42-L44
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 1
|
||||
synopsis: Typically, SDK applications include interfaces to let end-users interact with the application. This document introduces the different types of interfaces for SDK applications.
|
||||
-->
|
||||
|
||||
# Interfaces
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
Typically, SDK applications include interfaces to let end-users interact with the application. This document introduces the different types of interfaces for SDK applications. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
* [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq}
|
||||
* [Lifecycle of a Transaction](../basics/tx-lifecycle.md) {prereq}
|
||||
|
||||
@@ -1,16 +1,17 @@
|
||||
<!--
|
||||
order: 3
|
||||
synopsis: "This document describes how to configure and use the keyring and its various backends for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for an SDK [**module**](../building-modules/intro.md) can be found [here](#../building-modules/module-interfaces.md#cli)."
|
||||
-->
|
||||
|
||||
# The keyring
|
||||
|
||||
This document describes how to configure and use the keyring and its various backends for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for an SDK [**module**](../building-modules/intro.md) can be found [here](#../building-modules/module-interfaces.md#cli). {synopsis}
|
||||
|
||||
Starting with the v0.38.0 release, Cosmos SDK comes with a new keyring implementation
|
||||
that provides a set of commands to manage cryptographic keys in a secure fashion. The
|
||||
new keyring supports multiple storage backends, some of which may not be available on
|
||||
all operating systems.
|
||||
|
||||
## The 'os' backend
|
||||
## The `os` backend
|
||||
|
||||
The `os` backend relies on operating system-specific defaults to handle key storage
|
||||
securely. Typically, operating systems credentials sub-systems handle passwords prompt,
|
||||
@@ -33,7 +34,7 @@ client.
|
||||
designed to meet users' most common needs and provide them with a comfortable
|
||||
experience without compromising on security.
|
||||
|
||||
## The 'file' backend
|
||||
## The `file` backend
|
||||
|
||||
The `file` backend more closely resembles the keybase implementation used prior to
|
||||
v0.38.1. It stores the keyring encrypted within the apps configuration directory. This
|
||||
@@ -43,16 +44,17 @@ to execute commands using the `file` option you may want to utilize the followin
|
||||
for multiple prompts:
|
||||
|
||||
```sh
|
||||
$ gaiacli config keyring-backend file # use file backend
|
||||
$ (echo '1234567890'; echo '1234567890') | gaiacli keys add me # add the key 'me'
|
||||
$ (echo '1234567890'; echo '1234567890'; echo '1234567890') | gaiad collect-gentxs # multiple prompts
|
||||
# assuming that KEYPASSWD is set in the environment
|
||||
$ gaiacli config keyring-backend file # use file backend
|
||||
$ (echo $KEYPASSWD; echo $KEYPASSWD) | gaiacli keys add me # multiple prompts
|
||||
$ echo $KEYPASSWD | gaiacli keys show me # single prompt
|
||||
```
|
||||
|
||||
::: tip
|
||||
The first time you add a key to an empty keyring, you will be prompted to type the password twice.
|
||||
:::
|
||||
|
||||
## The 'pass' backend
|
||||
## The `pass` backend
|
||||
|
||||
The `pass` backend uses the [pass](https://www.passwordstore.org/) utility to manage on-disk
|
||||
encryption of keys' sensitive data and metadata. Keys are stored inside `gpg` encrypted files
|
||||
@@ -76,13 +78,13 @@ $ pass init <GPG_KEY_ID>
|
||||
Replace `<GPG_KEY_ID>` with your GPG key ID. You can use your personal GPG key or an alternative
|
||||
one you may want to use specifically to encrypt the password store.
|
||||
|
||||
## The 'test' backend
|
||||
## The `test` backend
|
||||
|
||||
The `test` backend is a password-less variation of the `file` backend. Keys are stored
|
||||
unencrypted on disk. This backend is meant for testing purposes only and **should never be used
|
||||
in production environments**.
|
||||
|
||||
## The 'kwallet' backend
|
||||
## The `kwallet` backend
|
||||
|
||||
The `kwallet` backend uses `KDE Wallet Manager`, which comes installed by default on the
|
||||
GNU/Linux distributions that ships KDE as default desktop environment. Please refer to
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 2
|
||||
synopsis: "This document describes the lifecycle of a query in a SDK application, from the user interface to application stores and back. The query will be referred to as `Query`."
|
||||
-->
|
||||
|
||||
# Query Lifecycle
|
||||
|
||||
## Pre-requisite Readings {hide}
|
||||
This document describes the lifecycle of a query in a SDK application, from the user interface to application stores and back. The query will be referred to as `Query`. {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
* [Introduction to Interfaces](./interfaces-intro.md) {prereq}
|
||||
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<!--
|
||||
order: 4
|
||||
synopsis: "This document describes how to create a REST interface for an SDK **application**. A separate document for creating a [**module**](../building-modules/intro.md) REST interface can be found [here](#../module-interfaces.md#rest)."
|
||||
-->
|
||||
|
||||
# REST Interface
|
||||
|
||||
## Prerequisites {hide}
|
||||
This document describes how to create a REST interface for an SDK **application**. A separate document for creating a [**module**](../building-modules/intro.md) REST interface can be found [here](#../module-interfaces.md#rest). {synopsis}
|
||||
|
||||
## Pre-requisite Readings
|
||||
|
||||
- [Query Lifecycle](./query-lifecycle.md) {prereq}
|
||||
- [Application CLI](./cli.md) {prereq}
|
||||
|
||||
@@ -1,10 +1,11 @@
|
||||
<!--
|
||||
order: 2
|
||||
synopsis: This document explains what application-specific blockchains are, and why developers would want to build one as opposed to writing Smart Contracts.
|
||||
-->
|
||||
|
||||
# Application-Specific Blockchains
|
||||
|
||||
This document explains what application-specific blockchains are, and why developers would want to build one as opposed to writing Smart Contracts. {synopsis}
|
||||
|
||||
## What are application-specific blockchains?
|
||||
|
||||
Application-specific blockchains are blockchains customized to operate a single application. Instead of building a decentralised application on top of an underlying blockchain like Ethereum, developers build their own blockchain from the ground up. This means building a full-node client, a light-client, and all the necessary interfaces (CLI, REST, ...) to interract with the nodes.
|
||||
|
||||
Generated
+1201
-587
File diff suppressed because it is too large
Load Diff
+2
-4
@@ -14,9 +14,7 @@
|
||||
"author": "",
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"@vuepress/plugin-google-analytics": "^1.2.0",
|
||||
"tiny-cookie": "^2.3.1",
|
||||
"vuepress-plugin-smooth-scroll": "0.0.9",
|
||||
"vuepress-theme-cosmos": "^1.0.113"
|
||||
"@vuepress/plugin-google-analytics": "^1.3.1",
|
||||
"vuepress-theme-cosmos": "^1.0.156"
|
||||
}
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user