Merge branch 'develop' into release/v0.34.2

2019-04-25 21:40:33 -04:00
parent 296a8c81c8 95e3d7d05e
commit e7ca82d808
193 changed files with 2659 additions and 871 deletions
@@ -1,17 +1,13 @@
 ### `cosmos/cosmos-sdk` Release Process

- [ ] 1. Decide on release designation (are we doing a patch, or minor version bump) and start a branch for the release
- [ ] 2. Add commits/PRs that are desired for this release **that haven’t already been added to develop**
- [ ] 3. Merge items in `PENDING.md` into the `CHANGELOG.md`. While doing this make sure that each entry contains links to issues/PRs for each item
- [ ] 4. Summarize breaking API changes section under “Breaking Changes” section to the `CHANGELOG.md` to bring attention to any breaking API changes that affect RPC consumers.
- [ ] 5. Tag the commit `git tag -a { .Release.Name }-rcN -m 'Release { .Release.Name }'`
- [ ] 6. Open PRs for both `master` and `develop`. From now onwards ***no additional PRs targeting develop should be merged**. Additional commits can be added on top of the release branch though.
- [ ] 7. Ensure both `master` and `develop` PRs ***pass tests***.
- [ ] 8. Kick off 1 day of automated fuzz testing
- [ ] 9. Release Lead assigns 2 people to perform [buddy testing script](/docs/RELEASE_TEST_SCRIPT.md) and update the relevant documentation
- [ ] 10. If errors are found in either #6 or #7 go back to #2 (*NOTE*: be sure to increment the `rcN`)
- [ ] 11. After #6 and #7 have successfully completed then merge the release PR create the final release annotated tag:
- - `git tag -a -m { .Release.Name } 'Release { .Release.Name }'
- - Merge **the release tag** to both `master` and `develop` so that both branches sit on top of the same commit: `branches='master develop' ; for b in $branches ; do git checkout $b ; git merge { .Release.Name } ; git push $b`.
- Alternatively merge both the aforementioned release PRs.
- - Push the final annotated release tag: `git push --tags`
+Unless otherwise stated, all of the following tasks will be undertaken by the release manager/coordinator:
+
+- [ ] 1. Decide on release designation (are we doing a patch, or minor version bump)
+- [ ] 2. Ensure that all commits/PRs which are destined for this release are merged to the `master` branch
+- [ ] 3. Create the release candidate branch `rcN` (please start with `N=1`) (going forward known as **RC**) and ensure it's protected against pushing from anyone except the release manager/coordinator. **no PRs targeting this branch should be merged unless exceptional circumstances arise**
+- [ ] 4. On the `RC` branch, use `clog` to prepare the `CHANGELOG.md`.
+- [ ] 5. Summarize breaking API changes section under “Breaking Changes” section to the `CHANGELOG.md` to bring attention to any breaking API changes that affect RPC consumers.
+- [ ] 6. Kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks) 
+- [ ] 7. If errors are found in either #6 or #7 go back to #2 (*NOTE*: be sure to increment the `rcN`)
+- [ ] 8. After #6 and #7 have successfully completed create the release branch from the `RC` branch (this will trigger the automated relase process which will build binaries, tag the release and push to github)
+- [ ] 9. Merge the release branch to `master` and delete the `RC` branch
@@ -7,7 +7,6 @@ Once you have finallized your application, install it using `go get`. The follow
 ```bash
 go get github.com/<your_username>/cosmos-sdk
 cd $GOPATH/src/github.com/<your_username>/cosmos-sdk
-make get_vendor_deps
 make install
 make install_examples
 ```
@@ -10,7 +10,7 @@ To start a REST server, we need to specify the following parameters:
 | trust-node  | bool      | "false"                 | true     | Whether this LCD is connected to a trusted full node |
 | trust-store | DIRECTORY | "$HOME/.lcd"            | false    | directory for save checkpoints and validator sets    |

-For example::
+For example:

 ```bash
 gaiacli rest-server --chain-id=test \
