Merge PR #4787: Updated docs build process
This commit is contained in:
mircea-c
Alexander Bezobchuk
parent
d3aa9feaca
commit
450c8ced2c
|
|
@ -35,6 +35,17 @@ commands:
|
|||
make << parameters.target >>
|
||||
|
||||
jobs:
|
||||
build_docs:
|
||||
executor: docs
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
Name : "Build docs"
|
||||
command: make build-docs
|
||||
- run:
|
||||
name: "Upload docs to S3"
|
||||
command: make sync-docs
|
||||
|
||||
setup_dependencies:
|
||||
executor: golang
|
||||
steps:
|
||||
|
|
@ -199,3 +210,21 @@ workflows:
|
|||
- upload_coverage:
|
||||
requires:
|
||||
- test_cover
|
||||
- build_docs:
|
||||
context: docs-deployment-master
|
||||
filters:
|
||||
branches:
|
||||
only:
|
||||
- /.*/
|
||||
tags:
|
||||
ignore:
|
||||
- /^v.*/
|
||||
- build_docs:
|
||||
context: docs-deployment-release
|
||||
filters:
|
||||
branches:
|
||||
ignore:
|
||||
- /.*/
|
||||
tags:
|
||||
only:
|
||||
- /v.*/
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@ tools/bin/*
|
|||
examples/build/*
|
||||
docs/_build
|
||||
docs/tutorial
|
||||
docs/node_modules
|
||||
dist
|
||||
tools-stamp
|
||||
|
||||
|
|
|
|||
17
Makefile
17
Makefile
|
|
@ -68,6 +68,23 @@ godocs:
|
|||
@echo "--> Wait a few seconds and visit http://localhost:6060/pkg/github.com/cosmos/cosmos-sdk/types"
|
||||
godoc -http=:6060
|
||||
|
||||
build-docs:
|
||||
@cd docs && \
|
||||
while read p; do \
|
||||
(git checkout $${p} && npm install && VUEPRESS_BASE="/$${p}/" npm run build) ; \
|
||||
mkdir -p ~/output/$${p} ; \
|
||||
cp -r .vuepress/dist/* ~/output/$${p}/ ; \
|
||||
echo "<a href='$${p}'>$${p}</a>" >> ~/output/index.html ; \
|
||||
done < versions ;
|
||||
|
||||
sync-docs:
|
||||
cd ~/output && \
|
||||
echo "role_arn = ${DEPLOYMENT_ROLE_ARN}" >> /root/.aws/config ; \
|
||||
echo "CI job = ${CIRCLE_BUILD_URL}" >> version.html ; \
|
||||
aws s3 sync . s3://${WEBSITE_BUCKET} --profile terraform --delete ; \
|
||||
aws cloudfront create-invalidation --distribution-id ${CF_DISTRIBUTION_ID} --profile terraform --path "/*" ;
|
||||
.PHONY: sync_docs
|
||||
|
||||
########################################
|
||||
### Testing
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
<template>
|
||||
<div>
|
||||
{{url}}
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script>
|
||||
export default {
|
||||
computed: {
|
||||
url() {
|
||||
const c = this.$themeConfig
|
||||
if (c && c.repo && c.docsDir && c.docsBranch) {
|
||||
return `https://github.com/${c.repo}/tree/${c.docsBranch}/${c.docsDir}/${this.$page.relativePath}`
|
||||
}
|
||||
},
|
||||
},
|
||||
}
|
||||
</script>
|
||||
|
|
@ -1,78 +1,95 @@
|
|||
const glob = require("glob");
|
||||
const markdownIt = require("markdown-it");
|
||||
const meta = require("markdown-it-meta");
|
||||
const fs = require("fs");
|
||||
const _ = require("lodash");
|
||||
|
||||
const sidebar = (directory, array) => {
|
||||
return array.map(i => {
|
||||
const children = _.sortBy(
|
||||
glob
|
||||
.sync(`./${directory}/${i[1]}/*.md`)
|
||||
.map(path => {
|
||||
const md = new markdownIt();
|
||||
const file = fs.readFileSync(path, "utf8");
|
||||
md.use(meta);
|
||||
md.render(file);
|
||||
const order = md.meta.order;
|
||||
return { path, order };
|
||||
})
|
||||
.filter(f => f.order !== false),
|
||||
["order", "path"]
|
||||
)
|
||||
.map(f => f.path)
|
||||
.filter(f => !f.match("readme"));
|
||||
return {
|
||||
title: i[0],
|
||||
children
|
||||
};
|
||||
});
|
||||
};
|
||||
|
||||
module.exports = {
|
||||
title: "Cosmos SDK Documentation",
|
||||
description: "Documentation for the Cosmos SDK and Gaia.",
|
||||
ga: "UA-51029217-2",
|
||||
dest: "./dist/docs",
|
||||
base: "/docs/",
|
||||
markdown: {
|
||||
lineNumbers: true
|
||||
title: "Cosmos SDK",
|
||||
base: process.env.VUEPRESS_BASE || "/",
|
||||
locales: {
|
||||
"/": {
|
||||
lang: "en-US"
|
||||
},
|
||||
"/ru/": {
|
||||
lang: "ru"
|
||||
},
|
||||
},
|
||||
themeConfig: {
|
||||
repo: "cosmos/cosmos-sdk",
|
||||
editLinks: true,
|
||||
docsDir: "docs",
|
||||
editLinks: true,
|
||||
docsBranch: "master",
|
||||
editLinkText: "Edit this page on Github",
|
||||
lastUpdated: true,
|
||||
algolia: {
|
||||
apiKey: "a6e2f64347bb826b732e118c1366819a",
|
||||
indexName: "cosmos_network",
|
||||
debug: false
|
||||
},
|
||||
nav: [
|
||||
{ text: "Back to Cosmos", link: "https://cosmos.network" },
|
||||
{ text: "RPC", link: "https://cosmos.network/rpc/" }
|
||||
],
|
||||
sidebar: [
|
||||
{
|
||||
title: "Overview",
|
||||
collapsable: true,
|
||||
children: [
|
||||
"/intro/",
|
||||
"/intro/why-app-specific",
|
||||
"/intro/sdk-app-architecture",
|
||||
"/intro/sdk-design"
|
||||
]
|
||||
locales: {
|
||||
"/": {
|
||||
label: "English",
|
||||
sidebar: sidebar("", [
|
||||
["Intro", "intro"],
|
||||
["Basics", "basics"],
|
||||
["SDK Core", "core"],
|
||||
["About Modules", "modules"],
|
||||
["Using the SDK", "sdk"],
|
||||
["Interfaces", "interfaces"]
|
||||
])
|
||||
},
|
||||
{
|
||||
title: "Tutorial",
|
||||
collapsable: true,
|
||||
children: [
|
||||
"/tutorial/",
|
||||
"/tutorial/app-design",
|
||||
"/tutorial/app-init",
|
||||
"/tutorial/types",
|
||||
"/tutorial/key",
|
||||
"/tutorial/keeper",
|
||||
"/tutorial/msgs-handlers",
|
||||
"/tutorial/set-name",
|
||||
"/tutorial/buy-name",
|
||||
"/tutorial/queriers",
|
||||
"/tutorial/alias",
|
||||
"/tutorial/codec",
|
||||
"/tutorial/cli",
|
||||
"/tutorial/rest",
|
||||
"/tutorial/module",
|
||||
"/tutorial/genesis",
|
||||
"/tutorial/app-complete",
|
||||
"/tutorial/entrypoint",
|
||||
"/tutorial/gomod",
|
||||
"/tutorial/build-run",
|
||||
"/tutorial/run-rest"
|
||||
]
|
||||
"/ru/": {
|
||||
label: "Русский",
|
||||
sidebar: sidebar("ru", [
|
||||
["Введение", "intro"],
|
||||
["Основы", "basics"],
|
||||
["SDK Core", "core"],
|
||||
["Модули", "modules"],
|
||||
["Используем SDK", "sdk"],
|
||||
["Интерфейсы", "interfaces"]
|
||||
])
|
||||
},
|
||||
{
|
||||
title: "Interfaces",
|
||||
collapsable: true,
|
||||
children: [
|
||||
"/interfaces/",
|
||||
"/interfaces/cli",
|
||||
"/interfaces/service-providers",
|
||||
"/interfaces/lite/", // this renders the readme
|
||||
"/interfaces/lite/getting_started",
|
||||
"/interfaces/lite/specification"
|
||||
]
|
||||
}
|
||||
]
|
||||
'/kr/': {
|
||||
label: '한국어',
|
||||
sidebar: sidebar('kr', [
|
||||
['소개', 'intro'],
|
||||
['기초', 'basics'],
|
||||
['SDK Core', 'core'],
|
||||
['모듈들', 'modules'],
|
||||
['프로그램 사용', 'sdk'],
|
||||
['인터페이스', 'interfaces'],
|
||||
]),
|
||||
},
|
||||
'/cn/': {
|
||||
label: '中文',
|
||||
sidebar: sidebar('cn', [
|
||||
['介绍', 'intro'],
|
||||
['基本', 'basics'],
|
||||
['SDK Core', 'core'],
|
||||
['模块', 'modules'],
|
||||
['使用该程序', 'sdk'],
|
||||
['接口', 'interfaces'],
|
||||
]),
|
||||
},
|
||||
}
|
||||
}
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,3 +1,8 @@
|
|||
export default ({ router }) => {
|
||||
router.addRoutes([{ path: "/testnet/", redirect: "/" }])
|
||||
}
|
||||
import axios from 'axios'
|
||||
import Vue from 'vue'
|
||||
|
||||
Vue.use({
|
||||
install (Vue) {
|
||||
Vue.prototype.$axios = axios.create()
|
||||
}
|
||||
})
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
$accentColor = #304DE9
|
||||
$textColor = #15192C
|
||||
$borderColor = #eaecef
|
||||
$codeBgColor = #282c34
|
||||
|
|
@ -83,4 +83,4 @@ Accepted
|
|||
|
||||
- https://github.com/cosmos/cosmos-sdk/issues/1460
|
||||
- https://github.com/cosmos/cosmos-sdk/pull/2695
|
||||
- https://github.com/cosmos/cosmos-sdk/issues/2611
|
||||
- https://github.com/cosmos/cosmos-sdk/issues/2611
|
||||
|
|
@ -37,4 +37,4 @@
|
|||
|
||||
## References
|
||||
|
||||
- {reference link}
|
||||
- {reference link}
|
||||
|
|
@ -229,7 +229,7 @@ See an example of an application's main command-line file [here](https://github.
|
|||
|
||||
## Dependencies and Makefile
|
||||
|
||||
This section is optional, as developers are free to choose their depencency manager and project building method. That said, the current most used framework for versioning control is [`go.mod`](https://github.com/golang/go/wiki/Modules). It ensures each of the libraries used throughout the application are imported with the correct version. An example can be found [here](https://github.com/cosmos/sdk-application-tutorial/blob/master/go.mod).
|
||||
This section is optional, as developers are free to choose their dependency manager and project building method. That said, the current most used framework for versioning control is [`go.mod`](https://github.com/golang/go/wiki/Modules). It ensures each of the libraries used throughout the application are imported with the correct version. An example can be found [here](https://github.com/cosmos/sdk-application-tutorial/blob/master/go.mod).
|
||||
|
||||
For building the application, a [Makefile](https://en.wikipedia.org/wiki/Makefile) is generally used. The Makefile primarily ensures that the `go.mod` is run before building the two entrypoints to the application, [`appd`](#node-client) and [`appcli`](#application-interface). An example of Makefile can be found [here](https://github.com/cosmos/sdk-application-tutorial/blob/master/Makefile).
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,34 @@
|
|||
# Module Manager and `AppModule` Interface
|
||||
|
||||
## Pre-requisite Reading
|
||||
|
||||
- [Introduction to SDK Modules](./intro.md)
|
||||
|
||||
## 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 the application developer to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#begingblocker-and-endblocker).
|
||||
|
||||
## Application Module Interfaces
|
||||
|
||||
[Application module interfaces](https://github.com/cosmos/cosmos-sdk/blob/master/types/module/module.go) exist to facilitate the composition of modules together to form a functional SDK application. There are 3 main application module interfaces:
|
||||
|
||||
- [`AppModuleBasic`](#appmodulebasic) for independent module functionalities.
|
||||
- [`AppModule`](#appmodule) for inter-dependent module functionalities (except genesis-related functionalities).
|
||||
- [`AppModuleGenesis`](#appmodulegenesis) for inter-dependent genesis-related module functionalities.
|
||||
|
||||
The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](../basics/app-antomy.md#core-application-file).
|
||||
|
||||
The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interact with other modules, typically through [`keeper`s](./keeper.md), which means there is a need for an interface where modules list their `keeper`s and other methods that require a reference to another module's object. `AppModule` interface also enables the module manager to set the order of execution between module's methods like `BeginBlock` and `EndBlock`, which is important in cases where the order of execution between modules matters in the context of the application.
|
||||
|
||||
Lastly the interface for genesis functionality `AppModuleGenesis` is separated out from full module functionality `AppModule` so that modules which
|
||||
are only used for genesis can take advantage of the `Module` patterns without having to define many placeholder functions.
|
||||
|
||||
### `AppModuleBasic`
|
||||
|
||||
### `AppModule`
|
||||
|
||||
### `AppModuleGenesis`
|
||||
|
||||
### Implementing the Application Module Interfaces
|
||||
|
||||
## Module Manager
|
||||
|
|
@ -16,7 +16,7 @@ Cosmos SDK 轻节点（Gaia-lite）分为两个独立的组件。 第一个组
|
|||
|
||||
想要为 Cosmos Hub（或任何其他 zone）构建第三方客户端应用程序的应用程序开发人员，应根据其规范 API 构建。 该API 是多个部分的组合。 所有 zone 都必须暴露ICS0（TendermintAPI）。 除此之外，任何 zone 都可以自由选择模块 API的任意组合，具体取决于状态机使用的模块。 Cosmos Hub最初将支持[ICS0](https://cosmos.network/rpc/#/ICS0) (TendermintAPI)、 [ICS1](https://cosmos.network/rpc/#/ICS1) (KeyAPI)、 [ICS20](https://cosmos.network/rpc/#/ICS20) (TokenAPI)、 [ICS21](https://cosmos.network/rpc/#/ICS21) (StakingAPI)、 [ICS22](https://cosmos.network/rpc/#/ICS22) (GovernanceAPI) 和 [ICS23](https://cosmos.network/rpc/#/ICS23) (SlashingAPI)。
|
||||
|
||||
|
||||
|
||||
|
||||
预计所有应用程序仅依赖于 Gaia-lite 运行。 Gaia-lite 是唯一一款围绕 zone API 提供稳定性保证的软件。
|
||||
|
||||
|
|
@ -49,12 +49,12 @@ Gaia-lite的基本设计理念遵循两个规则：
|
|||
|
||||
原始的可信验证人集应该预先放置到其信任库中，通常这个验证人集来自 genesis 文件。 在运行时期间，如果 Gaia-lite 检测到不同的验证人集，它将验证它并将可信的验证人集保存到信任库中。
|
||||
|
||||
|
||||
|
||||
|
||||
### 信任传播
|
||||
|
||||
从上面的小节中，我们了解了如何获得可信验证器集以及 LCD 如何跟踪验证人集演化。 验证人集是信任的基础，信任可以传播到其他区块链数据，例如块和交易。 传播架构如下所示：
|
||||
|
||||
|
||||
|
||||
|
||||
通常，通过可信验证人集，轻客户端可以验证包含所有预提交数据和块头数据的每个提交块。 此时块哈希、数据哈希和应用哈希是可信的。 基于此和默克尔证明，所有交易数据和 ABCI 状态也可以被验证。
|
||||
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
众所周知，基于 cosmos-sdk 的应用程序的存储包含多个子库。 每个子目录由 IAVL 存储实现。 这些子组件由简单的 Merkle 树组成。 创建树时，我们需要从这些子库中提取名字、高度和存储根哈希以构建一组简单的 Merkle 叶节点，然后计算从叶节点到根的哈希。 简单 Merkle 树的根哈希是 AppHash，它将包含在块头中。
|
||||
|
||||
|
||||
|
||||
|
||||
正如我们在[LCD信任传播](https://github.com/irisnet/cosmos-sdk/tree/bianjie/lcd_spec/docs/spec/lcd#trust-propagation)中所讨论的那样，可以通过检查针对可信验证人集的投票权来验证 AppHash。 这里我们只需要建立从 ABCI 状态到 AppHash 的证明。 证据包含两部分：
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ type KeyExistsProof struct {
|
|||
|
||||
存在证据的数据结构如上所示。 构建和验证存在证明的过程如下所示：
|
||||
|
||||
|
||||
|
||||
|
||||
构建证明的步骤：
|
||||
|
||||
|
|
@ -78,11 +78,11 @@ type KeyExistsProof struct {
|
|||
|
||||
众所周知，所有 IAVL 叶节点都按每个叶节点的密钥排序。 因此，我们可以在 IAVL 树的整个密钥集中计算出目标密钥的位置。 如下图所示，我们可以找到左键和右键。 如果我们可以证明左键和右键肯定存在，并且它们是相邻的节点，那么目标密钥肯定不存在。
|
||||
|
||||
|
||||
|
||||
|
||||
如果目标密钥大于最右边的叶节点或小于最左边的叶子节点，则目标密钥肯定不存在。
|
||||
|
||||
|
||||
|
||||
|
||||
```go
|
||||
type proofLeafNode struct {
|
||||
|
|
@ -128,7 +128,7 @@ type KeyAbsentProof struct {
|
|||
|
||||
在验证了 IAVL 证明之后，我们就可以开始验证针对 AppHash 的 substore 证明。 首先，迭代 MultiStoreCommitInfo 并通过证明 StoreName 找到 substore commitID。 验证 commitID 中的哈希是否等于证明根哈希，如果不相等则证明无效。 然后通过 substore name 的哈希对 substore commitInfo 数组进行排序。 最后，使用所有 substore commitInfo 数组构建简单的 Merkle 树，并验证 Merkle 根哈希值是否等于appHash。
|
||||
|
||||
|
||||
|
||||
|
||||
```go
|
||||
func SimpleHashFromTwoHashes(left []byte, right []byte) []byte {
|
||||
|
|
@ -166,13 +166,13 @@ func SimpleHashFromHashes(hashes [][]byte) []byte {
|
|||
|
||||
上面的小节中经常提到 appHash，但可信的appHash来自哪里？ 实际上，appHash 存在于区块头中，因此接下来我们需要针对 LCD 可信验证人集验证特定高度的区块头。 验证流程如下所示：
|
||||
|
||||
|
||||
|
||||
|
||||
当可信验证人集与区块头不匹配时，我们需要尝试将验证人集更新为此块的高度。 LCD 有一条规则，即每个验证人集的变化不应超过1/3投票权。 如果目标验证人集的投票权变化超过1/3，则与可信验证人集进行比较。 我们必须验证，在目标验证人集之前是否存在隐含的验证人集变更。 只有当所有验证人集变更都遵循这条规则时，才能完成验证人集的更新。
|
||||
|
||||
例如：
|
||||
|
||||
|
||||
|
||||
|
||||
* 更新到 10000，失败，变更太大
|
||||
* 更新到 5050，失败，变更太大
|
||||
|
|
@ -106,7 +106,7 @@ Flags:
|
|||
|
||||
监听入向交易推荐的方法是通过 LCD 的以下端点定期查询区块链：
|
||||
|
||||
[`/bank/balance/{address}`](https://cosmos.network/rpc/#/ICS20/get_bank_balances__address_)
|
||||
<!-- [`/bank/balance/{address}`](https://cosmos.network/rpc/#/ICS20/get_bank_balances__address_) -->
|
||||
|
||||
## Rest API
|
||||
|
||||
|
|
@ -17,10 +17,10 @@ This document describes `baseapp`, the abstraction that implements most of the c
|
|||
- [Main ABCI Messages](#abci)
|
||||
- [CheckTx](#checktx)
|
||||
- [DeliverTx](#delivertx)
|
||||
- [RunTx(), AnteHandler and RunMsgs](<#runtx()-,antehandler-and-runmsgs()>)
|
||||
- [RunTx()](<#runtx()>)
|
||||
- [RunTx, AnteHandler and RunMsgs](#runtx-antehandler-and-runmsgs)
|
||||
- [RunTx](#runtx)
|
||||
- [AnteHandler](#antehandler)
|
||||
- [RunMsgs()](<#runmsgs()>)
|
||||
- [RunMsgs](#runmsgs)
|
||||
- [Other ABCI Message](#other-abci-message)
|
||||
- [InitChain](#initchain)
|
||||
- [BeginBlock](#beginblock)
|
||||
|
|
@ -31,13 +31,13 @@ This document describes `baseapp`, the abstraction that implements most of the c
|
|||
|
||||
## Introduction
|
||||
|
||||
`baseapp` is a base class that implements the core of an SDK application, namely:
|
||||
`baseapp` is an abstraction that implements the core of an SDK application, namely:
|
||||
|
||||
- The [Application-Blockchain Interface](#abci), for the state-machine to communicate with the underlying consensus engine (e.g. Tendermint).
|
||||
- A [Router](#routing), to route messages and queries to the appropriate module.
|
||||
- Different [states](#states), as the state-machine can have different parallel states updated based on the ABCI message received.
|
||||
|
||||
The goal of `baseapp` is to provide the fundamental layer of an SDK application that developers can easily extend to build their own custom application. Usually, developers will create a custom type for their application, like so:
|
||||
The goal of `baseapp` is to provide a boilerplate SDK application that developers can easily extend to build their own custom application. Usually, developers will create a custom type for their application, like so:
|
||||
|
||||
```go
|
||||
type app struct {
|
||||
|
|
@ -200,7 +200,7 @@ Developers building on top of the Cosmos SDK need not implement the ABCI themsel
|
|||
|
||||
### CheckTx
|
||||
|
||||
The `CheckTx` ABCI message is sent by the underlying consensus engine when a new unconfirmed (i.e. not yet included in a valid block) transaction is received by a full-node, and it is handled by the `CheckTx(req abci.RequestCheckTx)` method of `baseapp` (abbreviated to `CheckTx()` thereafter). The role of `CheckTx()` is to guard the full-node's mempool (where unconfirmed transactions are stored until they are included in a block) from spam transactions. Unconfirmed transactions are relayed to peers only if they pass `CheckTx()`.
|
||||
`CheckTx` is sent by the underlying consensus engine when a new unconfirmed (i.e. not yet included in a valid block) transaction is received by a full-node. The role of `CheckTx` is to guard the full-node's mempool (where unconfirmed transactions are stored until they are included in a block) from spam transactions. Unconfirmed transactions are relayed to peers only if they pass `CheckTx`.
|
||||
|
||||
`CheckTx()` can perform both _stateful_ and _stateless_ checks, but developers should strive to make them lightweight. In the Cosmos SDK, after decoding transactions, `CheckTx()` is implemented to do the following checks:
|
||||
|
||||
|
|
@ -211,7 +211,7 @@ The `CheckTx` ABCI message is sent by the underlying consensus engine when a new
|
|||
|
||||
Steps 2. and 3. are performed by the `anteHandler` in the [`RunTx()`](<#runtx()-,antehandler-and-runmsgs()>) function, which `CheckTx()` calls with the `runTxModeCheck` mode. During each step of `CheckTx()`, a special [volatile state](#volatile-states) called `checkState` is updated. This state is used to keep track of the temporary changes triggered by the `CheckTx()` calls of each transaction without modifying the [main canonical state](#main-state) . For example, when a transaction goes through `CheckTx()`, the transaction's fees are deducted from the sender's account in `checkState`. If a second transaction is received from the same account before the first is processed, and the account has consumed all its funds in `checkState` during the first transaction, the second transaction will fail `CheckTx`() and be rejected. In any case, the sender's account will not actually pay the fees until the transaction is actually included in a block, because `checkState` never gets committed to the main state. `checkState` is reset to the latest state of the main state each time a blocks gets [committed](#commit).
|
||||
|
||||
`CheckTx()` returns a response to the underlying consensus engine of type [`abci.ResponseCheckTx`](https://tendermint.com/docs/spec/abci/abci.html#messages). The response contains:
|
||||
`CheckTx` returns a response to the underlying consensus engine of type [`abci.ResponseCheckTx`](https://tendermint.com/docs/spec/abci/abci.html#messages). The response contains:
|
||||
|
||||
- `Code (uint32)`: Response Code. `0` if successful.
|
||||
- `Data ([]byte)`: Result bytes, if any.
|
||||
|
|
@ -224,18 +224,18 @@ Steps 2. and 3. are performed by the `anteHandler` in the [`RunTx()`](<#runtx()-
|
|||
|
||||
### DeliverTx
|
||||
|
||||
When the underlying consensus engine receives a block proposal, each transaction in the block needs to be processed by the application. To that end, the underlying consensus engine sends a `DeliverTx` message to the application for each transaction in a sequential order. This ABCI message is handled by the `DeliverTx()` method of `baseapp` (abbreviated to `DeliverTx()` thereafter).
|
||||
When the underlying consensus engine receives a block proposal, each transaction in the block needs to be processed by the application. To that end, the underlying consensus engine sends a `DeliverTx` message to the application for each transaction in a sequential order.
|
||||
|
||||
Before the first transaction of a given block is processed, a [volatile state](#volatile-states) called `deliverState` is initialized during [`BeginBlock`](#beginblock). This state is updated each time a transaction is processed via `DeliverTx()`, and committed to the [main state](#main-state) when the block is [committed](#commit), after what is is set to `nil`.
|
||||
|
||||
`DeliverTx()` performs the **exact same steps as `CheckTx()`**, with a little caveat at step 3 and the addition of a fifth step:
|
||||
`DeliverTx` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step:
|
||||
|
||||
3. The `anteHandler` does **not** check that the transaction's `gas-prices` is sufficient. That is because the `min-gas-prices` value `gas-prices` is checked against is local to the node, and therefore what is enough for one full-node might not be for another. This means that the proposer can potentially include transactions for free, although they are not incentivised to do so, as they earn a bonus on the total fee of the block they propose.
|
||||
4. For each `message` in the transaction, route to the appropriate module's `handler`. Additional _stateful_ checks are performed, and the cache-wrapped multistore held in `deliverState`'s `context` is updated by the module's `keeper`. If the `handler` returns successfully, the cache-wrapped multistore held in `context` is written to `deliverState` `CacheMultiStore`.
|
||||
|
||||
During step 5., each read/write to the store increases the value of `GasConsumed`. You can find the default cost of each operation [here](https://github.com/cosmos/cosmos-sdk/blob/master/store/types/gas.go#L142-L150). At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0` and `DeliverTx()` fails.
|
||||
|
||||
`DeliverTx()` returns a response to the underlying consensus engine of type [`abci.ResponseCheckTx`](https://tendermint.com/docs/spec/abci/abci.html#messages). The response contains:
|
||||
`DeliverTx` returns a response to the underlying consensus engine of type [`abci.ResponseCheckTx`](https://tendermint.com/docs/spec/abci/abci.html#messages). The response contains:
|
||||
|
||||
- `Code (uint32)`: Response Code. `0` if successful.
|
||||
- `Data ([]byte)`: Result bytes, if any.
|
||||
|
|
@ -246,19 +246,19 @@ During step 5., each read/write to the store increases the value of `GasConsumed
|
|||
- `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account).
|
||||
- `Codespace (string)`: Namespace for the Code.
|
||||
|
||||
## RunTx(), AnteHandler and RunMsgs()
|
||||
## RunTx, AnteHandler and RunMsgs
|
||||
|
||||
### RunTx()
|
||||
### RunTx
|
||||
|
||||
`RunTx()` is called from `CheckTx()`/`DeliverTx()` to handle the transaction, with `runTxModeCheck` or `runTxModeDeliver` as parameter to differentiate between the two modes of execution. Note that when `RunTx()` receives a transaction, it has already been decoded.
|
||||
|
||||
The first thing `RunTx()` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `runTxModeDeliver`). This `CacheMultiStore` is a cached version of the main store instantiated during `BeginBlock` for `DeliverTx` and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for `gas` management. They are executed when `RunTx()` returns and make sure `gas` is actually consumed, and will throw errors, if any.
|
||||
|
||||
After that, `RunTx()` calls `ValidateBasic()` on each `message`in the `Tx`, which runs prelimary _stateless_ validity checks. If any `message` fails to pass `ValidateBasic()`, `RunTx()` returns with an error.
|
||||
After that, `RunTx()` calls `ValidateBasic()` on each `message`in the `Tx`, which runs preliminary _stateless_ validity checks. If any `message` fails to pass `ValidateBasic()`, `RunTx()` returns with an error.
|
||||
|
||||
Then, the [`anteHandler`](#antehandler) of the application is run (if it exists). In preparation of this step, both the `checkState`/`deliverState`'s `context` and `context`'s `CacheMultiStore` are cached-wrapped using the [`cacheTxContext()`](https://github.com/cosmos/cosmos-sdk/blob/master/baseapp/baseapp.go#L781-L798) function. This allows `RunTx()` not to commit the changes made to the state during the execution of `anteHandler` if it ends up failing. It also prevents the module implementing the `anteHandler` from writing to state, which is an important part of the [object-capabilities](./ocap.md) of the Cosmos SDK.
|
||||
|
||||
Finally, the [`RunMsgs()`](<#runmsgs()>) function is called to process the `messages`s in the `Tx`. In preparation of this step, just like with the `anteHandler`, both the `checkState`/`deliverState`'s `context` and `context`'s `CacheMultiStore` are cached-wrapped using the `cacheTxContext()` function.
|
||||
Finally, the [`RunMsgs()`](#runmsgs) function is called to process the `messages`s in the `Tx`. In preparation of this step, just like with the `anteHandler`, both the `checkState`/`deliverState`'s `context` and `context`'s `CacheMultiStore` are cached-wrapped using the `cacheTxContext()` function.
|
||||
|
||||
### AnteHandler
|
||||
|
||||
|
|
@ -272,7 +272,7 @@ The `AnteHandler` is theoretically optional, but still a very important componen
|
|||
|
||||
`baseapp` holds an `anteHandler` as parameter, which is initialized in the [application's constructor](../basics/app-anatomy.md#application-constructor). The most widely used `anteHandler` today is that of the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/master/x/auth/ante.go).
|
||||
|
||||
### RunMsgs()
|
||||
### RunMsgs
|
||||
|
||||
`RunMsgs()` is called from `RunTx()` with `runTxModeCheck` as parameter to check the existence of a route for each message contained in the transaction, and with `runTxModeDeliver` to actually process the `message`s.
|
||||
|
||||
|
|
@ -282,7 +282,7 @@ First, it retrieves the `message`'s `route` using the `Msg.Route()` method. Then
|
|||
|
||||
### InitChain
|
||||
|
||||
The [`InitChain` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#initchain) is sent from the underlying Tendermint engine when the chain is first started, and is handled by the `InitChain(req abci.RequestInitChain)` method of `baseapp`. It is mainly used to **initialize** parameters and state like:
|
||||
The [`InitChain` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#initchain) is sent from the underlying Tendermint engine when the chain is first started. It is mainly used to **initialize** parameters and state like:
|
||||
|
||||
- [Consensus Parameters](https://tendermint.com/docs/spec/abci/apps.html#consensus-parameters) via `setConsensusParams`.
|
||||
- [`checkState` and `deliverState`](#volatile-states) via `setCheckState` and `setDeliverState`.
|
||||
|
|
@ -292,7 +292,7 @@ Finally, the `InitChain(req abci.RequestInitChain)` method of `baseapp` calls th
|
|||
|
||||
### BeginBlock
|
||||
|
||||
The [`BeginBlock` ABCI message](#https://tendermint.com/docs/app-dev/abci-spec.html#beginblock) is sent from the underlying Tendermint engine when a block proposal created by the correct proposer is received, before [`DeliverTx()`](#delivertx) is run for each transaction in the block. It allows developers to have logic be executed at the beginning of each block. In the Cosmos SDK, the `BeginBlock(req abci.RequestBeginBlock)` method does the following:
|
||||
The [`BeginBlock` ABCI message](#https://tendermint.com/docs/app-dev/abci-spec.html#beginblock) is sent from the underlying Tendermint engine when a block proposal created by the correct proposer is received, before [`DeliverTx`](#delivertx) is run for each transaction in the block. It allows developers to have logic be executed at the beginning of each block. In the Cosmos SDK, the `BeginBlock(req abci.RequestBeginBlock)` method does the following:
|
||||
|
||||
- Initialize [`deliverState`](#volatile-states) with the latest header using the `req abci.RequestBeginBlock` passed as parameter via the [`setDeliverState`](https://github.com/cosmos/cosmos-sdk/blob/master/baseapp/baseapp.go#L283-L289) function.
|
||||
- Initialize the block gas meter with the `maxGas` limit. The `gas` consumed within the block cannot go above `maxGas`. This parameter is defined in the application's consensus parameters.
|
||||
|
|
@ -301,7 +301,7 @@ The [`BeginBlock` ABCI message](#https://tendermint.com/docs/app-dev/abci-spec.h
|
|||
|
||||
### EndBlock
|
||||
|
||||
The [`EndBlock` ABCI message](#https://tendermint.com/docs/app-dev/abci-spec.html#endblock) is sent from the underlying Tendermint engine after [`DeliverTx`](#delivertx) as been run for each transactioni n the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`endBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock), which mainly runs the `EndBlocker()` method of each of the application's modules.
|
||||
The [`EndBlock` ABCI message](#https://tendermint.com/docs/app-dev/abci-spec.html#endblock) is sent from the underlying Tendermint engine after [`DeliverTx`](#delivertx) as been run for each transaction n the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`endBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock), which mainly runs the `EndBlocker()` method of each of the application's modules.
|
||||
|
||||
### Commit
|
||||
|
||||
|
|
@ -324,8 +324,4 @@ The `baseapp` implementation of the `Query(req abci.RequestQuery)` method is a s
|
|||
- Application-related queries like querying the application's version, which are served via the `handleQueryApp` method.
|
||||
- Direct queries to the multistore, which are served by the `handlerQueryStore` method. These direct queries are different from custom queries which go through `app.queryRouter`, and are mainly used by third-party service provider like block explorers.
|
||||
- P2P queries, which are served via the `handleQueryP2P` method. These queries return either `app.addrPeerFilter` or `app.ipPeerFilter` that contain the list of peers filtered by address or IP respectively. These lists are first initialized via `options` in `baseapp`'s [constructor](#constructor).
|
||||
- Custom queries, which encompass most queries, are served via the `handleQueryCustom` method. The `handleQueryCustom` cache-wraps the multistore before using the `queryRoute` obtained from [`app.queryRouter`](#query-routing) to map the query to the appropriate module's [`querier`](../building-modules/querier.md).
|
||||
|
||||
## Next
|
||||
|
||||
Learn more about [stores](./store.md).
|
||||
- Custom queries, which encompass most queries, are served via the `handleQueryCustom` method. The `handleQueryCustom` cache-wraps the multistore before using the `queryRoute` obtained from [`app.queryRouter`](#query-routing) to map the query to the appropriate module's `querier`.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: false
|
||||
---
|
||||
|
||||
# BaseApp
|
||||
|
||||
The BaseApp defines the foundational implementation for a basic ABCI application
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: false
|
||||
---
|
||||
|
||||
# Object-Capability Model
|
||||
|
||||
## Intro
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# SDK Intro
|
||||
|
||||
## What is the SDK?
|
||||
|
|
@ -26,5 +30,4 @@ The Cosmos SDK is the most advanced framework for building custom application-sp
|
|||
## Getting started with the Cosmos SDK
|
||||
|
||||
- Learn more about the [architecture of an SDK application](./sdk-app-architecture.md)
|
||||
- Learn how to build an application-specific blockchain from scratch with the [SDK Tutorial](https://cosmos.network/docs/tutorial)
|
||||
|
||||
- Learn how to build an application-specific blockchain from scratch with the [SDK Tutorial](https://cosmos.network/docs/tutorial)
|
||||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# SDK Application Architecture
|
||||
|
||||
## State machine
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Cosmos SDK design overview
|
||||
|
||||
The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the SDK is a boilerplate implementation of the ABCI in Golang. It comes with a `multistore` to persist data and a `router` to handle transactions.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 31 KiB |
|
Before Width: | Height: | Size: 95 KiB After Width: | Height: | Size: 95 KiB |
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 31 KiB |
|
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 28 KiB |
|
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 30 KiB |
|
Before Width: | Height: | Size: 8.7 KiB After Width: | Height: | Size: 8.7 KiB |
|
Before Width: | Height: | Size: 63 KiB After Width: | Height: | Size: 63 KiB |
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 94 KiB After Width: | Height: | Size: 94 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
|
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
|
Before Width: | Height: | Size: 61 KiB After Width: | Height: | Size: 61 KiB |
|
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
|
Before Width: | Height: | Size: 49 KiB After Width: | Height: | Size: 49 KiB |
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
|
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 283 KiB After Width: | Height: | Size: 283 KiB |
|
Before Width: | Height: | Size: 186 KiB After Width: | Height: | Size: 186 KiB |
|
|
@ -0,0 +1,91 @@
|
|||
---
|
||||
order: false
|
||||
---
|
||||
|
||||
# Auth
|
||||
|
||||
The `x/auth` modules is used for accounts
|
||||
|
||||
See the [API docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/auth)
|
||||
|
||||
See the [specification](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/auth)
|
||||
|
||||
# Bank
|
||||
|
||||
The `x/bank` module is for transferring coins between accounts.
|
||||
|
||||
See the [API docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/bank).
|
||||
|
||||
See the [specification](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/bank)
|
||||
|
||||
# Stake
|
||||
|
||||
The `x/staking` module is for Cosmos Delegated-Proof-of-Stake.
|
||||
|
||||
See the [API docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/staking).
|
||||
|
||||
See the
|
||||
[specification](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/staking)
|
||||
|
||||
# Slashing
|
||||
|
||||
The `x/slashing` module is for Cosmos Delegated-Proof-of-Stake.
|
||||
|
||||
See the [API docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/slashing)
|
||||
|
||||
See the
|
||||
[specification](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/slashing)
|
||||
|
||||
# Distribution
|
||||
|
||||
The `x/distribution` module is for distributing fees and inflation across bonded
|
||||
stakeholders.
|
||||
|
||||
See the [API docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/distribution)
|
||||
|
||||
See the
|
||||
[specification](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/distribution)
|
||||
|
||||
# Governance
|
||||
|
||||
The `x/gov` module is for bonded stakeholders to make proposals and vote on them.
|
||||
|
||||
See the [API docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/gov)
|
||||
|
||||
See the
|
||||
[specification](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/governance)
|
||||
|
||||
# IBC
|
||||
|
||||
The `x/ibc` module is for InterBlockchain Communication.
|
||||
|
||||
See the [API docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/ibc)
|
||||
|
||||
See the
|
||||
[specification](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/ibc)
|
||||
|
||||
To keep up with the current status of IBC, follow and contribute to [ICS](https://github.com/cosmos/ics)
|
||||
|
||||
# Crisis
|
||||
|
||||
The `x/crisis` module is for halting the blockchain under certain circumstances.
|
||||
|
||||
See the [API Docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/crisis)
|
||||
|
||||
See the [specification](https://github.com/cosmos/cosmos-sdk/blob/master/docs/spec/crisis)
|
||||
|
||||
# Mint
|
||||
|
||||
The `x/mint` module is for flexible inflation rates and effect a balance between market liquidity and staked supply.
|
||||
|
||||
See the [API Docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/mint)
|
||||
|
||||
See the [specification](https://github.com/cosmos/cosmos-sdk/blob/master/docs/spec/mint)
|
||||
|
||||
# Params
|
||||
|
||||
The `x/params` module provides a globally available parameter store.
|
||||
|
||||
See the [API Docs](https://godoc.org/github.com/cosmos/cosmos-sdk/x/params)
|
||||
|
||||
See the [specification](https://github.com/cosmos/cosmos-sdk/blob/master/docs/spec/params)
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,21 @@
|
|||
{
|
||||
"name": "docs",
|
||||
"version": "1.0.0",
|
||||
"description": "## Get Started",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"serve": "vuepress dev",
|
||||
"build": "vuepress build"
|
||||
},
|
||||
"author": "",
|
||||
"license": "ISC",
|
||||
"devDependencies": {
|
||||
"lodash": "^4.17.11",
|
||||
"markdown-it": "^8.4.2",
|
||||
"markdown-it-meta": "0.0.1",
|
||||
"vuepress": "^1.0.2"
|
||||
},
|
||||
"dependencies": {
|
||||
"axios": "^0.19.0"
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Введение в Cosmos SDK
|
||||
|
||||
## Что такое Cosmos SDK?
|
||||
|
||||
[Cosmos SDK](https://github.com/cosmos/cosmos-sdk) — это фреймворк для создания публичных Proof-of-Stake (PoS) и закрытых Proof-Of-Authority (PoA) multi-asset блокчейнов. Блокчейны, разработанные с помощью Cosmos SDK, называют application-specific, то есть созданные для конкретного приложения. Исходный код Cosmos SDK находится в свободном доступе и распространяется под лицензией Apache License 2.0.
|
||||
|
||||
Цель Cosmos SDK: дать разработчикам инструменты для создания с нуля собственных блокчейнов, которые смогут нативно взаимодействовать с другими блокчейнами. Мы видим SDK как напоминающий NPM фреймворк для разработки безопасных блокчейн-приложений поверх [Tendermint](https://github.com/tendermint/tendermint). Построенные с помощью SDK блокчейны состоят из совместимых друг с другом модулей, и большинство из них находятся в свободном доступе. Создать модуль для Cosmos SDK может любой разработчик, а для интеграции уже существующих модулей достаточно импортировать их в свое приложение. Cosmos SDK построен на системе «разрешений», которая позволяет разработчикам лучше контролировать взаимодействие между модулями. В общем, смарт-контракты ограничивают в отношении гибкости, суверенитета и производительности.
|
||||
|
||||
## Почему блокчейн для конкретного приложения?
|
||||
|
||||
Общепринятая парадигма в мире блокчейна предполагает существование виртуальной машины блокчейна, например Ethereum, и разработки децентрализованных приложений как набора смарт-контрактов поверх существующего блокчейна. Смарт-контракты могут быть удобны для создания «одноразовых» приложений, например для ICO, но плохо подходят для разработки сложных децентрализованных платформ.
|
||||
|
||||
[Блокчейны для конкретных приложений](./why-app-specific.md) работают в совершенно отличной от виртуальных машин парадигме. Такие блокчейны создаются под потребности конкретного приложения и разработчики имеют полную свободу в принятии технических решений для создания блокчейна, который позволит их приложению работать оптимально. Это позволяет избежать ограничений смарт-контрактов.
|
||||
|
||||
## Почему именно Cosmos SDK?
|
||||
|
||||
Cosmos SDK является наиболее полным фреймворком для создания блокчейнов для приложений. Есть ряд причин, которые помогут сделать выбор в пользу Cosmos SDK:
|
||||
|
||||
- В качестве движка консенсуса SDK по умолчанию использует [Tendermint Core](https://github.com/tendermint/tendermint) — проработанный BFT-движок, который пользуется широкой популярностью и фактически является «золотым стандартом» при построении Proof-of-Stake систем
|
||||
|
||||
- Исходный код SDK находится в свободном доступе, а модульная система позволяет разрабатывать блокчейн в виде отдельных совместимых друг с другом модулей. По мере роста экосистемы модулей, находящихся в свободном доступе, разработка сложных децентрализованных приложений будет становится еще проще.
|
||||
|
||||
- SDK построен на системе «разрешений» и большом опыте работы с вируальными машинами блокчейнов. Это делает Cosmos SDK очень безопасным фреймворком для создания блокчейнов.
|
||||
|
||||
- Самое важное: Cosmos SDK уже используется для создания работающих в продакшене блокчейнов. В качестве примеров можно привести [Cosmos Hub](https://hub.cosmos.network), [IRIS Hub](https://irisnet.org), [Binance Chain](https://docs.binance.org/), [Terra](https://terra.money/), [Lino](https://lino.network/) и многие другие проекты, которые находятся в стадии разработки, используют Cosmos SDK. Примеры использования можно посмотреть на [странице экосистемы](https://cosmos.network/ecosystem).
|
||||
|
||||
## Начало работы с Cosmos SDK
|
||||
|
||||
- Прочитайте об [архитектуре приложения](./sdk-app-architecture.md), разрабатываемого с помощью SDK.
|
||||
|
||||
- Узнайте, как с нуля создать блокчейн для вашего приложения в [пошаговом примере](https://cosmos.network/docs/tutorial).
|
||||
|
|
@ -0,0 +1,96 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Архитектура SDK-приложения
|
||||
|
||||
## Конечный автомат (state machine)
|
||||
|
||||
В ядре блокчейна находится [реплицированный детерминированный конечный автомат](https://en.wikipedia.org/wiki/State_machine_replication).
|
||||
|
||||
В информатике конечный автомат — это математическая абстракция, имеющая один вход, один выход и в каждый момент времени находящаяся в одном из множества состояний. **Состояние** описывает текущее состояние автомата, а **транзакции** описывают изменения текущего состояния.
|
||||
|
||||
Принимая в качестве входа состояние `S` и транзакцию `T`, автомат вернет новое состояние `S'`.
|
||||
|
||||
```
|
||||
+--------+ +--------+
|
||||
| | | |
|
||||
| S +---------------->+ S' |
|
||||
| | apply(T) | |
|
||||
+--------+ +--------+
|
||||
```
|
||||
|
||||
На практике транзакции сгруппированы в блоки, что позволяет сделать процесс более эффективным. Принимая в качестве входа состояние `S` и блок транзакций `B`, автомат вернет новое состояние `S'`.
|
||||
```
|
||||
+--------+ +--------+
|
||||
| | | |
|
||||
| S +----------------------------> | S' |
|
||||
| | For each T in B: apply(T) | |
|
||||
+--------+ +--------+
|
||||
```
|
||||
|
||||
В контексте блокчейна, конечный автомат является детерминированным. Детерминированность означает, что применение к одному состоянию одной и той же последовательности транзакций всегда приводит к одному и тому же конечному состоянию.
|
||||
|
||||
Cosmos SDK дает максимальную гибкость в определеини состояния разрабатываемого приложения, типов транзакций и функций изменения состояния. Процесс разработки конечного автомата с помощью SDK будет описан в следующих главах. В начале рассмотрим процесс репликации с использованием **Tendermint**.
|
||||
|
||||
### Tendermint
|
||||
|
||||
Единственное, что нужно сделать разработчику, это описать конечный автомат с помощью Cosmos SDK. Процесс репликации через сеть берет на себя [*Tendermint*](https://tendermint.com/docs/introduction/what-is-tendermint.html).
|
||||
|
||||
```
|
||||
^ +-------------------------------+ ^
|
||||
| | | | Built with Cosmos SDK
|
||||
| | Конечный автомат = приложение | |
|
||||
| | | v
|
||||
| +-------------------------------+
|
||||
| | | ^
|
||||
Нода блокчейна | | Консенсус | |
|
||||
| | | |
|
||||
| +-------------------------------+ | Tendermint Core
|
||||
| | | |
|
||||
| | Сеть | |
|
||||
| | | |
|
||||
v +-------------------------------+ v
|
||||
```
|
||||
|
||||
Tendermint — это независимая от разрабатываемого приложения программа, ответственная за **сетевое взаимодействие** и **консенсус**. На практике это означает, что Tendermint отвечает за передачу и упорядочивание байтов транзакций. [Tendermint Core](https://tendermint.com/docs/introduction/what-is-tendermint.html) основан на алгоритме Byzantine-Fault-Tolerant (BFT) для достижения консенсуса о порядке транзакций.
|
||||
|
||||
Алгоритм консенсуса Tendermint работает на множестве специальных нод, называемых **валидаторами**. Валидаторы отвечают за добавление блоков транзакций в блокчейн. В момент работы с каждым блоком существует множество валидаторов `V`. Из этого множества алгоритмом выбирается валидатор, который будет предлагать следующий блок. Блок считается валидным, если более чем две трети валидаторов подписали *[prevote](https://tendermint.com/docs/spec/consensus/consensus.html#prevote-step-height-h-round-r)* и *[precommit](https://tendermint.com/docs/spec/consensus/consensus.html#precommit-step-height-h-round-r)*, и все транзакции в блоке валидны. Множество валидаторов может быть изменено в правилах, по которым работает конечный автомат. Узнать подробнее о работе алгоритма можно на [следующей странице](https://tendermint.com/docs/introduction/what-is-tendermint.html#consensus-overview).
|
||||
|
||||
Основной частью приложения, написанного с помощью Cosmos SDK, является фоновая программа (daemon), которая запускается на каждой ноде. Если в множестве валидаторов злоумышленниками являются менее одной трети валидаторов, то при запросе каждая нода должна получить одно и то же состояние в данный момент времени.
|
||||
|
||||
## ABCI
|
||||
|
||||
Tendermint передает приложению транзакции по сети через интерфейс [ABCI](https://github.com/tendermint/tendermint/tree/master/abci), который приложение должно реализовать.
|
||||
|
||||
```
|
||||
+---------------------+
|
||||
| |
|
||||
| Приложение |
|
||||
| |
|
||||
+--------+---+--------+
|
||||
^ |
|
||||
| | ABCI
|
||||
| v
|
||||
+--------+---+--------+
|
||||
| |
|
||||
| |
|
||||
| Tendermint |
|
||||
| |
|
||||
| |
|
||||
+---------------------+
|
||||
```
|
||||
|
||||
**Tendermint работает с байтами транзакций**, но не имеет информации о том, что эти байты означают. Все, что делает Tendermint, — это детерминировано упорядочивает эти байты. Tendermint передает байты приложению через ABCI и ожидает получить код возврата, который содержит сообщение о том, успешно ли были обработаны транзакции.
|
||||
|
||||
Наиболее важные типы сообщений ABCI:
|
||||
|
||||
- `CheckTx`: после принятия транзации Tendermint Core, транзакция передается приложению для проверки базовых требований. `CheckTx` используется для защиты мемпула (mempool) нод от спама. Предварительный обработчик (Ante Handler) используется для выполнения последовательности валидационных шагов, таких как проверка вознаграждений (fees) и подписей валидаторов. Если транзакция валидна, она добавляется в [mempool](https://tendermint.com/docs/spec/reactors/mempool/functionality.html#mempool-functionality) и транслируется другим нодам. Следует заметить, что `CheckTx` не обрабатывает транзакции, то есть изменения состояния не происходит, потому что транзакции на этом этапе еще не были включены в блок.
|
||||
|
||||
- `DeliverTx`: когда Tendermint Core принимает [валидный блок](https://tendermint.com/docs/spec/blockchain/blockchain.html#validation), каждая транзакция в данном блоке передается приложению через `DeliverTx` для обработки. Именно на этом этапе происходит изменение состояния. Обработчик (Ante Handler) выполняется повторно вместе с остальными обработчиками для каждого сообщения в транзакции.
|
||||
|
||||
- `BeginBlock` / `EndBlock`: эти сообщения выполняются в начале и конце блока, вне зависимости от того, содержит блок транзакции или нет. Это удобно, если необходимо автоматически выполнить код. Следует заметить, что процессы, требующие больших вычислительных ресурсов, могут замедлить работу блокчейна или вовсе привести к остановке в случае бесконечного цикла.
|
||||
|
||||
Более подробный обзор методов и типов ABCI находится на [следующей странице](https://tendermint.com/docs/spec/abci/abci.html#overview).
|
||||
|
||||
Построенное на Tendermint приложение должно реализовать интерфейс ABCI для взаимодействия с локально запущенной программой Tendermint. К счастью, реализовывать интерфейс самостоятельно не нужно, потому что в составе Cosmos SDK уже есть его реализация в виде [baseapp](./sdk-design.md#baseapp).
|
||||
|
|
@ -0,0 +1,100 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Обзор дизайна Cosmos SDK
|
||||
|
||||
Cosmos SDK - это фреймворк, который облегчает разработку безопасных конечных автоматов поверх движка консенсуса Tendermint. По своей сути, SDK представляет собой реализацию ABCI на языке программирования Go. Он поставляется с хранилищем данных `multistore` и маршрутизатором для обработки транзакций `router`.
|
||||
|
||||
Далее представлен алгоритм обработки транзакций в приложении на Cosmos SDK при передаче транзакций из Tendermint через `DeliverTx`:
|
||||
|
||||
1. Декодируйте `transactions`, полученные от механизма консенсуса Tendermint (помните, что Tendermint работает только с `[]bytes`).
|
||||
|
||||
2. Извлеките `messages` из `transactions` и выполните базовые проверки.
|
||||
|
||||
3. Направьте каждое сообщение в соответствующий модуль для его обработки.
|
||||
|
||||
4. Сохраните изменения состояния.
|
||||
|
||||
Приложение также позволяет генерировать транзакции, кодировать их и передавать их базовому движку Tendermint для их трансляции.
|
||||
|
||||
## `baseapp`
|
||||
|
||||
`baseApp` — это базовая реализация ABCI в Cosmos SDK. Она поставляется с модулем `router` для маршрутизации транзакций в соответствующий модуль. Файл `app.go` вашего приложения будет определять ваш тип ` app`, который будет встраивать `baseapp`. Таким образом, ваш пользовательский тип `app` будет автоматически наследовать все ABCI-методы `baseapp`. Пример этого в [туториале по созданию приложения с помощью SDK] (https://github.com/cosmos/sdk-application-tutorial/blob/master/app.go#L27).
|
||||
|
||||
Цель `baseapp`: обеспечить безопасный интерфейс между хранилищем и расширяемым конечным автоматом, в то же время определяя как можно меньше о конечном компьютере (соответствуя ABCI).
|
||||
|
||||
УЗнать больше о `baseapp` можно [здесь](../concepts/baseapp.md).
|
||||
|
||||
## `multistore`
|
||||
|
||||
В составе Cosmos SDK есть хранилище для сохранения состояния. Это хранилище позволяет разработчикам создавать любое количество [`KVStores`](https://github.com/blocklayerhq/chainkit). Эти `KVStores` принимают только `[] byte` в качестве значения, и поэтому любая пользовательская структура должна быть собрана с помощью [go-amin](https://github.com/tendermint/go-amino) перед сохранением.
|
||||
|
||||
Абстракция в виде этого хранилища используется для разделения состояния на отдельные части, каждый из которых управляется своим собственным модулем. Получить больше информации о `multistore` можно [здесь](../concepts/store.md).
|
||||
|
||||
## Модули
|
||||
|
||||
Основное преимуществе Cosmos SDK заключается в его модульности. Приложения SDK создаются путем объединения набора совместимых модулей. Каждый модуль определяет подмножество состояния и содержит свой собственный обработчик сообщений/транзакций, в то время как SDK отвечает за маршрутизацию каждого сообщения в соответствующий модуль.
|
||||
|
||||
Вот упрощенное представление о том, как транзакция обрабатывается приложением каждого полной ноды, когда она получена в валидном блоке:
|
||||
|
||||
|
||||
```
|
||||
+
|
||||
|
|
||||
| Транзакция ретранслируется из движка Tendermint
|
||||
| полной ноды в приложение ноды через DeliverTx
|
||||
|
|
||||
|
|
||||
|
|
||||
+---------------------v--------------------------+
|
||||
| Приложение |
|
||||
| |
|
||||
| Используя методы baseapp, декодируй Tx, |
|
||||
| извлеки сообщение и маршрутизируй его |
|
||||
| |
|
||||
+---------------------+--------------------------+
|
||||
|
|
||||
|
|
||||
|
|
||||
+---------------------------+
|
||||
|
|
||||
|
|
||||
| Сообщение отправлено
|
||||
| в нужный модуль
|
||||
| для обработки
|
||||
|
|
||||
|
|
||||
+----------------+ +---------------+ +----------------+ +------v----------+
|
||||
| | | | | | | |
|
||||
| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE |
|
||||
| | | | | | | |
|
||||
| | | | | | | Обработай сооб.,|
|
||||
| | | | | | | обнови состояние|
|
||||
| | | | | | | |
|
||||
+----------------+ +---------------+ +----------------+ +------+----------+
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
+--------------------------+
|
||||
|
|
||||
| Верни результат в Tendermint
|
||||
| (0=Ok, 1=Err)
|
||||
v
|
||||
```
|
||||
|
||||
Каждый модуль можно рассматривать как самостоятельный конечный автомат. Разработчикам необходимо определить подмножество состояния, обрабатываемого модулем, а также настраиваемые типы сообщений, которые изменяют состояние (следует отметить, что `messages` извлекаются из `transactions` с использованием `baseapp`). В общем, каждый модуль создает свой собственный `KVStore` в `multistore`, чтобы сохранить подмножество состояния, которое он определяет. Большинству разработчиков потребуется доступ к другим сторонним модулям при создании своих собственных модулей. Учитывая, что Cosmos-SDK является открытой платформой, некоторые модули могут быть вредоносными, что означает необходимость создания правил безопасности для определения межмодульных взаимодействий. Эти правила основаны на [object-capabilities](../core/ocap.md). На практике это означает, что вместо того, чтобы каждый модуль вел список контроля доступа для других модулей, каждый модуль реализует специальные объекты, называемые хранителями, которые могут быть переданы другим модулям для предоставления предварительно определенного набора возможностей.
|
||||
|
||||
Модули SDK определены в директории `x/` SDK. Основные модули в составе Cosmos SDK:
|
||||
|
||||
- `x/auth`: используется для управления учетными записями и подписями.
|
||||
|
||||
- `x/bank`: используется для создания и передачи токенов.
|
||||
|
||||
- `x/staking` и `x/slashing`: используется для создания блокчейнов Proof-of-Stake.
|
||||
|
||||
В дополнение к уже существующим модулям в `x/`, которые каждый может использовать в своем приложении, SDK позволяет [создавать собственные модули](https://cosmos.network/docs/tutorial/keeper.html).
|
||||
|
||||
|
||||
### Далее, узнайте больше о модели безопасности Cosmos SDK, [ocap](./ocap.md)
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# Блокчейн для конкретного приложения
|
||||
|
||||
В этом разделе описаны особенности блокчейнов для конкретных приложений и почему разработчики могут сделать выбор в пользу них, а не смарт-контрактов.
|
||||
|
||||
## Почему блокчейн для конкретного приложения
|
||||
|
||||
Вместо создания децентрализованного приложения поверх существующего блокчейна, такого как Ethereum, разработчики могут написать собственный блокчейн с нуля, который настроен для работы с одним конкретным приложением. Это предполагает создание полного клиента, легкого клиента, необходимых интерфейсов (CLI, REST...) для взаимодействия с нодами.
|
||||
|
||||
```
|
||||
^ +-------------------------------+ ^
|
||||
| | | | Built with Cosmos SDK
|
||||
| | Конечный автомат = приложение | |
|
||||
| | | v
|
||||
| +-------------------------------+
|
||||
| | | ^
|
||||
Нода блокчейна | | Консенсус | |
|
||||
| | | |
|
||||
| +-------------------------------+ | Tendermint Core
|
||||
| | | |
|
||||
| | Сеть | |
|
||||
| | | |
|
||||
v +-------------------------------+ v
|
||||
```
|
||||
|
||||
## Какие недостатки есть у смарт-контрактов?
|
||||
|
||||
Блокчейны, основанные на виртуальных машинах, такие как Ethereum реализовали потребность в большей программируемости блокчейнов еще в 2014 году. В то время варианты доступные для создания децентрализованных приложений были ограничены. Большинство разработчиков строили свои приложения, используя сложный и ограниченный в возможностях скриптовый язык Биткоина, или же работая над форком исходного кода Биткоина, модифицировать который под свои потребности было сложно.
|
||||
|
||||
Блокчейны, основанные на виртуальных машинах, имели новое ценностное предложение. Их конечный автомат включает в себя виртуальную машину, способную интерпретировать Тьюринг-полные программы, называемые смарт-контрактами. Эти умные контракты хорошо подходили для «одноразовых» программ, таких как ICO, однако плохо для построения сложных децентрализованных платформ:
|
||||
|
||||
- Смарт-контракты обычно разрабатываются с использованием языков программирования, которые интерпретирует виртуальная машина. Эти языки часто действуют в рамках ограничений виртуальной машины. К примеру, виртуальная машина Ethereum (EVM) не позволяет разработчикам реализовать автоматическое исполнение кода. Разработчики также ограничены системой счетов EVM, и ограниченным множеством функций, необходимых для криптографии. Это примеры думонстрируют ограниченную **гибкость** смарт-контрактов.
|
||||
|
||||
- Все смарт-контракты выполняются на одной и той же виртуальной машине. Это означает, что они конкурируют за ресурсы, что существенного ограничивает производительность. Даже если конечный автомат будет разделен на несколько множеств (например, с помощью шардинга), смарт-контракты все равно выполняются на виртуальной машине. Это ведет к низкой производительности в сравнении с нативным приложением, написанным на уровне самого конечного автомата. Наши тесты показывают 10-и кратное увеличение производительности в ситуациях без виртуальной машины.
|
||||
|
||||
- Другая проблема связана с тем, что все смарт-контракты выполняются в одном окружении, что приводит к ограниченному **суверенитету**. Децентрализованное приложение — это экосистема, в которой участвуют несколько игроков. Если приложение построено на виртуальной машины общего блокчейна, эти игроки имеют очень ограниченный суверенитет над ним. Если в приложении есть ошибка, с этим мало что можно сделать.
|
||||
|
||||
Специфичные для приложения блокчейны призваны устранить эти недостатки.
|
||||
|
||||
### Преимущества специфичных блокчейнов
|
||||
|
||||
### Гибкость
|
||||
|
||||
Специфичные блокчейны предоставляют максимальную гибкость для разработчиков.
|
||||
|
||||
- В блокчейнах, построенных на Cosmos, конечный автомат типично соединен с лежащим в основе движком консенсуса через интерфейс ABCI. Этот интерфейс можно использовать из любого языка программирования, это означает, что разработчик может использовать предпочтительный язык для создания своего приложения.
|
||||
|
||||
- ABCI позволяет сменить движок консенсуса для своего блокчейна. На сегодняшний день только Tendermint готов для использования, но в будущем появятся и другие.
|
||||
|
||||
- Разработчики имеют полную свободу действий при выборе количества валидаторов, желаемой производительности, безопасности, DB или IAVL-деревьев для хранения, UTXO...
|
||||
|
||||
- Разработчики могут реализовать автоматическое исполнение кода. В Cosmos SDK код может автоматически запускаться в начале и конце каждого блока. У разработчика также остается выбор криптографической библиотеки, используемой в приложении.
|
||||
|
||||
### Производительность
|
||||
|
||||
Производительность децентрализованных приложений, построенных на основе смарт-контрактов, всегда ограничена окружением, в котором они работают. Построение приложения на своем собственном блокчейне позволяет оптимизировать производительность благодаря следующим преимуществам:
|
||||
|
||||
- Разработчики могут выбрать более современный движок консенсуса, например, Tendermint BFT. В сравнении с Proof-of-Work, используемым в большинстве виртуальных машин блокчейнов, Tendermint позволяет получить высокую пропускную способность.
|
||||
|
||||
- Собственный блокчейн хранит данные одного конкретного приложения, поэтому этому приложению не приходится конкурировать за ресурсы с другими. Это не так на большинстве блокчейнов, в которых смарт-контракты конкурируют за вычислительную мощность и пространство для хранения данных.
|
||||
|
||||
- Даже если виртуальная машина блокчейна дает возможность шардинга и имеет эффективный алгоритм консенсуса, производительность будет ограничена самой виртуальной машиной: необходимость интерпретации транзакций виртуальной машиной существенно увеличивает требуюмую вычислительную мощность для из обработки.
|
||||
|
||||
### Безопасность
|
||||
|
||||
Безопасность сложно охарактеризовать количественно, и степень безопасности системы различается в зависимости от платформы. Тем не менее блокчкейн для конкретного приложения имеет ряд преимуществ:
|
||||
|
||||
- Разработчики могут выбрать надежный и современный язык программирования, такой как, например, Go, для создания блокчейна, а не язык смарт-контрактов.
|
||||
|
||||
- Разработчики не ограничены набором криптографических функций, доступных виртуальной машине. Они могут использовать свои функции и необходимые им библиотеки, которые прошли аудит.
|
||||
|
||||
- Разработчикам не приходится переживать о безопасности самой виртуальной машины, что упрощает работу с безопаностью приложения.
|
||||
|
||||
### Независимость
|
||||
|
||||
Одно из основных преимуществ собственных блокчейнов заключается в их независимости. Децентрализованное приложение — это экосистема, которая включает множество акторов: пользователей, разработчиков, сторонних сервисов и прочих. Когда разработчики опираются на блокчейн виртуальной машины, где сосуществуют многие децентрализованные приложения, сообщество приложений отличается от сообщества блокчейна. Если появляется ошибка или требуется новая функция, сообщество приложения не имеет достаточных прав, чтобы внести измененения в код блокчейна. Если сообщество блокчейна отказывается самостоятельно исправлять ошибки, ничего не может произойти.
|
||||
|
||||
Основная проблема здесь заключается в том, что управление приложением и управление сетью не согласованы. Эта проблема решается с помощью блокчейнов для конкретных приложений. Поскольку специфичные для приложения блокчейны специализируются на работе с одним приложением, сообщество приложения имеет полный контроль над всей системой. Это гарантирует, что действия сообщества не будут заблокированы, если будет обнаружена ошибка, и что оно имеет полную свободу выбора в траектории своего развития.
|
||||
|
||||
## Начните создавать свой блокчейн для конкретного приложения уже сегодня
|
||||
|
||||
Очевидно, что собственные блокчейны имеют массу преимуществ. Cosmos SDK делает их разработку проще как никогда. Создайте свой блокчейн!
|
||||
|
||||
- Узнайте больше об [архитектуре](./ sdk-app-Architecture) приложения, построенного с помощью SDK.
|
||||
|
||||
- Узнайте, как создать блокчейн для конкретного приложения с нуля, с помощью [SDK tutorial](https://cosmos.network/docs/tutorial)
|
||||
|
|
@ -0,0 +1 @@
|
|||
# RU
|
||||
|
|
@ -65,7 +65,7 @@ JSON representation as defined [here](https://github.com/tendermint/tendermint/b
|
|||
|
||||
An example of such a canonical JSON structure is Tendermint's vote structure:
|
||||
|
||||
```golang
|
||||
```go
|
||||
type CanonicalJSONVote struct {
|
||||
ChainID string `json:"@chain_id"`
|
||||
Type string `json:"@type"`
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ The account interface exposes methods to read and write standard account informa
|
|||
Note that all of these methods operate on an account struct confirming to the interface
|
||||
- in order to write the account to the store, the account keeper will need to be used.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type Account interface {
|
||||
GetAddress() AccAddress
|
||||
SetAddress(AccAddress)
|
||||
|
|
@ -43,7 +43,7 @@ type Account interface {
|
|||
A base account is the simplest and most common account type, which just stores all requisite
|
||||
fields directly in a struct.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type BaseAccount struct {
|
||||
Address AccAddress
|
||||
Coins Coins
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ to include in their proposed block transactions which fail `CheckTx`.
|
|||
|
||||
### Ante Handler
|
||||
|
||||
```golang
|
||||
```go
|
||||
anteHandler(ak AccountKeeper, fck FeeCollectionKeeper, tx sdk.Tx)
|
||||
if !tx.(StdTx)
|
||||
fail with "not a StdTx"
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ a struct which implements the `sdk.Tx` interface using `StdFee` and `StdSignatur
|
|||
A `StdFee` is simply the combination of a fee amount, in any number of denominations,
|
||||
and a gas limit (where dividing the amount by the gas limit gives a "gas price").
|
||||
|
||||
```golang
|
||||
```go
|
||||
type StdFee struct {
|
||||
Amount Coins
|
||||
Gas uint64
|
||||
|
|
@ -24,7 +24,7 @@ A `StdSignature` is the combination of an optional public key and a cryptographi
|
|||
as a byte array. The SDK is agnostic to particular key or signature formats and supports any
|
||||
supported by the `PubKey` interface.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type StdSignature struct {
|
||||
PubKey PubKey
|
||||
Signature []byte
|
||||
|
|
@ -36,7 +36,7 @@ type StdSignature struct {
|
|||
A `StdTx` is a struct which implements the `sdk.Tx` interface, and is likely to be generic
|
||||
enough to serve the purposes of many Cosmos SDK blockchains.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type StdTx struct {
|
||||
Msgs []sdk.Msg
|
||||
Fee StdFee
|
||||
|
|
@ -53,7 +53,7 @@ will only be executable once on a particular blockchain.
|
|||
|
||||
`json.RawMessage` is preferred over using the SDK types for future compatibility.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type StdSignDoc struct {
|
||||
AccountNumber uint64
|
||||
ChainID string
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ The auth module only exposes one keeper, the account keeper, which can be used t
|
|||
Presently only one fully-permissioned account keeper is exposed, which has the ability to both read and write
|
||||
all fields of all accounts, and to iterate over all stored accounts.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type AccountKeeper interface {
|
||||
// Return a new account with the next account number and the specified address. Does not save the new account to the store.
|
||||
NewAccountWithAddress(AccAddress) Account
|
||||
|
|
|
|||
|
|
@ -365,30 +365,30 @@ V' = 0
|
|||
```
|
||||
|
||||
1. Immediately receives 1 coin
|
||||
```text
|
||||
```
|
||||
BC = 11
|
||||
```
|
||||
2. Time passes, 2 coins vest
|
||||
```text
|
||||
```
|
||||
V = 8
|
||||
V' = 2
|
||||
```
|
||||
3. Delegates 4 coins to validator A
|
||||
```text
|
||||
```
|
||||
DV = 4
|
||||
BC = 7
|
||||
```
|
||||
4. Sends 3 coins
|
||||
```text
|
||||
```
|
||||
BC = 4
|
||||
```
|
||||
5. More time passes, 2 more coins vest
|
||||
```text
|
||||
```
|
||||
V = 6
|
||||
V' = 4
|
||||
```
|
||||
6. Sends 2 coins. At this point the account cannot send anymore until further coins vest or it receives additional coins. It can still however, delegate.
|
||||
```text
|
||||
```
|
||||
BC = 2
|
||||
```
|
||||
|
||||
|
|
@ -397,28 +397,28 @@ V' = 0
|
|||
Same initial starting conditions as the simple example.
|
||||
|
||||
1. Time passes, 5 coins vest
|
||||
```text
|
||||
```
|
||||
V = 5
|
||||
V' = 5
|
||||
```
|
||||
2. Delegate 5 coins to validator A
|
||||
```text
|
||||
```
|
||||
DV = 5
|
||||
BC = 5
|
||||
```
|
||||
3. Delegate 5 coins to validator B
|
||||
```text
|
||||
```
|
||||
DF = 5
|
||||
BC = 0
|
||||
```
|
||||
4. Validator A gets slashed by 50%, making the delegation to A now worth 2.5 coins
|
||||
5. Undelegate from validator A (2.5 coins)
|
||||
```text
|
||||
```
|
||||
DF = 5 - 2.5 = 2.5
|
||||
BC = 0 + 2.5 = 2.5
|
||||
```
|
||||
6. Undelegate from validator B (5 coins). The account at this point can only send 2.5 coins unless it receives more coins or until more coins vest. It can still however, delegate.
|
||||
```text
|
||||
```
|
||||
DV = 5 - 2.5 = 2.5
|
||||
DF = 2.5 - 2.5 = 0
|
||||
BC = 2.5 + 5 = 7.5
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Note that you should always review the `bank` module code to ensure that permiss
|
|||
|
||||
An input of a multiparty transfer
|
||||
|
||||
```golang
|
||||
```go
|
||||
type Input struct {
|
||||
Address AccAddress
|
||||
Coins Coins
|
||||
|
|
@ -21,7 +21,7 @@ type Input struct {
|
|||
|
||||
An output of a multiparty transfer.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type Output struct {
|
||||
Address AccAddress
|
||||
Coins Coins
|
||||
|
|
@ -32,7 +32,7 @@ type Output struct {
|
|||
|
||||
The base keeper provides full-permission access: the ability to arbitrary modify any account's balance and mint or burn coins.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type BaseKeeper interface {
|
||||
SetCoins(addr AccAddress, amt Coins)
|
||||
SubtractCoins(addr AccAddress, amt Coins)
|
||||
|
|
@ -86,7 +86,7 @@ inputOutputCoins(inputs []Input, outputs []Output)
|
|||
|
||||
The send keeper provides access to account balances and the ability to transfer coins between accounts, but not to alter the total supply (mint or burn coins).
|
||||
|
||||
```golang
|
||||
```go
|
||||
type SendKeeper interface {
|
||||
SendCoins(from AccAddress, to AccAddress, amt Coins)
|
||||
}
|
||||
|
|
@ -104,7 +104,7 @@ sendCoins(from AccAddress, to AccAddress, amt Coins)
|
|||
|
||||
The view keeper provides read-only access to account balances but no balance alteration functionality. All balance lookups are `O(1)`.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type ViewKeeper interface {
|
||||
GetCoins(addr AccAddress) Coins
|
||||
HasCoins(addr AccAddress, amt Coins) bool
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## MsgSend
|
||||
|
||||
```golang
|
||||
```go
|
||||
type MsgSend struct {
|
||||
Inputs []Input
|
||||
Outputs []Output
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ corresponding updates to the state.
|
|||
|
||||
Blockchain invariants can be checked using the `MsgVerifyInvariant` message.
|
||||
|
||||
```golang
|
||||
```go
|
||||
type MsgVerifyInvariant struct {
|
||||
Sender sdk.AccAddress
|
||||
InvariantRoute string
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ When coins are distributed from the pool they are truncated back to
|
|||
|
||||
- FeePool: `0x00 -> amino(FeePool)`
|
||||
|
||||
```golang
|
||||
```go
|
||||
// coins with decimal
|
||||
type DecCoins []DecCoin
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ Validator distribution information for the relevant validator is updated each ti
|
|||
|
||||
- ValidatorDistInfo: `0x02 | ValOperatorAddr -> amino(validatorDistribution)`
|
||||
|
||||
```golang
|
||||
```go
|
||||
type ValidatorDistInfo struct {
|
||||
FeePoolWithdrawalHeight int64 // last height this validator withdrew from the global fee pool
|
||||
Pool DecCoins // rewards owed to delegators, commission has already been charged (includes proposer reward)
|
||||
|
|
@ -62,7 +62,7 @@ only the height of the last withdrawal and its current properties.
|
|||
|
||||
- DelegationDistInfo: `0x02 | DelegatorAddr | ValOperatorAddr -> amino(delegatorDist)`
|
||||
|
||||
```golang
|
||||
```go
|
||||
type DelegationDistInfo struct {
|
||||
WithdrawalHeight int64 // last time this delegation withdrew rewards
|
||||
}
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
updated-docs
|
||||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue