Translate doc clients to chinese. (#4129)
This commit is contained in:
Frank Yang
Alessio Treglia
parent
a75a8d3311
commit
1b726ad88a
|
|
@ -0,0 +1 @@
|
|||
#4129 Translate doc clients to chinese.
|
||||
|
|
@ -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,178 @@
|
|||
# 服务提供商（Service Providers）
|
||||
|
||||
我们将“服务提供商”定义为可以为最终用户提供服务的实体，这些实体涉及与基于 Cosmos-SDK 的区块链（包括Cosmos Hub）的某种形式的交互。更具体地说，本文档将集中于与 token 的交互。
|
||||
|
||||
本节不涉及想要提供[轻客户端](https://github.com/cosmos/cosmos-sdk/tree/develop/docs/light)功能的钱包开发者。服务提供商将作为最终用户的区块链的可信接入点。
|
||||
|
||||
## 架构的高级描述
|
||||
|
||||
有三个主要部分需要考虑：
|
||||
|
||||
- 全节点：与区块链交互。
|
||||
- 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 <destination_address> <amount> \
|
||||
--chain-id=<name_of_testnet_chain> \
|
||||
--from=<key_name>
|
||||
```
|
||||
|
||||
参数：
|
||||
- `<destination_address>`: 接收者地址。
|
||||
- `<amount>`: 接受`<value|coinName>`格式的参数，例如 `10faucetToken`。
|
||||
|
||||
标识：
|
||||
|
||||
- `--chain-id`: This flag allows you to specify the id of the chain. There will be different ids for different testnet chains and main chain.
|
||||
- `--from`: Name of the key of the sending account.
|
||||
|
||||
#### 帮助
|
||||
|
||||
如果您需要进行其他操作，最合适的命令是：
|
||||
|
||||
```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,42 @@
|
|||
# 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
|
||||
|
||||
### [`concepts`](../concepts/)
|
||||
|
||||
- ToDo
|
||||
|
||||
### [`spec`](../spec/)
|
||||
|
||||
- ToDo
|
||||
|
||||
### [`gaia`](../gaia/)
|
||||
|
||||
- Synced until commit [9e7440a9](https://github.com/cosmos/cosmos-sdk/commit/9e7440a92c14187b05a3064864899f708a507d82)
|
||||
|
||||
### [`intro`](../intro/)
|
||||
|
||||
- Synced until commit [160928b8](https://github.com/cosmos/cosmos-sdk/commit/160928b8f3586a2674cca136891e2cc15d4232d9)
|
||||
|
||||
### [`modules`](../modules/)
|
||||
|
||||
- ToDo
|
||||
|
||||
### [`clients`](../clients/)
|
||||
|
||||
- Synced until Commit [dfe58f8d](<https://github.com/cosmos/cosmos-sdk/commit/dfe58f8d8dff662aa6ff9d29503ee3cd3c1ec48c>)
|
||||
|
||||
Loading…
Reference in New Issue