Merge PR #4787: Updated docs build process
This commit is contained in:
mircea-c
committed by
Alexander Bezobchuk
Alexander Bezobchuk
parent
d3aa9feaca
commit
450c8ced2c
@@ -0,0 +1,36 @@
|
||||
# Cosmos SDK 文档
|
||||
|
||||
## 开始
|
||||
|
||||
- **[SDK 介绍](./intro/README.md)**：从“高层”了解Cosmos SDK.
|
||||
- **[SDK 开发教程](https://github.com/cosmos/sdk-application-tutorial)**: 一个学习 SDK 的教程。它展示了如何从头开始基于 sdk 构建区块链, 并在此过程中解释了 SDK 的基本原理。
|
||||
|
||||
|
||||
## 开发资源
|
||||
|
||||
- [规范](./spec/README.md): Cosmos SDK 的模块及其他规范。
|
||||
- [SDK API 参考](https://godoc.org/github.com/cosmos/cosmos-sdk): Cosmos SDK Godocs 文档 。
|
||||
- [REST API 规范](https://cosmos.network/rpc/): 通过 REST 与 `gaia` 全节点交互的 API 列表。
|
||||
|
||||
## 创建新的 SDK 项目
|
||||
|
||||
若要创建新项目, 以下两个方法任选其一:
|
||||
|
||||
- 克隆这个 [教程](https://github.com/cosmos/sdk-application-tutorial/)，如果不需要, 请不要忘记从各种文件中删除 `nameservice` 模块。
|
||||
- 使用社区工具, 如 [chainkit](https://github.com/blocklayerhq/chainkit).
|
||||
|
||||
## Cosmos Hub
|
||||
|
||||
Cosmos Hub (名为 `gaia`) 文档已经迁移到[这里](https://github.com/cosmos/gaia/tree/master/docs).
|
||||
|
||||
## 开发语言
|
||||
|
||||
Cosmos-SDK 目前是用 [Golang](https://golang.org/)编写的, 尽管该框架同样可以在其他语言中实现。请联系我们获取有关资助其他语言实现的信息。
|
||||
|
||||
## 贡献
|
||||
|
||||
参考 [文档说明](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md) 了解构建细节及更新时注意事项。
|
||||
|
||||
## 版本
|
||||
|
||||
这份文档通过以下提交构建:
|
||||
@@ -0,0 +1,19 @@
|
||||
# 客户端
|
||||
|
||||
本节说明包含区块链 SDK 的客户端的信息。
|
||||
|
||||
> *注*：此部分仍在开发中。
|
||||
|
||||
##轻客户端
|
||||
|
||||
轻客户端使用户能够与您的应用程序进行交互，且无需下载整个状态历史记录，但具有良好的安全性。
|
||||
|
||||
- [轻客户端概述](./lite/README.md)
|
||||
- [启动轻客户端服务器](./lite/getting_started.md)
|
||||
- [轻客户端规范](./lite/specification.md)
|
||||
|
||||
##其他客户端
|
||||
|
||||
- [区块链 SDK 的 CLI](./cli.md)
|
||||
- [服务提供商文档](./service-providers.md)
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
# CLI
|
||||
|
||||
> TODO: Rewrite this section to explain how CLI works for a generic SDK app.
|
||||
|
||||
@@ -0,0 +1,60 @@
|
||||
# 轻客户端概览
|
||||
|
||||
**点击[这里](https://cosmos.network/rpc/)查看Cosmos SDK 轻客户端 RPC 文档**
|
||||
|
||||
## 简介
|
||||
|
||||
轻客户端允许客户端（例如移动电话）从任何全节点接收区块链状态的证明。 轻客户端不必信任任何全节点，因为他们能够验证他们收到的任何证明，因此全节点不能对网络状态撒谎。
|
||||
|
||||
轻客户端可以用最低的带宽、计算和存储资源提供与全节点相同的安全性。 同时，它还可以根据用户的配置提供模块化功能。 这些出色的功能允许开发人员构建完全安全、高效且可用的移动应用、网站或任何其他应用程序，而无需部署或维护任何完整的区块链节点。
|
||||
|
||||
### 什么是轻节点
|
||||
|
||||
Cosmos SDK 轻节点（Gaia-lite）分为两个独立的组件。 第一个组件对于任何基于 Tendermint 的应用程序都是通用的，它处理区块头相关的安全性和连接性，并验证来自全节点的证明与本地可信验证人集合的对比。 此外，它暴露与任何Tendermint 核心节点完全相同的API。 第二个组件专用于 Cosmos Hub（`gaiad`），它作为查询端点工作，并公开特定于应用程序的功能，这些功能可以是任意的。 针对应用程序状态的所有查询都必须通过查询端点。 查询端点的优点是它可以验证应用程序返回的证据。
|
||||
|
||||
### 高层体系结构
|
||||
|
||||
想要为 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 提供稳定性保证的软件。
|
||||
|
||||
### 对比
|
||||
|
||||
ABCI 的全节点与其轻客户端的区别在于以下方面：
|
||||
|
||||
| | Full Node | 轻客户端 | Description |
|
||||
| ------------------------------- | --------------- | ------------- | ------------------------------------------------------------ |
|
||||
| 执行并验证交易 | Yes | No | 全节点将执行并验证所有交易，而Gaia-lite则不会 |
|
||||
| 验证和存储区块 | Yes | No | 全节点将验证并保存所有块，而Gaia-lite则不会 |
|
||||
| 参与共识 | Yes | No | 只有当全节点是验证人时，它才会参与共识。 Lite节点永远不会参与共识。 |
|
||||
| 带宽开销 | 巨大 | 很小 | 全节点将接收所有块。 如果带宽有限，它将落后于主网络。 更重要的是，如果碰巧是验证人，它将减缓共识过程。 轻客户端需要很少的带宽， 只有在提供本地请求时，才会占用带宽。 |
|
||||
| 计算资源 | 巨大 | 很小 | 全节点将执行所有交易并验证所有块，这需要大量的计算资源 |
|
||||
| 存储资源 | 巨大 | 很小 | 全节点将保存所有块和 ABCI 状态，而Gaia-lite只保存验证人集合和一些检查点。 |
|
||||
| 电力资源 | 巨大 | 很小 | 全节点必须在具有高性能并能一直运行的机器上部署，因此功耗将是巨大的。 Gaia-lite可以部署在与用户应用程序相同的机器上，也可以部署在独立但性能较差的机器上。 此外，Lite客户端可以在必要时随时关闭。所以Gaia-lite只消耗很少的功率，即使移动设备也能满足功率需求。 |
|
||||
| 提供的 APIs | 所有cosmos APIs | 部分模块 APIs | 全节点支持所有cosmos API。 Gaia-lite 根据用户的配置提供模块化API。 |
|
||||
| 安全等级 | 高 | 高 | 全节点将自行验证所有交易和块。 轻型客户端无法执行此操作，但它可以查询来自其他全节点的任何数据并独立验证数据。 因此，全节点和轻型客户端都不需要信任任何第三方节点，它们都可以实现高安全性。 |
|
||||
|
||||
根据上表，Gaia-lite 可以满足所有用户的功能和安全需求，但只需要很少的带宽、计算、存储和电力资源。
|
||||
|
||||
## 安全实现
|
||||
|
||||
### 可信验证人集合
|
||||
|
||||
Gaia-lite的基本设计理念遵循两个规则：
|
||||
|
||||
1. **不信任任何区块链节点，包括验证人节点和其他全节点**
|
||||
2. **只信任整个验证人集合**
|
||||
|
||||
原始的可信验证人集应该预先放置到其信任库中，通常这个验证人集来自 genesis 文件。 在运行时期间，如果 Gaia-lite 检测到不同的验证人集，它将验证它并将可信的验证人集保存到信任库中。
|
||||
|
||||
|
||||
|
||||
### 信任传播
|
||||
|
||||
从上面的小节中，我们了解了如何获得可信验证器集以及 LCD 如何跟踪验证人集演化。 验证人集是信任的基础，信任可以传播到其他区块链数据，例如块和交易。 传播架构如下所示：
|
||||
|
||||
|
||||
|
||||
通常，通过可信验证人集，轻客户端可以验证包含所有预提交数据和块头数据的每个提交块。 此时块哈希、数据哈希和应用哈希是可信的。 基于此和默克尔证明，所有交易数据和 ABCI 状态也可以被验证。
|
||||
@@ -0,0 +1,23 @@
|
||||
# 入门
|
||||
|
||||
要启动 REST 服务器，我们需要指定以下参数：
|
||||
|
||||
| 参数 | 类型 | 默认值 | 必填 | 描述 |
|
||||
| ----------- | --------- | ----------------------- | ----- | ---------------------------- |
|
||||
| chain-id | string | null | true | 要链接全节点的 chain id |
|
||||
| node | URL | "tcp://localhost:46657" | true | 要链接全节点的地址和端口号 |
|
||||
| laddr | URL | "tcp://localhost:1317" | true | 提供 REST 服务的地址和端口号 |
|
||||
| trust-node | bool | "false" | true | 是否信任 LCD 连接的全节点 |
|
||||
| trust-store | DIRECTORY | "$HOME/.lcd" | false | 保存检查点和验证人集的目录 |
|
||||
|
||||
示例：
|
||||
|
||||
```bash
|
||||
gaiacli rest-server --chain-id=test \
|
||||
--laddr=tcp://localhost:1317 \
|
||||
--node tcp://localhost:26657 \
|
||||
--trust-node=false
|
||||
```
|
||||
|
||||
有关Gaia-Lite RPC的更多信息，请参阅 [swagger documentation](https://cosmos.network/rpc/)
|
||||
|
||||
@@ -0,0 +1,183 @@
|
||||
# 规范
|
||||
|
||||
该规范描述了如何实现 LCD。 LCD 支持模块化 API。 目前，仅支持ICS0（TendermintAPI），ICS1（密钥API）和ICS20（Key API）。 如有必要，后续可以包含更多API。
|
||||
|
||||
## 构建并验证 ABCI 状态的证明
|
||||
|
||||
众所周知，基于 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 的证明。 证据包含两部分：
|
||||
|
||||
* IAVL 证明
|
||||
* 子库到 AppHash 的证明
|
||||
|
||||
### IAVL 证明
|
||||
|
||||
证明有两种类型：存在证明和缺席证明。 如果查询密钥存在于 IAVL 存储中，则它返回键值及其存在证明。 另一方面，如果密钥不存在，那么它只返回缺席证明，这可以证明密钥肯定不存在。
|
||||
|
||||
### IAVL 存在证明
|
||||
|
||||
```go
|
||||
type CommitID struct {
|
||||
Version int64
|
||||
Hash []byte
|
||||
}
|
||||
|
||||
type storeCore struct {
|
||||
CommitID CommitID
|
||||
}
|
||||
|
||||
type MultiStoreCommitID struct {
|
||||
Name string
|
||||
Core storeCore
|
||||
}
|
||||
|
||||
type proofInnerNode struct {
|
||||
Height int8
|
||||
Size int64
|
||||
Version int64
|
||||
Left []byte
|
||||
Right []byte
|
||||
}
|
||||
|
||||
type KeyExistsProof struct {
|
||||
MultiStoreCommitInfo []MultiStoreCommitID // 所有子库提交id
|
||||
StoreName string // 当前子库名字
|
||||
Height int64 // 当前子库提交高度
|
||||
RootHash cmn.HexBytes // 此 IAVL 树的根哈希
|
||||
Version int64 // 此 IAVL 树中 key-value 的版本号
|
||||
InnerNodes []proofInnerNode // 从根节点到 key-value 叶子节点的路径
|
||||
}
|
||||
```
|
||||
|
||||
存在证据的数据结构如上所示。 构建和验证存在证明的过程如下所示：
|
||||
|
||||
|
||||
|
||||
构建证明的步骤：
|
||||
|
||||
* 从根节点访问IAVL树
|
||||
* 记录 InnerNodes 中的访问节点
|
||||
* 找到目标叶节点后，将叶节点版本赋值给证明版本
|
||||
* 将当前 IAVL 树高赋值给证明高度
|
||||
* 将当前 IAVL 树根哈希赋值给证明根哈希
|
||||
* 将当前的子目录名称赋值给证明 StoreName
|
||||
* 从 multistore 读取指定高度的 commitInfo 并将其赋值给证明 StoreCommitInfo
|
||||
|
||||
验证证明的步骤：
|
||||
|
||||
* 使用证明版本中的键、值构建叶节点
|
||||
* 计算叶节点哈希
|
||||
* 将哈希值分配给第一个 innerNode 的 rightHash，然后计算第一个 innerNode 哈希值
|
||||
* 传播哈希计算过程。 如果先前的 innerNode 是下一个 innerNode 的左子节点，则将先前的 innerNode 散列分配给下一个 innerNode 的左散列。否则，将先前的 innerNode 散列分配给下一个innerNode的右散列
|
||||
* 最后 innerNode 的哈希应该等于此证明的根哈希， 否则证明无效。
|
||||
|
||||
### IAVL 缺席证明
|
||||
|
||||
众所周知，所有 IAVL 叶节点都按每个叶节点的密钥排序。 因此，我们可以在 IAVL 树的整个密钥集中计算出目标密钥的位置。 如下图所示，我们可以找到左键和右键。 如果我们可以证明左键和右键肯定存在，并且它们是相邻的节点，那么目标密钥肯定不存在。
|
||||
|
||||
|
||||
|
||||
如果目标密钥大于最右边的叶节点或小于最左边的叶子节点，则目标密钥肯定不存在。
|
||||
|
||||
|
||||
|
||||
```go
|
||||
type proofLeafNode struct {
|
||||
KeyBytes cmn.HexBytes
|
||||
ValueBytes cmn.HexBytes
|
||||
Version int64
|
||||
}
|
||||
|
||||
type pathWithNode struct {
|
||||
InnerNodes []proofInnerNode
|
||||
Node proofLeafNode
|
||||
}
|
||||
|
||||
type KeyAbsentProof struct {
|
||||
MultiStoreCommitInfo []MultiStoreCommitID
|
||||
StoreName string
|
||||
Height int64
|
||||
RootHash cmn.HexBytes
|
||||
Left *pathWithNode // Proof the left key exist
|
||||
Right *pathWithNode //Proof the right key exist
|
||||
}
|
||||
```
|
||||
|
||||
以上是缺席证明的数据结构。 构建证据的步骤：
|
||||
|
||||
* 从根节点访问IAVL树
|
||||
* 获取整个密钥集中密钥的对应索引（标记为INDEX）
|
||||
* 如果返回的索引等于0，则右索引应为0，且左节点不存在
|
||||
* 如果返回的索引等于整个密钥集的大小，则左节点索引应为INDEX-1，且右节点不存在
|
||||
* 否则，右节点索引应为INDEX，左节点索引应为INDEX-1
|
||||
* 将当前 IAVL 树高赋值给证明高度
|
||||
* 将当前 IAVL 树根哈希赋值给证明根哈希
|
||||
* 将当前的子目录名称赋值给证明 StoreName
|
||||
* 从 multistore 读取指定高度的 commitInfo 并将其赋值给证明 StoreCommitInfo
|
||||
|
||||
验证证明的步骤：
|
||||
|
||||
* 如果只存在右节点，请验证其存在的证明，并验证它是否是最左侧的节点
|
||||
* 如果仅存在左节点，请验证其存在的证据，并验证它是否是最右侧的节点
|
||||
* 如果右节点和左节点都存在，请验证它们是否相邻
|
||||
|
||||
### Substores 到 AppHash 的证明
|
||||
|
||||
在验证了 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 {
|
||||
var hasher = ripemd160.New()
|
||||
|
||||
err := encodeByteSlice(hasher, left)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
|
||||
err = encodeByteSlice(hasher, right)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
|
||||
return hasher.Sum(nil)
|
||||
}
|
||||
|
||||
func SimpleHashFromHashes(hashes [][]byte) []byte {
|
||||
// Recursive impl.
|
||||
switch len(hashes) {
|
||||
case 0:
|
||||
return nil
|
||||
case 1:
|
||||
return hashes[0]
|
||||
default:
|
||||
left := SimpleHashFromHashes(hashes[:(len(hashes)+1)/2])
|
||||
right := SimpleHashFromHashes(hashes[(len(hashes)+1)/2:])
|
||||
return SimpleHashFromTwoHashes(left, right)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 根据验证人集验证区块头
|
||||
|
||||
上面的小节中经常提到 appHash，但可信的appHash来自哪里？ 实际上，appHash 存在于区块头中，因此接下来我们需要针对 LCD 可信验证人集验证特定高度的区块头。 验证流程如下所示：
|
||||
|
||||
|
||||
|
||||
当可信验证人集与区块头不匹配时，我们需要尝试将验证人集更新为此块的高度。 LCD 有一条规则，即每个验证人集的变化不应超过1/3投票权。 如果目标验证人集的投票权变化超过1/3，则与可信验证人集进行比较。 我们必须验证，在目标验证人集之前是否存在隐含的验证人集变更。 只有当所有验证人集变更都遵循这条规则时，才能完成验证人集的更新。
|
||||
|
||||
例如：
|
||||
|
||||
|
||||
|
||||
* 更新到 10000，失败，变更太大
|
||||
* 更新到 5050，失败，变更太大
|
||||
* 更新至 2575，成功
|
||||
* 更新至 5050，成功
|
||||
* 更新到 10000，失败，变更太大
|
||||
* 更新至 7525，成功
|
||||
* 更新至 10000，成功
|
||||
@@ -0,0 +1,177 @@
|
||||
# 服务提供商（Service Providers）
|
||||
|
||||
我们将“服务提供商”定义为可以为最终用户提供服务的实体，这些实体涉及与基于 Cosmos-SDK 的区块链（包括Cosmos Hub）的某种形式的交互。更具体地说，本文档将集中于与 token 的交互。
|
||||
|
||||
本节不涉及想要提供[轻客户端](https://github.com/cosmos/cosmos-sdk/tree/master/docs/interfaces/lite)功能的钱包开发者。服务提供商将作为最终用户的区块链的可信接入点。
|
||||
|
||||
## 架构的高级描述
|
||||
|
||||
有三个主要部分需要考虑：
|
||||
|
||||
- 全节点：与区块链交互。
|
||||
- Rest Server：它充当 HTTP 调用的中继者。
|
||||
- Rest API：为 Rest Server 定义可用端点。
|
||||
|
||||
##运行全节点
|
||||
|
||||
###安装和配置
|
||||
|
||||
我们将描述为 Cosmos Hub 运行和交互全节点的步骤。对于其他基于 SDK 的区块链，该过程是类似的。
|
||||
|
||||
首先，您需要[安装软件](../cosmos-hub/installation.md).
|
||||
|
||||
然后，您可以开始[运行全节点](../cosmos-hub/join-testnet.md).
|
||||
|
||||
### 命令行界面（CLI）
|
||||
|
||||
接下来，您将用一些 CLI 命令与全节点交互。
|
||||
|
||||
#### 创建秘钥对
|
||||
|
||||
生成新秘钥（默认使用 secp256k1椭圆曲线算法）：
|
||||
|
||||
```bash
|
||||
gaiacli keys add <your_key_name>
|
||||
```
|
||||
|
||||
系统将要求您为此密钥对输入密码（至少8个字符）。该命令返回4个信息：
|
||||
|
||||
- `NAME`: 秘钥名称。
|
||||
- `TYPE`：秘钥类型，总是`local`。
|
||||
- `ADDRESS`：您的地址，用于接收资金。
|
||||
- `PUBKEY`：您的公钥 Your public key. Useful for validators.
|
||||
- `MNEMONIC`： 由24个单词组成的助记词。 **将这个助记词保存在安全的地方**，它用于在您忘记密码时恢复您的私钥。
|
||||
|
||||
您可以输入以下命令查看所有可用密钥：
|
||||
|
||||
```bash
|
||||
gaiacli keys list
|
||||
```
|
||||
|
||||
#### 检查您的余额
|
||||
|
||||
收到代币到您的地址后，您可以输入以下命令查看帐户的余额：
|
||||
|
||||
```bash
|
||||
gaiacli account <YOUR_ADDRESS>
|
||||
```
|
||||
|
||||
*注意：当您查询没有 token 帐户的余额时，您将得到以下错误：找不到地址为<YOUR_ADDRESS>的帐户。这是预料之中的！我们正在努力改进我们的错误提示信息。*
|
||||
|
||||
#### 通过 CLI 发送代币
|
||||
|
||||
以下是通过 CLI 发送代币的命令：
|
||||
|
||||
```bash
|
||||
gaiacli tx send <from_key_or_address> <to_address> <amount> \
|
||||
--chain-id=<name_of_testnet_chain>
|
||||
```
|
||||
|
||||
参数：
|
||||
- `<from_key_or_address>`: 发送账户的名称或地址。
|
||||
- `<to_address>`: 接收者地址。
|
||||
- `<amount>`: 接受`<value|coinName>`格式的参数，例如 `10faucetToken`。
|
||||
|
||||
标识：
|
||||
|
||||
- `--chain-id`: 此标志允许您指定链的ID，不同的testnet链和主链会有不同的 id。
|
||||
|
||||
#### 帮助
|
||||
|
||||
如果您需要进行其他操作，最合适的命令是：
|
||||
|
||||
```bash
|
||||
gaiacli
|
||||
```
|
||||
|
||||
它将显示所有可用命令。对于每个命令，您可以使用`--help`标识来获取更多信息。
|
||||
|
||||
## 设置 Rest 服务器
|
||||
|
||||
Rest 服务器充当前端点和全节点之间的媒介。 Rest 服务器不必与全节点同一台计算机上运行。
|
||||
|
||||
要启动 Rest 服务器：
|
||||
|
||||
```bash
|
||||
gaiacli rest-server --node=<full_node_address:full_node_port>
|
||||
```
|
||||
|
||||
Flags:
|
||||
- `--trust-node`: 布尔类型。如果为`true`，轻节点校验将被禁用。如果为`false`, 则会校验返回结果。 对于服务提供商，应将其设置为`true`。默认情况下，它设置为`true`。
|
||||
- `--node`: 全节点的IP地址和端口。格式为` <full_node_address:full_node_port>`。如果全节点在同一台机器上，则地址应为`tcp：// localhost：26657`。
|
||||
- `--laddr`: 此标识允许您指定 Rest 服务器的地址和端口（默认为“1317”）。通常只使用这个标识指定端口，此时只需输入“localhost”作为地址，格式为`<rest_server_address:port>`。
|
||||
|
||||
|
||||
### 监听入向交易
|
||||
|
||||
监听入向交易推荐的方法是通过 LCD 的以下端点定期查询区块链：
|
||||
|
||||
<!-- [`/bank/balance/{address}`](https://cosmos.network/rpc/#/ICS20/get_bank_balances__address_) -->
|
||||
|
||||
## Rest API
|
||||
|
||||
Rest API 记录了可用于与全节点交互的所有可用端点，您可以在[这里](https://cosmos.network/rpc/)查看。
|
||||
|
||||
API 针对每种类别的端点归纳为 ICS 标准。例如，[ICS20](https://cosmos.network/rpc/#/ICS20/)描述了API 与 token 的交互。
|
||||
|
||||
为了给开发者提供更大的灵活性，我们提供了生成未签名交易、[签名](https://cosmos.network/rpc/#/ICS20/post_tx_sign)和[广播](https://cosmos.network/rpc/#/ICS20/post_tx_broadcast)等不同的 API 端点。这允许服务提供商使用他们自己的签名机制。
|
||||
|
||||
为了生成一个未签名交易（例如 [coin transfer](https://cosmos.network/rpc/#/ICS20/post_bank_accounts__address__transfers)），你需要在`base_req`的主体中使用`generate_only`字段。
|
||||
|
||||
## Cosmos SDK 交易签名
|
||||
|
||||
Cosmos SDK 签名是一个相当简单的过程。
|
||||
|
||||
每个 Cosmos SDK 交易都有一个规范的 JSON 描述。 `gaiacli`和 REST 接口为交易提供规范的 JSON 描述，“广播”功能将提供紧凑的 Amino（类似 protobuf 的格式）编码转换。
|
||||
|
||||
签名消息时的注意事项：
|
||||
|
||||
格式如下
|
||||
|
||||
```json
|
||||
{
|
||||
"account_number": XXX,
|
||||
"chain_id": XXX,
|
||||
"fee": XXX,
|
||||
"sequence": XXX,
|
||||
"memo": XXX,
|
||||
"msgs": XXX
|
||||
}
|
||||
```
|
||||
|
||||
签名者必须提供 `"chain_id"`、 `"account number"` 和 `"sequence number"`。
|
||||
|
||||
交易构造接口将生成 `"fee"`、 `"msgs"` 和 `"memo"` 等字段.
|
||||
|
||||
You can load the mempool of a full node or validator with a sequence of uncommitted transactions with incrementing
|
||||
sequence numbers and it will mostly do the correct thing.
|
||||
|
||||
`"account_number"` 和 `"sequence"` 字段可以直接从区块链或本地缓存中查询。 错误的获取了这些数值和chainId，是产生无效签名错误的常见原因。您可以通过加载全节点或验证人中的 mempool 来获取未提交交易的自增序号，这样大大增加成功概率。
|
||||
|
||||
您可以使用递增序列号的一系列未提交事务加载完整节点或验证器的mempool，它将主要执行正确的操作。
|
||||
|
||||
在签名之前，所有键都要按字典顺序排序，并从 JSON 输出中删除所有空格。
|
||||
|
||||
签名编码是 ECDSArands 的 64字节连结（即`r || s`），其中`s`按字典顺序小于其反转以防止延展性。 这就像以太坊一样，但没有用户公钥恢复的额外字节，因为 Tendermint 假定公钥一定会提供。
|
||||
|
||||
已签名交易中的签名和公钥示例:
|
||||
|
||||
``` json
|
||||
{
|
||||
"type": "auth/StdTx",
|
||||
"value": {
|
||||
"msg": [...],
|
||||
"signatures": [
|
||||
{
|
||||
"pub_key": {
|
||||
"type": "tendermint/PubKeySecp256k1",
|
||||
"value": XXX
|
||||
},
|
||||
"signature": XXX
|
||||
}
|
||||
],
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
正确生成签名后，将 JSON 插入生成的交易中，然后调用广播端点进行广播。
|
||||
@@ -0,0 +1,46 @@
|
||||
# Cosmos SDK Documentation Translation (Chinese)
|
||||
|
||||
This document tracks the progress of the Chinese translation of the official Cosmos SDK documentation.
|
||||
|
||||
Documentation has been translated for **reference use only** and may contain typos, factual errors and be out-of-date with the latest english documentation.
|
||||
|
||||
Please refer to the official english version of the documentation for the latest and accurate information.
|
||||
|
||||
## Cosmos SDK文档翻译
|
||||
|
||||
本文档跟踪官方 Cosmos SDK 文档的中文翻译进度。
|
||||
|
||||
已翻译的文件**仅供参考**，可能包含拼写错误、翻译不准确，并且可能慢于英文版更新。
|
||||
|
||||
有关最新和准确的信息，请参阅文档的官方英文版。
|
||||
|
||||
## Progress by directory
|
||||
|
||||
### README.md
|
||||
|
||||
- Synced until commit [1c326ea5](https://github.com/cosmos/cosmos-sdk/commit/1c326ea524eade1da8771cd7e4343012203a166f) (2019-05-27)
|
||||
|
||||
### [`concepts`](../concepts/)
|
||||
|
||||
- ToDo
|
||||
|
||||
### [`spec`](../spec/)
|
||||
|
||||
- ToDo
|
||||
|
||||
### [`cosmos-hub`](../cosmos-hub/)
|
||||
|
||||
- Synced until commit [7558f760](https://github.com/cosmos/cosmos-sdk/commit/7558f7607918b6337a8b58b8f956d6776f503138) (2019-05-13)
|
||||
|
||||
### [`intro`](../intro/)
|
||||
|
||||
- Synced until commit [1c326ea5](https://github.com/cosmos/cosmos-sdk/commit/1c326ea524eade1da8771cd7e4343012203a166f) (2019-05-27)
|
||||
|
||||
### [`modules`](../modules/)
|
||||
|
||||
- ToDo
|
||||
|
||||
### [`clients`](../clients/)
|
||||
|
||||
- Synced until Commit [7558f760](https://github.com/cosmos/cosmos-sdk/commit/7558f7607918b6337a8b58b8f956d6776f503138) (2019-05-13)
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
# SDK介绍
|
||||
|
||||
## 什么是Cosmos SDK?
|
||||
|
||||
[Cosmos-SDK](https://github.com/cosmos/cosmos-sdk) 是一个架构，用于构建多资产股权证明(PoS)的区块链，比如Cosmos Hub，以及权益证明(PoA)的区块链。使用Cosmos SDK构建的区块链通常称为**特定应用区块链**。
|
||||
|
||||
Cosmos SDK的目标是允许开发者从头开始轻松创建原生就能同其他区块链相互操作的自定义区块链。我们设想SDK类似于Ruby-on-Rails框架之上构建应用一样，可以很方便在[Tendermint](https://github.com/tendermint/tendermint)之上构建安全的区块链应用。 基于SDK的区块链通过可组合的模块构建出来的，大部分模块是开源的，并且可供任何开发人员使用。 任何人都可以为Cosmos-SDK 创建一个模块，集成已经构建的模块就像将它们导入到区块链应用程序一样简单。 更重要的是，Cosmos SDK是一个基于**能力**（capabilities）的系统，开发人员可以更好地了解模块之间交互的安全性。 要深入了解能力，请跳到[OCAP](./ocap.md)。
|
||||
|
||||
## 什么是特定应用区块链?
|
||||
|
||||
|
||||
今天区块链的一个发展模式是像以太坊这样的虚拟机区块链，开发通常围绕着在现有区块链之上通过智能合约构建一个去中心化的应用程序。 虽然智能合约对于像单用途应用程序（如ICO）这样的一些场景非常有用，但对于构建复杂的去中心化平台往往是不够的。 更一般地说，智能合约在灵活性、主权和性能方面受到限制。
|
||||
|
||||
特定应用区块链提供了与虚拟机区块链截然不同的开发模式。 特定应用区块链是一个定制的区块链来服务单个应用程序：开发人员可以自由地做出应用程序运行最佳所需的设计决策。 它们还可以提供更好的主权、安全和性能。
|
||||
|
||||
要了解有关特定应用区块链的更多信息，可参考[这里](./why-app-specific.md)。
|
||||
|
||||
## 为什么是 Cosmos SDK?
|
||||
|
||||
Cosmos SDK 是目前用于构建自定义的特定应用区块链的最先进的框架。 以下是一些你可能需要考虑使用 Cosmos SDK 构建去中心化应用的原因：
|
||||
|
||||
* SDK中默认共识引擎是 [Tendermint Core](https://github.com/tendermint/tendermint) 。 Tendermint 是已存在的最成熟（也是唯一的）的BFT共识引擎。 它被广泛应用于行业，被认为是建立股权证明系统（POS）的黄金标准共识引擎。
|
||||
* SDK是开源的，旨在使其易于从可组合模块中构建区块链。 随着开源SDK模块生态系统的发展，使用它构建复杂的去中心化平台将变得越来越容易。
|
||||
* SDK 受基于能力的安全性启发，及多年来解决区块链状态机的经验。 这使得 Cosmos SDK 成为构建区块链的非常安全的环境。
|
||||
* 最重要的是，Cosmos SDK已经被许多特定应用区块链产品所使用。 如：[Cosmos Hub](https://hub.cosmos.network), [Iris](https://irisnet.org), [Binance Chain](https://docs.binance.org/), [Terra](https://terra.money/) or [Lino](https://lino.network/) ，除此之外还有很多建立在Cosmos SDK的项目。 你可以在这里查看[生态系统](https://cosmos.network/ecosystem)。
|
||||
|
||||
|
||||
## 开始使用 Cosmos SDK
|
||||
|
||||
* 了解[SDK 应用体系架构](./sdk-app-architecture.md)的详细信息
|
||||
* 了解如何从头构建特定应用区块链，参考[SDK教程](/docs/tutorial) 。
|
||||
@@ -0,0 +1,64 @@
|
||||
# 对象能力模型（Object-Capability Model）
|
||||
|
||||
## 介绍
|
||||
|
||||
在考虑安全性时，最好从特定的威胁模型开始。我们的威胁模型如下:
|
||||
|
||||
> 我们假设蓬勃发展的 Cosmos-SDK 模块生态中会包含错误或恶意的模块。
|
||||
|
||||
Cosmos SDK旨在通过以对象能力系统作为基础来解决此威胁。
|
||||
|
||||
> 对象能力系统的结构特性有利于代码设计模块化，并确保代码实现的可靠封装。
|
||||
>
|
||||
> 这些结构上的特性便于分析一个对象能力程序或操作系统的某些安全属性。其中一些 - 特别是信息流属性 - 可以在对象引用和连接级别进行分析，而不需要依赖于了解或分析（决定对象行为的）代码。
|
||||
>
|
||||
> 因此，可以在存在包含未知或（可能）恶意代码的新对象的情况下建立和维护这些安全属性。
|
||||
>
|
||||
> 这些结构属性源于管理对已存在对象的访问的两个规则：
|
||||
> 1. 只有在对象A持有对象B的引用，A才可以向B发送一条消息，。
|
||||
> 2. 只有对象A收到了一条包含对象C引用的消息，A才可以获得C的引用。
|
||||
> 根据这两条规则，一个对象只有通过一条先前存在的引用链获得另一个对象的引用，简而言之，“只有连接才能产生连接”。
|
||||
|
||||
关于对象能力（object-capabilities），可以阅读这边[文章](http://habitatchronicles.com/2017/05/what-are-capabilities/)了解更多。
|
||||
|
||||
严格来说，Golang 由于几个问题没有完全实现对象能力：
|
||||
|
||||
+ 无处不在地引入原始（基础）模块（比如unsafe, os）
|
||||
+ 无处不在地重写模块变量
|
||||
+ 存在2个以上goroutine时的数据竞态漏洞可以创建非法的接口值
|
||||
|
||||
第一点很容易通过审计import和使用适当的依赖版本控制系统（如Dep）来捕获。但第二点和第三点就不容易了，需要成本进行代码审核。
|
||||
|
||||
|
||||
## 对象能力模式实践
|
||||
|
||||
想法就是只暴露完成工作所需要的部分。
|
||||
|
||||
比如，下面的代码片段违反了对象能力原则：
|
||||
|
||||
```go
|
||||
type AppAccount struct {...}
|
||||
var account := &AppAccount{
|
||||
Address: pub.Address(),
|
||||
Coins: sdk.Coins{sdk.NewInt64Coin("ATM", 100)},
|
||||
}
|
||||
var sumValue := externalModule.ComputeSumValue(account)
|
||||
```
|
||||
|
||||
方法名`ComputeSumValue`暗示了这是一个不修改状态的纯函数，但传入指针值意味着函数可以修改其值。更好的函数定义是使用一个拷贝来替代：
|
||||
|
||||
```go
|
||||
var sumValue := externalModule.ComputeSumValue(*account)
|
||||
```
|
||||
|
||||
在Cosmos SDK中，你可以看到[gaia app](https://github.com/cosmos/cosmos-sdk/blob/master/simapp/app.go)中对该原则的实践。
|
||||
|
||||
```go
|
||||
// register message routes
|
||||
app.Router().
|
||||
AddRoute(bank.RouterKey, bank.NewHandler(app.bankKeeper)).
|
||||
AddRoute(staking.RouterKey, staking.NewHandler(app.stakingKeeper)).
|
||||
AddRoute(distr.RouterKey, distr.NewHandler(app.distrKeeper)).
|
||||
AddRoute(slashing.RouterKey, slashing.NewHandler(app.slashingKeeper)).
|
||||
AddRoute(gov.RouterKey, gov.NewHandler(app.govKeeper))
|
||||
```
|
||||
@@ -0,0 +1,95 @@
|
||||
# SDK 应用程序架构
|
||||
|
||||
## 状态机
|
||||
|
||||
区块链应用的核心是[具有最终确定性的复制状态机](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/introduction.html)将会为你处理网络层的状态复制。
|
||||
|
||||
```
|
||||
^ +-------------------------------+ ^
|
||||
| | | | 通过 Cosmos SDK 构建
|
||||
| | 状态机 = 应用（层） | |
|
||||
| | | v
|
||||
| +-------------------------------+
|
||||
| | | ^
|
||||
链节点 | | 共识层 | |
|
||||
| | | |
|
||||
| +-------------------------------+ | Tendermint Core
|
||||
| | | |
|
||||
| | 网络层 | |
|
||||
| | | |
|
||||
v +-------------------------------+ v
|
||||
```
|
||||
|
||||
Tendermint是一个与应用程序无关的引擎，负责处理区块链的*网络层*和*共识层*。实际上，这意味着Tendermint负责传播和排序交易字节。Tendermint Core 依赖于拜占庭容错（BFT）算法来达成交易顺序的共识。要深入了解Tendermint，可点击[这里](https://tendermint.com/docs/introduction/what-is-tendermint.html)。
|
||||
|
||||
Tendermint一致性算法通过一组称为*验证人*的特殊节点一起运作。验证人负责向区块链添加交易区块。对于任何给定的区块，有一组验证人V。通过算法选择V中的验证人A作为下一个区块的提议人。如果超过三分之二的V签署了[prevote](https://tendermint.com/docs/spec/consensus/consensus.html#state-machine-spec)和[precommit](https://tendermint.com/docs/spec/consensus/consensus.html#state-machine-spec)，并且区块包含的所有交易都是有效的，则该区块被认为是有效的。验证人集合可以通过状态机中编写的规则进行更改。要深入了解算法，[点击](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 。
|
||||
|
||||
```
|
||||
+---------------------+
|
||||
| |
|
||||
| 应用 |
|
||||
| |
|
||||
+--------+---+--------+
|
||||
^ |
|
||||
| | ABCI
|
||||
| v
|
||||
+--------+---+--------+
|
||||
| |
|
||||
| |
|
||||
| Tendermint |
|
||||
| |
|
||||
| |
|
||||
+---------------------+
|
||||
```
|
||||
|
||||
注意，Tendermint 仅处理交易字节。它不知道这些字节究竟是什么意思。Tendermint 所做的只是对交易确定性地排序。赋予这些字节意义是应用程序的工作。Tendermint通过ABCI将交易字节传递给应用程序，并期望返回代码以知晓消息是否成功。
|
||||
|
||||
以下是ABCI中最重要的消息类型：
|
||||
|
||||
- `CheckTx` : 当 Tendermint Core 收到交易时，如果符合一些的基本的要求会将其传递给应用程序。`Checkx` 用于保护全节点的交易池免受垃圾邮件的侵害。一个名为“Ante Handler”的特殊处理器用于执行一系列验证步骤，例如检查手续费用是否足够和验证签名是否合法。如果交易有效，则将交易添加到[交易池（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”也将连同实际处理交易中每条消息的handler一起再次执行。
|
||||
- `BeginBlock`/`EndBlock` : 无论区块是否包含交易，这两个消息都将在每个区块的开头和结尾执行。触发自动的逻辑执行是很有用的。过程中要足够小心，因为计算成本高昂的循环运算可能会减慢区块链的速度，甚至发生无限循环引起区块链本身停滞。
|
||||
|
||||
|
||||
有关 ABCI 方法和类型的详细介绍请[点击](https://tendermint.com/docs/spec/abci/abci.html#overview)。
|
||||
|
||||
在 Tendermint 上构建的任何应用程序都需要实现ABCI接口，来同本地的底层 Tendermint 引擎进行通信。幸运的是，你不用必需实现ABCI接口。Cosmos SDK以[baseapp](./sdk-design.md#baseapp)的形式提供了样板实现。
|
||||
|
||||
### 接下来，让我们学习[SDK的高级设计原则](./sdk-design.md)
|
||||
@@ -0,0 +1,86 @@
|
||||
# Cosmos SDK 设计概览
|
||||
|
||||
Cosmos SDK是一个方便开发者开发基于Tendermint的安全可靠状态机的一套框架。其核心是Golang版的ABCI的实现。它附带一个`multistore`来持久化存储数据还有一个`router`来处理交易。
|
||||
|
||||
下面一个简单的视图展示了当从Tendermint的`DeliverTx`请求（`CheckTx`的处理流程与其相同，除了不会执行状态的改变）中接收到一笔交易时，基于Cosmos SDK构建的应用程序是如何处理交易的：
|
||||
|
||||
1. 解码从Tendermint共识引擎接收到的交易（记住Tendermint只处理`[]bytes`）
|
||||
2. 从交易中提取消息并进行基本的合理性检查。
|
||||
3. 将每条消息路由至对应的模块进行处理。
|
||||
4. 提交状态变更。
|
||||
|
||||
应用同样可以生成交易，进行编码并传递给底层的Tendermint来进行广播
|
||||
|
||||
## `baseapp`
|
||||
|
||||
`baseApp` 是Cosmos SDK的ABCI的实现样板。里面的 `router` 用来把交易路由到对应的模块。我们应用程序的主体文件`app.go` 将自定义`app`类型，它将嵌入`baseapp`。这样，自定义的`app`类型将自动继承`baseapp`的所有方法。阅览[SDK应用教程](https://github.com/cosmos/sdk-application-tutorial/blob/master/app.go#L27)代码示例。
|
||||
|
||||
`baseapp`的目的是在存储和可扩展状态机的之间提供安全接口，同时尽可能少地定义该状态机（保持对ABCI的真实性）。
|
||||
|
||||
有关`baseapp`的更多信息，请点击[这里](../concepts/baseapp.md)。
|
||||
|
||||
## Multistore
|
||||
|
||||
Cosmos SDK 为状态持久化提供了 multistore 。multistore 允许开发者声明任意数量的[`KVStores`](https://github.com/blocklayerhq/chainkit)。`KVStores`只接受`[]byte`类型作为值，因此任何自定义的类型都需要在存储之前使用[go-amino](https://github.com/tendermint/go-amino)进行编码。
|
||||
|
||||
multistore 抽象用于区分不同的模块的状态，每个都由其自身模块管理。要了解更多关于 multistore 的信息，点击[这里](../concepts/store.md)
|
||||
|
||||
## Modules
|
||||
|
||||
Cosmos SDK 的强大之处在于其模块化开发的理念。应用程序通过把一组可以互相操作的模块组合起来进行构建。每个模块定义状态子集，并包含其自己的消息/交易处理器，而SDK负责将每条消息路由到其各自归属的模块。
|
||||
|
||||
下面是一个简化视图, 旨在说明每个应用链的全节点是如何处理接收的有效块中交易的:
|
||||
|
||||
```
|
||||
+
|
||||
|
|
||||
| 交易通过全节点的 Tendermint 引擎的DeliverTx
|
||||
| 传递到应用层
|
||||
|
|
||||
|
|
||||
+---------------------v--------------------------+
|
||||
| 应用（层） |
|
||||
| |
|
||||
| 用 baseapp 的方法: 解码 Tx, |
|
||||
| 提取及路由消息 |
|
||||
| |
|
||||
+---------------------+--------------------------+
|
||||
|
|
||||
|
|
||||
|
|
||||
+---------------------------+
|
||||
|
|
||||
|
|
||||
|
|
||||
| 消息传给相应的模块处理
|
||||
|
|
||||
|
|
||||
+----------------+ +---------------+ +----------------+ +------v----------+
|
||||
| | | | | | | |
|
||||
| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE |
|
||||
| | | | | | | |
|
||||
| | | | | | | 处理消息, 更改状态 |
|
||||
| | | | | | | |
|
||||
| | | | | | | |
|
||||
+----------------+ +---------------+ +----------------+ +------+----------+
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
+--------------------------+
|
||||
|
|
||||
| 返回结果到 Tendermint
|
||||
| (0=Ok, 1=Err)
|
||||
v
|
||||
```
|
||||
|
||||
每个模块都可以看做一个小型的状态机。开发人员需要定义模块所处理的状态的子集，以及修改状态的message自定义类型(*注意* : message 是由 `baseapp` 的方法从交易中提取的)。通常，每个模块在 multistore 声明它自己的`KVStore` 来持久化保存它所定义的状态子集。大多数开发者在构建自己的模块时也需要访问其他的第三方模块。鉴于Cosmos-SDK是一个开源的框架，一些模块可能是恶意的，这就意味着需要安全原则来合理化模块之间的交互。这些原则基于[object-capabilities](./ocap.md)。实际上，这意味着不是让每个模块保留其他模块的访问控制列表，而是每个模块都实现称作`keeper`的特殊对象，这些对象可以传递给其他模块并授予预先定义的一组能力。
|
||||
|
||||
SDK模块在SDK的`x/`目录下定义。一些核心模块包括：
|
||||
+ `x/auth`: 用于管理账户和签名.
|
||||
+ `x/bank`: 用于实现token和token转账.
|
||||
+ `x/staking` + `x/slashing`: 用于构建POS区块链.
|
||||
|
||||
除了`x/`中已有的模块，任何人都可以在他们的应用程序中使用它们自己定义的模块。你可以查看[示例教程](https://learnblockchain.cn/docs/cosmos/tutorial/04-keeper.html)。
|
||||
|
||||
### 接下来 学习 Cosmos SDK 安全模型，[ocap](./ocap.md)
|
||||
Reference in New Issue
Block a user