Merge PR #4089: Update docs from release/v0.34.0
This commit is contained in:
Alexander Bezobchuk
GitHub
parent
fa8e0823f7
commit
eb94252011
@ -1,6 +1,6 @@
|
||||
# Gaia Documentation
|
||||
# Cosmos Hub Documentation
|
||||
|
||||
Welcome to the `Gaia` docs. `Gaia` is the current name of the Cosmos SDK application for the Cosmos Hub.
|
||||
Welcome to the documentation of the **Cosmos Hub application: `gaia`**.
|
||||
|
||||
## Join the Cosmos Hub Mainnet
|
||||
|
||||
@ -12,11 +12,11 @@ Welcome to the `Gaia` docs. `Gaia` is the current name of the Cosmos SDK applica
|
||||
|
||||
- [Join the testnet](./join-testnet.md)
|
||||
|
||||
## Setup your own `gaia` testnet
|
||||
## Setup Your Own `gaia` Testnet
|
||||
|
||||
- [Setup your own `gaia` testnet](./deploy-testnet.md)
|
||||
|
||||
## Additional resources
|
||||
## Additional Resources
|
||||
|
||||
- [Intro to validators](./validators/overview.md)
|
||||
- [Validator FAQ](./validators/validator-faq.md)
|
||||
@ -27,22 +27,22 @@ of any kind.
|
||||
|
||||
Please exercise extreme caution!
|
||||
|
||||
## Table of contents
|
||||
## Table of Contents
|
||||
|
||||
- [Installing `gaiacli`](#installing-gaiacli)
|
||||
- [Cosmos Accounts](#cosmos-accounts)
|
||||
+ [Restoring an account from the fundraiser](#restoring-an-account-from-the-fundraiser)
|
||||
+ [Creating an account](#creating-an-account)
|
||||
- [Accessing the Cosmos Hub network](#accessing-the-cosmos-hub-network)
|
||||
+ [Running your own full-node](#running-your-own-full-node)
|
||||
+ [Connecting to a remote full-node](#connecting-to-a-remote-full-node)
|
||||
- [Setting up `gaiacli`](#setting-up-gaiacli)
|
||||
- [Querying the state](#querying-the-state)
|
||||
+ [Restoring an Account from the Fundraiser](#restoring-an-account-from-the-fundraiser)
|
||||
+ [Creating an Account](#creating-an-account)
|
||||
- [Accessing the Cosmos Hub Network](#accessing-the-cosmos-hub-network)
|
||||
+ [Running Your Own Full-Node](#running-your-own-full-node)
|
||||
+ [Connecting to a Remote Full-Node](#connecting-to-a-remote-full-node)
|
||||
- [Setting Up `gaiacli`](#setting-up-gaiacli)
|
||||
- [Querying the State](#querying-the-state)
|
||||
- [Sending Transactions](#sending-transactions)
|
||||
+ [A note on gas and fees](#a-note-on-gas-and-fees)
|
||||
+ [Bonding Atoms and Withdrawing rewards](#bonding-atoms-and-withdrawing-rewards)
|
||||
+ [A Note on Gas and Fees](#a-note-on-gas-and-fees)
|
||||
+ [Bonding Atoms and Withdrawing Rewards](#bonding-atoms-and-withdrawing-rewards)
|
||||
+ [Participating in Governance](#participating-in-governance)
|
||||
+ [Signing transactions from an offline computer](#signing-transactions-from-an-offline-computer)
|
||||
+ [Signing Transactions from an Offline Computer](#signing-transactions-from-an-offline-computer)
|
||||
|
||||
## Installing `gaiacli`
|
||||
|
||||
@ -109,7 +109,7 @@ The funds stored in an account are controlled by the private key. This private k
|
||||
|
||||
The address is a public string with a human-readable prefix (e.g. `cosmos10snjt8dmpr5my0h76xj48ty80uzwhraqalu4eg`) that identifies your account. When someone wants to send you funds, they send it to your address. It is computationally infeasible to find the private key associated with a given address.
|
||||
|
||||
### Restoring an account from the fundraiser
|
||||
### Restoring an Account from the Fundraiser
|
||||
|
||||
::: tip
|
||||
*NOTE: This section only concerns fundraiser participants*
|
||||
@ -117,7 +117,7 @@ The address is a public string with a human-readable prefix (e.g. `cosmos10snjt8
|
||||
|
||||
If you participated in the fundraiser, you should be in possession of a 12-words mnemonic. Newly generated mnemonics use 24 words, but 12-word mnemonics are also compatible with all the Cosmos tools.
|
||||
|
||||
#### On a ledger device
|
||||
#### On a Ledger Device
|
||||
|
||||
At the core of a ledger device, there is a mnemonic used to generate accounts on multiple blockchains (including the Cosmos Hub). Usually, you will create a new mnemonic when you initialize your ledger device. However, it is possible to tell the ledger device to use a mnemonic provided by the user instead. Let us go ahead and see how you can input the mnemonic you obtained during the fundraiser as the seed of your ledger device.
|
||||
|
||||
@ -138,7 +138,7 @@ Your ledger is now correctly set up with your fundraiser mnemonic! Do not lose t
|
||||
|
||||
Next, click [here](#using-a-ledger-device) to learn how to generate an account.
|
||||
|
||||
#### On a computer
|
||||
#### On a Computer
|
||||
|
||||
::: warning
|
||||
**NOTE: It is more secure to perform this action on an offline computer**
|
||||
@ -155,11 +155,11 @@ You will be prompted to input a passphrase that is used to encrypt the private k
|
||||
- `<yourKeyName>` is the name of the account. It is a reference to the account number used to derive the key pair from the mnemonic. You will use this name to identify your account when you want to send a transaction.
|
||||
- You can add the optional `--account` flag to specify the path (`0`, `1`, `2`, ...) you want to use to generate your account. By default, account `0` is generated.
|
||||
|
||||
### Creating an account
|
||||
### Creating an Account
|
||||
|
||||
To create an account, you just need to have `gaiacli` installed. Before creating it, you need to know where you intend to store and interact with your private keys. The best options are to store them in an offline dedicated computer or a ledger device. Storing them on your regular online computer involves more risk, since anyone who infiltrates your computer through the internet could exfiltrate your private keys and steal your funds.
|
||||
|
||||
#### Using a ledger device
|
||||
#### Using a Ledger Device
|
||||
|
||||
::: warning
|
||||
**Only use Ledger devices that you bought factory new or trust fully**
|
||||
@ -185,7 +185,7 @@ gaiacli keys add <yourAccountName> --ledger
|
||||
- `<yourKeyName>` is the name of the account. It is a reference to the account number used to derive the key pair from the mnemonic. You will use this name to identify your account when you want to send a transaction.
|
||||
- You can add the optional `--account` flag to specify the path (`0`, `1`, `2`, ...) you want to use to generate your account. By default, account `0` is generated.
|
||||
|
||||
#### Using a computer
|
||||
#### Using a Computer
|
||||
|
||||
::: warning
|
||||
**NOTE: It is more secure to perform this action on an offline computer**
|
||||
@ -225,7 +225,7 @@ gaiacli keys add <yourKeyName> --recover --account 1
|
||||
This command will prompt you to input a passphrase as well as your mnemonic. Change the account number to generate a different account.
|
||||
|
||||
|
||||
## Accessing the Cosmos Hub network
|
||||
## Accessing the Cosmos Hub Network
|
||||
|
||||
In order to query the state and send transactions, you need a way to access the network. To do so, you can either run your own full-node, or connect to someone else's.
|
||||
|
||||
@ -233,19 +233,19 @@ In order to query the state and send transactions, you need a way to access the
|
||||
**NOTE: Do not share your mnemonic (12 or 24 words) with anyone. The only person who should ever need to know it is you. This is especially important if you are ever approached via email or direct message by someone requesting that you share your mnemonic for any kind of blockchain services or support. No one from Cosmos, the Tendermint team or the Interchain Foundation will ever send an email that asks for you to share any kind of account credentials or your mnemonic."**.
|
||||
:::
|
||||
|
||||
### Running your own full-node
|
||||
### Running Your Own Full-Node
|
||||
|
||||
This is the most secure option, but comes with relatively high resource requirements. In order to run your own full-node, you need good bandwidth and at least 1TB of disk space.
|
||||
|
||||
You will find the tutorial on how to install `gaiad` [here](https://cosmos.network/docs/gaia/installation.html), and the guide to run a full-node [here](https://cosmos.network/docs/gaia/join-mainnet.html).
|
||||
|
||||
### Connecting to a remote full-node
|
||||
### Connecting to a Remote Full-Node
|
||||
|
||||
If you do not want or cannot run your own node, you can connect to someone else's full-node. You should pick an operator you trust, because a malicious operator could return incorrect query results or censor your transactions. However, they will never be able to steal your funds, as your private keys are stored locally on your computer or ledger device. Possible options of full-node operators include validators, wallet providers or exchanges.
|
||||
|
||||
In order to connect to the full-node, you will need an address of the following form: `https://77.87.106.33:26657` (*Note: This is a placeholder*). This address has to be communicated by the full-node operator you choose to trust. You will use this address in the [following section](#setting-up-gaiacli).
|
||||
|
||||
## Setting up `gaiacli`
|
||||
## Setting Up `gaiacli`
|
||||
|
||||
::: tip
|
||||
**Before setting up `gaiacli`, make sure you have set up a way to [access the Cosmos Hub network](#accessing-the-cosmos-hub-network)**
|
||||
@ -289,7 +289,7 @@ Finally, let us set the `chain-id` of the blockchain we want to interact with:
|
||||
gaiacli config chain-id cosmoshub-1
|
||||
```
|
||||
|
||||
## Querying the state
|
||||
## Querying the State
|
||||
|
||||
::: tip
|
||||
**Before you can bond atoms and withdraw rewards, you need to [set up `gaiacli`](#setting-up-gaiacli)**
|
||||
@ -340,7 +340,7 @@ For each command, you can use the `-h` or `--help` flag to get more information.
|
||||
On Cosmos Hub mainnet, the accepted denom is `uatom`, where `1atom = 1,000,000uatom`
|
||||
:::
|
||||
|
||||
### A note on gas and fees
|
||||
### A Note on Gas and Fees
|
||||
|
||||
Transactions on the Cosmos Hub network need to include a transaction fee in order to be processed. This fee pays for the gas required to run the transaction. The formula is the following:
|
||||
|
||||
@ -358,7 +358,7 @@ The transaction `fees` are the product of `gas` and `gasPrice`. As a user, you h
|
||||
For mainnet, the recommended `gas-prices` is `0.025uatom`.
|
||||
:::
|
||||
|
||||
### Bonding Atoms and Withdrawing rewards
|
||||
### Bonding Atoms and Withdrawing Rewards
|
||||
|
||||
::: tip
|
||||
**Before you can bond atoms and withdraw rewards, you need to [set up `gaiacli`](#setting-up-gaiacli) and [create an account](#creating-an-account)**
|
||||
@ -379,6 +379,14 @@ For mainnet, the recommended `gas-prices` is `0.025uatom`.
|
||||
gaiacli tx staking delegate <validatorAddress> <amountToBond> --from <delegatorKeyName> --gas auto --gas-adjustment 1.5 --gas-prices <gasPrice>
|
||||
|
||||
|
||||
// Redelegate a certain amount of Atoms from a validator to another
|
||||
// Can only be used if already bonded to a validator
|
||||
// Redelegation takes effect immediately, there is no waiting period to redelegate
|
||||
// After a redelegation, no other redelegation can be made from the account for the next 3 weeks
|
||||
// ex value for flags: <stcValidatorAddress>=cosmosvaloper18thamkhnj9wz8pa4nhnp9rldprgant57pk2m8s, <amountToRedelegate>=100000000uatom, <gasPrice>=0.025uatom
|
||||
|
||||
gaiacli tx staking redelegate <srcValidatorAddress> <destValidatorAddress> <amountToRedelegate> --from <delegatorKeyName> --gas auto --gas-adjustment 1.5 --gas-prices <gasPrice>
|
||||
|
||||
// Withdraw all rewards
|
||||
// ex value for flag: <gasPrice>=0.025uatom
|
||||
|
||||
@ -413,9 +421,9 @@ gaiacli query tx <txHash>
|
||||
|
||||
Double check with a block explorer if you interact with the network through a trusted full-node.
|
||||
|
||||
## Participating in governance
|
||||
## Participating in Governance
|
||||
|
||||
#### Primer on governance
|
||||
#### Primer on Governance
|
||||
|
||||
The Cosmos Hub has a built-in governance system that lets bonded Atom holders vote on proposals. There are three types of proposal:
|
||||
|
||||
@ -429,7 +437,7 @@ Once the `deposit` reaches `minDeposit`, the proposal enters the `voting_period`
|
||||
|
||||
At the end of the voting period, the proposal is accepted if there are more than 50% `Yes` votes (excluding `Abstain ` votes) and less than 33.33% of `NoWithVeto` votes (excluding `Abstain` votes).
|
||||
|
||||
#### In practice
|
||||
#### In Practice
|
||||
|
||||
::: tip
|
||||
**Before you can bond atoms and withdraw rewards, you need to [bond Atoms](#bonding-atoms-and-withdrawing-rewards)**
|
||||
@ -459,7 +467,7 @@ gaiacli tx gov deposit <proposalID> <deposit> --gas auto --gas-adjustment 1.5 --
|
||||
gaiacli tx gov vote <proposalID> <option> --gas auto --gas-adjustment 1.5 --gas-prices <gasPrice> --from <delegatorKeyName>
|
||||
```
|
||||
|
||||
### Signing transactions from an offline computer
|
||||
### Signing Transactions From an Offline Computer
|
||||
|
||||
If you do not have a ledger device and want to interact with your private key on an offline computer, you can use the following procedure. First, generate an unsigned transaction on an **online computer** with the following command (example with a bonding transaction):
|
||||
|
||||
@ -470,15 +478,9 @@ If you do not have a ledger device and want to interact with your private key on
|
||||
gaiacli tx staking delegate <validatorAddress> <amountToBond> --from <delegatorAddress> --gas auto --gas-adjustment 1.5 --gas-prices <gasPrice> --generate-only > unsignedTX.json
|
||||
```
|
||||
|
||||
<<<<<<< HEAD
|
||||
In order to sign, you will also need the `chain-id`, `account-number` and `sequence`. The `chain-id` is a unique identifier for the blockchain on which you are submitting the transaction. The `account-number` is an identifier generated when your account first receives funds. The `sequence` number is used to keep track of the number of transactions you have sent and prevent replay attacks.
|
||||
|
||||
Get the chain-id from the genesis file (`cosmoshub-1`), and the two other fields using the account query:
|
||||
=======
|
||||
In order to sign, you will also need the `chain-id`, `account-number` and `sequence`. The `account-number` is an identifier generated when your account first receives funds. The `sequence` number is used to keep track of the number of transactions you have sent and prevent replay attacks.
|
||||
|
||||
Get the chain-id from the genesis file (`cosmoshub-1`), and the two other information using the `account query`:
|
||||
>>>>>>> 6371dacb... docs offline procedure improvment + other minor fixes
|
||||
|
||||
```bash
|
||||
gaiacli query account <yourAddress> --chain-id cosmoshub-1
|
||||
@ -490,11 +492,7 @@ Then, copy `unsignedTx.json` and transfer it (e.g. via USB) to the offline compu
|
||||
cat unsignedTx.json
|
||||
```
|
||||
|
||||
<<<<<<< HEAD
|
||||
Now, sign the transaction using the following command. You will need the `chain-id`, `sequence` and `account-number` obtained earlier:
|
||||
=======
|
||||
Now, sign the transaction using the following command. You will need the `chaind-id`, `sequence` and `account-number` obtained earlier:
|
||||
>>>>>>> 6371dacb... docs offline procedure improvment + other minor fixes
|
||||
|
||||
```bash
|
||||
gaiacli tx sign unsignedTx.json --from <delegatorKeyName> --offline --chain-id cosmoshub-1 --sequence <sequence> --account-number <account-number> > signedTx.json
|
||||
@ -1,4 +1,4 @@
|
||||
# Deploy your own testnet
|
||||
# Deploy Your Own Testnet
|
||||
|
||||
This document describes 3 ways to setup a network of `gaiad` nodes, each serving a different usecase:
|
||||
|
||||
@ -20,7 +20,7 @@ In case you need to use or deploy gaia as a container you could skip the `build`
|
||||
|
||||
The same images can be used to build your own docker-compose stack.
|
||||
|
||||
## Single-node, local, manual testnet
|
||||
## Single-node, Local, Manual Testnet
|
||||
|
||||
This guide helps you create a single validator node that runs a network locally for testing and other development related uses.
|
||||
|
||||
@ -29,7 +29,7 @@ This guide helps you create a single validator node that runs a network locally
|
||||
- [Install gaia](./installation.md)
|
||||
- [Install `jq`](https://stedolan.github.io/jq/download/) (optional)
|
||||
|
||||
### Create genesis file and start the network
|
||||
### Create Genesis File and Start the Network
|
||||
|
||||
```bash
|
||||
# You can run all of these commands from your home directory
|
||||
@ -58,7 +58,7 @@ gaiad start
|
||||
|
||||
This setup puts all the data for `gaiad` in `~/.gaiad`. You can examine the genesis file you created at `~/.gaiad/config/genesis.json`. With this configuration `gaiacli` is also ready to use and has an account with tokens (both staking and custom).
|
||||
|
||||
## Multi-node, local, automated testnet
|
||||
## Multi-node, Local, Automated Testnet
|
||||
|
||||
From the [networks/local directory](https://github.com/cosmos/cosmos-sdk/tree/develop/networks/local):
|
||||
|
||||
@ -83,7 +83,7 @@ make build-linux
|
||||
make build-docker-gaiadnode
|
||||
```
|
||||
|
||||
### Run your testnet
|
||||
### Run Your Testnet
|
||||
|
||||
To start a 4 node testnet run:
|
||||
|
||||
@ -181,7 +181,7 @@ funds!
|
||||
**Note**: Each node's seed is located at `./build/nodeN/gaiacli/key_seed.json` and can be restored to the CLI using the `gaiacli keys add --restore` command
|
||||
:::
|
||||
|
||||
### Special binaries
|
||||
### Special Binaries
|
||||
|
||||
If you have multiple binaries with different names, you can specify which one to run with the BINARY environment variable. The path of the binary is relative to the attached volume. For example:
|
||||
|
||||
@ -190,7 +190,7 @@ If you have multiple binaries with different names, you can specify which one to
|
||||
BINARY=gaiafoo make localnet-start
|
||||
```
|
||||
|
||||
## Multi-node, remote, automated testnet
|
||||
## Multi-Node, Remote, Automated Testnet
|
||||
|
||||
The following should be run from the [networks directory](https://github.com/cosmos/cosmos-sdk/tree/develop/networks).
|
||||
|
||||
@ -216,7 +216,7 @@ export SSH_PUBLIC_FILE="$HOME/.ssh/id_rsa.pub"
|
||||
|
||||
These will be used by both `terraform` and `ansible`.
|
||||
|
||||
### Create a remote network
|
||||
### Create a Remote Network
|
||||
|
||||
```
|
||||
SERVERS=1 REGION_LIMIT=1 make validators-start
|
||||
@ -228,13 +228,13 @@ The testnet name is what's going to be used in --chain-id, while the cluster nam
|
||||
./new-testnet.sh "$TESTNET_NAME" "$CLUSTER_NAME" 1 1
|
||||
```
|
||||
|
||||
### Quickly see the /status endpoint
|
||||
### Quickly see the /status Endpoint
|
||||
|
||||
```
|
||||
make validators-status
|
||||
```
|
||||
|
||||
### Delete servers
|
||||
### Delete Servers
|
||||
|
||||
```
|
||||
make validators-stop
|
||||
@ -1,4 +1,4 @@
|
||||
# Gaia client
|
||||
# Gaia Client
|
||||
|
||||
## Gaia CLI
|
||||
|
||||
@ -97,7 +97,7 @@ Note that this is the Tendermint signing key, _not_ the operator key you will us
|
||||
We strongly recommend _NOT_ using the same passphrase for multiple keys. The Tendermint team and the Interchain Foundation will not be responsible for the loss of funds.
|
||||
:::
|
||||
|
||||
#### Generate multisig public keys
|
||||
#### Generate Multisig Public Keys
|
||||
|
||||
You can generate and print a multisig public key by typing:
|
||||
|
||||
@ -154,7 +154,7 @@ txs by `gasPrice` in the mempool, so providing higher fees or gas prices may yie
|
||||
e.g.
|
||||
|
||||
```bash
|
||||
gaiacli tx send ... --fees=1000000uatom
|
||||
gaiacli tx send ... --fees=50000uatom
|
||||
```
|
||||
|
||||
or
|
||||
@ -169,7 +169,7 @@ gaiacli tx send ... --gas-prices=0.025uatom
|
||||
|
||||
The best way to get tokens is from the [Cosmos Testnet Faucet](https://faucetcosmos.network). If the faucet is not working for you, try asking [#cosmos-validators](https://riot.im/app/#/room/#cosmos-validators:matrix.org). The faucet needs the `cosmos` from the account you wish to use for staking.
|
||||
|
||||
#### Query Account balance
|
||||
#### Query Account Balance
|
||||
|
||||
After receiving tokens to your address, you can view your account's balance by typing:
|
||||
|
||||
@ -256,7 +256,7 @@ gaiacli tx broadcast --node=<node> signedSendTx.json
|
||||
|
||||
### Query Transactions
|
||||
|
||||
#### Matching a set of tags
|
||||
#### Matching a Set of Tags
|
||||
|
||||
You can use the transaction search command to query for transactions that match a specific set of `tags`, which are added on every transaction.
|
||||
|
||||
@ -293,7 +293,7 @@ You can find a list of available `tags` on each of the SDK modules:
|
||||
- [Bank tags](https://github.com/cosmos/cosmos-sdk/blob/d1e76221d8e28824bb4791cb4ad8662d2ae9051e/x/bank/keeper.go#L193-L206)
|
||||
:::
|
||||
|
||||
#### Matching a transaction's hash
|
||||
#### Matching a Transaction's Hash
|
||||
|
||||
You can also query a single transaction by its hash using the following command:
|
||||
|
||||
@ -533,7 +533,7 @@ Some considerations about the voting process:
|
||||
|
||||
For more information about the governance process and how it works, please check out the Governance module [specification](./../spec/governance).
|
||||
|
||||
#### Create a Governance proposal
|
||||
#### Create a Governance Proposal
|
||||
|
||||
In order to create a governance proposal, you must submit an initial deposit along with the proposal details:
|
||||
|
||||
@ -551,7 +551,7 @@ gaiacli tx gov submit-proposal \
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
##### Query proposals
|
||||
##### Query Proposals
|
||||
|
||||
Once created, you can now query information of the proposal:
|
||||
|
||||
@ -573,9 +573,9 @@ To query for the proposer of a given governance proposal:
|
||||
gaiacli query gov proposer <proposal_id>
|
||||
```
|
||||
|
||||
#### Increase deposit
|
||||
#### Increase Deposit
|
||||
|
||||
In order for a proposal to be broadcasted to the network, the amount deposited must be above a `minDeposit` value (default: `512000000uatom`). If the proposal you previously created didn't meet this requirement, you can still increase the total amount deposited to activate it. Once the minimum deposit is reached, the proposal enters voting period:
|
||||
In order for a proposal to be broadcasted to the network, the amount deposited must be above a `minDeposit` value (initial value: `512000000uatom`). If the proposal you previously created didn't meet this requirement, you can still increase the total amount deposited to activate it. Once the minimum deposit is reached, the proposal enters voting period:
|
||||
|
||||
```bash
|
||||
gaiacli tx gov deposit <proposal_id> "10000000uatom" \
|
||||
@ -585,7 +585,7 @@ gaiacli tx gov deposit <proposal_id> "10000000uatom" \
|
||||
|
||||
> _NOTE_: Proposals that don't meet this requirement will be deleted after `MaxDepositPeriod` is reached.
|
||||
|
||||
##### Query deposits
|
||||
##### Query Deposits
|
||||
|
||||
Once a new proposal is created, you can query all the deposits submitted to it:
|
||||
|
||||
@ -599,7 +599,7 @@ You can also query a deposit submitted by a specific address:
|
||||
gaiacli query gov deposit <proposal_id> <depositor_address>
|
||||
```
|
||||
|
||||
#### Vote on a proposal
|
||||
#### Vote on a Proposal
|
||||
|
||||
After a proposal's deposit reaches the `MinDeposit` value, the voting period opens. Bonded `Atom` holders can then cast vote on it:
|
||||
|
||||
@ -609,7 +609,7 @@ gaiacli tx gov vote <proposal_id> <Yes/No/NoWithVeto/Abstain> \
|
||||
--chain-id=<chain_id>
|
||||
```
|
||||
|
||||
##### Query votes
|
||||
##### Query Votes
|
||||
|
||||
Check the vote with the option you just submitted:
|
||||
|
||||
@ -631,7 +631,7 @@ To check the current tally of a given proposal you can use the `tally` command:
|
||||
gaiacli query gov tally <proposal_id>
|
||||
```
|
||||
|
||||
#### Query governance parameters
|
||||
#### Query Governance Parameters
|
||||
|
||||
To check the current governance parameters run:
|
||||
|
||||
@ -649,7 +649,7 @@ gaiacli query gov param deposit
|
||||
|
||||
### Fee Distribution
|
||||
|
||||
#### Query distribution parameters
|
||||
#### Query Distribution Parameters
|
||||
|
||||
To check the current distribution parameters, run:
|
||||
|
||||
@ -673,7 +673,7 @@ To check the current outstanding (un-withdrawn) rewards, run:
|
||||
gaiacli query distr outstanding-rewards
|
||||
```
|
||||
|
||||
#### Query validator commission
|
||||
#### Query Validator Commission
|
||||
|
||||
To check the current outstanding commission for a validator, run:
|
||||
|
||||
@ -681,7 +681,7 @@ To check the current outstanding commission for a validator, run:
|
||||
gaiacli query distr commission <validator_address>
|
||||
```
|
||||
|
||||
#### Query validator slashes
|
||||
#### Query Validator Slashes
|
||||
|
||||
To check historical slashes for a validator, run:
|
||||
|
||||
@ -689,7 +689,7 @@ To check historical slashes for a validator, run:
|
||||
gaiacli query distr slashes <validator_address> <start_height> <end_height>
|
||||
```
|
||||
|
||||
#### Query delegator rewards
|
||||
#### Query Delegator Rewards
|
||||
|
||||
To check current rewards for a delegation (were they to be withdrawn), run:
|
||||
|
||||
@ -697,7 +697,7 @@ To check current rewards for a delegation (were they to be withdrawn), run:
|
||||
gaiacli query distr rewards <delegator_address> <validator_address>
|
||||
```
|
||||
|
||||
#### Query all delegator rewards
|
||||
#### Query All Delegator Rewards
|
||||
|
||||
To check all current rewards for a delegation (were they to be withdrawn), run:
|
||||
|
||||
@ -705,7 +705,7 @@ To check all current rewards for a delegation (were they to be withdrawn), run:
|
||||
gaiacli query distr rewards <delegator_address>
|
||||
```
|
||||
|
||||
### Multisig transactions
|
||||
### Multisig Transactions
|
||||
|
||||
Multisig transactions require signatures of multiple private keys. Thus, generating and signing
|
||||
a transaction from a multisig account involve cooperation among the parties involved. A multisig
|
||||
@ -797,7 +797,7 @@ The transaction can now be sent to the node:
|
||||
gaiacli tx broadcast signedTx.json
|
||||
```
|
||||
|
||||
## Shells completion scripts
|
||||
## Shells Completion Scripts
|
||||
|
||||
Completion scripts for popular UNIX shell interpreters such as `Bash` and `Zsh`
|
||||
can be generated through the `completion` command, which is available for both
|
||||
332
docs/cosmos-hub/genesis.md
Normal file
332
docs/cosmos-hub/genesis.md
Normal file
@ -0,0 +1,332 @@
|
||||
# Genesis File
|
||||
|
||||
This document explains how the genesis file of the Cosmmos Hub mainnet is structured. It also explains how you can build a genesis file for your own `gaia` testnet.
|
||||
|
||||
Note that you can generate a default genesis file for your own testnet by running the following command:
|
||||
|
||||
```bash
|
||||
gaiad init <moniker> --chain-id <chain-id>
|
||||
```
|
||||
|
||||
The genesis file is stored in `~/.gaiad/config/genesis.toml`.
|
||||
|
||||
## What is a Genesis File
|
||||
|
||||
A genesis file is a JSON file which defines the initial state of your blockchain. It can be seen as height `0` of your blockchain. The first block, at height `1`, will reference the genesis file as its parent.
|
||||
|
||||
The state defined in the genesis file contains all the necessary information, like initial token allocation, genesis time, default parameters, and more. Let us break down these information.
|
||||
|
||||
## Genesis Time and Chain_id
|
||||
|
||||
The `genesis_time` is defined at the top of the genesis file. It is a `UTC` timestamps which specifies when the blockchain is due to start. At this time, genesis validators are supposed to come online and start participating in the consensus process. The blockchain starts when more than 2/3rd of the genesis validators (weighted by voting power) are online.
|
||||
|
||||
```json
|
||||
"genesis_time": "2019-03-13T17:00:00.000000000Z",
|
||||
```
|
||||
|
||||
The `chain_id` is a unique identifier for your chain. It helps differentiate between different chains using the same version of the software.
|
||||
|
||||
```json
|
||||
"chain_id": "cosmoshub-1",
|
||||
```
|
||||
|
||||
## Consensus Parameters
|
||||
|
||||
Next, the genesis file defines consensus parameters. Consensus parameters regroup all the parameters that are related to the consensus layer, which is `Tendermint` in the case of `gaia`. Let us look at these parameters:
|
||||
|
||||
- `block`
|
||||
+ `max_bytes`: Maximum number of bytes per block.
|
||||
+ `max_gas`: Gas limit per block. Each transaction included in the block will consume some gas. The total gas used by transactions included in a block cannot exceed this limit.
|
||||
- `evidence`
|
||||
+ `max_age`: An evidence is a proof that a validator signed two different blocks at the same height (and round). This is an explicitely malicious behaviour that is punished at the state-machine level. The `max_age` defines the maximum number of **blocks** after which an evidence is not valid anymore.
|
||||
- `validator`
|
||||
+ `pub_key_types`: The types of pubkey (`ed25519`, `secp256k1`, ...) that are accepted for validators. Currently only `ed25519` is accepted.
|
||||
|
||||
```json
|
||||
"consensus_params": {
|
||||
"block_size": {
|
||||
"max_bytes": "150000",
|
||||
"max_gas": "1500000"
|
||||
},
|
||||
"evidence": {
|
||||
"max_age": "1000000"
|
||||
},
|
||||
"validator": {
|
||||
"pub_key_types": [
|
||||
"ed25519"
|
||||
]
|
||||
}
|
||||
},
|
||||
```
|
||||
|
||||
## Application State
|
||||
|
||||
The application state defines the initial state of the state-machine.
|
||||
|
||||
### Genesis Accounts
|
||||
|
||||
In this section, initial allocation of tokens is defined. It is possible to add accounts manually by directly editing the genesis file, but it is also possible to use the following command:
|
||||
|
||||
```bash
|
||||
// Example: gaiad add-genesis-account cosmos1qs8tnw2t8l6amtzvdemnnsq9dzk0ag0z37gh3h 10000000uatom
|
||||
|
||||
gaiad add-genesis-account <account-address> <amount><denom>
|
||||
```
|
||||
|
||||
This command creates an item in the `accounts` list, under the `app_state` section.
|
||||
|
||||
```json
|
||||
"accounts": [
|
||||
{
|
||||
"address": "cosmos1qs8tnw2t8l6amtzvdemnnsq9dzk0ag0z37gh3h",
|
||||
"coins": [
|
||||
{
|
||||
"denom": "uatom",
|
||||
"amount": "10000000"
|
||||
}
|
||||
],
|
||||
"sequence_number": "0",
|
||||
"account_number": "0",
|
||||
"original_vesting": [
|
||||
{
|
||||
"denom": "uatom",
|
||||
"amount": "26306000000"
|
||||
}
|
||||
],
|
||||
"delegated_free": null,
|
||||
"delegated_vesting": null,
|
||||
"start_time": "0",
|
||||
"end_time": "10000"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Let us break down the parameters:
|
||||
|
||||
- `sequence_number`: This number is used to count the number of transactions sent by this account. It is incremented each time a transaction is included in a block, and used to prevent replay attacks. Initial value is `0`.
|
||||
- `account_number`: Unique identifier for the account. It is generated the first time a transaction including this account is included in a block.
|
||||
- `original_vesting`: Vesting is natively supported by `gaia`. You can define an amount of token owned by the account that needs to be vested for a period of time before they can be transferred. Vested tokens can be delegated. Default value is `null`.
|
||||
- `delegated_free`: Amount of delegated tokens that can be transferred after they've been vested. Most of the time, will be `null` in genesis.
|
||||
- `delegated_vesting`: Amount of delegated tokens that are still vesting. Most of the time, will be `null` in genesis.
|
||||
- `start_time`: Block at which the vesting period starts. `0` most of the time in genesis.
|
||||
- `end_time`: Block at which the vesting period ends. `0` if no vesting for this account.
|
||||
|
||||
### Bank
|
||||
|
||||
The `bank` module handles tokens. The only parameter that needs to be defined in this section is wether `transfers` are enabled at genesis or not.
|
||||
|
||||
```json
|
||||
"bank": {
|
||||
"send_enabled": false
|
||||
}
|
||||
```
|
||||
|
||||
### Staking
|
||||
|
||||
The `staking` module handles the bulk of the Proof-of-Stake logic of the state-machine. This section should look like the following:
|
||||
|
||||
```json
|
||||
"staking": {
|
||||
"pool": {
|
||||
"not_bonded_tokens": "10000000",
|
||||
"bonded_tokens": "0"
|
||||
},
|
||||
"params": {
|
||||
"unbonding_time": "1814400000000000",
|
||||
"max_validators": 100,
|
||||
"max_entries": 7,
|
||||
"bond_denom": "uatom"
|
||||
},
|
||||
"last_total_power": "0",
|
||||
"last_validator_powers": null,
|
||||
"validators": null,
|
||||
"bonds": null,
|
||||
"unbonding_delegations": null,
|
||||
"redelegations": null,
|
||||
"exported": false
|
||||
}
|
||||
```
|
||||
|
||||
Let us break down the parameters:
|
||||
|
||||
- `pool`
|
||||
+ `not_bonded_tokens`: Defines the amount of tokens not bonded (i.e. delegated) in genesis. Generally, it equals the total supply of the staking token (`uatom` in this example).
|
||||
+ `bonded_tokens`: Amount of bonded tokens in genesis. Generally `0`.
|
||||
- `params`
|
||||
+ `unbonding_time`: Time in **nanosecond** it takes for tokens to complete unbonding.
|
||||
+ `max_validators`: Maximum number of active validators.
|
||||
+ `max_entries`: Maximum unbonding delegations and redelegations between a particular pair of delegator / validator.
|
||||
+ `bond_denom`: Denomination of the staking token.
|
||||
- `last_total_power`: Total amount of voting power. Generally `0` in genesis (except if genesis was generated using a previous state).
|
||||
- `last_validator_powers`: Power of each validator in last known state. Generally `null` in genesis (except if genesis was generated using a previous state).
|
||||
- `validators`: List of last knoww validators. Generally `null` in genesis (except if genesis was generated using a previous state).
|
||||
- `bonds`: List of last known delegation. Generally `null` in genesis (except if genesis was generated using a previous state).
|
||||
- `unbonding_delegations`: List of last known unbonding delegations. Generally `null` in genesis (except if genesis was generated using a previous state).
|
||||
- `redelegations`: List of last known redelegations. Generally `null` in genesis (except if genesis was generated using a previous state).
|
||||
- `exported`: Wether this genesis was generated using the export of a previous state.
|
||||
|
||||
### Mint
|
||||
|
||||
The `mint` module governs the logic of inflating the supply of token. The `mint` section in the genesis file looks like the follwing:
|
||||
|
||||
```json
|
||||
"mint": {
|
||||
"minter": {
|
||||
"inflation": "0.070000000000000000",
|
||||
"annual_provisions": "0.000000000000000000"
|
||||
},
|
||||
"params": {
|
||||
"mint_denom": "uatom",
|
||||
"inflation_rate_change": "0.130000000000000000",
|
||||
"inflation_max": "0.200000000000000000",
|
||||
"inflation_min": "0.070000000000000000",
|
||||
"goal_bonded": "0.670000000000000000",
|
||||
"blocks_per_year": "6311520"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Let us break down the parameters:
|
||||
|
||||
- `minter`
|
||||
+ `inflation`: Initial yearly percentage of increase in the total supply of staking token, compounded weekly. A `0.070000000000000000` value means the target is `7%` yearly inflation, compounded weekly.
|
||||
+ `annual_provisions`: Calculated each block. Initialize at `0.000000000000000000`.
|
||||
- `params`
|
||||
+ `mint_denom`: Denom of the staking token that is inflated.
|
||||
+ `inflation_rate_change`: Max yearly change in inflation.
|
||||
+ `inflation_max`: Maximum level of inflation.
|
||||
+ `inflation_min`: Minimum level of inflation.
|
||||
+ `goal_bonded`: Percentage of the total supply that is targeted to be bonded. If the percentage of bonded staking tokens is below this target, the inflation increases (following `inflation_rate_change`) until it reaches `inflation_max`. If the percentage of bonded staking tokens is above this target, the inflation decreases (following `inflation_rate_change`) until it reaches `inflation_min`.
|
||||
+ `blocks_per_year`: Estimation of the amount of blocks per year. Used to compute the block reward coming from inflated staking token (called block provisions).
|
||||
|
||||
### Distribution
|
||||
|
||||
The `distr` module handles the logic of distribution block provisions and fees to validators and delegators. The `distr` section in the genesis file looks like the follwing:
|
||||
|
||||
```json
|
||||
"distr": {
|
||||
"fee_pool": {
|
||||
"community_pool": null
|
||||
},
|
||||
"community_tax": "0.020000000000000000",
|
||||
"base_proposer_reward": "0.010000000000000000",
|
||||
"bonus_proposer_reward": "0.040000000000000000",
|
||||
"withdraw_addr_enabled": false,
|
||||
"delegator_withdraw_infos": null,
|
||||
"previous_proposer": "",
|
||||
"outstanding_rewards": null,
|
||||
"validator_accumulated_commissions": null,
|
||||
"validator_historical_rewards": null,
|
||||
"validator_current_rewards": null,
|
||||
"delegator_starting_infos": null,
|
||||
"validator_slash_events": null
|
||||
}
|
||||
```
|
||||
|
||||
Let us break down the parameters:
|
||||
|
||||
- `fee_pool`
|
||||
+ `community_pool`: The community pool is a pool of tokens that can be used to pay for bounties. It is allocated via governance proposals. Generally `null` in genesis.
|
||||
- `community_tax`: The tax percentage on fees and block rewards that goes to the community pool.
|
||||
- `base_proposer_reward`: Base bonus on transaction fees collected in a valid block that goes to the proposer of block. If value is `0.010000000000000000`, 1% of the fees go to the proposer.
|
||||
- `bonus_proposer_reward`: Max bonus on transaction fees collected in a valid block that goes to the proposer of block. The bonus depends on the number of `precommits` the proposer includes. If the proposer includes 2/3rd `precommits` weighted by voting power (minimum for the block to be valid), they get a bonus of `base_proposer_reward`. This bonus increases linearly up to `bonus_proposer_reward` if the proposer includes 100% of `precommits`.
|
||||
- `withdraw_addr_enabled`: If `true`, delegators can set a different address to withdraw their rewards. Set to `false` if you want to disable transfers at genesis, as it can be used as a way to get around the restriction.
|
||||
- `delegator_withdraw_infos`: List of delegators withdraw address. Generally `null` if genesis was not exported from previous state.
|
||||
- `previous_proposer`: Proposer of the previous block. Set to `""` if genesis was not exported from previous state.
|
||||
- `outstanding_rewards`: Outstanding (un-withdrawn) rewards. Set to `null` if genesis was not exported from previous state.
|
||||
- `validator_accumulated_commission`: Outstanding (un-withdrawn) commission of validators. Set to `null` if genesis was not exported from previous state.
|
||||
- `validator_historical_rewards`: Set of information related to the historical rewards of validators and used by the `distr` module for various computation. Set to `null` if genesis was not exported from previous state.
|
||||
- `validators_current_rewards`: Set of information related to the current rewards of validators and used by the `distr` module for various computation. Set to `null` if genesis was not exported from previous state.
|
||||
- `delegator_starting_infos`: Tracks the previous validator period, the delegation's amount of staking token, and the creation height (to check later on if any slashes have occurred). Set to `null` if genesis was not exported from previous state.
|
||||
- `validator_slash_events`: Set of information related to the past slashing of validators. Set to `null` if genesis was not exported from previous state.
|
||||
|
||||
### Governance
|
||||
|
||||
The `gov` module handles all governance-related transactions. The initial state of the `gov` section looks like the following:
|
||||
|
||||
```json
|
||||
"gov": {
|
||||
"starting_proposal_id": "1",
|
||||
"deposits": null,
|
||||
"votes": null,
|
||||
"proposals": null,
|
||||
"deposit_params": {
|
||||
"min_deposit": [
|
||||
{
|
||||
"denom": "uatom",
|
||||
"amount": "512000000"
|
||||
}
|
||||
],
|
||||
"max_deposit_period": "1209600000000000"
|
||||
},
|
||||
"voting_params": {
|
||||
"voting_period": "1209600000000000"
|
||||
},
|
||||
"tally_params": {
|
||||
"quorum": "0.4",
|
||||
"threshold": "0.5",
|
||||
"veto": "0.334",
|
||||
"governance_penalty": "0.0"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Let us break down the parameters:
|
||||
|
||||
- `starting_proposal_id`: This parameter defines the ID of the first proposal. Each proposal is identified by a unique ID.
|
||||
- `deposits`: List of deposits for each proposal ID. Set to `null` if genesis was not exported from previous state.
|
||||
- `votes`: List of votes for each proposal ID. Set to `null` if genesis was not exported from previous state.
|
||||
- `proposals`: List of proposals for each proposal ID: Set to `null` if genesis was not exported from previous state.
|
||||
- `deposit_params`
|
||||
+ `min_deposit`: The minimum deposit required for the proposal to enter `Voting Period`. If multiple denoms are provided, the `OR` operator applies.
|
||||
+ `max_deposit_period`: The maximum period (in **nanoseconds**) after which it is not possible to deposit on the proposal anymore.
|
||||
- `voting_params`
|
||||
+ `voting_period`: Length of the voting period in **nanoseconds**.
|
||||
- `tally_params`
|
||||
+ `quorum`: Minimum percentage of bonded staking tokens that needs to vote for the result to be valid.
|
||||
+ `threshold`: Minimum percentage of votes that need to be `YES` for the result to be valid.
|
||||
+ `veto`: Maximum percentage `NO_WITH_VETO` votes for the result to be valid.
|
||||
+ `governance_penalty`: Penalty for validators that do not vote on a given proposal.
|
||||
|
||||
### Slashing
|
||||
|
||||
The `slashing` module handles the logic to slash delegators if their validator misbehave. The `slashing` section in genesis looks as follows:
|
||||
|
||||
```json
|
||||
"slashing": {
|
||||
"params": {
|
||||
"max_evidence_age": "1814400000000000",
|
||||
"signed_blocks_window": "10000",
|
||||
"min_signed_per_window": "0.050000000000000000",
|
||||
"downtime_jail_duration": "600000000000",
|
||||
"slash_fraction_double_sign": "0.050000000000000000",
|
||||
"slash_fraction_downtime": "0.000100000000000000"
|
||||
},
|
||||
"signing_infos": {},
|
||||
"missed_blocks": {}
|
||||
}
|
||||
```
|
||||
|
||||
Let us break down the parameters:
|
||||
|
||||
- `params`
|
||||
+ `max_evidence_age`: Maximum age of the evidence in **nanoseconds**.
|
||||
+ `signed_blocks_window`: Moving window of blocks to figure out offline validators.
|
||||
+ `min_signed_per_window`: Minimum percentage of `precommits`that must be present in the `block window` for the validator to be considered online.
|
||||
+ `downtime_jail_duration`: Duration in **nanoseconds** for which a validator is jailed after they get slashed for downtime.
|
||||
+ `slash_fraction_double_sign`: Percentage of delegators bonded stake slashed when their validator double signs.
|
||||
+ `slash_fraction_downtime`: Percentage of delegators bonded stake slashed when their validator is down.
|
||||
- `signing_infos`: Various infos per validator needed by the `slashing` module. Set to `{}` if genesis was not exported from previous state.
|
||||
- `missed_blocks`: Various infos related to missed blocks needed by the `slashing` module. Set to `{}` if genesis was not exported from previous state.
|
||||
|
||||
### Genesis Transactions
|
||||
|
||||
By default, the genesis file do not contain any `gentxs`. A `gentx` is a transaction that bonds staking token present in the genesis file under `accounts` to a validator, essentially creating a validator at genesis. The chain will start as soon as more than 2/3rds of the validators (weighted by voting power) that are the recipient of a valid `gentx` come online after `genesis_time`.
|
||||
|
||||
A `gentx` can be added manually to the genesis file, or via the following command:
|
||||
|
||||
```bash
|
||||
gaiad collect-gentxs
|
||||
```
|
||||
|
||||
This command will add all the `gentxs` stored in `~/.gaiad/config/gentx` to the genesis file. In order to create a genesis transaction, click [here](./validators/validator-setup.md#participate-in-genesis-as-a-validator).
|
||||
@ -9,9 +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 GO111MODULE=on" >> ~/.bash_profile
|
||||
echo "export GOBIN=$GOPATH/bin" >> ~/.bash_profile
|
||||
echo "export PATH=$PATH:$GOBIN" >> ~/.bash_profile
|
||||
source ~/.bash_profile
|
||||
```
|
||||
|
||||
@ -51,7 +50,7 @@ $ gaiacli version --long
|
||||
```
|
||||
cosmos-sdk: 0.33.0
|
||||
git commit: 7b4104aced52aa5b59a96c28b5ebeea7877fc4f0
|
||||
go.sum hash: d156153bd5e128fec3868eca9a1397a63a864edb5cfa0ac486db1b574b8eecfe
|
||||
vendor hash: 5db0df3e24cf10545c84f462a24ddc61882aa58f
|
||||
build tags: netgo ledger
|
||||
go version go1.12 linux/amd64
|
||||
```
|
||||
@ -81,7 +81,7 @@ You can also ask for peers on the [Validators Riot Room](https://riot.im/app/#/r
|
||||
|
||||
For more information on seeds and peers, you can [read this](https://github.com/tendermint/tendermint/blob/develop/docs/tendermint-core/using-tendermint.md#peers).
|
||||
|
||||
## A note on gas and fees
|
||||
## A Note on Gas and Fees
|
||||
|
||||
::: warning
|
||||
On Cosmos Hub mainnet, the accepted denom is `uatom`, where `1atom = 1.000.000uatom`
|
||||
@ -90,7 +90,7 @@ On Cosmos Hub mainnet, the accepted denom is `uatom`, where `1atom = 1.000.000ua
|
||||
Transactions on the Cosmos Hub network need to include a transaction fee in order to be processed. This fee pays for the gas required to run the transaction. The formula is the following:
|
||||
|
||||
```
|
||||
fees = gas * gasPrices
|
||||
fees = ceil(gas * gasPrices)
|
||||
```
|
||||
|
||||
The `gas` is dependent on the transaction. Different transaction require different amount of `gas`. The `gas` amount for a transaction is calculated as it is being processed, but there is a way to estimate it beforehand by using the `auto` value for the `gas` flag. Of course, this only gives an estimate. You can adjust this estimate with the flag `--gas-adjustment` (default `1.0`) if you want to be sure you provide enough `gas` for the transaction.
|
||||
@ -147,6 +147,36 @@ If you plan to start a new network from the exported state, export with the `--f
|
||||
gaiad export --height [height] --for-zero-height > [filename].json
|
||||
```
|
||||
|
||||
## Verify Mainnet
|
||||
|
||||
Help to prevent a catastrophe by running invariants on each block on your full
|
||||
node. In essence, by running invariants you ensure that the state of mainnet is
|
||||
the correct expected state. One vital invariant check is that no atoms are
|
||||
being created or destroyed outside of expected protocol, however there are many
|
||||
other invariant checks each unique to their respective module. Because invariant checks
|
||||
are computationally expensive, they are not enabled by default. To run a node with
|
||||
these checks start your node with the assert-invariants-blockly flag:
|
||||
|
||||
```bash
|
||||
gaiad start --assert-invariants-blockly
|
||||
```
|
||||
|
||||
If an invariant is broken on your node, your node will panic and prompt you to send
|
||||
a transaction which will halt mainnet. For example the provided message may look like:
|
||||
|
||||
```bash
|
||||
invariant broken:
|
||||
loose token invariance:
|
||||
pool.NotBondedTokens: 100
|
||||
sum of account tokens: 101
|
||||
CRITICAL please submit the following transaction:
|
||||
gaiacli tx crisis invariant-broken staking supply
|
||||
|
||||
```
|
||||
|
||||
When submitting a invariant-broken transaction, transaction fee tokens are not
|
||||
deducted as the blockchain will halt (aka. this is a free transaction).
|
||||
|
||||
## Upgrade to Validator Node
|
||||
|
||||
You now have an active full node. What's the next step? You can upgrade your full node to become a Cosmos Validator. The top 100 validators have the ability to propose new blocks to the Cosmos Hub. Continue onto [the Validator Setup](./validators/validator-setup.md).
|
||||
@ -10,7 +10,7 @@ of the Cosmos-SDK to use and details about the genesis file.
|
||||
**You need to [install gaia](./installation.md) before you go further**
|
||||
:::
|
||||
|
||||
## Starting a new Node
|
||||
## Starting a New Node
|
||||
|
||||
> NOTE: If you ran a full node on a previous testnet, please skip to [Upgrading From Previous Testnet](#upgrading-from-previous-testnet).
|
||||
|
||||
@ -21,7 +21,7 @@ To start a new node, the mainnet instructions apply:
|
||||
|
||||
The only difference is the SDK version and genesis file. See the [testnet repo](https://github.com/cosmos/testnets) for information on testnets, including the correct version of the Cosmos-SDK to use and details about the genesis file.
|
||||
|
||||
## Upgrading your Node
|
||||
## Upgrading Your Node
|
||||
|
||||
These instructions are for full nodes that have ran on previous versions of and would like to upgrade to the latest testnet.
|
||||
|
||||
@ -59,4 +59,4 @@ make update_tools install
|
||||
Note we use `master` here since it contains the latest stable release.
|
||||
See the [testnet repo](https://github.com/cosmos/testnets) for details on which version is needed for which testnet, and the [SDK release page](https://github.com/cosmos/cosmos-sdk/releases) for details on each release.
|
||||
|
||||
Your full node has been cleanly upgraded!
|
||||
Your full node has been cleanly upgraded!
|
||||
@ -1,6 +1,6 @@
|
||||
# Ledger Nano Support
|
||||
|
||||
## A note on HD wallet
|
||||
## A Note on HD Wallet
|
||||
|
||||
HD Wallets, originally specified in Bitcoin's [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), are a special kind of wallet that let users derive any number of accounts from a single seed. To understand what that means, let us first define some terminology:
|
||||
|
||||
@ -54,7 +54,7 @@ The process of derivating accounts from the seed is deterministic. This means th
|
||||
|
||||
The funds stored in an account are controlled by the private key. This private key is generated using a one-way function from the mnemonic. If you lose the private key, you can retrieve it using the mnemonic. However, if you lose the mnemonic, you will lose access to all the derived private keys. Likewise, if someone gains access to your mnemonic, they gain access to all the associated accounts.
|
||||
|
||||
## Ledger Support for account keys
|
||||
## Ledger Support for Account Keys
|
||||
|
||||
At the core of a Ledger device, there is a mnemonic that is used to generate private keys. When you initialize you Ledger, a mnemonic is generated.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
Each validator candidate is encouraged to run its operations independently, as diverse setups increase the resilience of the network. Validator candidates should commence their setup phase now in order to be on time for launch.
|
||||
|
||||
## Key management - HSM
|
||||
## Key Management - HSM
|
||||
|
||||
It is mission critical that an attacker cannot steal a validator's key. If this is possible, it puts the entire stake delegated to the compromised validator at risk. Hardware security modules are an important strategy for mitigating this risk.
|
||||
|
||||
@ -37,7 +37,9 @@ 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)
|
||||
private_peer_ids = "id of validator nodes"
|
||||
# Example ID: 3e16af0cead27979e1fc3dac57d03df3c7a77acc@3.87.179.235:26656
|
||||
|
||||
private_peer_ids = "node_ids_of_private_peers"
|
||||
```
|
||||
|
||||
## Environment Variables
|
||||
@ -55,15 +55,14 @@ When specifying commission parameters, the `commission-max-change-rate` is used
|
||||
|
||||
You can confirm that you are in the validator set by using a third party explorer.
|
||||
|
||||
## Participate in genesis as a validator
|
||||
## Participate in Genesis as a Validator
|
||||
|
||||
::: warning
|
||||
This section only concerns validators that want to be in the genesis
|
||||
file of the Cosmos Hub mainnet. If the mainnet is already live, skip this section.
|
||||
The genesis ceremony for the Cosmos Hub mainnet is closed. Please skip to the next section.
|
||||
:::
|
||||
|
||||
If you want to participate in genesis as a validator, you need to justify that
|
||||
you have some atoms at genesis, create one (or multiple) transactions to bond these atoms to your validator address, and include this transaction in the genesis file.
|
||||
you have some stake at genesis, create one (or multiple) transactions to bond this stake to your validator address, and include this transaction in the genesis file.
|
||||
|
||||
Your `cosmosvalconspub` can be used to create a new validator by staking tokens. You can find your validator pubkey by running:
|
||||
|
||||
@ -178,7 +177,7 @@ If you got jailed for downtime, you can get your voting power back to your valid
|
||||
gaiad start
|
||||
```
|
||||
|
||||
Wait for your full node to catch up to the latest block. Next, run the following command. Then, you can [unjail your validator](#unjail-validator)
|
||||
Wait for your full node to catch up to the latest block. Then, you can [unjail your validator](#unjail-validator)
|
||||
|
||||
Lastly, check your validator again to see if your voting power is back.
|
||||
|
||||
@ -1,63 +0,0 @@
|
||||
# Cosmos主网创世成功启动，一键发链开启神奇宇宙之旅！
|
||||
|
||||
## 关于Cosmos
|
||||
2014年，Cosmos创始人Jae Kwon发现经典拜占庭容错（BFT）共识算法的安全性有助于我们在公链环境中利用PoS机制，而无需外部伪随机源来抵抗Sybil。 2015年，他与Ethan Buchman一起规划了Cosmos的蓝图，希望未来的区块链能像今天的互联网应用一样，遍地开花。
|
||||
|
||||
为了证明我们可以建立一个安全的BFT-PoS系统，我们需要在公开透明、去中心化的区块链上进行测试。Cosmos Hub就这样诞生了。
|
||||
|
||||
为可扩展的公链网络提供基础设施的美好愿景正是推动此次主网启动的核心动力。Cosmos就是要实现成千上万个加密货币系统之间的互联互通，而不必基于PoW就能实现网络的扩展。
|
||||
|
||||
为了实现这一愿景，我们开发了BFT共识引擎Tendermint Core，可以用作任何PoS区块链的底层。同时还需要搭建一个框架，以大大降低DApp开发的门槛。与Ruby on Rails或Django等Web框架引发寒武纪的Web应用爆炸类似，基于Cosmos SDK，你可以很容易地搭建区块链，因此区块链的应用也将会如雨后春笋一般，野蛮生长。
|
||||
|
||||
自Tendermint Core建立至今已近五年，建立一个基于BFT PoS的区块链互联网的梦想已成为现实。回首这一发展历程，我们更加信心倍增，斗志昂扬，继续Cosmos的神奇宇宙之旅！
|
||||
|
||||
|
||||
|
||||
有关Cosmos及其顶尖开源软件的介绍，请戳：cosmos.network/intro
|
||||
如何使用Cosmos SDK对自定义应用专有链进行编程，请参照[本教程](https://cosmos.network/docs/tutorial)。
|
||||
|
||||
|
||||
|
||||
## Cosmos主网上线
|
||||
|
||||
Cosmos主网是近40年来实用拜占庭容错（PBFT）研究历史中首个基于POS的公链。主网上线将分三个阶段（中文链接）：网络逐步趋于稳定、开启交易、启用IBC协议。
|
||||
|
||||
阅读Coindesk对Cosmos Hub发布的[评论](https://www.coindesk.com/a-blockchain-to-connect-all-blockchains-cosmos-is-now-officially-live)。
|
||||
|
||||
了解有关Cosmos的[更多信息](cosmos.network/about)。
|
||||
|
||||
|
||||
|
||||
## Cosmos生态
|
||||
|
||||
Tendermint Inc的A轮融资
|
||||
Tendermint Inc—— [Tendermint Core](https://github.com/tendermint/tendermint), [Cosmos SDK](https://github.com/cosmos/cosmos-sdk)和[Cosmos网络](https://cosmos.network)核心开发者，已完成了A轮融资，筹集了4亿美元的区块链基金，由[Paradigm](https://medium.com/paradigm-fund)领投，其他支持机构如[贝恩资本](https://medium.com/paradigm-fund)和[1 Confirmation](https://www.1confirmation.com)跟投。部分资金将由Tendermint Inc用于支持Cosmos网络及其生态系统的持续发展。
|
||||
|
||||
|
||||
|
||||
|
||||
## ICF研发
|
||||
[ICF](https://interchain.io)是一家瑞士的非营利性基金会，为Cosmos网络技术开发提供资金支持，同时也在通过与[其他研究机构](https://interchain.io/research)合作并发展其[内部团队](https://interchain.io/careers)开展研发工作，也接受其他需要资金的[项目的申请](https://interchain.typeform.com/to/P3tOm0)。
|
||||
|
||||
|
||||
|
||||
## 生态及用例
|
||||
|
||||
虽然Cosmos Hub是Cosmos网络中上线的第一个区块链，但更广泛的Cosmos项目正在迅速扩张。 核心软件库的代码贡献者数量已增至150多个。测试网上的验证人已逾百人，参与主网分布式启动的验证人共有67位。有一张社区贡献的策列表显示，共有80个项目表明他们正在或打算基于Cosmos SDK和/或Tendermint Core构建应用程序。 在我们的[生态系统页面](https://cosmos.network/ecosystem)上，可以看到一些非常耀眼的项目，涉及领域包括游戏、内容发布、音乐、生态监测和再生、跨链操作等应用程序 。这些都是通过我们提供的开源模块及通用的基础设施而实现的。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
基于Cosmos SDK / Tendermint Core开发的[项目列表](cosmos.network/ecosystem)。
|
||||
|
||||
|
||||
## 来自合作伙伴的评价
|
||||
|
||||
> “Cosmos团队搭建了一个非常必要的基础设施，有可能触发加密经济网络的指数型增长。” — Brian Kelly，BKCM
|
||||
>
|
||||
|
||||
> “我们很高兴能够支持Cosmos对跨链生态系统的愿景。 Jae Kwon带领的团队展现了严谨务实的奉献精神和对去中心化系统设计的远见卓识。 我们对团队在建立第一个生产就绪的 POS BFT系统方面的进展感到特别兴奋，期待能够看到新的去中心化应用早日实现。“ — Matt Huang和Charlie Noyes，Paradigm
|
||||
@ -1,47 +0,0 @@
|
||||
# Blastoff — The Cosmos Hub Mainnet is Live
|
||||
**Announcing the Mainnet Launch of the Cosmos Hub**
|
||||
|
||||
## About Cosmos
|
||||
In 2014, Jae Kwon observed that the safety-favoring nature of classical Byzantine Fault Tolerant (BFT) consensus algorithms would allow us to use Proof of Stake (PoS) for Sybil resistance in a public blockchain context without the need for external sources of pseudorandomness. In 2015, he was joined by Ethan Buchman to build a future where there are as many blockchains as there are web apps today.
|
||||
|
||||
In order to prove that we could have a secure, BFT system running on Proof-of-Stake, we needed to test the theory out on a public, decentralized blockchain. That blockchain is the Cosmos Hub.
|
||||
|
||||
The core motivation fueling this launch is the desire to provide infrastructure for a scalable public blockchain network. The Cosmos vision is to enable communication and connectivity among thousands of cryptocurrency systems, allowing the network to scale without utilizing Proof-of-Work.
|
||||
|
||||
To make this vision a reality, [Tendermint Core](https://github.com/tendermint/tendermint) was developed as a BFT consensus engine that could be used as the first layer for any PoS blockchain.
|
||||
|
||||
The vision also required a framework to significantly lower the barrier to entry for developing decentralized applications. Similar to how web frameworks such as Ruby on Rails or Django brought about a Cambrian explosion of web applications, the [Cosmos SDK](https://github.com/cosmos/cosmos-sdk) was created to make blockchain development easy and catalyze the explosion of blockchain applications.
|
||||
|
||||
Nearly five years since the creation of Tendermint Core, the dream of creating an Internet of Blockchains powered by BFT Proof-of-Stake has become a reality. Here’s a look back at a brief history of the development progress which set the gears in motion toward our journey to the Cosmos.
|
||||
|
||||
Get an intro to Cosmos and its flagship open-source software here: [cosmos.network/intro](https://cosmos.network/intro)
|
||||
|
||||
Learn how to program custom application-specific blockchains with the Cosmos SDK by following [this tutorial](https://cosmos.network/docs/tutorial/).
|
||||
|
||||
### Cosmos Mainnet Launch
|
||||
The Cosmos Hub is the first public BFT blockchain powered by proof-of-stake, and the first BFT system deployed at scale in almost 40 years of Byzantine Fault Tolerance (BFT) research history. The mainnet is set to be rolled out in three phases: network gains stability, transfers enabled, and IBC enabled.
|
||||
|
||||
- Read what Coindesk [has to say](https://www.coindesk.com/a-blockchain-to-connect-all-blockchains-cosmos-is-now-officially-live) about the Cosmos Hub launch.
|
||||
|
||||
Learn more about Cosmos here: [cosmos.network/about](https://cosmos.network/about)
|
||||
|
||||
## Cosmos Ecosystem
|
||||
Below are some highlights from the Cosmos universe.
|
||||
|
||||
### Tendermint Inc Series A Round
|
||||
Tendermint Inc, the lead developer of [Tendermint Core](https://github.com/tendermint/tendermint), [Cosmos SDK](https://github.com/cosmos/cosmos-sdk), and the [Cosmos Network](https://cosmos.network/), has raised its Series A in a round led by Paradigm’s USD $400 million blockchain fund. Other prominent investors like [Bain Capital](https://www.baincapitalventures.com/) and [1confirmation](https://www.1confirmation.com/) also participated. Part of the funds will be used by Tendermint Inc to support the continued development of the Cosmos Network and its ecosystem.
|
||||
|
||||
[Read more here](https://medium.com/tendermint/tendermint-inc-announces-series-a-round-9c062d1bd7de)
|
||||
|
||||
### Interchain Foundation Research & Development
|
||||
[Interchain Foundation](https://interchain.io/) (ICF), the Swiss non-profit funding development of the Cosmos Network technology, is growing its research and development efforts by [collaborating with other research institutions](https://interchain.io/research) and [growing its internal R&D team](https://interchain.io/careers). It is also [accepting applications](https://interchain.typeform.com/to/P3tOm0) from projects seeking funding.
|
||||
|
||||
### Ecosystem & Use Cases
|
||||
While the Cosmos Hub is the first blockchain launched in the Cosmos Network, the wider Cosmos project, like the observable universe, is quickly expanding. The number of contributors to the core software repositories has grown to over 150. The number of validators on testnets has been well over 100; the number of validators participating in the decentralized main net launch is over 50. There is a community-curated list where [80 projects](https://forum.cosmos.network/t/list-of-projects-in-cosmos-tendermint-ecosystem/243) and counting have indicated they are building, or intend to build, applications with the Cosmos SDK and/or Tendermint Core. Some of the highest profile projects can be found on the [ecosystem page](https://cosmos.network/ecosystem), and include applications in gaming, content distribution, music, ecological monitoring and regeneration, blockchain interoperability, and more — the wide diversity of use cases made possible by the modular and general purpose infrastructure that we’ve open-sourced.
|
||||
|
||||
Here’s a list of Cosmos SDK/Tendermint Core-based projects: [cosmos.network/ecosystem](https://cosmos.network/ecosystem)
|
||||
|
||||
### What our partners say about us
|
||||
“The Cosmos team has created an essential piece of infrastructure that has the potential to ignite exponential growth in crypto-economic networks.” — Brian Kelly, BKCM
|
||||
|
||||
“We are excited to support Cosmos’s vision for an ecosystem of interoperable blockchains. The team, led by Jae Kwon, has shown years of dedication and a keen understanding for trade-offs in decentralized system design. We are particularly excited with the team’s progress in building the first production-ready Proof of Stake BFT system, and we look forward to seeing what new decentralized applications that enables.” — Matt Huang & Charlie Noyes, Paradigm
|
||||
Loading…
Reference in New Issue
Block a user