@@ -62,7 +62,7 @@ type KeyExistsProof struct {
 }
 ```

-The data structure of exist proof is shown as above. The process to build and verify existance proof
+The data structure of exist proof is shown as above. The process to build and verify existence proof
 is shown as follows:

 ![Exist Proof](./pics/existProof.png)
@@ -18,9 +18,9 @@ There are three main pieces to consider:

 We will describe the steps to run and interract with a full-node for the Cosmos Hub. For other SDK-based blockchain, the process should be similar. 

-First, you need to [install the software](../getting-started/installation.md).
+First, you need to [install the software](../cosmos-hub/installation.md).

-Then, you can start [running a full-node](../getting-started/join-testnet.md).
+Then, you can start [running a full-node](../cosmos-hub/join-testnet.md).

 ### Command-Line interface

@@ -34,12 +34,13 @@ To generate a new key (default secp256k1 elliptic curve):
 gaiacli keys add <your_key_name>
 ```

-You will be asked to create a passwords (at least 8 characters) for this key-pair. The command returns 4 informations:
+You will be asked to create a passwords (at least 8 characters) for this key-pair. The command returns 5 informations:

 - `NAME`: Name of your key
+- `TYPE`: Type of your key, always `local`. 
 - `ADDRESS`: Your address. Used to receive funds.
 - `PUBKEY`: Your public key. Useful for validators.
- `Seed phrase`: 12-words phrase. **Save this seed phrase somewhere safe**. It is used to recover your private key in case you forget the password.
+- `MNEMONIC`: 24-words phrase. **Save this mnemonic somewhere safe**. It is used to recover your private key in case you forget the password.

 You can see all your available keys by typing:

@@ -62,14 +63,20 @@ gaiacli account <YOUR_ADDRESS>
 Here is the command to send coins via the CLI:

 ```bash
-gaiacli send --amount=10faucetToken --chain-id=<name_of_testnet_chain> --from=<key_name> --to=<destination_address>
+gaiacli tx send <destination_address> <amount> \
+    --chain-id=<name_of_testnet_chain> \
+    --from=<key_name>
 ```

+Parameters:
+
+- `<destination_address>`: Address of the recipient.
+- `<amount>`: This parameter accepts the format `<value|coinName>`, such as `10faucetToken`.
+
 Flags:
- `--amount`: This flag accepts the format `<value|coinName>`.
+
 - `--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.
- `--to`: Address of the recipient.

 #### Help

@@ -88,12 +95,12 @@ The Rest Server acts as an intermediary between the front-end and the full-node.
 To start the Rest server: 

 ```bash
-gaiacli advanced rest-server --node=<full_node_address:full_node_port>
+gaiacli rest-server --node=<full_node_address:full_node_port>
 ```

 Flags:
 - `--trust-node`: A boolean. If `true`, light-client verification is disabled. If `false`, it is disabled. For service providers, this should be set to `true`. By default, it set to `true`. 
- `--node`: This is where you indicate the address and the port of your full-node. The format is <full_node_address:full_node_port>. If the full-node is on the same machine, the address should be `tcp://localhost:26657`.
+- `--node`: This is where you indicate the address and the port of your full-node. The format is `<full_node_address:full_node_port>`. If the full-node is on the same machine, the address should be `tcp://localhost:26657`.
 - `--laddr`: This flag allows you to specify the address and port for the Rest Server (default `1317`). You will mostly use this flag only to specify the port, in which case just input "localhost" for the address. The format is <rest_server_address:port>.


@@ -101,7 +108,7 @@ Flags:

 The recommended way to listen for incoming transaction is to periodically query the blockchain through the following endpoint of the LCD:

-[`/bank/balance/{account}`](https://cosmos.network/rpc/#/ICS20/get_bank_balances__address_)
+[`/bank/balance/{address}`](https://cosmos.network/rpc/#/ICS20/get_bank_balances__address_)

 ## Rest API

@@ -201,13 +201,12 @@ When you query an account balance with zero tokens, you will get this error: `No
 The following command could be used to send coins from one account to another:

 ```bash
-gaiacli tx send <destination_cosmos> 10faucetToken \
-  --chain-id=<chain_id> \
-  --from=<key_name> \
+gaiacli tx send <sender_key_name_or_address> <recipient_address> 10faucetToken \
+  --chain-id=<chain_id>
 ```

 ::: warning Note
-The `--amount` flag accepts the format `--amount=<value|coin_name>`.
+The `amount` argument accepts the format `<value|coin_name>`.
 :::

 ::: tip Note
@@ -233,9 +232,8 @@ You can simulate a transaction without actually broadcasting it by appending the
 `--dry-run` flag to the command line:

 ```bash
-gaiacli tx send <destination_cosmosaccaddr> 10faucetToken \
+gaiacli tx send <sender_key_name_or_address> <destination_cosmosaccaddr> 10faucetToken \
  --chain-id=<chain_id> \
-  --from=<key_name> \
  --dry-run
 ```

@@ -243,9 +241,8 @@ Furthermore, you can build a transaction and print its JSON format to STDOUT by
 appending `--generate-only` to the list of the command line arguments:

 ```bash
-gaiacli tx send <destination_cosmosaccaddr> 10faucetToken \
+gaiacli tx send <sender_address> <recipient_address> 10faucetToken \
  --chain-id=<chain_id> \
-  --from=<key_name> \
  --generate-only > unsignedSendTx.json
 ```

@@ -258,6 +255,7 @@ gaiacli tx sign \

 ::: tip Note
 The `--generate-only` flag prevents `gaiacli` from accessing the local keybase.
+Thus when such flag is supplied `<sender_key_name_or_address>` must be an address.
 :::

 You can validate the transaction's signatures by typing the following:
@@ -9,8 +9,8 @@ Install `go` by following the [official docs](https://golang.org/doc/install). R
 ```bash
 mkdir -p $HOME/go/bin
 echo "export GOPATH=$HOME/go" >> ~/.bash_profile
-echo "export GOBIN=$GOPATH/bin" >> ~/.bash_profile
-echo "export PATH=$PATH:$GOBIN" >> ~/.bash_profile
+echo "export GOBIN=\$GOPATH/bin" >> ~/.bash_profile
+echo "export PATH=\$PATH:\$GOBIN" >> ~/.bash_profile
 source ~/.bash_profile
 ```

@@ -0,0 +1,34 @@
+# KMS - Key Management System
+
+[Tendermint KMS](https://github.com/tendermint/kms) is a key management service that allows separating key management from Tendermint nodes. In addition it provides other advantages such as:
+
+- Improved security and risk management policies
+- Unified API and support for various HSM (hardware security modules)
+- Double signing protection (software or hardware based)
+
+It is recommended that the KMS service runs in a separate physical hosts.
+
+## Building
+
+Detailed build instructions can be found [here](https://github.com/tendermint/kms#installation).
+
+::: tip
+When compiling the KMS, ensure you have enabled the applicable features:
+:::
+
+| Backend               | Recommended Command line              |
+|-----------------------|---------------------------------------|
+| YubiHSM               | ```cargo build --features yubihsm```  |
+| Ledger+Tendermint App | ```cargo build --features ledgertm``` |
+
+## Configuration
+
+A KMS can be configured in various ways:
+
+### Using a YubiHSM
+  
+  Detailed information on how to setup a KMS with YubiHSM2 can be found [here](https://github.com/tendermint/kms/blob/master/README.yubihsm.md)
+
+### Using a Ledger device running the Tendermint app
+
+  Detailed information on how to setup a KMS with Ledger Tendermint App can be found [here](kms_ledger.md)
@@ -0,0 +1,113 @@
+# Setting up Tendermint KMS + Ledger
+
+::: danger Warning
+The following instructions are a brief walkthrough and not a comprehensive guideline. You should consider and [research more about the security implications](./security.md) of activating an external KMS.
+:::
+
+::: danger Warning
+KMS and Ledger Tendermint app are currently work in progress. Details may vary. Use with care under your own risk.
+:::
+
+## Tendermint Validator app (for Ledger devices)
+
+You should be able to find the Tendermint app in Ledger Live.
+
+*Note: at the moment, you might need to enable `developer mode` in Ledger Live settings*
+
+## KMS configuration
+
+In this section, we will configure a KMS to use a Ledger device running the Tendermint Validator App. 
+
+### Config file
+
+You can find other configuration examples [here](https://github.com/tendermint/kms/blob/master/tmkms.toml.example)
+
+- Create a `~/.tmkms/tmkms.toml` file with the following content (use an adequate `chain_id`)
+
+```toml
+# Example KMS configuration file
+[[validator]]
+addr = "tcp://localhost:26658"    # or "unix:///path/to/socket"
+chain_id = "gaia-11001"
+reconnect = true # true is the default
+secret_key = "~/.tmkms/secret_connection.key"
+
+[[providers.ledgertm]]
+chain_ids = ["gaia-11001"]
+```
+
+- Edit `addr` to point to your `gaiad` instance.
+- Adjust `chain-id` to match your `.gaiad/config/config.toml` settings.
+- `provider.ledgertm` has not additional parameters at the moment, however, it is important that you keep that header to enable the feature.
+
+*Plug your Ledger device and open the Tendermint validator app.*
+
+### Generate secret key
+
+Now you need to generate secret_key:
+
+```bash
+tmkms keygen ~/.tmkms/secret_connection.key
+```
+
+### Retrieve validator key
+
+The last step is to retrieve the validator key that you will use in `gaiad`.
+
+Start the KMS:
+
+```bash
+tmkms start -c ~/.tmkms/tmkms.toml
+```
+
+The output should look similar to:
+
+```text
+07:28:24 [INFO] tmkms 0.3.0 starting up...
+07:28:24 [INFO] [keyring:ledgertm:ledgertm] added validator key cosmosvalconspub1zcjduepqy53m39prgp9dz3nz96kaav3el5e0th8ltwcf8cpavqdvpxgr5slsd6wz6f
+07:28:24 [INFO] KMS node ID: 1BC12314E2E1C29015B66017A397F170C6ECDE4A
+```
+
+The KMS may complain that it cannot connect to gaiad. That is fine, we will fix it in the next section.
+
+This output indicates the validator key linked to this particular device is: `cosmosvalconspub1zcjduepqy53m39prgp9dz3nz96kaav3el5e0th8ltwcf8cpavqdvpxgr5slsd6wz6f`
+
+Take note of the validator pubkey that appears in your screen. *We will use it in the next section.*
+
+## Gaia configuration
+
+You need to enable KMS access by editing `.gaiad/config/config.toml`. In this file, modify `priv_validator_laddr` to create a listening address/port or a unix socket in `gaiad`.
+
+For example:
+
+```toml
+...
+# TCP or UNIX socket address for Tendermint to listen on for
+# connections from an external PrivValidator process
+priv_validator_laddr = "tcp://127.0.0.1:26658"
+...
+```
+
+Let's assume that you have set up your validator account and called it `kmsval`. You can tell gaiad the key that we've got in the previous section.
+
+```bash
+gaiad gentx --name kmsval --pubkey {.ValidatorKey} 
+```
+
+Now start `gaiad`. You should see that the KMS connects and receives a signature request.
+
+Once the ledger receives the first message, it will ask for confirmation that the values are adequate.
+
+![](ledger_1.jpg)
+
+Click the right button, if the height and round are correct.
+
+After that, you will see that the KMS will start forwarding all signature requests to the ledger:
+
+![](ledger_2.jpg)
+
+::: danger Warning
+The word TEST in the second picture, second line appears because they were taken on a pre-release version.
+
+Once the app as been released in Ledger's app store, this word should NOT appear.
+:::
@@ -25,6 +25,7 @@ Sentry nodes can be quickly spun up or change their IP addresses. Because the li
 To setup your sentry node architecture you can follow the instructions below:

 Validators nodes should edit their config.toml:
+
 ```bash
 # Comma separated list of nodes to keep persistent connections to
 # Do not add private peers to this list if you don't want them advertised
@@ -35,6 +36,7 @@ pex = false
 ```

 Sentry Nodes should edit their config.toml:
+
 ```bash
 # Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
 # Example ID: 3e16af0cead27979e1fc3dac57d03df3c7a77acc@3.87.179.235:26656
@@ -50,5 +52,5 @@ By default, uppercase environment variables with the following prefixes will rep
 - `TM` (for Tendermint flags)
 - `BC` (for democli or basecli flags)

-For example, the environment variable `GA_CHAIN_ID` will map to the command line flag `--chain-id`. Note that while explicit command-line flags will take precedence over environment variables, environment variables will take precedence over any of your configuration files. For this reason, it's imperative that you lock down your environment such that any critical parameters are defined as flags on the CLI or prevent modification of any environment variables. 
-  
+For example, the environment variable `GA_CHAIN_ID` will map to the command line flag `--chain-id`. Note that while explicit command-line flags will take precedence over environment variables, environment variables will take precedence over any of your configuration files. For this reason, it's imperative that you lock down your environment such that any critical parameters are defined as flags on the CLI or prevent modification of any environment variables.
+  
@@ -6,6 +6,8 @@ Information on how to join the mainnet (`genesis.json` file and seeds) is held [

 Before setting up your validator node, make sure you've already gone through the [Full Node Setup](../join-mainnet.md) guide.

+If you plan to use a KMS (key management system), you should go through these steps first: [Using a KMS](kms/kms.md).
+
 ## What is a Validator?

 [Validators](./overview.md) are responsible for committing new blocks to the blockchain through voting. A validator's stake is slashed if they become unavailable or sign blocks at the same height. Please read about [Sentry Node Architecture](./validator-faq.md#how-can-validators-protect-themselves-from-denial-of-service-attacks) to protect your node from DDOS attacks and to ensure high-availability.
@@ -165,6 +167,15 @@ You should now see your validator in one of the Cosmos Hub explorers. You are lo
 To be in the validator set, you need to have more total voting power than the 100th validator.
 :::

+## Halting Your Validator
+
+When attempting to perform routine maintenance or planning for an upcoming coordinated
+upgrade, it can be useful to have your validator systematically and gracefully halt.
+You can achieve this by either setting the `halt-height` to the height at which
+you want your node to shutdown or by passing the `--halt-height` flag to `gaiad`.
+The node will shutdown with a zero exit code at that given height after committing
+the block.
+
 ## Common Problems

 ### Problem #1: My validator has `voting_power: 0`
@@ -6,7 +6,18 @@ The bank module emits the following events/tags:

 ### MsgSend

-| Key       | Value                     |
-|-----------|---------------------------|
-| sender    | {senderAccountAddress}    |
-| recipient | {recipientAccountAddress} |
+| Key         | Value                     |
+|-------------|---------------------------|
+| `action`    | `send`                    |
+| `category`  | `bank`                    |
+| `sender`    | {senderAccountAddress}    |
+| `recipient` | {recipientAccountAddress} |
+
+### MsgMultiSend
+
+| Key         | Value                     |
+|-------------|---------------------------|
+| `action`    | `multisend`               |
+| `category`  | `bank`                    |
+| `sender`    | {senderAccountAddress}    |
+| `recipient` | {recipientAccountAddress} |
@@ -6,8 +6,9 @@ The crisis module emits the following events/tags:

 ### MsgVerifyInvariance

-| Key       | Value               |
-|-----------|---------------------|
-| action    | verify_invariant    |
-| sender    | {message-sender}    |
-| invariant | {invariant-route}   |
+| Key         | Value              |
+|-------------|--------------------|
+| `action`    | `verify_invariant` |
+| `category`  | `crisis`           |
+| `sender`    | {message-sender}   |
+| `invariant` | {invariant-route}  |
@@ -6,25 +6,25 @@ The distribution module emits the following events/tags:

 ### MsgSetWithdrawAddress

-| Key       | Value                     |
-|-----------|---------------------------|
-| delegator | {delegatorAccountAddress} |
-
-### MsgWithdrawDelegatorRewardsAll
-
-| Key       | Value                     |
-|-----------|---------------------------|
-| delegator | {delegatorAccountAddress} |
+| Key        | Value                     |
+|------------|---------------------------|
+| `action`   | `set_withdraw_address`    |
+| `category` | `distribution`            |
+| `sender`   | {delegatorAccountAddress} |

 ### MsgWithdrawDelegatorReward

-| Key              | Value                     |
-|------------------|---------------------------|
-| delegator        | {delegatorAccountAddress} |
-| source-validator | {srcOperatorAddress}      |
+| Key                | Value                       |
+|--------------------|-----------------------------|
+| `action`           | `withdraw_delegator_reward` |
+| `category`         | `distribution`              |
+| `sender`           | {delegatorAccountAddress}   |
+| `source-validator` | {srcOperatorAddress}        |

-### MsgWithdrawValidatorRewardsAll
+### MsgWithdrawValidatorCommission

-| Key              | Value                |
-|------------------|----------------------|
-| source-validator | {srcOperatorAddress} |
+| Key        | Value                           |
+|------------|---------------------------------|
+| `action`   | `withdraw_validator_commission` |
+| `category` | `distribution`                  |
+| `sender`   | {srcOperatorAddress}            |
@@ -4,35 +4,38 @@ The governance module emits the following events/tags:

 ## EndBlocker

-| Key             | Value                                                |
-|-----------------|------------------------------------------------------|
-| proposal-result | proposal-passed\|proposal-rejected\|proposal-dropped |
+| Key               | Value                                                      |
+|-------------------|------------------------------------------------------------|
+| `proposal-result` | `proposal-passed`\|`proposal-rejected`\|`proposal-dropped` |

 ## Handlers

 ### MsgSubmitProposal

-| Key                     | Value                    |
-|-------------------------|--------------------------|
-| action                  | proposal-vote            |
-| proposer                | {proposerAccountAddress} |
-| proposal-id             | {proposalID}             |
-| voting-period-start [0] | {proposalID}             |
+| Key                       | Value                    |
+|---------------------------|--------------------------|
+| `action`                  | `submit_proposal`        |
+| `category`                | `governance`             |
+| `sender`                  | {proposerAccountAddress} |
+| `proposal-id`             | {proposalID}             |
+| `voting-period-start` [0] | {proposalID}             |

 * [0] Tag only emitted if the voting period starts during the submission.

 ### MsgVote

-| Key         | Value                 |
-|-------------|-----------------------|
-| action      | proposal-vote         |
-| voter       | {voterAccountAddress} |
-| proposal-id | {proposalID}          |
+| Key           | Value                 |
+|---------------|-----------------------|
+| `action`      | `vote`                |
+| `category`    | `governance`          |
+| `sender`      | {voterAccountAddress} |
+| `proposal-id` | {proposalID}          |

 ### MsgDeposit

-| Key         | Value                     |
-|-------------|---------------------------|
-| action      | proposal-vote             |
-| depositor   | {depositorAccountAddress} |
-| proposal-id | {proposalID}              |
+| Key           | Value                     |
+|---------------|---------------------------|
+| `action`      | `deposit`                 |
+| `category`    | `governance`              |
+| `sender`      | {depositorAccountAddress} |
+| `proposal-id` | {proposalID}              |
@@ -8,7 +8,7 @@ The IBC protocol creates a mechanism by which two replicated fault-tolerant stat

 The IBC protocol assumes that multiple applications are running on their own blockchain with their own state and own logic. Communication is achieved over an ordered message queue primitive, allowing the creation of complex inter-chain processes without trusted third parties.

-The message packets are not signed by one psuedonymous account, or even multiple, as in multi-signature sidechain implementations. Rather, IBC assigns authorization of the packets to the source blockchain's consensus algorithm, performing light-client style verification on the destination chain. The Byzantine-fault-tolerant properties of the underlying blockchains are preserved: a user transferring assets between two chains using IBC must trust only the consensus algorithms of both chains.
+The message packets are not signed by one pseudonymous account, or even multiple, as in multi-signature sidechain implementations. Rather, IBC assigns authorization of the packets to the source blockchain's consensus algorithm, performing light-client style verification on the destination chain. The Byzantine-fault-tolerant properties of the underlying blockchains are preserved: a user transferring assets between two chains using IBC must trust only the consensus algorithms of both chains.

 In this paper, we define a process of posting block headers and Merkle tree proofs to enable secure verification of individual packets. We then describe how to combine these packets into a messaging queue to guarantee ordered delivery. We then explain how to handle packet receipts (response/error) on the source chain, which enables the creation of asynchronous RPC-like protocols on top of IBC. Finally, we detail some optimizations and how to handle Byzantine blockchains.

@@ -6,7 +6,8 @@ The slashing module emits the following events/tags:

 ### MsgUnjail

-| Key       | Value                      |
-|-----------|----------------------------|
-| action    | validator-unjailed         |
-| validator | {validatorOperatorAddress} |
+| Key        | Value                      |
+|------------|----------------------------|
+| `action`   | `unjail`                   |
+| `category` | `slashing`                 |
+| `sender`   | {validatorOperatorAddress} |
@@ -4,55 +4,62 @@ The staking module emits the following events/tags:

 ## EndBlocker

-| Key                   | Value                                     |
-|-----------------------|-------------------------------------------|
-| action                | complete-unbonding\|complete-redelegation |
-| delegator             | {delegatorAccountAddress}                 |
-| source-validator      | {srcOperatorAddress}                      |
-| destination-validator | {dstOperatorAddress}                      |
+| Key                     | Value                                         |
+|-------------------------|-----------------------------------------------|
+| `action`                | `complete-unbonding`\|`complete-redelegation` |
+| `category`              | `staking`                                     |
+| `delegator`             | {delegatorAccountAddress}                     |
+| `source-validator`      | {srcOperatorAddress}                          |
+| `destination-validator` | {dstOperatorAddress}                          |

 ## Handlers

 ### MsgCreateValidator

-| Key                   | Value                |
-|-----------------------|----------------------|
-| destination-validator | {dstOperatorAddress} |
-| moniker               | {validatorMoniker}   |
-| identity              | {validatorIdentity}  |
+| Key        | Value                |
+|------------|----------------------|
+| `action`   | `create_validator`   |
+| `category` | `staking`            |
+| `sender`   | {dstOperatorAddress} |

 ### MsgEditValidator

-| Key                   | Value                |
-|-----------------------|----------------------|
-| destination-validator | {dstOperatorAddress} |
-| moniker               | {validatorMoniker}   |
-| identity              | {validatorIdentity}  |
+| Key        | Value                |
+|------------|----------------------|
+| `action`   | `edit_validator`     |
+| `category` | `staking`            |
+| `sender`   | {dstOperatorAddress} |

 ### MsgDelegate

-| Key                   | Value                                     |
-|-----------------------|-------------------------------------------|
-| delegator             | {delegatorAccountAddress}                 |
-| destination-validator | {dstOperatorAddress}                      |
+| Key                     | Value                     |
+|-------------------------|---------------------------|
+| `action`                | `delegate`                |
+| `category`              | `staking`                 |
+| `sender`                | {delegatorAccountAddress} |
+| `destination-validator` | {dstOperatorAddress}      |

 ### MsgBeginRedelegate

-| Key                   | Value                                     |
-|-----------------------|-------------------------------------------|
-| delegator             | {delegatorAccountAddress}                 |
-| source-validator      | {srcOperatorAddress}                      |
-| destination-validator | {dstOperatorAddress}                      |
-| end-time [0]          | {delegationFinishTime}                    |
+| Key                     | Value                     |
+|-------------------------|---------------------------|
+| `action`                | `begin_redelegate`        |
+| `category`              | `staking`                 |
+| `sender`                | {delegatorAccountAddress} |
+| `source-validator`      | {srcOperatorAddress}      |
+| `destination-validator` | {dstOperatorAddress}      |
+| `end-time` [0]          | {delegationFinishTime}    |

 * [0] Time is formatted in the RFC3339 standard

 ### MsgUndelegate

-| Key              | Value                     |
-|------------------|---------------------------|
-| delegator        | {delegatorAccountAddress} |
-| source-validator | {srcOperatorAddress}      |
-| end-time [0]     | {delegationFinishTime}    |
+| Key                | Value                     |
+|--------------------|---------------------------|
+| `action`           | `begin_unbonding`         |
+| `category`         | `staking`                 |
+| `sender`           | {delegatorAccountAddress} |
+| `source-validator` | {srcOperatorAddress}      |
+| `end-time` [0]     | {delegationFinishTime}    |

 * [0] Time is formatted in the RFC3339 standard
@@ -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)。
+
+![high-level](../../../../clients/lite/pics/high-level.png)
+
+预计所有应用程序仅依赖于 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 检测到不同的验证人集，它将验证它并将可信的验证人集保存到信任库中。
+
+![validator-set-change](../../../../clients/lite/pics/validatorSetChange.png)
+
+### 信任传播
+
+从上面的小节中，我们了解了如何获得可信验证器集以及 LCD 如何跟踪验证人集演化。 验证人集是信任的基础，信任可以传播到其他区块链数据，例如块和交易。 传播架构如下所示：
+
+![change-process](../../../../clients/lite/pics/trustPropagate.png)
+
+通常，通过可信验证人集，轻客户端可以验证包含所有预提交数据和块头数据的每个提交块。 此时块哈希、数据哈希和应用哈希是可信的。 基于此和默克尔证明，所有交易数据和 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，它将包含在块头中。
+
+![Simple Merkle Tree](../../../../clients/lite/pics/simpleMerkleTree.png)
+
+正如我们在[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 叶子节点的路径
+}
+```
+
+存在证据的数据结构如上所示。 构建和验证存在证明的过程如下所示：
+
+![Exist Proof](../../../../clients/lite/pics/existProof.png)
+
+构建证明的步骤：
+
+* 从根节点访问IAVL树
+* 记录 InnerNodes 中的访问节点
+* 找到目标叶节点后，将叶节点版本赋值给证明版本
+* 将当前 IAVL 树高赋值给证明高度
+* 将当前 IAVL 树根哈希赋值给证明根哈希
+* 将当前的子目录名称赋值给证明 StoreName
+* 从 multistore 读取指定高度的 commitInfo 并将其赋值给证明 StoreCommitInfo
+
+验证证明的步骤：
+
+* 使用证明版本中的键、值构建叶节点
+* 计算叶节点哈希
+* 将哈希值分配给第一个 innerNode 的 rightHash，然后计算第一个 innerNode 哈希值
+* 传播哈希计算过程。 如果先前的 innerNode 是下一个 innerNode 的左子节点，则将先前的 innerNode 散列分配给下一个 innerNode 的左散列。否则，将先前的 innerNode 散列分配给下一个innerNode的右散列
+* 最后 innerNode 的哈希应该等于此证明的根哈希， 否则证明无效。
+
+###  IAVL 缺席证明
+
+众所周知，所有 IAVL 叶节点都按每个叶节点的密钥排序。 因此，我们可以在 IAVL 树的整个密钥集中计算出目标密钥的位置。 如下图所示，我们可以找到左键和右键。 如果我们可以证明左键和右键肯定存在，并且它们是相邻的节点，那么目标密钥肯定不存在。
+
+![Absence Proof1](../../../../clients/lite/pics/absence1.png)
+
+如果目标密钥大于最右边的叶节点或小于最左边的叶子节点，则目标密钥肯定不存在。
+
+![Absence Proof2](../../../../clients/lite/pics/absence2.png)![Absence Proof3](../../../../clients/lite/pics/absence3.png)
+
+```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。
+
+![substore proof](../../../../clients/lite/pics/substoreProof.png)
+
+```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 可信验证人集验证特定高度的区块头。 验证流程如下所示：
+
+![commit verification](../../../../clients/lite/pics/commitValidation.png)
+
+当可信验证人集与区块头不匹配时，我们需要尝试将验证人集更新为此块的高度。 LCD 有一条规则，即每个验证人集的变化不应超过1/3投票权。 如果目标验证人集的投票权变化超过1/3，则与可信验证人集进行比较。 我们必须验证，在目标验证人集之前是否存在隐含的验证人集变更。 只有当所有验证人集变更都遵循这条规则时，才能完成验证人集的更新。
+
+例如：
+
+![Update validator set to height](../../../../clients/lite/pics/updateValidatorToHeight.png)
+
+* 更新到 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>)
+
@@ -11,6 +11,7 @@ mkdir -p $HOME/go/bin
 echo "export GOPATH=$HOME/go" >> ~/.bash_profile
 echo "export GOBIN=\$GOPATH/bin" >> ~/.bash_profile
 echo "export PATH=\$PATH:\$GOBIN" >> ~/.bash_profile
+echo "export GO111MODULE=on" >> ~/.bash_profile
 source ~/.bash_profile
 ```

@@ -48,7 +49,7 @@ $ gaiacli version --long
 ```
 cosmos-sdk: 0.33.0
 git commit: 7b4104aced52aa5b59a96c28b5ebeea7877fc4f0
-vendor hash: 5db0df3e24cf10545c84f462a24ddc61882aa58f
+go.sum hash: d156153bd5e128fec3868eca9a1397a63a864edb5cfa0ac486db1b574b8eecfe
 build tags: netgo ledger
 go version go1.12 linux/amd64
 ```
@@ -63,4 +64,4 @@ build tags指定了可执行程序具有的特殊特性。
 | ledger    | 支持Ledger设备(硬件钱包) |

 ### 接下来
-然后你可以选择 加入公共测试网 或是 创建私有测试网。
+然后你可以选择 加入公共测试网 或是 创建私有测试网。
@@ -11,6 +11,7 @@ mkdir -p $HOME/go/bin
 echo "export GOPATH=$HOME/go" >> ~/.bash_profile
 echo "export GOBIN=\$GOPATH/bin" >> ~/.bash_profile
 echo "export PATH=\$PATH:\$GOBIN" >> ~/.bash_profile
+echo "export GO111MODULE=on" >> ~/.bash_profile
 source ~/.bash_profile
 ```