From 90ae8e37f4a87896989a6fba4c8af0df10784227 Mon Sep 17 00:00:00 2001 From: Jacob Gadikian Date: Mon, 5 Dec 2022 14:39:34 +0700 Subject: [PATCH] markdownlint --- CHANGELOG.md | 55 +++--- CONTRIBUTING.md | 7 +- README.md | 37 ++--- RELEASING.md | 33 ++-- SECURITY.md | 8 +- contrib/githooks/README.md | 6 +- contrib/testnets/test_platform/README.md | 12 +- docs/DOCS_README.md | 9 +- docs/README.md | 2 +- docs/delegators/delegator-faq.md | 12 +- docs/delegators/delegator-security.md | 37 +++-- docs/es/gaia-tutorials/installation.md | 4 +- docs/es/gaia-tutorials/join-mainnet.md | 3 +- .../governance/community-pool-spend/README.md | 16 +- .../es/governance/params-change/Governance.md | 65 +++++++- docs/getting-started/installation.md | 3 +- docs/getting-started/quickstart.md | 18 +- docs/getting-started/what-is-gaia.md | 2 +- docs/governance/README.md | 7 +- docs/governance/best-practices.md | 36 ++-- .../governance/community-pool-spend/README.md | 3 + docs/governance/formatting.md | 3 - docs/governance/params-change/Auth.md | 20 ++- docs/governance/params-change/Bank.md | 6 +- docs/governance/params-change/Crisis.md | 4 + docs/governance/params-change/Distribution.md | 27 ++- docs/governance/params-change/Governance.md | 78 ++++++--- docs/governance/params-change/Mint.md | 72 +++++--- docs/governance/params-change/README.md | 5 +- docs/governance/params-change/Slashing.md | 23 ++- docs/governance/params-change/Staking.md | 18 +- .../2020-11-inflation-rate-change/README.md | 8 +- .../2021-01-atom2021_marketing/README.md | 1 - .../2021-01-delay-stargate-upgrade/README.md | 8 +- .../2021-01-stargate-upgrade/README.md | 1 - .../2021-04-advancing-ethermint/README.md | 6 +- .../README.md | 8 +- .../2021-04-prop34-continuation/README.md | 137 ++++++++------- .../README.md | 10 +- .../README.md | 2 +- .../2021-09-hub-ibc-router/README.md | 2 +- .../proposals/previous-proposals/README.md | 55 +++--- .../governance/proposals/proposal-template.md | 10 +- .../state-of-cosmos-governance-2021.md | 53 +++--- docs/governance/submitting.md | 12 +- docs/gtm-interchain.md | 14 +- docs/hub-overview/overview.md | 2 - docs/hub-tutorials/gaiad.md | 2 +- docs/hub-tutorials/join-mainnet.md | 55 +++--- docs/hub-tutorials/join-testnet.md | 9 +- docs/interchain-security.md | 59 ++----- docs/ko/delegators/delegator-guide-cli.md | 75 ++++----- docs/ko/gaia-tutorials/installation.md | 4 +- docs/ko/gaia-tutorials/join-mainnet.md | 8 +- docs/ko/gaia-tutorials/join-testnet.md | 2 +- docs/ko/gaia-tutorials/what-is-gaia.md | 2 - docs/ko/launch/blog-1-kr.md | 15 +- docs/ko/launch/blog-2-kr.md | 1 + docs/ko/resources/gaiad.md | 8 +- docs/ko/resources/genesis.md | 68 ++++---- docs/ko/resources/hd-wallets.md | 1 - docs/ko/resources/ledger.md | 2 +- docs/ko/validators/security.md | 1 - docs/ko/validators/validator-faq.md | 15 +- docs/ko/validators/validator-setup.md | 13 +- docs/launch/blog-2-en.md | 15 +- docs/migration/cosmoshub-2.md | 38 ++--- docs/migration/cosmoshub-3.md | 89 +++++----- docs/migration/cosmoshub-3[ES_es].md | 30 ++-- docs/migration/cosmoshub-3[KR_kr].md | 39 ++--- docs/migration/cosmoshub-4-delta-upgrade.md | 26 +-- .../migration/cosmoshub-4-v7-Theta-upgrade.md | 45 ++++- docs/migration/cosmoshub-4-vega-upgrade.md | 64 +++++-- docs/modules/README.md | 2 +- docs/modules/globalfee.md | 51 ++++-- docs/proto/proto-docs.md | 51 ++---- docs/readiness/README.md | 20 +-- docs/readiness/adr-001-interchain-accounts.md | 23 ++- docs/readiness/template.md | 19 +++ docs/resources/ledger.md | 13 +- docs/resources/reproducible-builds.md | 1 + docs/resources/service-providers.md | 3 - docs/roadmap/README.md | 1 + docs/roadmap/cosmos-hub-roadmap-2.0.md | 32 ++-- docs/validators/README.md | 4 +- docs/validators/kms/kms_ledger.md | 2 +- docs/validators/overview.md | 2 +- docs/validators/security.md | 2 +- docs/validators/validator-setup.md | 15 +- docs/zh/delegator/delegator-guide-cli.md | 156 +++++++----------- docs/zh/gaia-tutorials/installation.md | 4 +- docs/zh/gaia-tutorials/join-mainnet.md | 1 + docs/zh/launch/blog-1-cn.md | 3 +- docs/zh/launch/blog-2-cn.md | 53 +----- docs/zh/resources/gaiad.md | 43 ++--- docs/zh/resources/genesis.md | 2 +- docs/zh/validators/overview.md | 4 - docs/zh/validators/security.md | 2 - docs/zh/validators/validator-faq.md | 56 ++----- docs/zh/validators/validator-setup.md | 6 +- 100 files changed, 1189 insertions(+), 1028 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 21781f2fda7..05dd8b5b018 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -36,8 +36,8 @@ Ref: https://keepachangelog.com/en/1.0.0/ ## [Unreleased] - ## [v8.0.0] - 2022-10-31 + * (gaia) bump [cosmos-sdk](https://github.com/cosmos/cosmos-sdk) to [v0.46.4](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.46.4). See [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/v0.46.4/CHANGELOG.md) for details. Notably, Gov module has major changes while remaining backwards compatible. * (gaia) [#1573](https://github.com/cosmos/gaia/issues/1573), [#1576](https://github.com/cosmos/gaia/issues/1576) update [cosmos ledger](https://github.com/cosmos/ledger-go) version to [v.0.9.3](https://github.com/cosmos/ledger-go/releases/tag/v0.9.3). * (gaia) bump [Liquidity](https://github.com/Gravity-Devs/liquidity) module to [v2.0.1](https://github.com/Gravity-Devs/liquidity/releases/tag/v2.0.1). @@ -51,12 +51,14 @@ Ref: https://keepachangelog.com/en/1.0.0/ Distribution, Encode, Evidence, FeeGrant, Global Fee, Legacy Gov, New Gov, Groups, IBC, ICA, packet forwarding middleware, Slashing, Staking, and Vesting module. * (tests) use gaiad to swap out [Ignite](https://github.com/ignite/cli) in [liveness tests](https://github.com/cosmos/gaia/blob/main/.github/workflows/test.yml). -* (gaia) [#1845](https://github.com/cosmos/gaia/pull/1447) Add bech32-convert command to gaiad +* (gaia) [#1845](https://github.com/cosmos/gaia/pull/1447) Add bech32-convert command to gaiad ## [v7.1.0] -2022-10-14 + * (gaia) bump [cosmos-sdk](https://github.com/cosmos/cosmos-sdk) to [v0.45.9](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.9) to fix the security vulnerability! See [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/v0.45.9/CHANGELOG.md) for details. ## [v7.0.3] -2022-08-03 + * (gaia) update go to 1.18. * (gaia) bump [cosmos-sdk](https://github.com/cosmos/cosmos-sdk) to [v0.45.6](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.6). See [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/v0.45.6/CHANGELOG.md) for details. * (gaia) bump [Liquidity](https://github.com/Gravity-Devs/liquidity) module to [v1.5.1](https://github.com/Gravity-Devs/liquidity/releases/tag/v1.5.1). @@ -78,12 +80,12 @@ Ref: https://keepachangelog.com/en/1.0.0/ ## [v7.0.0] - 2022-03-24 -- (gaia) bump [cosmos-sdk](https://github.com/cosmos/cosmos-sdk) to [v0.45.1](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.1). See [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/v0.45.1/CHANGELOG.md#v0451---2022-02-03) for details. -- (gaia) bump [ibc-go](https://github.com/cosmos/ibc-go) module to [v3.0.0](https://github.com/cosmos/ibc-go/releases/tag/v3.0.0). See [CHANGELOG.md](https://github.com/cosmos/ibc-go/blob/v3.0.0/CHANGELOG.md#v300---2022-03-15) for details. -- (gaia) add [interchain account](https://github.com/cosmos/ibc-go/tree/main/modules/apps/27-interchain-accounts) module (interhchain-account module is part of ibc-go module). -- (gaia) bump [liquidity](https://github.com/gravity-devs/liquidity) module to [v1.5.0](https://github.com/Gravity-Devs/liquidity/releases/tag/v1.5.0). See [CHANGELOG.md](https://github.com/Gravity-Devs/liquidity/blob/v1.5.0/CHANGELOG.md#v150---20220223) for details. -- (gaia) bump [packet-forward-middleware](https://github.com/strangelove-ventures/packet-forward-middleware) module to [v2.1.1](https://github.com/strangelove-ventures/packet-forward-middleware/releases/tag/v2.1.1). -- (gaia) add migration logs for upgrade process. +* (gaia) bump [cosmos-sdk](https://github.com/cosmos/cosmos-sdk) to [v0.45.1](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.1). See [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/v0.45.1/CHANGELOG.md#v0451---2022-02-03) for details. +* (gaia) bump [ibc-go](https://github.com/cosmos/ibc-go) module to [v3.0.0](https://github.com/cosmos/ibc-go/releases/tag/v3.0.0). See [CHANGELOG.md](https://github.com/cosmos/ibc-go/blob/v3.0.0/CHANGELOG.md#v300---2022-03-15) for details. +* (gaia) add [interchain account](https://github.com/cosmos/ibc-go/tree/main/modules/apps/27-interchain-accounts) module (interhchain-account module is part of ibc-go module). +* (gaia) bump [liquidity](https://github.com/gravity-devs/liquidity) module to [v1.5.0](https://github.com/Gravity-Devs/liquidity/releases/tag/v1.5.0). See [CHANGELOG.md](https://github.com/Gravity-Devs/liquidity/blob/v1.5.0/CHANGELOG.md#v150---20220223) for details. +* (gaia) bump [packet-forward-middleware](https://github.com/strangelove-ventures/packet-forward-middleware) module to [v2.1.1](https://github.com/strangelove-ventures/packet-forward-middleware/releases/tag/v2.1.1). +* (gaia) add migration logs for upgrade process. ## [v6.0.4] - 2022-03-10 @@ -93,28 +95,31 @@ Ref: https://keepachangelog.com/en/1.0.0/ * (gaia) [#1135](https://github.com/cosmos/gaia/pull/1135) Fix rocksdb build tag usage. * (gaia) [#1160](https://github.com/cosmos/gaia/pull/1160) Improvement: update state sync configs. * (gaia) [#1208](https://github.com/cosmos/gaia/pull/1208) Update statesync.bash. -* * (gaia) Bump [Cosmos-SDK](https://github.com/cosmos/cosmos-sdk) to [v0.44.6](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.44.6) + * * (gaia) Bump [Cosmos-SDK](https://github.com/cosmos/cosmos-sdk) to [v0.44.6](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.44.6) * (gaia) Bump [Versions](https://github.com/cosmos/gaia/pull/1100) of various smaller dependencies, remove the Cosmos SDK replace statement, update `initiClientCtx` params, ensure `stdout` and `stderr` are handled correctly in the CLI. ## [v6.0.3] - 2022-02-18 - * This is a reverted release that is the same as v6.0.0 + +* This is a reverted release that is the same as v6.0.0 ## [v6.0.2] - 2022-02-17 - * Unusable release + +* Unusable release ## [v6.0.1] - 2022-02-10 - * Unusable release + +* Unusable release ## [v6.0.0] - 2021-11-24 - * (gaia) Add NewSetUpContextDecorator to anteDecorators - * (gaia) Reconfigure SetUpgradeHandler to ensure vesting is configured after auth and new modules have InitGenesis run. - * (golang) Bump golang prerequisite to 1.17. - * (gaia) Bump [Liquidity](https://github.com/gravity-devs/liquidity) module to [v1.4.2](https://github.com/Gravity-Devs/liquidity/releases/tag/v1.4.2). - * (gaia) Bump [Cosmos SDK](https://github.com/cosmos/cosmos-sdk) to [v0.44.3](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.44.3). See the [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/release/v0.44.x/CHANGELOG.md#v0443---2021-10-21) for details. - * (gaia) Add [IBC](https://github.com/cosmos/ibc-go) as a standalone module from the Cosmos SDK using version [v2.0.0](https://github.com/cosmos/ibc-go/releases/tag/v2.0.0). See the [CHANGELOG.md](https://github.com/cosmos/ibc-go/blob/v2.0.0/CHANGELOG.md) for details. - * (gaia) Add [packet-forward-middleware](https://github.com/strangelove-ventures/packet-forward-middleware) [v1.0.1](https://github.com/strangelove-ventures/packet-forward-middleware/releases/tag/v1.0.1). - * (gaia) [#969](https://github.com/cosmos/gaia/issues/969) Remove legacy migration code. +* (gaia) Add NewSetUpContextDecorator to anteDecorators +* (gaia) Reconfigure SetUpgradeHandler to ensure vesting is configured after auth and new modules have InitGenesis run. +* (golang) Bump golang prerequisite to 1.17. +* (gaia) Bump [Liquidity](https://github.com/gravity-devs/liquidity) module to [v1.4.2](https://github.com/Gravity-Devs/liquidity/releases/tag/v1.4.2). +* (gaia) Bump [Cosmos SDK](https://github.com/cosmos/cosmos-sdk) to [v0.44.3](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.44.3). See the [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/release/v0.44.x/CHANGELOG.md#v0443---2021-10-21) for details. +* (gaia) Add [IBC](https://github.com/cosmos/ibc-go) as a standalone module from the Cosmos SDK using version [v2.0.0](https://github.com/cosmos/ibc-go/releases/tag/v2.0.0). See the [CHANGELOG.md](https://github.com/cosmos/ibc-go/blob/v2.0.0/CHANGELOG.md) for details. +* (gaia) Add [packet-forward-middleware](https://github.com/strangelove-ventures/packet-forward-middleware) [v1.0.1](https://github.com/strangelove-ventures/packet-forward-middleware/releases/tag/v1.0.1). +* (gaia) [#969](https://github.com/cosmos/gaia/issues/969) Remove legacy migration code. ## [v5.0.8] - 2021-10-14 @@ -126,19 +131,19 @@ Ref: https://keepachangelog.com/en/1.0.0/ ## [v5.0.7] - 2021-09-30 - * (gaia) Bump Cosmos SDK to 0.42.10 +* (gaia) Bump Cosmos SDK to 0.42.10 ## [v5.0.6] - 2021-09-16 - * (gaia) Bump tendermint to 0.34.13 +* (gaia) Bump tendermint to 0.34.13 - ## [v5.0.5] - 2021-08-05 - * (gaia) Bump SDK to [0.42.9](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.42.9) to resolve IBC channel restart issue ([9800](https://github.com/cosmos/cosmos-sdk/issues/9800)). +* (gaia) Bump SDK to [0.42.9](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.42.9) to resolve IBC channel restart issue ([9800](https://github.com/cosmos/cosmos-sdk/issues/9800)). ## [v5.0.4] - 2021-07-31 - * (chore) Fix release to include intended items from `v5.0.3`. + +* (chore) Fix release to include intended items from `v5.0.3`. ## [v5.0.3] - 2021-07-30 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7b03b8fc3da..5d92b1b3044 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -75,13 +75,14 @@ code refactoring and cleanup should be submitted as a separate PRs from bugfixes In order to simplify reviewing large changes, submissions should have a created an issue with a description of the submission, a description tracking the changes and relevant discussions, -and a checklist of changes and tasks to be done. +and a checklist of changes and tasks to be done. The issue can then be used to develop multiple well-scoped PRs that are easy to review. The following PR structuring checklist can be used when submitting changes to the Gaia repository for review: -- [ ] Proto files: PR updating proto files. As a suggested next step, don't regenerate updated protobuf - implementations using `protgen`, since this will break existing code. + +- [ ] Proto files: PR updating proto files. As a suggested next step, don't regenerate updated protobuf + implementations using `protgen`, since this will break existing code. - [ ] Broken code: If `protogen` is run, a PR disabling broken code - [ ] Validation: PR with validation of types - [ ] Functionality: PR integrating supporting functionality diff --git a/README.md b/README.md index bf5b505aca9..cdc3d70ab1a 100644 --- a/README.md +++ b/README.md @@ -20,8 +20,8 @@
+### 🤔 — Why should you be interested in the Cosmos Hub -### 🤔 — Why should you be interested in the Cosmos Hub ___ The Cosmos Hub is built using the [Cosmos SDK](https://github.com/cosmos/cosmos-sdk) and compiled to a binary called `gaiad` (Gaia Daemon). The Cosmos Hub and other fully sovereign Cosmos SDK blockchains interact with one another using a protocol called [IBC](https://github.com/cosmos/ibc) that enables Inter-Blockchain Communication. In order to understand what the Cosmos Hub is you can read this [introductory explanation](https://hub.cosmos.network/main/hub-overview/overview.html). @@ -30,97 +30,87 @@ The Cosmos Hub is built using the [Cosmos SDK](https://github.com/cosmos/cosmos- | --- | --- | --- | --- | --- | | [![codecov](https://codecov.io/gh/cosmos/gaia/branch/master/graph/badge.svg)](https://codecov.io/gh/cosmos/gaia) | [![Go Report Card](https://goreportcard.com/badge/github.com/cosmos/gaia)](https://goreportcard.com/report/github.com/cosmos/gaia) | [![license](https://img.shields.io/github/license/cosmos/gaia.svg)](https://github.com/cosmos/gaia/blob/main/LICENSE) | [![LoC](https://tokei.rs/b1/github/cosmos/gaia)](https://github.com/cosmos/gaia) | [![GolangCI](https://golangci.com/badges/github.com/cosmos/gaia.svg)](https://golangci.com/r/github.com/cosmos/gaia) | -

- ### ⚡ — Documentation & Introduction + ___ -Cosmos Hub is a blockchain network that operates on Proof-of-Stake consensus. You can find an introduction to the Cosmos Hub and how to use the `gaiad` binary as a delegator, validator or node operator as well as how governance on the Cosmos Hub works in the [documentation](https://hub.cosmos.network/main/hub-overview/overview.html). +Cosmos Hub is a blockchain network that operates on Proof-of-Stake consensus. You can find an introduction to the Cosmos Hub and how to use the `gaiad` binary as a delegator, validator or node operator as well as how governance on the Cosmos Hub works in the [documentation](https://hub.cosmos.network/main/hub-overview/overview.html). Alternatively, whether you're new to blockchain technology or interested in getting involed, the Cosmos Network [Course](https://tutorials.cosmos.network/academy/0-welcome/) will guide you through everything. The course walks you through the basics of blockchain technology, to staking, setting up your own node, and beyond. - - -

- ### 👤 — Node Operators + ___ If you're interested in running a node on the current Cosmos Hub, check out the docs to [Join the Cosmos Hub Mainnet](https://github.com/cosmos/gaia/blob/main/docs/hub-tutorials/join-mainnet.md). -

- ### 🗣️ — Validators + ___ If you want to participate and help secure Cosmos Hub, check out becoming a validator. Information on what a validator is and how to participate as one can be found at the [Validator FAQ](https://hub.cosmos.network/main/validators/validator-faq.html#). If you're running a validator node on the Cosmos Hub, reach out to a Janitor on the [Cosmos Developers Discord](https://discord.gg/cosmosnetwork) to join the `#validators-verified` channel. -

- ### 👥 — Delegators + ___ If you still want to participate on the Cosmos Hub, check out becoming a delegator. Information what a delegator is and how to participate as one can be found at the [Delegator FAQ](https://hub.cosmos.network/main/delegators/delegator-faq.html). -

### 👥 — Testnet + ___ To participate in or utilize the current Cosmos Hub testnet, take a look at the [cosmos/testnets](https://github.com/cosmos/testnets) repository. This testnet is for the Theta Upgrade expected in Q1 2022. For future upgrades of the Cosmos Hub take a look at the [roadmap](https://github.com/cosmos/gaia/blob/main/docs/roadmap/cosmos-hub-roadmap-2.0.md). -

- ### 🌐 — Roadmap + ___ For an overview of upcoming changes to the Cosmos Hub take a look at the [Roadmap](https://github.com/cosmos/gaia/blob/main/docs/roadmap/cosmos-hub-roadmap-2.0.md). -

- ### 🗄️ — Archives & Genesis + ___ -With each version of the Cosmos Hub, the chain is restarted from a new Genesis state. +With each version of the Cosmos Hub, the chain is restarted from a new Genesis state. Mainnet is currently running as `cosmoshub-4`. Archives of the state of `cosmoshub-1`, `cosmoshub-2`, and `cosmoshub-3` are available [here](./docs/resources/archives.md). If you are looking for historical genesis files and other data [`cosmos/mainnet`](http://github.com/cosmos/mainnet) is an excellent resource. Snapshots are also available at [cosmos.quicksync.io](https://cosmos.quicksync.io). -

+### 🤝 — How to contribute -### 🤝 — How to contribute ___ Check out [contributing.md](CONTRIBUTING.md) for our guidelines & policies for how we develop the Cosmos Hub. Thank you to all those who have contributed! -

- ### 💬 — Talk to us + ___ We have active, helpful communities on Twitter, Discord, and Telegram. @@ -131,14 +121,13 @@ We have active, helpful communities on Twitter, Discord, and Telegram. | Cosmos Twitter | Tweet | | Cosmos Telegram | Telegram | - For updates on the Cosmos Hub team's activities follow us on the [Cosmos Hub Twitter](https://twitter.com/cosmoshub) account. -

### 👏 — Supporters + ___ [![Stargazers repo roster for @cosmos/gaia](https://reporoster.com/stars/cosmos/gaia)](https://github.com/cosmos/gaia/stargazers) diff --git a/RELEASING.md b/RELEASING.md index 11cfa0b5782..6142e34f3f0 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -1,6 +1,6 @@ # Releasing -This document outlines the release process for https://github.com/cosmos/gaia. We use [Long-Lived Version Branch Approach](x) on a `main` branch and a `release` branch. +This document outlines the release process for . We use [Long-Lived Version Branch Approach](x) on a `main` branch and a `release` branch. We follow [Semver](https://semver.org/) in that any patch releases are non-breaking changes. It's important to note, that breaking changes in a Blockchain context include non-determinism. So if a code change is backwards compatible, it may still impact the amount of gas needed to execute an action, which means the change is in fact breaking as it results in a different apphash after the code is executed. It's important for non-breaking changes to be possible to be used on the live network prior to the release. @@ -11,23 +11,27 @@ Each major release will have a release branch and patch releases will be tagged In the Gaia repo, there are two categories of long-lived branches: ### Branch: `main` -The `main` branch should be targeted for PRs that contain a bug-fix/feature/improvement that will be included for the next release. + +The `main` branch should be targeted for PRs that contain a bug-fix/feature/improvement that will be included for the next release. ### Branch: `release` + There are multiple long-lived branches with the `release/` prefix. Each release series follows the format `release/vn.0.x`, e.g. `release/v7.0.x`. The branch `release/vn.0.x` should point to the most updated `vn` release, e.g. `release/v5.0.x` should be the same as `release/v5.0.8` if that's the latest `v5.0` release. ## Other Branches -### branches for the next release: + +### branches for the next release Other feature/fix branches targeting at `main` contain commits preparing for the next release. When the `release-prepare-branch` is ready for next release, add label `A:backport/vn.0.x` to the PR of `release-prepare-branch` against `main`, then the mergifybot will create a new PR of `mergify/bp/release/vn.0.x` against `Release/vn.0.x`. -### branches for the backport release: +### branches for the backport release -If the feature/fix branches are for a backport release, `main` branch already contains the commits for the next major release `vn`, the feature/fix branch's PR should target at `Release/vn-1` rather than `main`. +If the feature/fix branches are for a backport release, `main` branch already contains the commits for the next major release `vn`, the feature/fix branch's PR should target at `Release/vn-1` rather than `main`. ## Release Procedure ### Checks and tests + Before merge and release, the following tests checks need to be conducted: - check the `replace` line in `go.mod`, check all the versions in `go.mod` are correct. @@ -41,45 +45,52 @@ For minor release. Merge or use mergify to merge the commits to `release/vn.0.x` Usually the first release on the `release/vn.0.x` is a release candidate. -#### example of releasing `v8.0.0-rc0`: +#### example of releasing `v8.0.0-rc0` 1. checkout `release/v8.0.x` off `main` 1. get the `v8-prepare-branch` ready including CHANGELOG.md, create a PR to merge `v8-prepare-branch` to `main`, label this PR `A:backport/v8.0.x`. 1. after merge `v8-prepare-branch` to `main`, mergifybot will create a new PR of `mergify/bp/release/v8.0.x` to `release/v8.0.x`. Check the PR, and merge this PR. 1. checkout `release/v8.0.x` and tag `v8.0.0-rc0`. -#### example of releasing `v8.0.0`: +#### example of releasing `v8.0.0` 1. get the `v800-prepare-branch` ready including CHANGELOG.md, create a PR to merge `v800-prepare-branch` to `main`, label this PR `A:backport/v8.0.x`. 1. after merge `v800-prepare-branch` to `main`, mergifybot will create a new PR of `mergify/bp/release/v8.0.x` to `release/v8.0.x`. Check the PR, and merge this PR. 1. checkout `release/v8.0.x` and tag `v8.0.0`. -#### example of releasing `v8.0.1`: +#### example of releasing `v8.0.1` 1. get the `v801-prepare-branch`(off `main`) ready including CHANGELOG.md, create a PR to merge `v801-prepare-branch` to `main`, label this PR `A:backport/v8.0.x`. 1. after merge `v801-prepare-branch` to `main`, mergifybot will create a new PR of `mergify/bp/release/v8.0.x` to `release/v8.0.x`. Check the PR, and merge this PR. 1. checkout `release/v8.0.x` and tag `v8.0.1`. ### backport release + For a backport release, checkout a new branch from the right release branch, for example, `release/vn-1.0.x`. Commits to this new branch and merge into `release/vn-1.0.x`, tag the backport version from `release/vn-1.0.x`. -#### example of backport release `v7.0.5`: +#### example of backport release `v7.0.5` + assume main branch is at `v8`. + 1. checkout `v705-prepare-branch` off `release/v7.0.x`, get the backport changes ready including CHANGELOG.md on `v705-prepare-branch`. 1. create a PR to merge `v705-prepare-branch` to `release/v7.0.x`, and merge. 1. checkout `release/v7.0.x` tag `v7.0.5`. ### Test building artifacts + Before tagging the version, please test the building releasing artifacts by + ```bash make distclean build-reproducible ``` -The above command will generate a directory + +The above command will generate a directory `gaia/artifacts` with different os and architecture binaries. If the above command runs sucessfully, delete the directory `rm -r gaia/artifacts`. ### Tagging The following steps are the default for tagging a specific branch commit (usually on a branch labeled `release/vX.X.X`): + 1. Ensure you have checked out the commit you wish to tag 1. `git pull --tags --dry-run` 1. `git pull --tags` @@ -89,11 +100,13 @@ The following steps are the default for tagging a specific branch commit (usuall 1. `git push --tags` To re-create a tag: + 1. `git tag -d v4.0.0` to delete a tag locally 1. `git push --delete origin v4.0.0`, to push the deletion to the remote 1. Proceed with the above steps to create a tag To tag and build without a public release (e.g., as part of a timed security release): + 1. Follow the steps above for tagging locally, but do not push the tags to the repository. 1. After adding the tag locally, you can build the binary, e.g., `make build-reproducible`. 1. To finalize the release, push the local tags, create a release based off the newly pushed tag, and attach the binaries. diff --git a/SECURITY.md b/SECURITY.md index 43d4b001991..b5eb4fb060d 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,11 +1,11 @@ # Security -This security document is the process that the Gaia team follows regarding security issues -that can impact partners and users of Gaia and the Cosmos Hub network. +This security document is the process that the Gaia team follows regarding security issues +that can impact partners and users of Gaia and the Cosmos Hub network. ## Prerequisites -If a vulnerability and its exploit are both publicly known, the security process may not apply. +If a vulnerability and its exploit are both publicly known, the security process may not apply. However, in such cases, resolutions and mitigation strategies may still be eligible for rewards through a bounty program. ## Reporting a Bug @@ -48,6 +48,7 @@ This process can take some time. Every effort will be made to handle the bug in ### Disclosure Communications Communications to Cosmos Hub Validators will include the following details: + 1. Affected version(s) 1. New release version 1. Impact on user funds @@ -56,6 +57,7 @@ Communications to Cosmos Hub Validators will include the following details: 1. Potential actions to take if an adverse condition arises during the security release process An example notice looks like: + ``` Dear Cosmos Hub Validators, diff --git a/contrib/githooks/README.md b/contrib/githooks/README.md index 633acef6a68..4bbaab31484 100644 --- a/contrib/githooks/README.md +++ b/contrib/githooks/README.md @@ -3,7 +3,7 @@ Installation: ``` -$ git config core.hooksPath contrib/githooks +git config core.hooksPath contrib/githooks ``` ## pre-commit @@ -14,8 +14,8 @@ that all the aforementioned commands are installed and available in the user's search `$PATH` environment variable: ``` -$ go install golang.org/x/tools/cmd/goimports -$ go install github.com/golangci/misspell/cmd/misspell@master +go install golang.org/x/tools/cmd/goimports +go install github.com/golangci/misspell/cmd/misspell@master ``` It also runs `go mod tidy` and `golangci-lint` if available. diff --git a/contrib/testnets/test_platform/README.md b/contrib/testnets/test_platform/README.md index a9172d5f1f5..a360a4d556f 100644 --- a/contrib/testnets/test_platform/README.md +++ b/contrib/testnets/test_platform/README.md @@ -15,9 +15,8 @@ This tool aims to simplify testing of key Cosmos Hub operations, such as module 1. Supports taking a pre-existing genesis file and creating a network with a sufficient number of validators. The network creates as many validators as needed to attain majority voting power on the new network (and produce new blocks with pre-existing genesis file). The validators that are replaced is the set that provides at least 66% of the total voting power given in the genesis file. - - **This feature allows testing upgrades and module migrations of existing networks, using their pre-existing genesis** :star: + **This feature allows testing upgrades and module migrations of existing networks, using their pre-existing genesis** :star: ## Usage @@ -27,13 +26,14 @@ This tool aims to simplify testing of key Cosmos Hub operations, such as module 1. Set `num_of_nodes_to_apply` to the _number of nodes to run_, e.g., `num_of_nodes_to_apply=4` 1. To create a network based on an existing genesis file: 1. Set `replacement_genesis` to the source genesis file; `.tar.gz` files are also supported - 1. Set `replacement_genesis_make_safe` to `True` in order to create as many nodes as needed to run a majority of validators. - 1. Otherwise, set `replacement_genesis_make_safe` value to blank to create `num_of_nodes_to_apply` nodes, e.g., `replacement_genesis_make_safe=`. + 1. Set `replacement_genesis_make_safe` to `True` in order to create as many nodes as needed to run a majority of validators. + 1. Otherwise, set `replacement_genesis_make_safe` value to blank to create `num_of_nodes_to_apply` nodes, e.g., `replacement_genesis_make_safe=`. Important: if the `replacement_genesis_make_safe` is not set, then the validator keys in the genesis file aren't replaced and so the network may not produce new blocks. 1. Optionally, set `LOG_LEVEL` to one of _(trace | debug | info | warn | error | fatal | panic)_; default _info_ 1. Start `gaiad_config_manager.py` -Notes for `template/replacement_defaults.txt`: +Notes for `template/replacement_defaults.txt`: + - only the last occurrence of a key and it's value are used, i.e., earlier occurrences are overwritten. - keys ending in `_PORT` are automatically incremented for each node @@ -42,4 +42,4 @@ Notes for `template/replacement_defaults.txt`: 1. custom network architectures 1. custom failure testing 1. ibc integration testing -1. module integration testing \ No newline at end of file +1. module integration testing diff --git a/docs/DOCS_README.md b/docs/DOCS_README.md index 91dde2de1df..6bc18257882 100644 --- a/docs/DOCS_README.md +++ b/docs/DOCS_README.md @@ -18,7 +18,7 @@ If you want to open a PR on Gaia to update the documentation, please follow the The documentation for Gaia is hosted at: -- https://hub.cosmos.network/ +- built from the files in this (`/docs`) directory for [main](https://github.com/cosmos/gaia/tree/main/docs). @@ -69,19 +69,23 @@ to send users to the GitHub. To build and serve the documentation locally, make sure you're in the `docs` directory and run the following: Clear `node_modules` for a clean install. This is not necessary every time. + ```bash rm -rf node_modules ``` Install project dependencies + ```bash npm install ``` Serve the app + ```bash npm run serve ``` + then navigate to `localhost:8080` in your browser. To build documentation as a static website run `npm run build`. You will find the website in `.vuepress/dist` directory. @@ -98,14 +102,17 @@ much as possible with its [counterpart in the Tendermint Core repo](https://gith ### Update and Build the RPC docs 1. Execute the following command at the root directory to install the swagger-ui generate tool. + ```bash make tools ``` + 2. Edit API docs 1. Directly Edit API docs manually: `cmd/gaiad/swagger-ui/swagger.yaml`. 2. Edit API docs within the [Swagger Editor](https://editor.swagger.io/). Please refer to this [document](https://swagger.io/docs/specification/2-0/basic-structure/) for the correct structure in `.yaml`. 3. Download `swagger.yaml` and replace the old `swagger.yaml` under fold `cmd/gaiad/swagger-ui`. 4. Compile gaiad + ```bash make install ``` diff --git a/docs/README.md b/docs/README.md index 2249d0b8fda..19d503ab37f 100644 --- a/docs/README.md +++ b/docs/README.md @@ -4,7 +4,7 @@ parent: layout: home --> -# Cosmos Hub Documentation +# Cosmos Hub Documentation Welcome to the documentation of the **Cosmos Hub application: `gaia`**. diff --git a/docs/delegators/delegator-faq.md b/docs/delegators/delegator-faq.md index 937c11f9d58..a7d4e1b3a89 100644 --- a/docs/delegators/delegator-faq.md +++ b/docs/delegators/delegator-faq.md @@ -11,7 +11,7 @@ People that cannot or do not want to operate [validator nodes](../validators/ove **Delegators share the revenue of their validators, but they also share the risks.** In terms of revenue, validators and delegators differ in that validators can apply a commission on the revenue that goes to their delegator before it is distributed. This commission is known to delegators beforehand and can only change according to predefined constraints (see [section](#choosing-a-validator) below). In terms of risk, delegators' Atoms can be slashed if their validator misbehaves. For more, see [Risks](#risks) section. -To become delegators, Atom holders need to send a ["Delegate transaction"](./delegator-guide-cli.md#sending-transactions) where they specify how many Atoms they want to bond and to which validator. A list of validator candidates will be displayed in Cosmos Hub explorers. Later, if a delegator wants to unbond part or all of their stake, they needs to send an "Unbond transaction". From there, the delegator will have to wait 3 weeks to retrieve their Atoms. Delegators can also send a "Rebond Transaction" to switch from one validator to another, without having to go through the 3 weeks waiting period. +To become delegators, Atom holders need to send a ["Delegate transaction"](./delegator-guide-cli.md#sending-transactions) where they specify how many Atoms they want to bond and to which validator. A list of validator candidates will be displayed in Cosmos Hub explorers. Later, if a delegator wants to unbond part or all of their stake, they needs to send an "Unbond transaction". From there, the delegator will have to wait 3 weeks to retrieve their Atoms. Delegators can also send a "Rebond Transaction" to switch from one validator to another, without having to go through the 3 weeks waiting period. For a practical guide on how to become a delegator, click [here](./delegator-guide-cli.md). @@ -23,9 +23,9 @@ In order to choose their validators, delegators have access to a range of inform - **Validator's description**: Description provided by the validator operator. - **Validator's website**: Link to the validator's website. - **Initial commission rate**: The commission rate on revenue charged to any delegator by the validator (see below for more detail). -- **Commission max change rate:** The maximum daily increase of the validator's commission. This parameter cannot be changed by the validator operator. -- **Maximum commission:** The maximum commission rate this validator candidate can charge. This parameter cannot be changed by the validator operator. -- **Minimum self-bond amount**: Minimum amount of Atoms the validator candidate need to have bonded at all time. If the validator's self-bonded stake falls below this limit, their entire staking pool (i.e. all its delegators) will unbond. This parameter exists as a safeguard for delegators. Indeed, when a validator misbehaves, part of their total stake gets slashed. This included the validator's self-delegateds stake as well as their delegators' stake. Thus, a validator with a high amount of self-delegated Atoms has more skin-in-the-game than a validator with a low amount. The minimum self-bond amount parameter guarantees to delegators that a validator will never fall below a certain amount of self-bonded stake, thereby ensuring a minimum level of skin-in-the-game. This parameter can only be increased by the validator operator. +- **Commission max change rate:** The maximum daily increase of the validator's commission. This parameter cannot be changed by the validator operator. +- **Maximum commission:** The maximum commission rate this validator candidate can charge. This parameter cannot be changed by the validator operator. +- **Minimum self-bond amount**: Minimum amount of Atoms the validator candidate need to have bonded at all time. If the validator's self-bonded stake falls below this limit, their entire staking pool (i.e. all its delegators) will unbond. This parameter exists as a safeguard for delegators. Indeed, when a validator misbehaves, part of their total stake gets slashed. This included the validator's self-delegateds stake as well as their delegators' stake. Thus, a validator with a high amount of self-delegated Atoms has more skin-in-the-game than a validator with a low amount. The minimum self-bond amount parameter guarantees to delegators that a validator will never fall below a certain amount of self-bonded stake, thereby ensuring a minimum level of skin-in-the-game. This parameter can only be increased by the validator operator. ## Directives of delegators @@ -55,7 +55,7 @@ This amounts to a total of 1000 Atoms and 100 Photons to be distributed among al Our validator's staking pool represents 10% of the total stake, which means the pool obtains 100 Atoms and 10 Photons. Now let us look at the internal distribution of revenue: -- Commission = `10% * 80% * 100` Atoms = 8 Atoms +- Commission = `10% * 80% * 100` Atoms = 8 Atoms - Validator's revenue = `20% * 100` Atoms + Commission = 28 Atoms - Delegators' total revenue = `80% * 100` Atoms - Commission = 72 Atoms @@ -67,6 +67,6 @@ Staking Atoms is not free of risk. First, staked Atoms are locked up, and retrie There is one main slashing condition: -- **Double signing:** If someone reports on that a validator signed two different blocks with the same chain ID at the same height, this validator will get slashed. +- **Double signing:** If someone reports on that a validator signed two different blocks with the same chain ID at the same height, this validator will get slashed. This is why Atom holders should perform careful due diligence on validators before delegating. It is also important that delegators actively monitor the activity of their validators. If a validator behaves suspiciously or is too often offline, delegators can choose to unbond from them or switch to another validator. **Delegators can also mitigate risk by distributing their stake across multiple validators.**s diff --git a/docs/delegators/delegator-security.md b/docs/delegators/delegator-security.md index 4d628723ffd..97768a26c6c 100644 --- a/docs/delegators/delegator-security.md +++ b/docs/delegators/delegator-security.md @@ -9,49 +9,50 @@ The launch of any public blockchain is an incredibly exciting time, and it's def ## Social Engineering -_[Social engineering](https://en.wikipedia.org/wiki/Social_engineering_(security))_ has existed for about as long as human beings have been on the planet, and in the technical era, it usually takes in the form of [phishing](https://ssd.eff.org/en/module/how-avoid-phishing-attacks) or [spearphishing](https://en.wikipedia.org/wiki/Phishing#Spear_phishing) . Both of these attacks are wildly successful forms of trickery that are responsible for over 95% of account security breaches, and they don't just happen via email: these days, opportunistic and targeted phishing attempts take place [anywhere that you have an inbox](https://www.umass.edu/it/security/phishing-fraudulent-emails-text-messages-phone-calls) . It doesn't matter if you're using Signal, Telegram, SMS, Twitter, or just checking your DMs on forums or social networks, attackers have a [plethora of opportunities](https://jia.sipa.columbia.edu/weaponization-social-media-spear-phishing-and-cyberattacks-democracy) to gain foothold in your digital life in effort to separate you from valuable information and assets that you most definitely don't want to lose. If a deal pops up that [sounds too good to be true](https://www.psychologytoday.com/us/blog/mind-in-the-machine/201712/how-fear-is-being-used-manipulate-cryptocurrency-markets) , or a message shows up asking for information that should never, ever be shared with someone else, you can always verify it before engaging with it by navigating to our official website or an official Cosmos communication channel on your own. +_[Social engineering](https://en.wikipedia.org/wiki/Social_engineering_(security))_ has existed for about as long as human beings have been on the planet, and in the technical era, it usually takes in the form of [phishing](https://ssd.eff.org/en/module/how-avoid-phishing-attacks) or [spearphishing](https://en.wikipedia.org/wiki/Phishing#Spear_phishing) . Both of these attacks are wildly successful forms of trickery that are responsible for over 95% of account security breaches, and they don't just happen via email: these days, opportunistic and targeted phishing attempts take place [anywhere that you have an inbox](https://www.umass.edu/it/security/phishing-fraudulent-emails-text-messages-phone-calls) . It doesn't matter if you're using Signal, Telegram, SMS, Twitter, or just checking your DMs on forums or social networks, attackers have a [plethora of opportunities](https://jia.sipa.columbia.edu/weaponization-social-media-spear-phishing-and-cyberattacks-democracy) to gain foothold in your digital life in effort to separate you from valuable information and assets that you most definitely don't want to lose. If a deal pops up that [sounds too good to be true](https://www.psychologytoday.com/us/blog/mind-in-the-machine/201712/how-fear-is-being-used-manipulate-cryptocurrency-markets) , or a message shows up asking for information that should never, ever be shared with someone else, you can always verify it before engaging with it by navigating to our official website or an official Cosmos communication channel on your own. -* **Be skeptical of unexpected attachments, or emails that ask you to visit a suspicious or unfamiliar website in the context of blockchains or cryptocurrency.** An attacker may attempt to lure you to a [compromised site](https://blog.malwarebytes.com/cybercrime/2013/02/tools-of-the-trade-exploit-kits/) designed to steal sensitive information from your computer. If you're a Gmail user, test your resilience against the latest email-based phishing tactics [here](https://phishingquiz.withgoogle.com/) . +* **Be skeptical of unexpected attachments, or emails that ask you to visit a suspicious or unfamiliar website in the context of blockchains or cryptocurrency.** An attacker may attempt to lure you to a [compromised site](https://blog.malwarebytes.com/cybercrime/2013/02/tools-of-the-trade-exploit-kits/) designed to steal sensitive information from your computer. If you're a Gmail user, test your resilience against the latest email-based phishing tactics [here](https://phishingquiz.withgoogle.com/) . -* **Do your due diligence before purchasing ATOM. Neither the Tendermint team nor the Interchain Foundation will be selling ATOM at launch**, so if you see social media posts or emails advertising a token sale from us, they're not real and should be dismissed immediately. If you're on the hunt for ATOM, make sure that you've researched the seller or exchange to confirm that the tokens are coming from a trustworthy source. +* **Do your due diligence before purchasing ATOM. Neither the Tendermint team nor the Interchain Foundation will be selling ATOM at launch**, so if you see social media posts or emails advertising a token sale from us, they're not real and should be dismissed immediately. If you're on the hunt for ATOM, make sure that you've researched the seller or exchange to confirm that the tokens are coming from a trustworthy source. * **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 12 words with us**, and we will always use our official Twitter, Medium, and Github accounts to communicate important news directly to the Cosmos community. If you receive an email or tweet that sounds too good to be true, is likely to be a scam. +## Key Management -## Key Management -The best way to minimize the risk of theft or loss of ATOM is to have a strong storage and backup strategy for your private keys. The safest way to store your keys is offline, either in a cryptocurrency wallet or on a device that you never connect to the internet. The best backup strategy for your k yes is to ensure that you have multiple copies of them stored in safe places, and to take specific measures to protect at least one copy of your keys from any kind of natural disaster that is a likely possibility in your part of the world. - -**To protect your ATOM, do not share your 12 words with anyone.** The only person who should ever need to know them is you. You do not need to share your private keys if you're delegating ATOM to a validator on the network or to use custodial services. If anyone asks for your key material, +The best way to minimize the risk of theft or loss of ATOM is to have a strong storage and backup strategy for your private keys. The safest way to store your keys is offline, either in a cryptocurrency wallet or on a device that you never connect to the internet. The best backup strategy for your k yes is to ensure that you have multiple copies of them stored in safe places, and to take specific measures to protect at least one copy of your keys from any kind of natural disaster that is a likely possibility in your part of the world. +**To protect your ATOM, do not share your 12 words with anyone.** The only person who should ever need to know them is you. You do not need to share your private keys if you're delegating ATOM to a validator on the network or to use custodial services. If anyone asks for your key material, ## Software Vulnerabilities -To protect yourself and ensure you're using the safest code is to use the latest version of software available, and to update immediately (or as soon as you can) after a security advisory is released. This is important for your laptops, mobile devices, cryptocurrency wallets, and anything else that may be linked to your identity or your cryptocurrency. -*To protect your ATOM, you should only download software directly from official sources, and make sure that you're always using the latest, most secure version of `gaiad` when you're doing anything that involves your 12 words*. The latest versions of `Tendermint`, the `Cosmos-SDK`, and `gaiad` will always be available from our official Github repositories. +To protect yourself and ensure you're using the safest code is to use the latest version of software available, and to update immediately (or as soon as you can) after a security advisory is released. This is important for your laptops, mobile devices, cryptocurrency wallets, and anything else that may be linked to your identity or your cryptocurrency. -No one from Cosmos, the Tendermint team or the Interchain Foundation will ever send an email that asks for you to download a software attachment after sending out a security advisory or making a patch available. +*To protect your ATOM, you should only download software directly from official sources, and make sure that you're always using the latest, most secure version of `gaiad` when you're doing anything that involves your 12 words*. The latest versions of `Tendermint`, the `Cosmos-SDK`, and `gaiad` will always be available from our official Github repositories. +No one from Cosmos, the Tendermint team or the Interchain Foundation will ever send an email that asks for you to download a software attachment after sending out a security advisory or making a patch available. ## Verifying Transactions -Be skeptical of technical advice, especially advice that comes from people you do not know in forums and on group chat channels. Familiarize yourself with important commands, especially those that will help you carry out high-risk actions, and consult our official documentation to make sure that you're not being tricked into doing something that will harm you or your validator. -**When sending transactions or doing anything that may spend coins, you should always verify those transactions before hitting send**. While address strings are long, it is important to visually comparing them in blocks of 4 characters at a time to ensure that you are sending them to the right place rather than into oblivion. +Be skeptical of technical advice, especially advice that comes from people you do not know in forums and on group chat channels. Familiarize yourself with important commands, especially those that will help you carry out high-risk actions, and consult our official documentation to make sure that you're not being tricked into doing something that will harm you or your validator. + +**When sending transactions or doing anything that may spend coins, you should always verify those transactions before hitting send**. While address strings are long, it is important to visually comparing them in blocks of 4 characters at a time to ensure that you are sending them to the right place rather than into oblivion. ## Account Security -One of the most important things you can do to protect your cryptocurrency and eliminate risk is to harden all of your critical online accounts. Attackers will try to gain foothold wherever they can, and will use that foothold to pivot from one place to another. Unprotected accounts like email, social media, your Github account, the Cosmos Forum and anything in between could give an attacker an opportunities to gain foothold in your online life. -For people who hold cryptocurrency, there are two specific account security actions that can be taken to eliminate specific risks that come with being part of the blockchain world. +One of the most important things you can do to protect your cryptocurrency and eliminate risk is to harden all of your critical online accounts. Attackers will try to gain foothold wherever they can, and will use that foothold to pivot from one place to another. Unprotected accounts like email, social media, your Github account, the Cosmos Forum and anything in between could give an attacker an opportunities to gain foothold in your online life. -* First, it is important to enable 2-factor authentication everywhere you can, and to make sure that you are using a code generator or [U2F hardware key](https://en.wikipedia.org/wiki/Universal_2nd_Factor) as a second factor. +For people who hold cryptocurrency, there are two specific account security actions that can be taken to eliminate specific risks that come with being part of the blockchain world. -* Second, be mindful of account recovery methods used to regain access to your most important accounts and make sure that you do not use SMS as a recovery method. If you haven't done so yet, start using an authenticator app or a hardware key immediately for your personal email account and wherever else you manage your tokens, especially if you use online exchanges. +* First, it is important to enable 2-factor authentication everywhere you can, and to make sure that you are using a code generator or [U2F hardware key](https://en.wikipedia.org/wiki/Universal_2nd_Factor) as a second factor. +* Second, be mindful of account recovery methods used to regain access to your most important accounts and make sure that you do not use SMS as a recovery method. If you haven't done so yet, start using an authenticator app or a hardware key immediately for your personal email account and wherever else you manage your tokens, especially if you use online exchanges. ## Supply Chain Attacks -Whether you're buying a hardware or a hardware wallet, it is important to purchase whatever you need directly from the supplier or from a trusted source. This is the only way to completely eliminate the risk of a compromised device or chip from stealing your private keys, especially since there are reports of compromised wallets being sold on Amazon and through other popular online marketplaces. + +Whether you're buying a hardware or a hardware wallet, it is important to purchase whatever you need directly from the supplier or from a trusted source. This is the only way to completely eliminate the risk of a compromised device or chip from stealing your private keys, especially since there are reports of compromised wallets being sold on Amazon and through other popular online marketplaces. ## Disclaimer -Please note that this is highly experimental software. In these early days, we can expect to have issues, updates, and bugs. The existing tools require advanced technical skills and involve risks which are outside of the control of the Interchain Foundation and/or the Tendermint team (see also the risk section in the Interchain Cosmos Contribution Terms). Any use of this open source Apache 2.0 licensed software is done at your own risk and on a "AS IS" basis, without warranties or conditions of any kind, and any and all liability of the Interchain Foundation and/or the Tendermint team for damages arising in connection to the software is excluded. Please exercise extreme caution!` \ No newline at end of file +Please note that this is highly experimental software. In these early days, we can expect to have issues, updates, and bugs. The existing tools require advanced technical skills and involve risks which are outside of the control of the Interchain Foundation and/or the Tendermint team (see also the risk section in the Interchain Cosmos Contribution Terms). Any use of this open source Apache 2.0 licensed software is done at your own risk and on a "AS IS" basis, without warranties or conditions of any kind, and any and all liability of the Interchain Foundation and/or the Tendermint team for damages arising in connection to the software is excluded. Please exercise extreme caution!` diff --git a/docs/es/gaia-tutorials/installation.md b/docs/es/gaia-tutorials/installation.md index 839fa49e05f..bf9246f3605 100644 --- a/docs/es/gaia-tutorials/installation.md +++ b/docs/es/gaia-tutorials/installation.md @@ -52,8 +52,8 @@ LDFLAGS="" make install Esto debería instalar los binarios de `gaiad`y `gaiad`. Verifique que todo esta OK: ```bash -$ gaiad version --long -$ gaiad version --long +gaiad version --long +gaiad version --long ``` `gaiad` por su parte, debería dar como resultado algo similar a: diff --git a/docs/es/gaia-tutorials/join-mainnet.md b/docs/es/gaia-tutorials/join-mainnet.md index 8bfe97a30e7..af65e00a3dd 100644 --- a/docs/es/gaia-tutorials/join-mainnet.md +++ b/docs/es/gaia-tutorials/join-mainnet.md @@ -33,6 +33,7 @@ Puede editar el apodo (`moniker`) después, en el archivo `~/.gaia/config/config # A custom human readable name for this node moniker = "" ``` + Puede editar el archivo `~/.gaia/config/app.toml` para activar el mecanismo antispam y rechazar las transacciones entrantes con valores inferiores a los precios mínimos para el _gas_: ``` @@ -95,7 +96,7 @@ Las transacciones en la red del Hub de Cosmos deben incluir una tarifa de transa tarifa = techo(gas * precioPorGas) ``` -El `gas` depende de la transacción. Diferentes transacciones requieren diferentes cantidades de `gas`. La cantidad de `gas` para una transacción se calcula mientras se procesa, pero hay una forma previa de estimarla usando el valor `auto` para el indicador de `gas`. Por supuesto, esto sólo da una estimación. Puede ajustar esta estimación con el identificador `--gas-adjustment` (por defecto `1.0`) si quiere estar seguro de que proporciona suficiente `gas` para la transacción. +El `gas` depende de la transacción. Diferentes transacciones requieren diferentes cantidades de `gas`. La cantidad de `gas` para una transacción se calcula mientras se procesa, pero hay una forma previa de estimarla usando el valor `auto` para el indicador de `gas`. Por supuesto, esto sólo da una estimación. Puede ajustar esta estimación con el identificador `--gas-adjustment` (por defecto `1.0`) si quiere estar seguro de que proporciona suficiente `gas` para la transacción. El `gasPrice` (i.e `precioPorGas`) es el precio de cada unidad de `gas`. Cada validador establece un valor de `min-gas-price`, y sólo incluirá transacciones que tengan un `gasPrice` mayor que su `min-gas-price`. diff --git a/docs/es/governance/community-pool-spend/README.md b/docs/es/governance/community-pool-spend/README.md index 04cf7779dad..8d70e86462a 100644 --- a/docs/es/governance/community-pool-spend/README.md +++ b/docs/es/governance/community-pool-spend/README.md @@ -1,8 +1,10 @@ # Cosmos Hub 3 y la Community Pool + La iniciativa Cosmos Hub 3 fue lanzada por parte de la comunidad el 11 de Diciembre de 2019, liberando así la posibilidad de que las personas con tokens puedan votar la aprobación de gastos desde la Community Pool.**Esta documentación es un desarrollo en curso, por favor, de momento no te bases en esta información** [Puedes debatir este desarrollo aquí](https://forum.cosmos.network/t/gwg-community-spend-best-practices/3240). ## ¿Por qué crear una propuesta para utilizar fondos de la Community Pool? + Hay otras opciones de financiación, principalmente el programa de concesión de la Interchain Foundation. ¿Por qué crear una propuesta para gastos? **Como estrategia: puedes hacer ambas.** Puedes enviar tu propuesta a la Interchain Foundation, pero también tienes la posibilidad sobre la cadena de forma pública. Si el Hub vota a favor, puedes retirar tu solicitud a la Interchain Foundation. @@ -14,10 +16,11 @@ Hay otras opciones de financiación, principalmente el programa de concesión de **Para ser más independiente.** La Interchain Foundation (ICF) puede no ser capaz de financiar trabajo siempre. Tener una fuente de financiación más constante y con un canal directo a los stakeholders, significa que puedes usar tus buenas relaciones para tener la confianza de ser capaz de encontrar financiación segura sin depender únicamente de la ICF. ## Creación de una propuesta de gastos a la comunidad -Crear y enviar una propuesta es un proceso que lleva tiempo, atención y conlleva riesgo. El objetivo de esta documentación es hacer este proceso más fácil, preparando a los participantes para aquello en lo que deben prestar atención, la información que debe ser incluida en la propuesta, y cómo reducir el riesgo de perder depósitos. Idealmente, una propuesta que no sigue adelante debería ser solamente porque los votantes 1) son conscientes y están involucrados y 2) son capaces de tomar una decisión e informarla votando en la propuesta. +Crear y enviar una propuesta es un proceso que lleva tiempo, atención y conlleva riesgo. El objetivo de esta documentación es hacer este proceso más fácil, preparando a los participantes para aquello en lo que deben prestar atención, la información que debe ser incluida en la propuesta, y cómo reducir el riesgo de perder depósitos. Idealmente, una propuesta que no sigue adelante debería ser solamente porque los votantes 1) son conscientes y están involucrados y 2) son capaces de tomar una decisión e informarla votando en la propuesta. Si estás considerando realizar una propuesta, deberías conocer: + 1. [Sobre la Community Pool](#sobre-la-community-pool) 2. [Cómo funciona el mecanismo de voto y gobernanza](../overview.md#_2-voting-period) 3. [Dónde y cómo involucrar a la comunidad de Cosmos acerca de tu idea](../best_practices.md) @@ -25,22 +28,25 @@ Si estás considerando realizar una propuesta, deberías conocer: 5. [Cómo preparar tu borrador de propuesta final para ser enviada](../submitting.md) 6. [Cómo enviar tu propuesta al Cosmos Hub testnet & mainnet](../submitting.md) - ## Sobre la Community Pool ### ¿Cómo está financiada la Community Pool? + El 2% de todas las delegaciones de fondos generadas (vía recompensa de bloques y tasas de transacción) es continuamente transferido y acumulado en la Community Pool. Por ejemplo, desde el 19 de Diciembre de 2019 hasta el 20 de Enero de 2020 (32 días), se generaron y añadieron a la pool un total de 28,726 ATOM. ### ¿Cómo puede cambiar la financiación de la Community Pool? -Aunque la tasa de financiación está actualmente fijada en el 2% de las delegaciones, la tasa más efectiva es dependiente de los fondos pertenecientes al Cosmos Hub, que puede cambiar con la inflacción y tiempos de bloque. + +Aunque la tasa de financiación está actualmente fijada en el 2% de las delegaciones, la tasa más efectiva es dependiente de los fondos pertenecientes al Cosmos Hub, que puede cambiar con la inflacción y tiempos de bloque. La tasa actual del 2% de financiación podría ser modificada con una propuesta de gobernanza y aprobaba de forma inmediata en cuanto la propuesta sea aprobada. Actualmente, no se pueden enviar fondos a la Community Pool, pero esperamos que esto cambie con la siguiente actualización. Lee más sobre esta nueva funcionalidad [aqui](https://github.com/cosmos/cosmos-sdk/pull/5249). ¿Qué hace que esta funcionalidad sea importante? + 1. Los proyectos financiados que finalmente no se ejecuten deben devolver los fondos a la Community Pool; 2. Las entidades podrían ayudar a aportar fondos a la Community Pool mediante aportación directa a la cuenta. ### ¿Cuál es el saldo de la Community Pool? + Puedes solicitar directamente al Cosmos Hub 3 el saldo de la Community Pool: ```gaiad q distribution community-pool --chain-id cosmoshub-3 --node cosmos-node-1.figment.io:26657``` @@ -48,12 +54,15 @@ Puedes solicitar directamente al Cosmos Hub 3 el saldo de la Community Pool: De forma alternativa, los navegadores de Cosmos más populares como [Big Dipper](https://cosmos.bigdipper.live) y [Hubble](https://hubble.figment.io/cosmos/chains/cosmoshub-3) muestran la evolución del saldo de la Community Pool. ### ¿Cómo se pueden gastar los fondos de la Community Pool? + Los fondos de la Cosmos Community Pool pueden ser gastados a través de propuestas de gobernanza aprobadas. ### ¿Cómo se deberían gastar los fondos de la Community Pool? + No lo sabemos 🤷 La suposición principal es que los fondos deberían ser gastados de forma que aporte valor al Cosmos Hub. Sin embargo, hay debate entorno a cómo hacer el fondo sostenible. También hay algún debate acerca de cómo se debería recibir financiación. Por ejemplo, parte de la comunidad cree que los fondos solamente deberían ser utilizados por aquellas personas que más los necesiten. Otros temas de discusión son: + - concesiones retroactivas - negociación de precio - desembolso de fondos (por ejemplo, pagos por fases; pagos fijos para reducir volatilidad) @@ -62,6 +71,7 @@ La suposición principal es que los fondos deberían ser gastados de forma que a Esperamos que todo esto tome forma a medida que las propuestas sean debatidas, aceptadas, y rechazadas por parte de la comunidad Cosmos Hub. ### ¿Cómo se desembolsan los fondos una vez que una prouesta de gastos de comunidad es aprobada? + Si una propuesta de gastos de comunidad es aprobada, el número de ATOM inluidos en la propuesta serán transferidos desde la community pool a la dirección especificada en la propuesta, y esto ocurrirá justo inmediatamente después de que el periodo de votación termine. diff --git a/docs/es/governance/params-change/Governance.md b/docs/es/governance/params-change/Governance.md index 2e50c55cc0a..dcc7ac06fcc 100644 --- a/docs/es/governance/params-change/Governance.md +++ b/docs/es/governance/params-change/Governance.md @@ -1,6 +1,8 @@ # Módulo `gov` + El módulo `gov` es responsable de las propuestas de gobierno en cadena y la funcionalidad de la votación. Nótese que [este módulo requiere una forma única de cambiar sus parámetros](https://github.com/cosmos/cosmos-sdk/issues/5800). `gov` está activo en Cosmos Hub 3 y actualmente tiene tres parámetros con seis subkeys que pueden ser modificados por una propuesta de gobernanza: + 1. [`depositparams`](#1-depositparams) - [`mindeposit`](#mindeposit) - `512000000` `uatom` (micro-ATOMs) - [`maxdepositperiod`](#maxdepositperiod) - `1209600000000000` (nanosegundos) @@ -20,108 +22,151 @@ Se están considerando [algunas funciones adicionales](./Governance.md#future) p Si estás técnicamente preparado, [estas son las especificaciones técnicas](./Governance.md#technical-specifications). Si quieres crear una propuesta para cambiar uno o más de estos parámetros, [mira esta sección para el formato](../submitting.md#formatting-the-json-file-for-the-governance-proposal). ## 1. `depositparams` + ## `mindeposit` + ### El depósito mínimo requerido para que una propuesta entre en el [período de votación](params-change/Governance.md#votingperiod), en micro-ATOMs + #### `cosmoshub-3` por defecto: `512000000` `uatom` Antes de que una propuesta de gobierno entre en el [período de votación](./Governance.md#votingperiod) (es decir, para que la propuesta sea votada), debe haber al menos un número mínimo de ATOMs depositados. Cualquiera puede contribuir a este depósito. Los depósitos de las propuestas aprobadas y fallidas se devuelven a los contribuyentes. Los depósitos se queman cuando las propuestas 1) [expiran](./Governance.md#maxdepositperiod), 2) no alcanzan el [quórum](./Governance.md#quorum), o 3) son [vetadas](./Governance.md#veto). El valor de subkey de este parámetro representa el depósito mínimo requerido para que una propuesta entre en el [período de votación](./Governance.md#votingperiod) en micro-ATOMs, donde `512000000uatom` equivalen a 512 ATOM. ### Posibles consecuencias + #### Disminución del valor `mindeposit` + La disminución del valor de subkey `mindeposit` permitirá que las propuestas de gobernanza entren en el [período de votación](./Governance.md#votingperiod) con menos ATOMs en juego. Es probable que esto aumente el volumen de nuevas propuestas de gobernanza. #### Aumentar el valor `mindeposit` + Para aumentar el valor de subkey `mindeposit` será necesario arriesgar un mayor número de ATOMs antes de que las propuestas de gobierno puedan entrar en el [período de votación](./Governance.md#votingperiod). Es probable que esto disminuya el volumen de nuevas propuestas de gobierno. ## `maxdepositperiod` -### La cantidad máxima de tiempo que una propuesta puede aceptar contribuciones de depósito antes de expirar, en nanosegundos. + +### La cantidad máxima de tiempo que una propuesta puede aceptar contribuciones de depósito antes de expirar, en nanosegundos + #### `cosmoshub-3` por defecto: `1209600000000000` Antes de que una propuesta de gobierno entre en el [período de votación](./Governance.md#votingperiod), debe haber al menos un número mínimo de ATOMs depositados. El valor de subkey de este parámetro representa la cantidad máxima de tiempo que la propuesta tiene para alcanzar la cantidad mínima de depósito antes de expirar. La cantidad máxima de tiempo que una propuesta puede aceptar contribuciones de depósito antes de expirar es actualmente de 1209600000000000 nanosegundos o 14 días. Si la propuesta expira, cualquier cantidad de depósito será quemada. ### Posibles consecuencias + #### Disminución del valor `maxdepositperiod` + La disminución del valor de subkey `maxdepositperiod` reducirá el tiempo de depósito de las contribuciones a las propuestas de gobernanza. Es probable que esto disminuya el tiempo que algunas propuestas permanecen visibles y que disminuya la probabilidad de que entren en el período de votación. Esto puede aumentar la probabilidad de que las propuestas caduquen y se quemen sus depósitos. #### Aumentar el valor `maxdepositperiod` + El aumento del valor de subkey `maxdepositperiod` ampliará el plazo para las contribuciones de depósito a las propuestas de gobernanza. Es probable que esto aumente el tiempo en que algunas propuestas siguen siendo visibles y aumente potencialmente la probabilidad de que entren en el [período de votación](./Governance.md#votingperiod). Esto puede disminuir la probabilidad de que las propuestas caduquen y se quemen sus depósitos. #### Observaciones + Actualmente, la mayoría de los exploradores de la red (por ejemplo, Hubble, Big Dipper, Mintscan) dan la misma visibilidad a las propuestas en el período de depósito que a las del [período de votación](./Governance.md#votingperiod). Esto significa que una propuesta con un pequeño depósito (por ejemplo, 0.001 ATOM) tendrá la misma visibilidad que aquellas con un depósito completo de 512 ATOM en el período de votación. ## 2. `votingparams` + ## `votingperiod` -### La cantidad máxima de tiempo que una propuesta puede aceptar votos antes de que concluya el período de votación, en nanosegundos. + +### La cantidad máxima de tiempo que una propuesta puede aceptar votos antes de que concluya el período de votación, en nanosegundos + #### `cosmoshub-3` por defecto: `1209600000000000` Una vez que una propuesta de gobierno entra en el período de votación, hay un período máximo de tiempo que puede transcurrir antes de que concluya el período de votación. El valor de subkey de este parámetro representa la cantidad máxima de tiempo que la propuesta tiene para aceptar los votos, que actualmente es de `1209600000000000` nanosegundos o 14 días. Si la votación de la propuesta no alcanza el quórum (es decir, el 40% del poder de voto de la red participa) antes de este tiempo, se quemarán las cantidades depositadas y el resultado de la propuesta no se considerará válido. Los votantes pueden cambiar su voto tantas veces como quieran antes de que termine el período de votación. Este período de votación es actualmente el mismo para cualquier tipo de propuesta de gobierno. ### Posibles consecuencias + #### Disminución del valor `votingperiod` + La disminución del valor de subkey `votingperiod` reducirá el tiempo de votación de las propuestas de gobernanza. Esto podría significar: + 1. disminuir la proporción de la red que participa en la votación, y 2. disminución de la probabilidad de que se alcance el quórum. #### Aumentar el valor `votingperiod` + El aumento del valor de subkey `votingperiod` aumentará el tiempo de votación de las propuestas de gobernanza. Esto puede: + 1. aumentar la proporción de la red que participa en la votación, y 2. aumentar la probabilidad de que se alcance el quórum. #### Observaciones + Históricamente, los debates y el compromiso fuera de la cadena parecen haber sido mayores durante el período de votación de una propuesta de gobernanza que cuando la propuesta se publica fuera de la cadena como un boceto. En la segunda semana del período de votación se ha votado una cantidad no trivial del poder de voto. Las propuestas 23, 19 y 13 tuvieron cada una aproximadamente un 80% de participación en la red o más. ## 2. `tallyparams` + ## `quorum` -### La proporción mínima de poder de voto de la red que se requiere para que el resultado de una propuesta de gobierno se considere válido. + +### La proporción mínima de poder de voto de la red que se requiere para que el resultado de una propuesta de gobierno se considere válido + #### `cosmoshub-3` por defecto: `0.400000000000000000` Se requiere quórum para que el resultado de la votación de una propuesta de gobierno se considere válido y para que los contribuyentes de depósitos recuperen sus cantidades depositadas, y el valor de subkey de este parámetro representa el valor mínimo para el quórum. El poder de voto, ya sea que respalde un voto de 'yes', 'abstain', 'no', or 'no-with-veto', cuenta para el quórum. Si la votación de la propuesta no alcanza el quórum (es decir, el 40% del poder de voto de la red participa) antes de este momento, se quemará cualquier cantidad depositada y el resultado de la propuesta no se considerará válido. ### Posibles consecuencias + #### Disminución del valor `quorum` + La disminución del valor de subkey `quorum` permitirá que una proporción menor de la red legitime el resultado de una propuesta. Esto aumenta el riesgo de que se tome una decisión con una proporción menor de los participantes con ATOMs, al tiempo que disminuye el riesgo de que una propuesta se considere inválida. Esto probablemente disminuirá el riesgo de que el depósito de una propuesta se queme. #### Aumentar el valor `quorum` + El aumento del valor de subkey `quorum` requerirá una mayor proporción de la red para legitimar el resultado de una propuesta. Esto disminuye el riesgo de que se tome una decisión con una proporción menor de los participantes con ATOMs, al tiempo que aumenta el riesgo de que una propuesta se considere inválida. Es probable que esto aumente el riesgo de que se queme el depósito de una propuesta. ## `threshold` -### La proporción mínima del poder de voto necesario para que se apruebe una propuesta de gobierno. + +### La proporción mínima del poder de voto necesario para que se apruebe una propuesta de gobierno + #### `cosmoshub-3` por defecto: `0.500000000000000000` Se requiere una mayoría simple de votos a favor (es decir, el 50% del poder de voto participativo) para que se apruebe una propuesta de gobierno. Aunque es necesario, un voto de mayoría simple 'yes' puede no ser suficiente para aprobar una propuesta en dos escenarios: + 1. No se alcanza un [quórum](./Governance.md#quorum) del 40% de la capacidad de la red o 2. Un voto de 'no-with-veto' del 33,4% del poder de voto o mayor. Si se aprueba una propuesta de gobernanza, las cantidades depositadas se devuelven a los contribuyentes. Si se aprueba una propuesta basada en texto, nada se promulga automáticamente, pero existe una expectativa social de que los participantes se coordinen para promulgar los compromisos señalados en la propuesta. Si se aprueba una propuesta de cambio de parámetros, el parámetro de protocolo cambiará inmediatamente después de que termine el [período de votación](./Governance.md#votingperiod), y sin necesidad de ejecutar un nuevo software. Si se aprueba una propuesta de gasto comunitario, el saldo de la Reserva Comunitaria disminuirá en el número de ATOMs indicados en la propuesta y la dirección del destinatario aumentará en ese mismo número de ATOMs inmediatamente después de que termine el período de votación. ### Posibles consecuencias + #### Disminución del valor `threshold` + La disminución del valor de subkey `threshold` disminuirá la proporción del poder de voto necesario para aprobar una propuesta. Esto puede: + 1. aumentará la probabilidad de que una propuesta sea aprobada, y 2. aumentará la probabilidad de que un grupo minoritario realice cambios en la red. #### Aumentar el valor `threshold` + Aumentar el valor de subkey `threshold` aumentará la proporción de poder de voto necesario para aprobar una propuesta. Esto puede: + 1. disminuir la probabilidad de que una propuesta sea aprobada, y 2. disminuir la probabilidad de que un grupo minoritario realice cambios en la red. ## `veto` -### La proporción mínima de poder de voto de los participantes para vetar (es decir, rechazar) una propuesta de gobierno. + +### La proporción mínima de poder de voto de los participantes para vetar (es decir, rechazar) una propuesta de gobierno + #### `cosmoshub-3` por defecto: `0.334000000000000000` Aunque se requiere un voto de 'yes' por mayoría simple (es decir, el 50% del poder de voto participante) para que se apruebe una propuesta de gobierno, un voto de 'no-with-veto' del 33,4% del poder de voto participante o superior puede anular este resultado y hacer que la propuesta fracase. Esto permite que un grupo minoritario que represente más de 1/3 del poder de voto pueda hacer fracasar una propuesta que de otro modo sería aprobada. ### Posibles consecuencias + #### Disminución del valor `veto` + Disminuir el valor de subkey `veto` disminuirá la proporción de poder de voto de los participantes requerida para vetar. Esto puede: + 1. permiten a un grupo minoritario más pequeño evitar que las propuestas sean aprobadas, y 2. disminuyen la probabilidad de que se aprueben propuestas controvertidas. #### Aumentar el valor `veto` + Aumentar el valor de subkey `veto` aumentará la proporción del poder de voto requerido para vetar. Esto requerirá un grupo minoritario más grande para evitar que las propuestas sean aprobadas, y probablemente aumentará la probabilidad de que se aprueben las propuestas controvertidas. # Verificar los valores de los parámetros + ## Parámetros de Génesis (aka lanzamiento) + Esto es útil si no tienes `gaiad` instalado y no tienes una razón para creer que el parámetro ha cambiado desde que se lanzó la cadena. Cada parámetro puede ser verificado en el archivo génesis de la cadena, que encuentra [aquí](https://raw.githubusercontent.com/cosmos/launch/master/genesis.json). Estos son los parámetros con los que la última cadena del Hub de Cosmos se lanzó, y seguirá haciéndolo, a menos que una propuesta de gobierno los cambie. He resumido esos valores originales en la sección [Especificaciones Técnicas](./Governance.md#technical-specifications). @@ -131,16 +176,18 @@ El archivo génesis contiene texto y es grande. El esquema de nombres de los par Por ejemplo, si quiero buscar `depositparams`, buscaré en el [génesis](https://raw.githubusercontent.com/cosmos/launch/master/genesis.json) `deposit_params`. ## Parámetros actuales + Puede verificar los valores actuales de los parámetros (en caso de que hayan sido modificados mediante la propuesta de gobierno posterior al lanzamiento) con la aplicación de [línea de comandos gaiad](params-change/gaiad). Aquí están los comandos para cada uno: + 1. `depositparams` - `gaiad q ..` --> **to do** <-- ## Futuro La documentación actual sólo describe el producto mínimo viable para el módulo de gobernanza. Las mejoras futuras pueden incluir: -* **`BountyProposals`:** Si es aceptada, un `BountyProposal` crea una recompensa abierta. El `BountyProposal` especifica cuántos átomos se entregarán al finalizar. Estos átomos serán tomados del `reserve pool`. Después de que un `BountyProposal` es aceptado por el gobierno, cualquiera puede presentar un `SoftwareUpgradeProposal` con el código para reclamar la recompensa. Tenga en cuenta que una vez que el `BountyProposal` es aceptado, los fondos correspondientes en la `reserve pool` se bloquean para que el pago siempre pueda ser cumplido. Para vincular un `SoftwareUpgradeProposal` con una recompensa abierta, el remitente del `SoftwareUpgradeProposal` utilizará el atributo `Proposal.LinkedProposal`. Si un `SoftwareUpgradeProposal` vinculado a una recompensa abierta es aceptado por la administración, los fondos reservados se transfieren automáticamente al autor de la propuesta. -* **Complex delegation:** Los delegadores podrán elegir otros representantes además de sus validadores. En última instancia, la cadena de representantes siempre terminaría en un validador, pero los delegadores podrían heredar el voto de su representante elegido antes de heredar el voto de su validador. En otras palabras, sólo heredarían el voto de su validador si su otro representante designado no votara. -* **Mejor proceso de revisión de propuestas:** La propuesta consta de dos partes de `proposal.Deposit`, uno para la lucha contra el correo basura (igual que en el MVP) y otro para recompensar a los auditores de terceros. +- **`BountyProposals`:** Si es aceptada, un `BountyProposal` crea una recompensa abierta. El `BountyProposal` especifica cuántos átomos se entregarán al finalizar. Estos átomos serán tomados del `reserve pool`. Después de que un `BountyProposal` es aceptado por el gobierno, cualquiera puede presentar un `SoftwareUpgradeProposal` con el código para reclamar la recompensa. Tenga en cuenta que una vez que el `BountyProposal` es aceptado, los fondos correspondientes en la `reserve pool` se bloquean para que el pago siempre pueda ser cumplido. Para vincular un `SoftwareUpgradeProposal` con una recompensa abierta, el remitente del `SoftwareUpgradeProposal` utilizará el atributo `Proposal.LinkedProposal`. Si un `SoftwareUpgradeProposal` vinculado a una recompensa abierta es aceptado por la administración, los fondos reservados se transfieren automáticamente al autor de la propuesta. +- **Complex delegation:** Los delegadores podrán elegir otros representantes además de sus validadores. En última instancia, la cadena de representantes siempre terminaría en un validador, pero los delegadores podrían heredar el voto de su representante elegido antes de heredar el voto de su validador. En otras palabras, sólo heredarían el voto de su validador si su otro representante designado no votara. +- **Mejor proceso de revisión de propuestas:** La propuesta consta de dos partes de `proposal.Deposit`, uno para la lucha contra el correo basura (igual que en el MVP) y otro para recompensar a los auditores de terceros. [origen](https://github.com/cosmos/cosmos-sdk/blob/master/x/gov/spec/05_future_improvements.md) @@ -176,6 +223,6 @@ El módulo `gov` contiene los siguientes parámetros: | threshold | string (dec) | "0.500000000000000000" | | veto | string (dec) | "0.334000000000000000" | -__Observación__: El módulo de gobierno contiene parámetros que son objetos que no son como los demás módulos. Si sólo se desea modificar un subconjunto de parámetros, sólo hay que incluirlos y no toda la estructura de objetos de parámetros. +**Observación**: El módulo de gobierno contiene parámetros que son objetos que no son como los demás módulos. Si sólo se desea modificar un subconjunto de parámetros, sólo hay que incluirlos y no toda la estructura de objetos de parámetros. diff --git a/docs/getting-started/installation.md b/docs/getting-started/installation.md index 1052edd462e..ac407ae7bc1 100644 --- a/docs/getting-started/installation.md +++ b/docs/getting-started/installation.md @@ -15,12 +15,12 @@ At present, the SDK fully supports installation on linux distributions. For the 2. [Install Go](#install-go) 3. [Install `Gaiad` binaries](#install-the-binaries) - ## Build Tools Install `make` and `gcc`. **Ubuntu:** + ```bash sudo apt-get update @@ -40,6 +40,7 @@ We suggest the following two ways to install Go. Check out the [official docs](h **Ubuntu:** At the time of this writing, the latest release is `1.18.2`. We're going to download the tarball, extract it to `/usr/local`, and export `GOROOT` to our `$PATH` + ```bash curl -OL https://golang.org/dl/go1.18.2.linux-amd64.tar.gz diff --git a/docs/getting-started/quickstart.md b/docs/getting-started/quickstart.md index 12a6ccc605e..08ff9852fbb 100644 --- a/docs/getting-started/quickstart.md +++ b/docs/getting-started/quickstart.md @@ -8,9 +8,11 @@ title: Quick Start - Join Mainnet **Bootstrap a `cosmoshub-4` mainnet node** ### Prerequisites + > **Note**: Make sure the [Gaia CLI is installed](./installation.md). ### Sync Options + To quickly get started, node operators can choose to sync via State Sync or by downloading a snapshot from Quicksync. State Sync works by replaying larger chunks of application state directly rather than replaying individual blocks or consensus rounds. Quicksync is a service provided courtesy of ChainLayer, and offers historical state of the chain available for download every 24 hours. For more advanced information on setting up a node, see the Sync Options section of the full [Joining Mainnet Tutorial](../hub-tutorials/join-mainnet.md) @@ -43,6 +45,7 @@ sed -i'' 's/rpc_servers = ""/rpc_servers = "https:\/\/rpc.cosmos.network:443,htt #Start Gaia gaiad start --x-crisis-skip-assert-invariants ``` + :::::: :::::: tab Quicksync @@ -50,6 +53,7 @@ gaiad start --x-crisis-skip-assert-invariants > **Note**: Make sure to set the `--home` flag when initializing and starting `gaiad` if mounting quicksync data externally. #### Create Gaia Home & Config + ```bash mkdir $HOME/.gaia/config -p ``` @@ -61,6 +65,7 @@ Node Operators can decide how much of historical state they want to preserve by :::: tabs :options="{ useUrlFragment: false }" ::: tab Default + ```bash= sudo apt-get install wget liblz4-tool aria2 jq -y @@ -72,9 +77,11 @@ cd $HOME/.gaia aria2c -x5 $URL ``` + ::: ::: tab Pruned + ```bash= sudo apt-get install wget liblz4-tool aria2 jq -y @@ -86,9 +93,11 @@ cd $HOME/.gaia aria2c -x5 $URL ``` + ::: ::: tab Archive + ```bash= sudo apt-get install wget liblz4-tool aria2 jq -y @@ -100,6 +109,7 @@ cd $HOME/.gaia aria2c -x5 $URL ``` + ::: :::: @@ -107,12 +117,14 @@ aria2c -x5 $URL **The download logs should look like the following** + ``` 01/11 07:48:17 [NOTICE] Downloading 1 item(s) [#7cca5a 484MiB/271GiB(0%) CN:5 DL:108MiB ETA:42m41s] ``` **Completed Download Process:** + ``` [#7cca5a 271GiB/271GiB(99%) CN:1 DL:77MiB] 01/11 08:32:19 [NOTICE] Download complete: /mnt/quicksync_01/cosmoshub-4-pruned.20220111.0310.tar.lz4 @@ -127,22 +139,24 @@ Status Legend: ``` #### Unzip + ```bash lz4 -c -d `basename $URL` | tar xf - ``` - #### Copy Address Book Quicksync + ```bash curl https://quicksync.io/addrbook.cosmos.json > $HOME/.gaia/config/addrbook.json ``` - #### Start Gaia + ```bash gaiad start --x-crisis-skip-assert-invariants ``` + :::::: ::::::: diff --git a/docs/getting-started/what-is-gaia.md b/docs/getting-started/what-is-gaia.md index bab16553805..750885e1fef 100644 --- a/docs/getting-started/what-is-gaia.md +++ b/docs/getting-started/what-is-gaia.md @@ -18,7 +18,7 @@ title: What is Gaia? - `x/distribution`: Fee distribution logic. - `x/slashing`: Slashing logic. - `x/gov`: Governance logic. -- `ibc-go/modules`: Inter-blockchain communication. Hosted in the `cosmos/ibc-go` repository. +- `ibc-go/modules`: Inter-blockchain communication. Hosted in the `cosmos/ibc-go` repository. - `x/params`: Handles app-level parameters. About the Cosmos Hub: The Cosmos Hub is the first Hub to be launched in the Cosmos Network. The role of a Hub is to facilitate transfers between blockchains. If a blockchain connects to a Hub via IBC, it automatically gains access to all the other blockchains that are connected to it. The Cosmos Hub is a public Proof-of-Stake chain. Its staking token is called the Atom. diff --git a/docs/governance/README.md b/docs/governance/README.md index 398ef25b898..02f6f20f3c6 100644 --- a/docs/governance/README.md +++ b/docs/governance/README.md @@ -27,9 +27,9 @@ ATOM stakers can find active on-chain proposals to vote on [here](https://www.mi - [On-Chain Process](./process.md) - [Best Practices for Drafting a Proposal](./best-practices.md) - Proposal Types: - - Text Proposal - - [Parameter Change Proposal](./params-change) - - [Community Spend Proposal](./community-pool-spend) + - Text Proposal + - [Parameter Change Proposal](./params-change) + - [Community Spend Proposal](./community-pool-spend) - [Submitting a Proposal](./submitting.md) - [List of Proposals](./proposals) @@ -45,4 +45,3 @@ community members, including: - [Reddit](http://reddit.com/r/cosmosnetwork) - [Telegram](https://t.me/atomgov) - anywhere else you might interact with members of the Cosmos community! - diff --git a/docs/governance/best-practices.md b/docs/governance/best-practices.md index 8119108a5ca..c306d2ebd71 100644 --- a/docs/governance/best-practices.md +++ b/docs/governance/best-practices.md @@ -2,19 +2,20 @@ order: 3 --- -# Best Practices for Drafting a Proposal +# Best Practices for Drafting a Proposal + +There are currently three types of proposals supported by the Cosmos Hub: -There are currently three types of proposals supported by the Cosmos Hub: - [**Community Pool Spend**](./community-pool-spend) - Proposal to spend funds from the community pool on an important project. - [**Parameter Change**](./params-change) - Proposal to change a core on-chain parameter. -- **Text** - Proposal to agree to a certain strategy, plan, commitment, - future upgrade or other statement. Text proposals are exclusively a - signalling mechanism and focal point for future coordination - +- **Text** - Proposal to agree to a certain strategy, plan, commitment, + future upgrade or other statement. Text proposals are exclusively a + signalling mechanism and focal point for future coordination - they do not directly cause any changes. You'll first want to determine which kind of proposal you are making. Be sure to -review all details of your specific proposal type. +review all details of your specific proposal type. ## Engage directly with the voting community and seek feedback @@ -23,9 +24,10 @@ Engagement is likely to be critical to the success of a proposal. The degree to There are many different ways to engage. One strategy involves a few stages of engagement before and after submitting a proposal on chain. **Why do it in stages?** It's a more conservative approach to save resources. The idea is to check in with key stakeholders at each stage before investing more resources into developing your proposal. In the first stage of this strategy, you should engage people (ideally experts) informally about your idea. You'll want to start with the minimal, critical components (name, value to cosmos hub, timeline, any funding needs) and check: -- Does it make sense? -- Are there critical flaws? -- Does it need to be reconsidered? + +- Does it make sense? +- Are there critical flaws? +- Does it need to be reconsidered? You should be able enagaging with key stakeholders (eg. a large validator operator) with a few short sentences to measure their support. Here's an example: @@ -41,7 +43,7 @@ If you're already confident about your idea, [skip to Stage 2](#stage-2-your-dra ### Not yet confident about your idea? -Great! Governance proposals potentially impact many stakeholders. Introduce your idea with known members of the community before investing resources into drafting a proposal. Don't let negative feedback dissuade you from exploring your idea if you think that it's still important. +Great! Governance proposals potentially impact many stakeholders. Introduce your idea with known members of the community before investing resources into drafting a proposal. Don't let negative feedback dissuade you from exploring your idea if you think that it's still important. If you know people who are very involved with the Cosmos Hub, send them a private message with a concise overview of what you think will result from your idea or proposed changes. Wait for them to ask questions before providing details. Do the same in semi-private channels where people tend to be respectful (and hopefully supportive). I recommend the private Cosmos Network VIP Telegram channel (ask for an invite [on the forum][forum] if you are or would like to be a Cosmos contributor). @@ -51,7 +53,7 @@ Great! However, remember that governance proposals potentially impact many stake ### Are you ready to draft a governance proposal? -There will likely be differences of opinion about the value of what you're proposing to do and the strategy by which you're planning to do it. If you've considered feedback from broad perspectives and think that what you're doing is valuable and that your strategy should work, and you believe that others feel this way as well, it's likely worth drafting a proposal. However, remember that the largest ATOM stakers have the biggest vote, so a vocal minority isn't necessarily representative or predictive of the outcome of an on-chain vote. +There will likely be differences of opinion about the value of what you're proposing to do and the strategy by which you're planning to do it. If you've considered feedback from broad perspectives and think that what you're doing is valuable and that your strategy should work, and you believe that others feel this way as well, it's likely worth drafting a proposal. However, remember that the largest ATOM stakers have the biggest vote, so a vocal minority isn't necessarily representative or predictive of the outcome of an on-chain vote. A conservative approach is to have some confidence that you roughly have initial support from a majority of the voting power before proceeding to drafting your proposal. However, there are likely other approaches, and if your idea is important enough, you may want to pursue it regardless of whether or not you are confident that the voting power will support it. @@ -59,12 +61,12 @@ A conservative approach is to have some confidence that you roughly have initial The next major section outlines and describes some potential elements of drafting a proposal. Ensure that you have considered your proposal and anticipated questions that the community will likely ask. Once your proposal is on-chain, you will not be able to change it. -### Proposal Elements +### Proposal Elements It will be important to balance two things: being detailed and being concise. You'll want to be concise so that people can assess your proposal quickly. You'll want to be detailed so that voters will have a clear, meaningful understanding of what the changes are and how they are likely to be impacted. There is a [proposal template](./proposals/proposal-template.md) with suggested sections. Each proposal should contain a summmary with key details: - + - who is submitting the proposal - the amount of the proposal or parameter(s) being changed; - and deliverables and timeline @@ -82,7 +84,6 @@ Assume that many people will stop reading at this point. However it is important 1. Risks & Benefits - clearly describe how making this/these change(s) may expose stakeholders to new benefits and/or risks 1. Supplementary materials - optional materials eg. models, graphs, tables, research, signed petition, etc - #### Community-Spend Proposal 1. Applicant(s) - the profile of the person(s)/entity making the proposal @@ -149,14 +150,14 @@ on Github is the ultimate standard for distributed collaboration on text files. 1. Post a draft of your proposal as a topic in the 'governance' category of the [Cosmos forum][forum]. Ideally this should contain a link to this repository, either directly to your proposal if it has been merged, or else to a pull-request containing your proposal if it has not been merged yet. 2. Directly engage key members of the community for feedback. These could be large contributors, those likely to be most impacted by the proposal, and entities with high stake-backing (eg. high-ranked validators; large stakers). 3. Engage with the Cosmos Governance Working Group (GWG). These are people focused on Cosmos governance--they won't write your proposal, but will provide feedback and recommend resources to support your work. Members can be contacted on the [forum][forum] (they use the tag 'GWG' in posts) and in [Telegram](https://t.me/hubgov). -4. Target members of the community in a semi-public way before bringing the draft to a full public audience. The burden of public scrutiny in a semi-anonymized environment (eg. Twitter) can be stressful and overwhelming without establishing support. Solicit opinions in places with people who have established reputations first. For example, there is a private Telegram group called Cosmos Network VIP (ask for an invite [on the forum][forum] if you are or would like to be a Cosmos contributor). +4. Target members of the community in a semi-public way before bringing the draft to a full public audience. The burden of public scrutiny in a semi-anonymized environment (eg. Twitter) can be stressful and overwhelming without establishing support. Solicit opinions in places with people who have established reputations first. For example, there is a private Telegram group called Cosmos Network VIP (ask for an invite [on the forum][forum] if you are or would like to be a Cosmos contributor). 5. Alert the entire community to the draft proposal via - Twitter, tagging accounts such as the All in Bits [Cosmos account](https://twitter.com/cosmos), the [Cosmos GWG](https://twitter.com/CosmosGov), and Today in Cosmos [@adriana_kalpa](https://twitter.com/adriana_kalpa) - [Telegram](https://t.me/cosmosproject), [Adriana](https://t.me/adriana_KalpaTech) (All in Bits) ### Submit your proposal to the testnet -I intend to expand this [guide to include testnet instructions](submitting.md#submitting-your-proposal-to-the-testnet). +I intend to expand this [guide to include testnet instructions](submitting.md#submitting-your-proposal-to-the-testnet). You may want to submit your proposal to the testnet chain before the mainnet for a number of reasons, such as wanting to see what the proposal description will look like, to share what the proposal will look like in advance with stakeholders, and to signal that your proposal is about to go live on the mainnet. @@ -176,11 +177,12 @@ The deposit period currently lasts 14 days. If you submitted your transaction wi This is a stage where proposals may begin to get broader attention. Most popular explorers currently display proposals that are in the deposit period, but due to proposal spamming, this may change. [Hubble](https://hubble.figment.io/cosmos/chains/cosmoshub-4/governance), for example, only displays proposals that have 10% or more of the minimum deposit, so 6.4 ATOM or more. -A large cross-section of the blockchain/cryptocurrency community exists on Twitter. Having your proposal in the deposit period is a good time to engage the so-called 'crypto Twitter' Cosmos community to prepare validators to vote (eg. tag [@cosmosvalidator](https://twitter.com/cosmosvalidator)) and ATOM-holders that are staking (eg. tag [@cosmos](https://twitter.com/cosmos), [@adriana_kalpa](https://twitter.com/adriana_kalpa)). +A large cross-section of the blockchain/cryptocurrency community exists on Twitter. Having your proposal in the deposit period is a good time to engage the so-called 'crypto Twitter' Cosmos community to prepare validators to vote (eg. tag [@cosmosvalidator](https://twitter.com/cosmosvalidator)) and ATOM-holders that are staking (eg. tag [@cosmos](https://twitter.com/cosmos), [@adriana_kalpa](https://twitter.com/adriana_kalpa)). ### The Voting Period At this point you'll want to track which validator has voted and which has not. You'll want to re-engage directly with top stake-holders, ie. the highest-ranking validator operators, to ensure that: + 1. they are aware of your proposal; 2. they can ask you any questions about your proposal; and 3. they are prepared to vote. diff --git a/docs/governance/community-pool-spend/README.md b/docs/governance/community-pool-spend/README.md index b365b06f0d9..52a72339073 100644 --- a/docs/governance/community-pool-spend/README.md +++ b/docs/governance/community-pool-spend/README.md @@ -28,6 +28,7 @@ Drafting and submitting a proposal is a process that takes time, attention, and If you are considering drafting a proposal, you should review the general background on drafting and submitting a proposal: + 1. [How the voting process and governance mechanism works](../process.md) 1. [How to draft your proposal and engage with the Cosmos community about it](../best-practices.md) 1. [How to format proposals](../formatting.md) @@ -48,6 +49,7 @@ Though the rate of funding is currently fixed at 2% of staking rewards, the effe The current 2% tax rate of funding may be modified with a governance proposal and enacted immediately after the proposal passes. Currently, funds cannot be sent to the Community Pool, but we should expect this to change with the next upgrade. Read more about this new functionality [here](https://github.com/cosmos/cosmos-sdk/pull/5249). What makes this functionality important? + 1. Funded projects that fail to deliver may return funding to Community Pool; 2. Entities may help fund the Community Pool by depositing funds directly to the account. @@ -68,6 +70,7 @@ Funds from the Cosmos Community Pool may be spent via successful governance prop We don't know 🤷 The prevailing assumption is that funds should be spent in a way that brings value to the Cosmos Hub. However, there is debate about how to keep the fund sustainable. There is also some debate about who should receive funding. For example, part of the community believes that the funds should only be used for those who need funding most. Other topics of concern include: + - retroactive grants - price negotiation - fund disbursal (eg. payments in stages; payments pegged to reduce volitiliy) diff --git a/docs/governance/formatting.md b/docs/governance/formatting.md index 0c52d6e342b..15037f7f9b8 100644 --- a/docs/governance/formatting.md +++ b/docs/governance/formatting.md @@ -88,7 +88,6 @@ You use can also use [Hubble](https://hubble.figment.io/cosmos/chains/cosmoshub- ## Params Change - **Note:** Changes to the [`gov` module](https://docs.cosmos.network/main/modules/gov) are different from the other kinds of parameter changes because `gov` has subkeys, [as discussed here](https://github.com/cosmos/cosmos-sdk/issues/5800). Only the `key` part of the JSON file is different for `gov` parameter-change proposals. For parameter-change proposals, there are seven (7) components: @@ -132,10 +131,8 @@ The deposit `denom` is `uatom` and `amount` is `100000`. Since 1,000,000 micro-A ### Mainnet Example - To date, the Cosmos Hub's parameters have not been changed by a parameter-change governance proposal. This is a hypothetical example of the JSON file that would be used with a command line transaction to create a new proposal. This is an example of a proposal that changes two parameters, and both parameters are from the [`slashing` module](https://docs.cosmos.network/main/modules/slashing). A single parameter-change governance proposal can reportedly change any number of parameters. - ```json { "title": "Parameter changes for validator downtime", diff --git a/docs/governance/params-change/Auth.md b/docs/governance/params-change/Auth.md index 7268c642c17..262cb9297a4 100644 --- a/docs/governance/params-change/Auth.md +++ b/docs/governance/params-change/Auth.md @@ -18,6 +18,7 @@ The `auth` module is responsible for specifying the base transaction and account ## Governance notes on parameters ### `MaxMemoCharacters` + **The character limit for each transaction memo.** There is an option to include a "memo," or additional information (data) to Cosmos Hub transactions, whether sending funds, delegating, voting, or other transaction types. This parameter limits the number of characters that may be included in the memo line of each transaction. @@ -27,12 +28,15 @@ There is an option to include a "memo," or additional information (data) to Cosm * `cosmoshub-3` genesis: `512` #### Decreasing the value of `MaxMemoCharacters` + Decreasing the value of `MaxMemoCharacters` will decrease the character limit for each transaction memo. This may break the functionality of applications that rely upon the data in the memo field. For example, an exchange may use a common deposit address for all of its users, and then individualize account deposits using the memo field. If the memo field suddenly decreased, the exchange may no longer automatically sort its users' transactions. #### Increasing the value of `MaxMemoCharacters` + Increasing the value of `MaxMemoCharacters` will increase the character limit for each transaction memo. This may enable new functionality for applications that use transaction memos. It may also enable an increase in the amount of data in each block, leading to an increased storage need for the blockchain and [state bloat](https://thecontrol.co/state-growth-a-look-at-the-problem-and-its-solutions-6de9d7634b0b). ### `TxSigLimit` + **The max number of signatures per transaction** Users and applications may create multisignature (aka multisig) accounts. These accounts require more than one signature to generate a transaction. This parameter limits the number of signatures in a transaction. @@ -42,12 +46,15 @@ Users and applications may create multisignature (aka multisig) accounts. These * `cosmoshub-3` genesis: `7` #### Decreasing the value of `TxSigLimit` + Decreasing the value of `TxSigLimit` will decrease the maximum number of signatures possible. This may constrain stakeholders that want to use as many as seven signatures to authorize a transaction. It will also break the functionality of entities or applications dependent upon up to seven transactions, meaning that those transactions will no longer be able to be authorized. In this case, funds and functions controlled by a multisignature address will no longer be accessible, and funds may become stranded. #### Increasing the value of `TxSigLimit` + Increasing the value of `TxSigLimit` will increase the maximum number of signatures possible. As this value increases, the network becomes more likely to be susceptible to attacks that slow block production, due to the burden of computational cost when verifying more signatures (since signature verification is costlier than other operations). ### `TxSizeCostPerByte` + **Sets the cost of transactions, in units of gas.** `TxSizeCostPerByte` is used to compute the gas-unit consumption for each transaction. @@ -57,12 +64,15 @@ Increasing the value of `TxSigLimit` will increase the maximum number of signatu * `cosmoshub-3` genesis: `10` #### Decreasing the value of `TxSizeCostPerByte` + Decreasing the value of `TxSizeCostPerByte` will reduce the number of gas units used per transaction. This may also reduce the fees that validators earn for processing transactions. There may be other effects that have not been detailed here. #### Increasing the value of `TxSizeCostPerByte` + Increasing the value of `TxSizeCostPerByte` will raise the number of gas units used per transaction. This may also increase the fees that validators earn for processing transactions. There may be other effects that have not been detailed here. ### `SigVerifyCostED25519` + **The cost for verifying ED25519 signatures, in units of gas.** Ed25519 is the EdDSA cryptographic signature scheme (using SHA-512 (SHA-2) and Curve25519) that is used by Cosmos Hub validators. `SigVerifyCostED25519` is the gas (ie. computational) cost for verifying ED25519 signatures, and ED25519-based transactions are not currently accepted by the Cosmos Hub. @@ -72,15 +82,19 @@ Ed25519 is the EdDSA cryptographic signature scheme (using SHA-512 (SHA-2) and C * `cosmoshub-3` genesis: `590` #### Decreasing the value of `SigVerifyCostED25519` + Decreasing the value of `SigVerifyCostED25519` will decrease the amount of gas that is consumed by transactions that require Ed25519 signature verifications. Since Ed25519-signed transactions are not currently accepted by Cosmos Hub, changing this parameter is unlikely to affect stakeholders at this time. #### Increasing the value of `SigVerifyCostED25519` + Increasing the value of `SigVerifyCostED25519` will increase the amount of gas that is consumed by transactions that require Ed25519 signature verifications. Since Ed25519 signature transactions are not currently accepted by Cosmos Hub, changing this parameter is unlikely to affect stakeholders at this time. #### Notes + Ed25519 signatures are not currently being accepted by the Cosmos Hub. Ed25519 signatures will be verified and can be considered valid, so the gas to verify them will be consumed. However, the transaction itself will be rejected. It could be that these signatures will be used for transactions a later time, such as after inter-blockchain communication (IBC) evidence upgrades happen. ### `SigVerifyCostSecp256k1` + **The cost for verifying Secp256k1 signatures, in units of gas.** Secp256k1 is an elliptic curve domain parameter for cryptographic signatures used by user accounts in the Cosmos Hub. `SigVerifyCostSecp256k1` is the gas (ie. computational) cost for verifying Secp256k1 signatures. Practically all Cosmos Hub transactions require Secp256k1 signature verifications. @@ -90,11 +104,13 @@ Secp256k1 is an elliptic curve domain parameter for cryptographic signatures use * `cosmoshub-3` default: `1000` #### Decreasing the value of `SigVerifyCostSecp256k1` + Decreasing the value of `SigVerifyCostSecp256k1` will decrease the amount of gas that is consumed by practically all Cosmos Hub transactions, which require Secp256k1 signature verifications. Decreasing this parameter may have unintended effects on how the Cosmos Hub operates, since the computational cost of verifying a transaction may be greater than what the system's assumption is. #### Increasing the value of `SigVerifyCostSecp256k1` -Increasing the value of `SigVerifyCostSecp256k1` will increase the amount of gas that is consumed by practically all Cosmos Hub transactions, which require Secp256k1 signature verifications. Increasing this parameter may have unintended effects on how the Cosmos Hub operates, since the computational cost of verifying a transaction may be less than what the system's assumption is. +Increasing the value of `SigVerifyCostSecp256k1` will increase the amount of gas that is consumed by practically all Cosmos Hub transactions, which require Secp256k1 signature verifications. Increasing this parameter may have unintended effects on how the Cosmos Hub operates, since the computational cost of verifying a transaction may be less than what the system's assumption is. #### Notes -There should be a better understanding of what the potential implications are for changing `SigVerifyCostSecp256k1`. For example, gas calculations are important because blocks have a gas limit. Transactions could be rejected for exceeding the block gas limit, breaking application functionality or perhaps preventing addresses controlled by multiple signatures from moving funds. \ No newline at end of file + +There should be a better understanding of what the potential implications are for changing `SigVerifyCostSecp256k1`. For example, gas calculations are important because blocks have a gas limit. Transactions could be rejected for exceeding the block gas limit, breaking application functionality or perhaps preventing addresses controlled by multiple signatures from moving funds. diff --git a/docs/governance/params-change/Bank.md b/docs/governance/params-change/Bank.md index a95149da112..03819c9ea6f 100644 --- a/docs/governance/params-change/Bank.md +++ b/docs/governance/params-change/Bank.md @@ -14,7 +14,9 @@ The `bank` module is responsible for token transfer functionalities. It has the ## Governance notes on parameters + ### `SendEnabled` + **Token transfer functionality.** The Cosmos Hub (cosmoshub-1) launched without transfer functionality enabled. Users were able to stake and earn rewards, but were unable to transfer ATOMs between accounts until the cosmoshub-2 chain launched. Transfer functionality may be disabled and enabled via governance proposal. @@ -25,11 +27,13 @@ The Cosmos Hub (cosmoshub-1) launched without transfer functionality enabled. Us * `cosmoshub-3` default: `true` #### Enabling `sendenabled` + Setting the `sendenabled` parameter to `true` will enable ATOMs to be transferred between accounts. This capability was first enabled when the cosmoshub-2 chain launched. #### Disabling `sendenabled` -Setting the `sendenabled` parameter to `false` will prevent ATOMs from being transferred between accounts. ATOMs may still be staked and earn rewards. This is how the cosmoshub-1 chain launched. +Setting the `sendenabled` parameter to `false` will prevent ATOMs from being transferred between accounts. ATOMs may still be staked and earn rewards. This is how the cosmoshub-1 chain launched. #### Notes + The cosmoshub-1 chain launched with `sendenabled` set to `false` and with [`withdrawaddrenabled`](./Distribution.md#4-withdrawaddrenabled) set to `false`. Staking was enabled on cosmoshub-1, so setting `withdrawaddrenabled` to false was necessary to prevent a loophole that would enable ATOM transfer via diverting staking rewards to a designated address. diff --git a/docs/governance/params-change/Crisis.md b/docs/governance/params-change/Crisis.md index 8dd1ee75be1..ae8fdf84ff1 100644 --- a/docs/governance/params-change/Crisis.md +++ b/docs/governance/params-change/Crisis.md @@ -18,6 +18,7 @@ The `crisis` module is responsible for halting the blockchain under the circumst ## Governance notes on parameters ### `ConstantFee` + **The amount required to send a message to halt the Cosmos Hub chain if an invariant is broken, in micro-ATOM.** A Cosmos account (address) can send a transaction message that will halt the Cosmos Hub chain if an invariant is broken. An example of this would be if all of the account balances in total did not equal the total supply. This kind of transaction could consume excessive amounts of gas to compute, beyond the maximum allowable block gas limit. `ConstantFee` makes it possible to bypass the gas limit in order to process this transaction, while setting a cost to disincentivize using the function to attack the network. The cost of the transaction is `1333000000` `uatom` (1,333 ATOM) and will effectively not be paid if the chain halts due to a broken invariant (which similar to being refunded). If the invariant is not broken, then `ConstantFee` will be paid. All in Bits has published more information about the [crisis module here](https://docs.cosmos.network/main/modules/crisis). @@ -27,10 +28,13 @@ A Cosmos account (address) can send a transaction message that will halt the Cos * `cosmoshub-3` default: `1333000000` `uatom` #### Decreasing the value of `ConstantFee` + Decreasing the value of the `ConstantFee` parameter will reduce the cost of checking an invariant. This will likely make it easier to halt the chain if an invariant is actually broken, but it will lower the cost for an attacker to use this function to slow block production. #### Increasing the value of `ConstantFee` + Increasing the value of the `ConstantFee` parameter will increase the cost of checking an invariant. This will likely make it more difficult to halt the chain if an invariant is actually broken, but it will increase the cost for an attacker to use this function to slow block production. #### Notes + Only registered invariants may be checked with this transaction message. Validators are reportedly performant enough to handle large computations like invariant checks, and the likely outcome of multiple invariant checks would be longer block times. In the code, there is a comment that indicates that the designers were targeting $5000 USD as the required amount of ATOMs to run an invariant check. diff --git a/docs/governance/params-change/Distribution.md b/docs/governance/params-change/Distribution.md index 3b0bb4e1ee4..9759697ef10 100644 --- a/docs/governance/params-change/Distribution.md +++ b/docs/governance/params-change/Distribution.md @@ -15,11 +15,12 @@ The `distribution` module is responsible for distributing staking rewards betwee The `distribution` module enables a simple distribution mechanism that passively distributes rewards between validators and delegators. Collected rewards are pooled globally and divided out passively to validators and delegators. Each validator has the opportunity to charge commission to the delegators on the rewards collected on behalf of the delegators. Fees are collected directly into a global reward pool and validator proposer-reward pool. -**There is [a known bug](#known-bug) associated with this module.** +**There is [a known bug](#known-bug) associated with this module.** ## Governance notes on parameters ### `communitytax` + **The proportion of staking rewards diverted to the community pool.** Staking on the Cosmos Hub entitles participants to inflationary (aka "block") rewards and transaction fees. A portion of these staking rewards is diverted to the community pool, which can be spent with a successful community-spend governance proposal. `communitytax` is the parameter that determines the proportion of staking rewards diverted to the community pool, which is currently `0.020000000000000000` (2%) of all staking rewards. @@ -29,12 +30,15 @@ Staking on the Cosmos Hub entitles participants to inflationary (aka "block") re * `cosmoshub-3` default: `0.020000000000000000` #### Decreasing the value of `communitytax` + Decreasing the value of the `communitytax` parameter will decrease the rate that the community pool is funded and will increase the staking rewards captured by staking participants. This will make it more likely for the community pool to be exhausted and could potentially increase the motivation for participants to stake. #### Increasing the value of `communitytax` + Increasing the value of the `communitytax` parameter will increase the rate that the community pool is funded and will decrease the staking rewards captured by staking participants. This will make it more less for the community pool to be exhausted and could potentially decrease the motivation for participants to stake. ### `baseproposerreward` + **The fixed base reward bonus for the validator proposing a block, as a proportion of transaction fees.** All validators in the active set share the rewards for producing a block equally, except for the proposer of a valid block: that validator receives a bonus of `0.010000000000000000` (1%) more in transaction fees. The proposer must include a minimum of 2/3 of precommit signatures from the other validators in the active set in order for the block to be valid and to receive the `baseproposerreward` bonus. All in Bits has published more in-depth information [here](../../validators/validator-faq.md#how-are-fees-distributed). @@ -44,15 +48,19 @@ All validators in the active set share the rewards for producing a block equally * `cosmoshub-3` default: `0.010000000000000000` #### Decreasing the value of `baseproposerreward` + Decreasing the value of the `baseproposerreward` parameter will decrease the advantage that the proposer has over other validators. This may decrease an operator's motivation to ensure that its validator is reliably online and includes at least 2/3 precommit signatures of the other validators in its proposed block. #### Increasing the value of `baseproposerreward` + Increasing the value of the `baseproposerreward` parameter will increase the advantage that the proposer has over other validators. This may increase an operator's motivation to ensure that its validator is reliably online and includes at least 2/3 precommit signatures of the other validators in its proposed block. #### Notes + The Cosmos Hub transaction fee volume is proportionally very low in value compared to the inflationary block rewards, and until that changes, this parameter will likely have very little impact on validator behaviours. As fee volumes increase, the `baseproposerreward` bonus may incentivize delegations to the validator(s) with the greatest stake-backing. There are some detailed discussions about the proposer bonus [here](https://github.com/cosmos/cosmos-sdk/issues/3529). -### `bonusproposerreward` +### `bonusproposerreward` + **The maximum additional reward bonus for the validator proposing a block, as a proportion of transaction fees.** All validators in the active set share the rewards for producing a block equally, except for the proposer of a valid block. If that validator includes more than a minimum of 2/3 of precommit signatures from the other validators in the active set, they are eligible to receive the `bonusproposerreward` of up to 4% (`0.040000000000000000`), beyond the 1% `baseproposerreward`. The bonus proposer reward amount that a validator receives depends upon how many precommit signatures are included in the proposed block (additional to the requisite 2/3). All in Bits has published more in-depth information [here](../../validators/validator-faq.md#how-are-fees-distributed). @@ -62,15 +70,19 @@ All validators in the active set share the rewards for producing a block equally * `cosmoshub-3` default: `0.040000000000000000` #### Decreasing the value of `bonusproposerreward` + Decreasing the value of the `bonusproposerreward` parameter will decrease the advantage that the proposer has over other validators. This may decrease an operator's motivation to ensure that its validator is reliably online and includes more than 2/3 precommit signatures from the other validators in its proposed block. #### Increasing the value of `bonusproposerreward` -Increasing the value of the `bonusproposerreward` parameter will increase the advantage that the proposer has over other validators. This may increase an operator's motivation to ensure that its validator is reliably online and includes more than 2/3 precommit signatures from the other validators in its proposed block. + +Increasing the value of the `bonusproposerreward` parameter will increase the advantage that the proposer has over other validators. This may increase an operator's motivation to ensure that its validator is reliably online and includes more than 2/3 precommit signatures from the other validators in its proposed block. #### Notes + The Cosmos Hub transaction fee volume is proportionally very low in value compared to the inflationary block rewards, and until that changes, this parameter will likely have very little impact on validator behaviours. As fee volumes increase, the `bonusproposerreward` bonus may incentivize delegations to the validator(s) with the greatest stake-backing. There are some detailed discussions about the proposer bonus [here](https://github.com/cosmos/cosmos-sdk/issues/3529). #### Example + **Note** that "reserve pool" refers to the community pool. In this example from the [All in Bits website](../../validators/validator-faq.md#how-are-fees-distributed), there are 10 validators with equal stake. Each of them applies a 1% commission rate and has 20% of self-delegated Atoms. Now comes a successful block that collects a total of 1025.51020408 Atoms in fees. First, a 2% tax is applied. The corresponding Atoms go to the reserve pool (aka community pool). Reserve pool's funds can be allocated through governance to fund bounties and upgrades. @@ -86,7 +98,7 @@ For the proposer validator: The pool obtains R + R * 5%: 105 Atoms -Commission: 105 * 80% * 1% = 0.84 Atoms +Commission: 105 *80%* 1% = 0.84 Atoms Validator's reward: 105 * 20% + Commission = 21.84 Atoms @@ -96,13 +108,14 @@ For each non-proposer validator: The pool obtains R: 100 Atoms -Commission: 100 * 80% * 1% = 0.8 Atoms +Commission: 100 *80%* 1% = 0.8 Atoms Validator's reward: 100 * 20% + Commission = 20.8 Atoms Delegators' rewards: 100 * 80% - Commission = 79.2 Atoms (each delegator will be able to claim their portion of these rewards in proportion to their stake) ### `withdrawaddrenabled` + **Determines whether or not delegators may set a separate address for receiving staking rewards.** Delegators can designate a separate withdrawal address (account) that receives staking rewards when `withdrawaddrenabled` is set to `true`. When `withdrawaddrenabled` is set to `false`, the delegator can no longer designate a separate address for withdrawals. @@ -112,13 +125,17 @@ Delegators can designate a separate withdrawal address (account) that receives s * `cosmoshub-3` default: `true` #### Changing the `withdrawaddrenabled` parameter + Changing the `withdrawaddrenabled` to false will prevent delegators from changing or setting a separate withdrawal address (account) that receives the staking rewards. This may disrupt the functionality of applications and the expectations of staking participants. #### Notes + This parameter was set to `false` before transfers were enabled in order to prevent stakers from diverting their rewards to other addresses ie. to avoid a loophole that would enable ATOM transfer via diverting staking rewards to a designated address. This parameter likely is only useful if [`sendenabled`](./Bank.md#1-sendenabled) is set to `false`. ## Known Bug + There is a known bug associated with this module that has reportedly caused a chain to halt. In [this reported case](https://github.com/cosmos/cosmos-sdk/issues/5808), the chain's parameter values were changed to be: + ``` community_tax: "0.020000000000000000" base_proposer_reward: "0.999000000000000000" diff --git a/docs/governance/params-change/Governance.md b/docs/governance/params-change/Governance.md index 7585d5ab8e0..0c29e0bd012 100644 --- a/docs/governance/params-change/Governance.md +++ b/docs/governance/params-change/Governance.md @@ -1,4 +1,5 @@ # `gov` subspace + The `gov` module is responsible for on-chain governance proposals and voting functionality. @@ -24,115 +25,142 @@ The `gov` module is responsible for the on-chain governance system. In this syst ### `depositparams` #### `min_deposit` + **The minimum deposit required for a proposal to enter the [voting period](#votingperiod), in micro-ATOMs.** -* on-chain value: `{{ $themeConfig.currentParameters.gov.depositparams.min_deposit }}` -* [Proposal 47](https://www.mintscan.io/cosmos/proposals/47) change: `64000000` `uatom` -* `cosmoshub-4` default: `512000000` `uatom` -* `cosmoshub-3` default: `512000000` `uatom` +- on-chain value: `{{ $themeConfig.currentParameters.gov.depositparams.min_deposit }}` +- [Proposal 47](https://www.mintscan.io/cosmos/proposals/47) change: `64000000` `uatom` +- `cosmoshub-4` default: `512000000` `uatom` +- `cosmoshub-3` default: `512000000` `uatom` Prior to a governance proposal entering the [voting period](#votingperiod) (ie. for the proposal to be voted upon), there must be at least a minimum number of ATOMs deposited. Anyone may contribute to this deposit. Deposits of passed and failed proposals are returned to the contributors. Deposits are burned when proposals 1) [expire](#maxdepositperiod), 2) fail to reach [quorum](#quorum), or 3) are [vetoed](#veto). This parameter subkey value represents the minimum deposit required for a proposal to enter the [voting period](#votingperiod) in micro-ATOMs, where `512000000uatom` is equivalent to 512 ATOM. ##### Decreasing the value of `mindeposit` + Decreasing the value of the `mindeposit` subkey will enable governance proposals to enter the [voting period](#votingperiod) with fewer ATOMs at risk. This will likely increase the volume of new governance proposals. ##### Increasing the value of `mindeposit` + Increasing the value of the `mindeposit` subkey will require risking a greater number of ATOMs before governance proposals may enter the [voting period](#votingperiod). This will likely decrease the volume of new governance proposals. #### `max_deposit_period` + **The maximum amount of time that a proposal can accept deposit contributions before expiring, in nanoseconds.** -* on-chain value: `{{ $themeConfig.currentParameters.gov.depositparams.max_deposit_period}}` -* `cosmoshub-4` default: `1209600000000000` -* `cosmoshub-3` default: `1209600000000000` +- on-chain value: `{{ $themeConfig.currentParameters.gov.depositparams.max_deposit_period}}` +- `cosmoshub-4` default: `1209600000000000` +- `cosmoshub-3` default: `1209600000000000` Prior to a governance proposal entering the [voting period](#votingperiod), there must be at least a minimum number of ATOMs deposited. This parameter subkey value represents the maximum amount of time that the proposal has to reach the minimum deposit amount before expiring. The maximum amount of time that a proposal can accept deposit contributions before expiring is currently `1209600000000000` nanoseconds or 14 days. If the proposal expires, any deposit amounts will be burned. ##### Decreasing the value of `maxdepositperiod` + Decreasing the value of the `maxdepositperiod` subkey will decrease the time for deposit contributions to governance proposals. This will likely decrease the time that some proposals remain visible and potentially decrease the likelihood that they will enter the [voting period](#votingperiod). This may increase the likelihood that proposals will expire and have their deposits burned. ##### Increasing the value of `maxdepositperiod` + Increasing the value of the `maxdepositperiod` subkey will extend the time for deposit contributions to governance proposals. This will likely increase the time that some proposals remain visible and potentially increase the likelihood that they will enter the [voting period](#votingperiod). This may decrease the likelihood that proposals will expire and have their deposits burned. ##### Notes + Currently most network explorers (eg. Hubble, Big Dipper, Mintscan) give the same visibility to proposals in the deposit period as those in the [voting period](#votingperiod). This means that a proposal with a small deposit (eg. 0.001 ATOM) will have the same visibility as those with a full 512 ATOM deposit in the voting period. ### `votingparams` + #### `votingperiod` + **The maximum amount of time that a proposal can accept votes before the voting period concludes, in nanoseconds.** -* on-chain value: `{{ $themeConfig.currentParameters.gov.votingparams.voting_period}}` -* `cosmoshub-4` default: `1209600000000000` -* `cosmoshub-3` default: `1209600000000000` +- on-chain value: `{{ $themeConfig.currentParameters.gov.votingparams.voting_period}}` +- `cosmoshub-4` default: `1209600000000000` +- `cosmoshub-3` default: `1209600000000000` Once a governance proposal enters the voting period, there is a maximum period of time that may elapse before the voting period concludes. This parameter subkey value represents the maximum amount of time that the proposal has to accept votes, which is currently `1209600000000000` nanoseconds or 14 days. If the proposal vote does not reach quorum ((ie. 40% of the network's voting power is participating) before this time, any deposit amounts will be burned and the proposal's outcome will not be considered to be valid. Voters may change their vote any number of times before the voting period ends. This voting period is currently the same for any kind of governance proposal. ##### Decreasing the value of `votingperiod` + Decreasing the value of the `votingperiod` subkey will decrease the time for voting on governance proposals. This will likely: + 1. decrease the proportion of the network that participates in voting, and -2. decrease the likelihood that quorum will be reached. +2. decrease the likelihood that quorum will be reached. ##### Increasing the value of `votingperiod` + Increasing the value of the `votingperiod` subkey will increase the time for voting on governance proposals. This may: + 1. increase the proportion of the network that participates in voting, and -2. increase the likelihood that quorum will be reached. +2. increase the likelihood that quorum will be reached. ##### Notes + Historically, off-chain discussions and engagement appears to be have been greater occurred during the voting period of a governance proposal than when the proposal is posted off-chain as a draft. A non-trivial amount of the voting power has voted in the second week of the voting period. Proposals 23, 19, and 13 each had approximately 80% network participation or more. ### `tallyparams` + #### `quorum` + **The minimum proportion of network voting power required for a governance proposal's outcome to be considered valid.** -* on-chain value: `{{ $themeConfig.currentParameters.gov.tallyparams.quorum}}` -* `cosmoshub-4` default: `0.400000000000000000` -* `cosmoshub-3` default: `0.400000000000000000` +- on-chain value: `{{ $themeConfig.currentParameters.gov.tallyparams.quorum}}` +- `cosmoshub-4` default: `0.400000000000000000` +- `cosmoshub-3` default: `0.400000000000000000` Quorum is required for the outcome of a governance proposal vote to be considered valid and for deposit contributors to recover their deposit amounts, and this parameter subkey value represents the minimum value for quorum. Voting power, whether backing a vote of 'yes', 'abstain', 'no', or 'no-with-veto', counts toward quorum. If the proposal vote does not reach quorum (ie. 40% of the network's voting power is participating) before this time, any deposit amounts will be burned and the proposal outcome will not be considered to be valid. ##### Decreasing the value of `quorum` -Decreasing the value of the `quorum` subkey will enable a smaller proportion of the network to legitimize the outcome of a proposal. This increases the risk that a decision will be made with a smaller proportion of ATOM-stakers' positions being represented, while decreasing the risk that a proposal will be considered invalid. This will likely decrease the risk of a proposal's deposit being burned. + +Decreasing the value of the `quorum` subkey will enable a smaller proportion of the network to legitimize the outcome of a proposal. This increases the risk that a decision will be made with a smaller proportion of ATOM-stakers' positions being represented, while decreasing the risk that a proposal will be considered invalid. This will likely decrease the risk of a proposal's deposit being burned. ##### Increasing the value of `quorum` + Increasing the value of the `quorum` subkey will require a larger proportion of the network to legitimize the outcome of a proposal. This decreases the risk that a decision will be made with a smaller proportion of ATOM-stakers' positions being represented, while increasing the risk that a proposal will be considered invalid. This will likely increase the risk of a proposal's deposit being burned. #### `threshold` + **The minimum proportion of participating voting power required for a governance proposal to pass.** -* on-chain value: `{{ $themeConfig.currentParameters.gov.tallyparams.threshold}}` -* `cosmoshub-4` default: `0.500000000000000000` -* `cosmoshub-3` default: `0.500000000000000000` +- on-chain value: `{{ $themeConfig.currentParameters.gov.tallyparams.threshold}}` +- `cosmoshub-4` default: `0.500000000000000000` +- `cosmoshub-3` default: `0.500000000000000000` A simple majority 'yes' vote (ie. 50% of participating voting power) is required for a governance proposal vote to pass. Though necessary, a simple majority 'yes' vote may not be sufficient to pass a proposal in two scenarios: + 1. Failure to reach [quorum](#quorum) of 40% network power or 2. A 'no-with-veto' vote of 33.4% of participating voting power or greater. If a governance proposal passes, deposit amounts are returned to contributors. If a text-based proposal passes, nothing is enacted automatically, but there is a social expectation that participants will co-ordinate to enact the commitments signalled in the proposal. If a parameter change proposal passes, the protocol parameter will automatically change immediately after the [voting period](#votingperiod) ends, and without the need to run new software. If a community-spend proposal passes, the Community Pool balance will decrease by the number of ATOMs indicated in the proposal and the recipient's address will increase by this same number of ATOMs immediately after the voting period ends. ##### Decreasing the value of `threshold` + Decreasing the value of the `threshold` subkey will decrease the proportion of voting power required to pass a proposal. This may: + 1. increase the likelihood that a proposal will pass, and 2. increase the likelihood that a minority group will effect changes to the network. ##### Increasing the value of `threshold` + Increasing the value of the `threshold` subkey will increase the proportion of voting power required to pass a proposal. This may: + 1. decrease the likelihood that a proposal will pass, and 2. decrease the likelihood that a minority group will effect changes to the network. #### `veto_threshold` + **The minimum proportion of participating voting power to veto (ie. fail) a governance proposal.** -* on-chain value: `{{ $themeConfig.currentParameters.gov.tallyparams.veto_threshold}}` -* `cosmoshub-4` default: `0.334000000000000000` -* `cosmoshub-3` default: `0.334000000000000000` +- on-chain value: `{{ $themeConfig.currentParameters.gov.tallyparams.veto_threshold}}` +- `cosmoshub-4` default: `0.334000000000000000` +- `cosmoshub-3` default: `0.334000000000000000` Though a simple majority 'yes' vote (ie. 50% of participating voting power) is required for a governance proposal vote to pass, a 'no-with-veto' vote of 33.4% of participating voting power or greater can override this outcome and cause the proposal to fail. This enables a minority group representing greater than 1/3 of voting power to fail a proposal that would otherwise pass. ##### Decreasing the value of `veto_threshold` + Decreasing the value of the `veto_threshold` subkey will decrease the proportion of participating voting power required to veto. This will likely: -1. enable a smaller minority group to prevent proposals from passing, and -2. decrease the likelihood that contentious proposals will pass. +1. enable a smaller minority group to prevent proposals from passing, and +2. decrease the likelihood that contentious proposals will pass. ##### Increasing the value of `veto_threshold` -Increasing the value of the `veto_threshold` subkey will increase the proportion of participating voting power required to veto. This will require a larger minority group to prevent proposals from passing, and will likely increase the likelihood that contentious proposals will pass. \ No newline at end of file + +Increasing the value of the `veto_threshold` subkey will increase the proportion of participating voting power required to veto. This will require a larger minority group to prevent proposals from passing, and will likely increase the likelihood that contentious proposals will pass. diff --git a/docs/governance/params-change/Mint.md b/docs/governance/params-change/Mint.md index af1273c6f88..154b268b3e4 100644 --- a/docs/governance/params-change/Mint.md +++ b/docs/governance/params-change/Mint.md @@ -26,42 +26,51 @@ It can be broken down in the following way: ## Governance notes on parameters ### `MintDenom` + **Type of asset/coin that the Cosmos Hub mints.** -* on-chain value `{{ $themeConfig.currentParameters.mint.MintDenom }}` -* `cosmoshub-4` default: `uatom` -* `cosmoshub-3` default: `uatom` +- on-chain value `{{ $themeConfig.currentParameters.mint.MintDenom }}` +- `cosmoshub-4` default: `uatom` +- `cosmoshub-3` default: `uatom` This is the type of asset (aka coin) that is being minted. The Cosmos Hub produces `uatom`, or micro-ATOM, where 1,000,000 uatom is equivalent to 1 ATOM. #### Changing the `MintDenom` parameter + Changing the `MintDenom` will change the asset that the Cosmos Hub mints from the ATOM. This is likely to disrupt the functionality of applications and the expectations of staking participants. ### `InflationRateChange` + **A factor of and limit to the speed at which the Cosmos Hub's inflation rate changes.** -* on-chain value: `{{ $themeConfig.currentParameters.mint.InflationRateChange }}` -* [Proposal 48](https://www.mintscan.io/cosmos/proposals/48) change to `1.000000000000000000` -* `cosmoshub-4` default: `0.130000000000000000` -* `cosmoshub-3` default: `0.130000000000000000` +- on-chain value: `{{ $themeConfig.currentParameters.mint.InflationRateChange }}` +- [Proposal 48](https://www.mintscan.io/cosmos/proposals/48) change to `1.000000000000000000` +- `cosmoshub-4` default: `0.130000000000000000` +- `cosmoshub-3` default: `0.130000000000000000` Cosmos Hub's inflation rate can change faster or slower, depending on staking participation, and is limited to a minimum of 7% and maximum of 20%. The inflation rate cannot increase or decrease faster than 13% per year (`InflationRateChange`). The speed that the inflation rate changes depends upon two things: + 1. how far away the *current staking participation ratio* is from [`GoalBonded`](#5-GoalBonded) (67%) 2. the value of `InflationRateChange`, which is `{{ $themeConfig.currentParameters.mint.InflationRateChange }}` + ``` inflationRateChangePerYear = (1 - bondedRatio/params.GoalBonded) * params.InflationRateChange ``` + [The source for this information can be found here](https://github.com/cosmos/cosmos-sdk/tree/main/x/mint#begin-block). -The inflation rate increases when under 67% of the token supply is staking, and it will take less time to reach the maximum of rate of 20% inflation if (for example) 30% of the token supply is staking than if 50% is staking. +The inflation rate increases when under 67% of the token supply is staking, and it will take less time to reach the maximum of rate of 20% inflation if (for example) 30% of the token supply is staking than if 50% is staking. #### Decreasing the value of `InflationRateChange` + Decreasing the value of the `InflationRateChange` parameter will decrease both how fast the inflation rate changes and also the maximum speed that it can potentially change. It will then take longer for inflation to reach [`InflationMin`](#InflationMin) or [`InflationMax`](#InflationMax). This may lessen the response of staking behaviour to the incentive mechanism [described in the notes below](#notes). #### Increasing the value of `InflationRateChange` + Increasing the value of the `InflationRateChange` parameter will increase both how fast the inflation rate changes and also the maximum speed that it can potentially change. It will then take less time for inflation to reach [`InflationMin`](#InflationMin) or [`InflationMax`](#InflationMax). This may quicken the response of staking behaviour to the incentive mechanism [described in the notes below](#notes). #### Notes + **Example:** if the current staking participation ratio (aka "bond ratio") is 73%, then this is the calculation for speed that the inflation rate will change: (1 - 73%/67%) * 13% = -1.16% per year @@ -73,75 +82,88 @@ If `InflationRateChange` is 26% and the current staking participation ratio (aka The Cosmos Hub's inflation rate is tied to its staking participation ratio in order to make staking more or less desirable, since most of the Hub's inflation is used to fund staking rewards. If the speed of inflation responds more strongly to staking participation, it could be that staking behaviour will also respond more strongly. ### `InflationMax` + **The maximum rate that the Cosmos Hub can mint new ATOMs, proportional to the supply.** -* on-chain value: `{{ $themeConfig.currentParameters.mint.InflationMax }}` -* `cosmoshub-4` default: `0.200000000000000000` -* `cosmoshub-3` default: `0.200000000000000000` +- on-chain value: `{{ $themeConfig.currentParameters.mint.InflationMax }}` +- `cosmoshub-4` default: `0.200000000000000000` +- `cosmoshub-3` default: `0.200000000000000000` The maximum rate that the Cosmos Hub can be set to mint new ATOMs is determined by `InflationMax`, which is 20% (`0.200000000000000000`) of the ATOM supply per year and based on the assumption that there are 4,855,015 blocks produced per year (see [`BlocksPerYear`](#BlocksPerYear)). If the Cosmos Hub's staking ratio (ie. the number of ATOMs staked vs total supply) remains below [`GoalBonded`](#GoalBonded)(67%) for long enough, its inflation setting will eventually reach this maximum. #### Decreasing the value of `InflationMax` -Decreasing the value of the `InflationMax` parameter will lower the maximum rate that the Cosmos Hub produces new ATOMs and reduce the rate at which the ATOM supply expands. This will reduce the rate at which token-holders' assets are diluted and may reduce the incentive for staking participation. + +Decreasing the value of the `InflationMax` parameter will lower the maximum rate that the Cosmos Hub produces new ATOMs and reduce the rate at which the ATOM supply expands. This will reduce the rate at which token-holders' assets are diluted and may reduce the incentive for staking participation. #### Increasing the value of `InflationMax` -Increasing the value of the `InflationMax` parameter will raise the maximum rate that the Cosmos Hub produces new ATOMs and raise the rate at which the ATOM supply expands. This will increase the rate at which token-holders' assets are diluted and may increase the incentive for staking participation. + +Increasing the value of the `InflationMax` parameter will raise the maximum rate that the Cosmos Hub produces new ATOMs and raise the rate at which the ATOM supply expands. This will increase the rate at which token-holders' assets are diluted and may increase the incentive for staking participation. #### Notes + The effective rate of inflation tends to be different than the set rate of inflation because inflation is dependent upon the number of blocks produced per year. If blocks are produced more slowly than 6.50 seconds per block, then fewer than the assumed 4,855,015 will be produced per year, and effectively inflation will be lower than the set rate. If blocks are produced more quickly than 6.50 seconds per block, then more than the assumed 4,855,015 will be produced per year, and effectively inflation will be higher than the set rate. ### `InflationMin` + **The minimum rate that the Cosmos Hub can mint new ATOMs, proportional to the supply.** -* on-chain value: `{{ $themeConfig.currentParameters.mint.InflationMin }}` -* `cosmoshub-4` default: `0.070000000000000000` -* `cosmoshub-3` default: `0.070000000000000000` +- on-chain value: `{{ $themeConfig.currentParameters.mint.InflationMin }}` +- `cosmoshub-4` default: `0.070000000000000000` +- `cosmoshub-3` default: `0.070000000000000000` The minimum rate that the Cosmos Hub can be set to mint new ATOMs is determined by `InflationMin`, which is 7% (`0.070000000000000000`) of the ATOM supply per year and based on the assumption that there are 4,855,015 blocks produced per year (see [`BlocksPerYear`](#BlocksPerYear)). If the Cosmos Hub's staking ratio (ie. the number of ATOMs staked vs total supply) remains above [`GoalBonded`](#GoalBonded)(67%) for long enough, its inflation setting will eventually reach this minimum. #### Decreasing the value of `InflationMin` + Decreasing the value of the `InflationMin` parameter will lower the minimum rate that the Cosmos Hub produces new ATOMs and reduce the rate at which the ATOM supply expands. This will reduce the rate at which token-holders' assets are diluted and may reduce the incentive for staking participation. #### Increasing the value of `InflationMin` + Increasing the value of the `InflationMin` parameter will raise the minimum rate that the Cosmos Hub produces new ATOMs and raise the rate at which the ATOM supply expands. This will increase the rate at which token-holders' assets are diluted and may increase the incentive for staking participation. #### Notes + The effective rate of inflation tends to be different than the set rate of inflation because inflation is dependent upon the number of blocks produced per year. If blocks are produced more slowly than 6.50 seconds per block, then fewer than the assumed 4,855,015 will be produced per year, and effectively inflation will be lower than the set rate. If blocks are produced more quickly than 6.50 seconds per block, then more than the assumed 4,855,015 will be produced per year, and effectively inflation will be higher than the set rate. ### `GoalBonded` + **The target proportion of staking participation, relative to the ATOM supply.** -* on-chain value: `{{ $themeConfig.currentParameters.mint.GoalBonded }}` -* `cosmoshub-4` default: `0.670000000000000000` -* `cosmoshub-3` default: `0.670000000000000000` +- on-chain value: `{{ $themeConfig.currentParameters.mint.GoalBonded }}` +- `cosmoshub-4` default: `0.670000000000000000` +- `cosmoshub-3` default: `0.670000000000000000` `GoalBonded` is the target proportion of staking participation, relative to the ATOM supply. Currently the goal of the system's design is to have 67% (`0.670000000000000000`) of the total ATOM supply bonded and participating in staking. When over 67% of the supply is staked, the inflation set rate begins decreasing at a maximum yearly rate of [`InflationRateChange`](#InflationRateChange) until it reaches and remains at the [`InflationMin`](#InflationMin) of 7%. When under 67% of the supply is staked, the inflation set rate begins increasing at a maximum yearly rate of [`InflationRateChange`](#InflationRateChange) until it reaches and remains at the [`InflationMax`](#InflationMax) of 20%. #### Decreasing the value of `GoalBonded` + Decreasing the value of the `GoalBonded` parameter will cause the Cosmos Hub's inflation setting to begin decreasing at a lower participation rate, and this may reduce the incentive for staking participation. #### Increasing the value of `GoalBonded` + Increasing the value of the `GoalBonded` parameter will cause the Cosmos Hub's inflation setting to begin increasing at a lower participation rate, and this may increase the incentive for staking participation. ### `BlocksPerYear` + **The system's assumed number of blocks that the Cosmos Hub will produce in one year.** -* on-chain value: `{{ $themeConfig.currentParameters.mint.BlocksPerYear }}` -* `cosmoshub-4` default: `4360000` -* [Proposal 30](https://www.mintscan.io/cosmos/proposals/30) change to `4360000` -* `cosmoshub-3` default: `4855015` +- on-chain value: `{{ $themeConfig.currentParameters.mint.BlocksPerYear }}` +- `cosmoshub-4` default: `4360000` +- [Proposal 30](https://www.mintscan.io/cosmos/proposals/30) change to `4360000` +- `cosmoshub-3` default: `4855015` `BlocksPerYear` is the setting for the system's assumed number of blocks that the Cosmos Hub will produce in one year. `BlocksPerYear` is currently `{{ $themeConfig.currentParameters.mint.BlocksPerYear }` and the network's inflationary behaviour will be aligned with its settings when the average block time is 7.24 seconds (see [Proposal 30](https://www.mintscan.io/cosmos/proposals/30)) seconds over one year. `BlocksPerYear` is most notably used in by the system to determine the rate that new ATOMs are minted, which can vary if block times vary from 6.50 seconds per block, since effectively a different number of blocks will be produced in one year and ATOMs are minted each block. #### Changing the `BlocksPerYear` parameter + Changing the `BlocksPerYear` parameter will change the assumption that system makes about how many Cosmos Hub blocks will be produced per year. If block times are greater than 6.50 seconds, then this parameter should be decreased to make the Cosmos Hub's inflationary behaviour more aligned with its settings. If block times are less than 6.50 seconds, then this parameter should be increased to make the Cosmos Hub's behaviour more aligned with its settings. #### Notes + The calculation for seconds in one year: -365.24 (days) * 24 (hours) * 60 (minutes) * 60 (seconds) = 31556736 seconds +365.24 (days) *24 (hours)* 60 (minutes) * 60 (seconds) = 31556736 seconds **Example:** If block times are 7.12 seconds per block and 31556736 seconds per year: - 31556736 / 7.12 = ~4432126 blocks per year diff --git a/docs/governance/params-change/README.md b/docs/governance/params-change/README.md index 12a714342ad..6e9bbd73630 100644 --- a/docs/governance/params-change/README.md +++ b/docs/governance/params-change/README.md @@ -16,6 +16,7 @@ Drafting and submitting a parameter-change governance proposal involves two kind If you are considering drafting a proposal, you should review the general background on drafting and submitting a proposal: + 1. [How the voting process and governance mechanism works](../process.md) 1. [How to draft your proposal and engage with the Cosmos community about it](../best-practices.md) 1. [How to format proposals](../formatting.md) @@ -30,6 +31,7 @@ Each module has its own set of parameters. Any of them can be updated with a Params Change Proposal. There is an [index of these parameters here](./param-index.md). There are currently 8 modules active in the Cosmos Hub with parameters that may be altered via governance proposal: + 1. [auth](./Auth.md) - Authentication of accounts and transactions 2. [bank](./Bank.md) - Token transfer functionalities 3. [gov](./Governance.md) - On-chain governance proposals and voting @@ -41,7 +43,7 @@ There are currently 8 modules active in the Cosmos Hub with parameters that may The value or setting for each parameter may be verified in the chain's genesis file, [found here](https://raw.githubusercontent.com/cosmos/launch/master/genesis.json). These are the parameter settings that the latest Cosmos Hub chain launched with, and will remain so unless a governance proposal or software upgrade changes them. -There are also ways to query the current settings for each module's parameter(s). Some can be queried with the command line program [`gaiad`](../../getting-started/installation.md), but I'm still exploring the ways that these settings can be queried. +There are also ways to query the current settings for each module's parameter(s). Some can be queried with the command line program [`gaiad`](../../getting-started/installation.md), but I'm still exploring the ways that these settings can be queried. You can begin by using the command `gaia q [module] -h` to get help about the subcommands for the module you want to query. For example, `gaiad q staking params --chain-id cosmoshub-3 --node http://51.79.82.228:26657` returns the settings of four parameters: @@ -76,6 +78,7 @@ You can find a list of available Cosmos Hub endpoints under the [API section](ht This documentation was originally created by Gavin Birch ([Figment Networks](https://figment.io)). Its development was supported by funding approved on January 29, 2020 by the Cosmos Hub via Community Spend [Proposal 23](https://hubble.figment.io/cosmos/chains/cosmoshub-3/governance/proposals/23) ([full Proposal PDF here](https://ipfs.io/ipfs/QmSMGEoY2dfxADPfgoAsJxjjC6hwpSNx1dXAqePiCEMCbY)). In late 2021 and early 2022 significant updates were made by [Hypha, co-op](https://hypha.coop/), especially @dcwalk 🙏 **Special thanks** to the following for providing credible information: + - Aleks (All in Bits; Fission Labs) for answering countless questions about these parameters - Alessio (All in Bits) for explaining how [`SigVerifyCostED25519`](./Auth.md#4-sigverifycosted25519) & [`SigVerifyCostSecp256k1`](./Auth.md#5-sigverifycostsecp256k1) work, and detailed answers to my many questions - Vidor for volunteering to explain [`ConstantFee`](./Crisis.md#1-constantfee) and answering my many questions in detail diff --git a/docs/governance/params-change/Slashing.md b/docs/governance/params-change/Slashing.md index f0bb945fd95..e698f350788 100644 --- a/docs/governance/params-change/Slashing.md +++ b/docs/governance/params-change/Slashing.md @@ -16,6 +16,7 @@ The `slashing` module is responsible for enabling the Cosmos Hub to penalize any ## Governance notes on parameters ### `SignedBlocksWindow` + **Window for being offline without being slashed, in blocks.** * on-chain value: `{{ $themeConfig.currentParameters.slashing.SignedBlocksWindow }}` @@ -29,6 +30,7 @@ How long is being offline for too long? There are two components: `SignedBlocksW More about liveness [here](https://docs.cosmos.network/main/modules/slashing#signing-info-liveness). #### Decreasing the value of `SignedBlocksWindow` + Decreasing the value of the `SignedBlocksWindow` parameter will decrease the window for complying with the system's liveness rules. This will make it more likely that offline validators will be slashed by [`SlashFractionDowntime`](#SlashFractionDowntime) and temporarily removed from the active set for at least [`DowntimeJailDuration`](#DowntimeJailDuration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals. **Example:** @@ -40,6 +42,7 @@ Validators must now sign at least 5% of 5,000 blocks, which is 250 blocks. That That's ~9.25 hours instead of ~18.5 hours, assuming 7s block times. #### Increasing the value of `SignedBlocksWindow` + Increasing the value of the `SignedBlocksWindow` parameter will increase the window for complying with the system's liveness rules. This will make it less likely that offline validators will be slashed by [`SlashFractionDowntime`](#SlashFractionDowntime) and temporarily removed from the active set for at least [`DowntimeJailDuration`](#DowntimeJailDuration). **Example:** @@ -51,6 +54,7 @@ Validators must now sign at least 5% of 20,000 blocks, which is 1000 blocks. Tha That's ~37 hours instead of ~18.5 hours, assuming 7s block times. ### `MinSignedPerWindow` + **Minimum proportion of blocks signed per window without being slashed.** * on-chain value: `{{ $themeConfig.currentParameters.slashing.MinSignedPerWindow }}` @@ -61,10 +65,10 @@ If a validator in the active set is offline for too long, the validator will be How long is being offline for too long? There are two components: [`SignedBlocksWindow`](#SignedBlocksWindow) and `MinSignedPerWindow`. Since `MinSignedPerWindow` is 5% and `SignedBlocksWindow` is 10,000, a validator must have signed at least 5% of 10,000 blocks (500 out of 10,000) at any given time to comply with protocol rules. That means a validator that misses 9,500 consecutive blocks will be considered by the system to have committed a liveness violation. The threshold-proportion of blocks is determined by this parameter, so the greater that `MinSignedPerWindow` is, the lower the tolerance for missed blocks by the system. - More about liveness [here](https://docs.cosmos.network/main/modules/slashing#signing-info-liveness). #### Decreasing the value of `MinSignedPerWindow` + Decreasing the value of the `MinSignedPerWindow` parameter will increase the threshold for complying with the system's liveness rules. This will make it less likely that offline validators will be slashed by [`SlashFractionDowntime`](#5-SlashFractionDowntime) and temporarily removed from the active set for at least [`DowntimeJailDuration`](#3-DowntimeJailDuration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals. **Example:** @@ -76,6 +80,7 @@ Validators must now sign at least 2.5% of 10,000 blocks, which is 250 blocks. Th That's ~19 hours instead of ~18.5 hours, assuming 7s block times. #### Increasing the value of `MinSignedPerWindow` + Increasing the value of the `MinSignedPerWindow` parameter will decrease the threshold for complying with the system's liveness rules. This will make it more likely that offline validators will be slashed by [`SlashFractionDowntime`](#SlashFractionDowntime) and temporarily removed from the active set for at least [`DowntimeJailDuration`](#DowntimeJailDuration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals. **Example:** @@ -87,41 +92,45 @@ Validators must now sign at least 10% of 10,000 blocks, which is 1000 blocks. Th That's ~17.5 hours instead of ~18.5 hours, assuming 7s block times. ### `DowntimeJailDuration` + **The suspension time (aka jail time) for a validator that is offline too long, in nanoseconds.** * on-chain value: `{{ $themeConfig.currentParameters.slashing.DowntimeJailDuration }}` * `cosmoshub-4` default: `600000000000` * `cosmoshub-3` default: `600000000000` - A validator in the active set that's offline for too long, besides being slashed, will be temporarily removed from the active set (aka "[jailed](https://docs.cosmos.network/main/modules/slashing#unjail)") for at least [`DowntimeJailDuration`](#DowntimeJailDuration), which is 10 minutes (`600000000000` nanoseconds). During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. After the `DowntimeJailDuration` period has passed, the validator operator may send an "[unjail](https://docs.cosmos.network/main/modules/slashing#unjail)" transaction to resume validator operations. More about liveness [here](https://docs.cosmos.network/main/modules/slashing#signing-info-liveness). - #### Decreasing the value of `DowntimeJailDuration` + Decreasing the value of the `DowntimeJailDuration` parameter will require a validator to wait less time before resuming validator operations. During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. #### Increasing the value of `DowntimeJailDuration` -Increasing the value of the `DowntimeJailDuration` parameter will require a validator to wait more time before resuming validator operations. During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. +Increasing the value of the `DowntimeJailDuration` parameter will require a validator to wait more time before resuming validator operations. During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. ### `SlashFractionDoubleSign` + **Proportion of stake-backing that is bruned for equivocation (aka double-signing).** + * on-chain value: `{{ $themeConfig.currentParameters.slashing.SlashFractionDoubleSign }}` * `cosmoshub-4` default: `0.050000000000000000` * `cosmoshub-3` default: `0.050000000000000000` - A validator proven to have signed two blocks at the same height is considered to have committed equivocation, and the system will then permanently burn ("slash") that validator's total delegations (aka stake-backing) by `0.050000000000000000` (5%). All delegators to an offending validator will lose 5% of all ATOMs delegated to this validator. At this point the validator will be "[tombstoned](https://docs.cosmos.network/main/modules/slashing#staking-tombstone)," which means the validator will be permanently removed from the active set of validators, and the validator's stake-backing will only be slashed one time (regardless of how many equivocations). #### Decreasing the value of `SlashFractionDoubleSign` + Decreasing the value of the `SlashFractionDoubleSign` parameter will lessen the penalty for equivocation, and offending validators will have a smaller proportion of their stake-backing burned. This may reduce the motivation for operators to ensure that their validators are secure. #### Increasing the value of `SlashFractionDoubleSign` + Increasing the value of the `SlashFractionDoubleSign` parameter will heighten the penalty for equivocation, and offending validators will have a larger proportion of their stake-backing burned. This may increase the motivation for operators to ensure that their validators are secure. ### `SlashFractionDowntime` + **Proportion of stake that is slashed for being offline too long.** * on-chain value: `{{ $themeConfig.currentParameters.slashing.SlashFractionDowntime }}` @@ -131,14 +140,16 @@ Increasing the value of the `SlashFractionDoubleSign` parameter will heighten th If a validator in the active set is offline for too long, the system will permanently burn ("slash") that validator's total delegations (aka stake-backing) by a `SlashFractionDowntime` of `0.000100000000000000` (0.01%). All delegators to an offending validator will lose 0.01% of all ATOMs delegated to this validator. At this point the validator will be "[jailed](https://docs.cosmos.network/main/modules/slashing#unjail)," which means the validator will be temporarily removed from the active set of validators so the validator's stake-backing will only be slashed one time. #### Decreasing the value of `SlashFractionDowntime` + Decreasing the value of the `SlashFractionDowntime` parameter will lessen the penalty for liveness violations, and offending validators will have a smaller proportion of their stake-backing burned. This may reduce the motivation for operators to ensure that their validators are online. #### Increasing the value of `SlashFractionDowntime` + Increasing the value of the `SlashFractionDowntime` parameter will heighten the penalty for liveness violations, and offending validators will have a larger proportion of their stake-backing burned. This may increase the motivation for operators to ensure that their validators are online. ### `MaxEvidenceAge` + * deprecated in `cosmoshub-4` * `cosmoshub-3` default: `1814400000000000` - This parameter was present in `cosmoshub-3`, but was [deprecated](https://github.com/cosmos/cosmos-sdk/pull/5952) for `cosmoshub-4` genesis. diff --git a/docs/governance/params-change/Staking.md b/docs/governance/params-change/Staking.md index 68a8033e8e4..1ace1f039f4 100644 --- a/docs/governance/params-change/Staking.md +++ b/docs/governance/params-change/Staking.md @@ -1,4 +1,5 @@ # `staking` subspace + The `staking` module is responsible for the proof of stake (PoS) layer of the Cosmos Hub blockchain. It includes the following parameters:
@@ -17,6 +18,7 @@ The `staking` module is responsible for supporting an advanced Proof of Stake (P ## Governance notes on parameters ### `UnbondingTime` + **The time duration required for bonded ATOMs to unbond and become transferrable, in nanoseconds.** * on-chain value: `{{ $themeConfig.currentParameters.staking.UnbondingTime }}` @@ -30,17 +32,21 @@ ATOMs are used as a bond when staking. A bond may be slashed (ie. partially dest Why is `UnbondingTime` so long? It can take time to discover that a validator has committed equivocation ie. signed two blocks at the same block height. If a validator commits equivocation and then unbonds before being caught, the protocol can no longer slash (ie. partially destroy) the validator's bond. #### Decreasing the value of `UnbondingTime` + Decreasing the value of the `UnbondingTime` parameter will reduce the time it takes to unbond ATOMs. This will make it less likely for a validator's bond to be slashed after committing equivocation (aka double-signing). #### Increasing the value of `UnbondingTime` + Increasing the value of the `UnbondingTime` parameter will increase the time it takes to unbond ATOMs. This will make it more likely for a validator's bond to be slashed after committing equivocation (aka double-signing). #### Notes + The ability to punish a validator for committing equivocation is associated with the strength of the protocol's security guarantees. 1 second is equal to 1,000,000,000 nanoseconds. ## `MaxValidators` + **The maximum number of validators that may participate in validating blocks, earning rewards, and governance voting.** * on-chain value: `{{ $themeConfig.currentParameters.staking.MaxValidators }}` @@ -50,17 +56,21 @@ The ability to punish a validator for committing equivocation is associated with Validators are ranked by stake-backing based upon the sum of their delegations, and only the top 125 are designated to be active (aka "the active set"). The active set may change any time delegation amounts change. Only active validators may participate in validating blocks, earning rewards, and governance voting. ATOM-holders may participate in staking by delegating their bonded ATOMs to one or more validators in the active set. Delegators may only earn rewards and have their governance votes count if they are delegating to an active validator, the set of which is capped by `MaxValidators`. #### Decreasing the value of `MaxValidators` + Decreasing the value of the `MaxValidators` parameter will likely reduce the number of validators actively participating in validating blocks, earning rewards, and governance voting for the Cosmos Hub. This may decrease the time it takes to produce each new Cosmos Hub block. #### Increasing the value of `MaxValidators` + Increasing the value of the `MaxValidators` parameter will likely increase the number of validators actively participating in validating blocks, earning rewards, and governance voting for the Cosmos Hub. This may increase the time it takes to produce each new Cosmos Hub block. #### Notes + Prior to `cosmoshub-3`, the Cosmos Hub had a maximum set of 100 active validators. Text-based governance proposal [Prop10](https://hubble.figment.io/cosmos/chains/cosmoshub-2/governance/proposals/10) signalled agreement that the active set be increased to 125 validators. Block times were ~6.94 seconds/block with 100 validators, and are now ~7.08 seconds/block with 125 validators. It may be argued that after the Cosmos creators, the validator cohort may be the largest group of contributors to the Cosmos Hub community. Changes to the number of active validator participants may also affect the non-validator contributions to the Cosmos Hub. ### `KeyMaxEntries` + * **The maximum number of unbondings between a delegator and validator within the [unbonding period](#UnbondingTime).** * **A delegator's maximum number of simultaneous redelegations from one validator to another validator within the [unbonding period](#1-UnbondingTime).** @@ -71,15 +81,19 @@ It may be argued that after the Cosmos creators, the validator cohort may be the Each delegator has a limited number of times that they may unbond ATOM amounts from a unique validator within the [unbonding period](#1-UnbondingTime). Each delegator also has a limited number of times that they may redelegate from one unique validator to another unique validator within the unbonding period. This limit is set by the parameter `KeyMaxEntries`, which is currently `7`. To be clear, this limit does not apply to a delegator that is redelegating from one validator to different validators. #### Decreasing the value of `KeyMaxEntries` -Decreasing the value of the `KeyMaxEntries` parameter will, within the unbonding period, decrease the number of times that a delegator may unbond ATOM amounts from a single, unique validator. It will also decrease the number of redelegations a delegator may initiate between two unique validators. Since this activity across many accounts can affect the performance of the Cosmos Hub, decreasing this parameter's value decreases the likelihood of a performance reduction in the network. + +Decreasing the value of the `KeyMaxEntries` parameter will, within the unbonding period, decrease the number of times that a delegator may unbond ATOM amounts from a single, unique validator. It will also decrease the number of redelegations a delegator may initiate between two unique validators. Since this activity across many accounts can affect the performance of the Cosmos Hub, decreasing this parameter's value decreases the likelihood of a performance reduction in the network. #### Increasing the value of `KeyMaxEntries` + Increasing the value of the `KeyMaxEntries` parameter will, within the unbonding period, increase the number of times that a delegator may unbond ATOM amounts from a single, unique validator. It will also increase the number of redelegations a delegator may initiate between two unique validators. Since this activity across many accounts can affect the performance of the Cosmos Hub, increasing this parameter's value may increase the likelihood of a performance reduction in the network. ### Notes + Aleksandr (All in Bits; Fission Labs) wrote more about `KeyMaxEntries` [here in this article](https://blog.cosmos.network/re-delegations-in-the-cosmos-hub-7d2f5ea59f56). ### `BondDenom` + **The unit and denomination for the asset bonded in the system.** * on-chain value: `{{ $themeConfig.currentParameters.staking.BondDenom }}` @@ -89,9 +103,11 @@ Aleksandr (All in Bits; Fission Labs) wrote more about `KeyMaxEntries` [here in When using an asset as a bond on the Cosmos Hub, the unit and denomination of the asset is denoted as the `uatom`, or micro-ATOM, where 1 ATOM is considered 1000000uatom. The protocol doesn't use ATOM for bonds, only uatom. #### Changing the value of `BondDenom` + Changing the `BondDenom` parameter will make any bond transactions with `uatom` fail and will require the new `BondDenom` parameter string in order for bond transactions to be successful. Changing this parameter is likely to have breaking changes for applications that offer staking and delegation functionality. ### `HistoricalEntries` + **The number of HistoricalEntries to keep.** * on-chain value: `{{ $themeConfig.currentParameters.staking.HistoricalEntries }}` diff --git a/docs/governance/proposals/2020-11-inflation-rate-change/README.md b/docs/governance/proposals/2020-11-inflation-rate-change/README.md index 935ac7a7e9b..d210eafbdff 100644 --- a/docs/governance/proposals/2020-11-inflation-rate-change/README.md +++ b/docs/governance/proposals/2020-11-inflation-rate-change/README.md @@ -9,18 +9,16 @@ In this proposal we will be looking at adjusting the inflation rate change varia - When the cosmos hub inflation dynamics were originally designed, the goal was for the hub to go from the minimum rate (7%) to the maximum rate (20%) in roughly one year after a shock had unbond occurred. Thus, for the variable “inflation rate change” a value of .13 was chosen. Unfortunately, in practice the variable didn’t work as intended due to the fact the change in the inflation rate for the hub is proportional to the Target Bonded / current bonded ratio. - **How to select “inflation rate change” AKA Maximum Slope of the inflation curve** The purpose of changing the network's inflation rate is to protect it from unbonding shocks that can threaten to compromise the security of the network. When the bonded ratio gets below the goal bonded ratio (currently at 66% on the hub) the inflation rate & effective yield of staked atoms goes up in order to incentivize holders to bond new ATOMs with a view to securing the network. Inversely, if we regain a desired amount of staked tokens, the yield will drop and thusly decrease effective yields for all delegators. Ideally the inflation rate starts changing fast, optimizing network security over monetary hardness. To figure out what an appropriate selection for the cosmos hub would be, I created excel sheets to run through all the different scenarios to find what value made the inflation rate react in an optimal manner. **I came to the conclusion that 1 (AKA 100% per year is the maximum slope of the inflation curve) gave the most ideal characteristics, with the added benefit of simplifying the equation**. I’ll give some examples on how it would react. Since unbonding is what we are protecting against, I will look at flash unbonds while the inflation rate is at the floor due to that being the #1 time of vulnerability. **Scenarios of Shock Unbonds** -#1. Cosmos hub Bonded ratio flash crashes to 60%, which is not bad, but still 10% below the target. With our current variable of .13, it would take approx. 9.6 years to make it to the ceiling rate of 20%. On the other hand, if this variable was 1, the hub would reach it ceiling 17.2 months after the unbond shock (assuming bonded % stays at 60% the entire time for simplicity). - +# 1. Cosmos hub Bonded ratio flash crashes to 60%, which is not bad, but still 10% below the target. With our current variable of .13, it would take approx. 9.6 years to make it to the ceiling rate of 20%. On the other hand, if this variable was 1, the hub would reach it ceiling 17.2 months after the unbond shock (assuming bonded % stays at 60% the entire time for simplicity). -#2 Cosmos hub Bonded ratio flash crashes to 50%, starting to get a little scary, but only 25% below the 66% target. With our current variable of .13, it would take aprox. 4 years to make it to the ceiling rate of 20%. On the other hand, if this variable was 1, the hub would reach it ceiling 6.4 months after the unbond. +# 2 Cosmos hub Bonded ratio flash crashes to 50%, starting to get a little scary, but only 25% below the 66% target. With our current variable of .13, it would take aprox. 4 years to make it to the ceiling rate of 20%. On the other hand, if this variable was 1, the hub would reach it ceiling 6.4 months after the unbond. -#3 Cosmos hub Bonded ratio flash crashes to 35%, NOT GOOD!!!! We need to get more atoms staked ASAP! With our current variable of .13, it would take aprox 25 months to reach the ceiling rate of 20%. On the other hand, if this variable was 1, the hub would reach its ceiling 3.3 months after the unbond and the inflation rate would be increasing at a rate of 3.91% per month. +# 3 Cosmos hub Bonded ratio flash crashes to 35%, NOT GOOD!!!! We need to get more atoms staked ASAP! With our current variable of .13, it would take aprox 25 months to reach the ceiling rate of 20%. On the other hand, if this variable was 1, the hub would reach its ceiling 3.3 months after the unbond and the inflation rate would be increasing at a rate of 3.91% per month. All of the data above, graphs, and much more can be found at [https://docs.google.com/spreadsheets/d/1ZJWNzkNB7HUG3fsom9UO8bXODao8cJfFHkgdZ12IOnA/edit#gid=0](https://docs.google.com/spreadsheets/d/1ZJWNzkNB7HUG3fsom9UO8bXODao8cJfFHkgdZ12IOnA/edit#gid=0) diff --git a/docs/governance/proposals/2021-01-atom2021_marketing/README.md b/docs/governance/proposals/2021-01-atom2021_marketing/README.md index f6e2cbfa930..728e0f3d6f5 100644 --- a/docs/governance/proposals/2021-01-atom2021_marketing/README.md +++ b/docs/governance/proposals/2021-01-atom2021_marketing/README.md @@ -76,7 +76,6 @@ Since we are aware of the superiority of the project over any similar efforts on Funds will be released to a multi-sig committee which in turn may - depending on each initiative and based on a majority multisignature approval - release the funds to: 1) Tendermint (AiB) that will act as a liaison between Cosmos Hub community and third parties and distribute the payments according with the marketing proposal or where appropriate, 2) directly to the entities or individuals ( e.g. contest winners or various contributors) - **Funds’ Distribution:** The distribution of funds will be administered by 5 community members that have been selected via the governance working group. At least 3 will have to approve each spend for it to be released to AiB or any third party, according with the marketing proposal. diff --git a/docs/governance/proposals/2021-01-delay-stargate-upgrade/README.md b/docs/governance/proposals/2021-01-delay-stargate-upgrade/README.md index 1c6c6bb63fb..61529f63091 100644 --- a/docs/governance/proposals/2021-01-delay-stargate-upgrade/README.md +++ b/docs/governance/proposals/2021-01-delay-stargate-upgrade/README.md @@ -1,12 +1,12 @@ # Delay of Hub Stargate Upgrade - + The Stargate team is recommending that the Cosmos Hub reschedule the next upgrade to a new commit hash. The new commit hash is expected to be available on Tuesday Jan 26th with a new upgrade proposal immediately after. - + This governance proposal will signal that [proposal 35](https://www.mintscan.io/cosmos/proposals/35) will not be executed. The Hub governance will vote on the forthcoming proposal aiming for a final upgrade. The earliest target date would be February 11th. Given that Lunar New Year is on Feb 12th. The next best date is Feb 18th 06:00UTC. - + We are recommending the delay for the following reasons. - + * Bugs have been identified in the Proposal 29 implementation. They are resolved in this pull request[Additional review of prop 29 and migration testing by zmanian · Pull Request #559 · cosmos/gaia · GitHub](https://github.com/cosmos/gaia/pull/559) * A balance validation regression was identified during Prop 29 code review. [x/bank: balance and metadata validation by fedekunze · Pull Request #8417 · cosmos/cosmos-sdk · GitHub](https://github.com/cosmos/cosmos-sdk/pull/8417) * The IBC Go To Market Working Group has [identified Ledger hardware wallet](https://github.com/cosmos/cosmos-sdk/issues/8266) support as a necessary feature for the initial launch of IBC on the Hub. We have an opportunity to provide this support in this upgrade. The SDK believes this can be quickly remediated in the time available with merged PRs on Monday. diff --git a/docs/governance/proposals/2021-01-stargate-upgrade/README.md b/docs/governance/proposals/2021-01-stargate-upgrade/README.md index 89d3c865eb1..1658b81d0e7 100644 --- a/docs/governance/proposals/2021-01-stargate-upgrade/README.md +++ b/docs/governance/proposals/2021-01-stargate-upgrade/README.md @@ -71,7 +71,6 @@ Most exchanges and wallets have taken self-certification on directly. Our team c We have conducted numerous testnets with different partners. A particularly important testnet conducted with a significant fraction of the Hub validator set was a simulated upgrade of the cosmoshub on Nov 25th,2020. This tested the full upgrade flow including the prop29 implementation and height preserving upgrade functionality. - ### Conclusion The governance proposal is our report back to the community on the success of the Stargate program. We have compiled detailed information for the community as a reference in the Stargate [repository](https://github.com/cosmosdevs/stargate). diff --git a/docs/governance/proposals/2021-04-advancing-ethermint/README.md b/docs/governance/proposals/2021-04-advancing-ethermint/README.md index 8e48a218a00..a0fa349bc08 100644 --- a/docs/governance/proposals/2021-04-advancing-ethermint/README.md +++ b/docs/governance/proposals/2021-04-advancing-ethermint/README.md @@ -1,5 +1,5 @@ -# Advancing Ethermint - Governance Proposal: GTM and Engineering Plan for the Ethermint Chain +# Advancing Ethermint - Governance Proposal: GTM and Engineering Plan for the Ethermint Chain > **NOTE**: this is a short version of the full proposal. To read the full document click [here](https://forum.cosmos.network/t/advancing-ethermint-governance-proposal-gtm-and-engineering-plan-for-the-ethermint-chain/4554). @@ -55,7 +55,7 @@ These are the items that are mandatory for the release of funds. The items will > NOTE: Some of the items below are currently stated under ChainSafe's service agreement with the ICF for Ethermint. Our team will collaborate with them on these items so that they are included by the time the EVM chain is launched. These items are marked below as [CS] -#### Milestone 1: Developer Usability and Testing +#### Milestone 1: Developer Usability and Testing This milestone aims to reach a stage where developers can begin deployments of Ethermint with the latest Cosmos SDK version and test their smart contracts in what will feel like a seamless experience. @@ -112,7 +112,7 @@ See the [full version](https://forum.cosmos.network/t/advancing-ethermint-govern ## Conclusion -With this proposal, Tharsis plans to expedite the Ethermint chain's development and launch the network by Q4 2021. Ethermint will be the first EVM-compatible chain on Cosmos that will be fully interoperable with other BFT and EVM chains via IBC and the Gravity bridge. +With this proposal, Tharsis plans to expedite the Ethermint chain's development and launch the network by Q4 2021. Ethermint will be the first EVM-compatible chain on Cosmos that will be fully interoperable with other BFT and EVM chains via IBC and the Gravity bridge. By creating and envisioning this long-term roadmap, we believe Ethermint can act as the vital component of the Interchain and serve as the gateway between the Ethereum and Cosmos ecosystems: The Ethermint launch will combine the Cosmos and Ethereum communities and provide new economic opportunities for millions of users. diff --git a/docs/governance/proposals/2021-04-lower-deposit-requirement/README.md b/docs/governance/proposals/2021-04-lower-deposit-requirement/README.md index a83d27fbe31..5ac03a12f7f 100644 --- a/docs/governance/proposals/2021-04-lower-deposit-requirement/README.md +++ b/docs/governance/proposals/2021-04-lower-deposit-requirement/README.md @@ -52,9 +52,9 @@ This is an interesting design space, however it becomes more plausible if and wh The following items summarise the voting options and what it means for this proposal. -- **YES**: You approve the parameter change proposal to decrease the governance proposal deposit requirements from 512 to 64 ATOMs. -- **NO**: You disapprove of the parameter change in its current form (please indicate in the Cosmos Forum why this is the case). -- **NO WITH VETO**: You are strongly opposed to this change and will exit the network if passed. -- **ABSTAIN**: You are impartial to the outcome of the proposal. +- __YES__: You approve the parameter change proposal to decrease the governance proposal deposit requirements from 512 to 64 ATOMs. +- __NO__: You disapprove of the parameter change in its current form (please indicate in the Cosmos Forum why this is the case). +- __NO WITH VETO__: You are strongly opposed to this change and will exit the network if passed. +- __ABSTAIN__: You are impartial to the outcome of the proposal. \ No newline at end of file diff --git a/docs/governance/proposals/2021-04-prop34-continuation/README.md b/docs/governance/proposals/2021-04-prop34-continuation/README.md index dd49ac56fbd..9afbe15d31a 100644 --- a/docs/governance/proposals/2021-04-prop34-continuation/README.md +++ b/docs/governance/proposals/2021-04-prop34-continuation/README.md @@ -1,14 +1,14 @@ # Proposal 46: Extend Luna Mission to Fund ATOM Marketing - + The Cosmos community approved Proposal 34 on 2021-01-20 allocating 129,208 ATOM to implement a comprehensive ATOM marketing plan executed in collaboration with key community stakeholders. Proposal 46 is requesting an extension of the time allowed to spend the approved budget and allocate existing funds for additional ATOM-focused priorities. Below are details of this request and an outline of the successful results of Proposal 34 marketing spend as of 2021-03-31. - -## PROPOSAL 46 REQUEST: -1. _*Prop 34 Time Extension:*_ The Prop 34 Implementation team seeks a three-month extension (until 2021-07-20) to fully spend the existing budget allocation under the terms approved in Proposal 34. The multisig team and AiB (Tendermint) invested significant time and energy properly researching, vetting and managing vendors, contractors, and opportunities requiring additional time to complete the Prop 34 expenditure of funds. With the approval of Proposal 46, any unspent funds remaining from Proposal 34 efforts will be returned to the community pool on 2021-07-20. -1. _*Additional Budget Priority - Project Execution Fund Pool:*_ Execution, oversight, and accountability for this significant marketing spend requires substantive operational support. In addition to the 5 multisig administrators, Zaki Manian, Jack Zampolin, Immasssi, Jhonnie and Joe Dirtay, extensive support is being provided by Adriana Mihai (Kalpatech), Garrette Furo (Regen Network), David Fortson (Regen Network/LOACOM), and others. We request an allocation of 3000 ATOM (from the existing budget) to compensate the aforementioned contributors for previous and ongoing support of this expansive marketing campaign. Funds will be distributed through the multisig administration. -1. _*Additional Budget Priority - Gravity DEX:*_ This proposal seeks to allocate 10,000 - 20,000 ATOM (from approved Prop 34 budget) to identify and support robust marketing of the Gravity DEX testnet and DEX mainnet launch- an AMM exchange that will have a significant impact on ATOM valuation if successful. Gravity DEX is initially planned as an automated market maker (AMM) exchange that will allow users to trade IBC token pairs and provide liquidity for traders. These tokens would arrive on the Hub through IBC-enabled chains, IBC-wrapped ETH and ERC20 tokens, IBC-wrapped BTC tokens, and as well as future blockchain ecosystems that implement the IBC protocol. -1. _*Community Created YouTube Videos:*_ After evaluating the existing meme campaign, the project management team is recommending ceasing the community meme campaign and reallocating remaining funds for community-created YouTube videos. This campaign would reward community members for creating select videos for prospective or new token holders focused on ‘How to’ and explainer videos on topics such as “How to set up your wallet,” “How to stake your $ATOM,” “How to delegate, redelegate and participate in governance,” and more. +## PROPOSAL 46 REQUEST + +1. __Prop 34 Time Extension:__ The Prop 34 Implementation team seeks a three-month extension (until 2021-07-20) to fully spend the existing budget allocation under the terms approved in Proposal 34. The multisig team and AiB (Tendermint) invested significant time and energy properly researching, vetting and managing vendors, contractors, and opportunities requiring additional time to complete the Prop 34 expenditure of funds. With the approval of Proposal 46, any unspent funds remaining from Proposal 34 efforts will be returned to the community pool on 2021-07-20. +1. __Additional Budget Priority - Project Execution Fund Pool:__ Execution, oversight, and accountability for this significant marketing spend requires substantive operational support. In addition to the 5 multisig administrators, Zaki Manian, Jack Zampolin, Immasssi, Jhonnie and Joe Dirtay, extensive support is being provided by Adriana Mihai (Kalpatech), Garrette Furo (Regen Network), David Fortson (Regen Network/LOACOM), and others. We request an allocation of 3000 ATOM (from the existing budget) to compensate the aforementioned contributors for previous and ongoing support of this expansive marketing campaign. Funds will be distributed through the multisig administration. +1. __Additional Budget Priority - Gravity DEX:__ This proposal seeks to allocate 10,000 - 20,000 ATOM (from approved Prop 34 budget) to identify and support robust marketing of the Gravity DEX testnet and DEX mainnet launch- an AMM exchange that will have a significant impact on ATOM valuation if successful. Gravity DEX is initially planned as an automated market maker (AMM) exchange that will allow users to trade IBC token pairs and provide liquidity for traders. These tokens would arrive on the Hub through IBC-enabled chains, IBC-wrapped ETH and ERC20 tokens, IBC-wrapped BTC tokens, and as well as future blockchain ecosystems that implement the IBC protocol. +1. __Community Created YouTube Videos:__ After evaluating the existing meme campaign, the project management team is recommending ceasing the community meme campaign and reallocating remaining funds for community-created YouTube videos. This campaign would reward community members for creating select videos for prospective or new token holders focused on ‘How to’ and explainer videos on topics such as “How to set up your wallet,” “How to stake your $ATOM,” “How to delegate, redelegate and participate in governance,” and more. ## SECTION I OVERVIEW @@ -16,41 +16,41 @@ A summary report of current marketing activities and related analytics can be fo * ATOM Valuation: ATOM valuation has increased from $8.92 to $19.10 - a 214% increase. * Twitter: New 2020 and 2021 record on new followers and engagement: - - *New followers:* Q1 Twitter: 45,380 new followers ( 2,236 in Q1 2020, 1940% increase) - - *Engagement:* 10.3M impressions ( 2,16M in Q1 2020, 476% increase) + * _New followers:_ Q1 Twitter: 45,380 new followers ( 2,236 in Q1 2020, 1940% increase) + * _Engagement:_ 10.3M impressions ( 2,16M in Q1 2020, 476% increase) * Youtube - - *New subscribers:* 1,3k new subscribers (195 in Q1 2020, 667% increase) - - *Impressions and views:* 447k impressions ( 126k in Q1 2020, 355% increase) , 47,4k views ( 10,1k views Q1 2020, 469% increase) + * _New subscribers:_ 1,3k new subscribers (195 in Q1 2020, 667% increase) + * _Impressions and views:_ 447k impressions ( 126k in Q1 2020, 355% increase) , 47,4k views ( 10,1k views Q1 2020, 469% increase) * Cosmos website - - +396% new users, +355% sessions - - +380% unique page views, +64% pages per session, -28% bounce rate - - 1,079,000 visitors, 244,000 new users from which 28,804 acquired new users from the marketing campaign. + * +396% new users, +355% sessions + * +380% unique page views, +64% pages per session, -28% bounce rate + * 1,079,000 visitors, 244,000 new users from which 28,804 acquired new users from the marketing campaign. * Cosmos Hub - * 31,408 new delegators (increase from 41,885 to 73,293 - a 74% increase.) - * 92,561 new ATOM accounts (increase from 136,219 accounts to 228,780 accounts - a 68% increase.) + * 31,408 new delegators (increase from 41,885 to 73,293 - a 74% increase.) + * 92,561 new ATOM accounts (increase from 136,219 accounts to 228,780 accounts - a 68% increase.) * Blockfolio Signal - * 270,000 new followers, increase from 220,000 to 490,000 as of March 31st. ( As of April 21st, total number of followers reached 1,3 Million followers) + * 270,000 new followers, increase from 220,000 to 490,000 as of March 31st. ( As of April 21st, total number of followers reached 1,3 Million followers) ### Spend Overview As of 2021-03-31, a total of 41,912 ATOM have been spent in the following ways: -- Meme Contest: 0 ATOM -- Banner ads - 8,750 ATOM -- Influencers: twitter posts and youtube shows - 25,462 ATOM -- Podcasts, newsletters- 6,200 ATOM -- Media/TV: 1,000 ATOM -- Signers fee: 500 ATOM +* Meme Contest: 0 ATOM +* Banner ads - 8,750 ATOM +* Influencers: twitter posts and youtube shows - 25,462 ATOM +* Podcasts, newsletters- 6,200 ATOM +* Media/TV: 1,000 ATOM +* Signers fee: 500 ATOM Additionally as of 2021-04-21, a total of 22,610 ATOM have been spent for: -- Meme contest: 240 ATOM -- PR company: 990 ATOM -- Twitter influencers: 9,550 ATOM -- Community management: 150 ATOM -- Banner ads: 11,680 ATOM +* Meme contest: 240 ATOM +* PR company: 990 ATOM +* Twitter influencers: 9,550 ATOM +* Community management: 150 ATOM +* Banner ads: 11,680 ATOM -#### Total ATOM spent as of 2021-04-21 is of 64,522 ATOM, remaining budget is of 64,655 ATOM. +#### Total ATOM spent as of 2021-04-21 is of 64,522 ATOM, remaining budget is of 64,655 ATOM -## SECTION II - HISTORY +## SECTION II - HISTORY The Cosmos Hub (ATOM) community approved the passage of Proposal 34 - Luna Mission - Funding $ATOM on 2021-01-20 at 74% yes, 18.9% abstain and 7.1% no. @@ -61,51 +61,51 @@ Proposal 34 authorized a spending pool of 129,208 ATOM to implement a comprehens Proposal 34 - Results Summary - 2021-01-20 to 2021-03-31 1. Banner Ads - - Locations: - * Wallets: Blockfolio, Coinstats + * Locations: + * Wallets: Blockfolio, Coinstats * Platforms: Coingecko, Stacking Rewards - - Sample Banner: https://drive.google.com/drive/folders/1JFpJewRGsQfrK57BxEdE0Pk3ae37ldpL - - Duration of the campaign ads: 1-3 months - - Total performance on all 4 venues: (#37,000,000 impressions, #28,804 new acquired visitors, over #100,000 new wallets downloads with ATOM as preset currency) - - Total Spent: *8,750 ATOMs* -1. Marketing contracts - * Podcasts: - - Charlie Shrem - * Twitter account: https://twitter.com/CharlieShrem + * Sample Banner: + * Duration of the campaign ads: 1-3 months + * Total performance on all 4 venues: (#37,000,000 impressions, #28,804 new acquired visitors, over #100,000 new wallets downloads with ATOM as preset currency) + * Total Spent: _8,750 ATOMs_ +1. Marketing contracts + * Podcasts: + * Charlie Shrem + * Twitter account: * Followers: 199k - * https://twitter.com/CharlieShrem/status/1376550892321730563?s=20 + * * Performance: 268K Twitter Impressions, 6265 Podcast Downloads, & 7600 youtube views. - - Scott Melker - * Twitter Account: https://twitter.com/scottmelker + * Scott Melker + * Twitter Account: * Followers: 290K - * https://www.youtube.com/watch?v=MdIb6xImS5Q + * * Newsletters/Articles: - - Scott Melker: https://thewolfofallstreets.link/cosmos​ - - The Daily Chain - * https://thedailychain.com/the-stargate-upgrade-launch-is-coming-on-cosmos-hub/ - * https://thedailychain.com/cosmos-hub-governance-passes-new-proposals-to-improve-the-project/ - * https://thedailychain.com/solving-blockchain-interoperability-with-the-cosmos-hub/ - - Blockworks - * Tweet https://twitter.com/Blockworks_/status/1381969023584272395?s=20 - * Article https://blockworks.co/cosmos-why-we-need-interoperability-in-blockchain/ + * Scott Melker: ​ + * The Daily Chain + * + * + * + * Blockworks + * Tweet + * Article * 250,255 Dedicated Twitter Impressions, 10,653 Newsletter Impressions, 1,147 pageviews - - Total Spent: *6,200 ATOM* + * Total Spent: _6,200 ATOM_ 1. Influencers * Twitter - - Over 30 Twitter influencers engaged including Crypto Dog, Michaël van de Poppe and the Wolf of all Streets. - - Sample Posts: + * Over 30 Twitter influencers engaged including Crypto Dog, Michaël van de Poppe and the Wolf of all Streets. + * Sample Posts: * [Crypto Dog](https://twitter.com/thecryptodog/status/1376640286428864514?s=21 ) * [Michaël van de Poppe](https://twitter.com/CryptoMichNL/status/1381264254033133569?s=20) - * [Scott Melker ](https://twitter.com/scottmelker/status/1383155303525576706?s=20) + * [Scott Melker](https://twitter.com/scottmelker/status/1383155303525576706?s=20) * [StackingUSD](https://twitter.com/stackingusd/status/1362133942435012608?s=28) * [MacroCRG](https://twitter.com/macrocrg/status/1364606751878881288?s=28) * [Trader_XO](https://twitter.com/trader_xo/status/1369038610415161347?s=28 ) * [Crypto_Chasr](https://twitter.com/crypto_chase/status/1381696722557136899?s=28 ) - - Results: from the 1st-month Twitter only (second-month data was not complete in time) + * Results: from the 1st-month Twitter only (second-month data was not complete in time) * 245 tweets, 20,000 Likes, 4,000 Retweets, 1700 Comments * YouTube Shows & Podcasts - - Programs: Crypto Daily, Data Dash, Tech Con Catalina,Crypto Busy, Hashoshi, Crypto Michael. - - Featured Shows: + * Programs: Crypto Daily, Data Dash, Tech Con Catalina,Crypto Busy, Hashoshi, Crypto Michael. + * Featured Shows: * [Crypto Daily](https://www.youtube.com/watch?v=g55JAdwVs2Q&t=254s&ab_channel=CryptoDaily) * Subscribers: 193K * Video views: 52,834 @@ -118,11 +118,11 @@ Proposal 34 - Results Summary - 2021-01-20 to 2021-03-31 * YouTube Followers - 115K Subscribers * Video views: 42,415 * Publish date: April 12th - * [Crypto Busy](https://www.youtube.com/watch?v=G2zHiIw_DZM) + * [Crypto Busy](https://www.youtube.com/watch?v=G2zHiIw_DZM) * YouTube Followers - 152K Subscribers * Video views: 24,468 * Publish date: March 3rd - * [Hashoshi](https://www.youtube.com/watch?v=jVjcCjfGOxU) + * [Hashoshi](https://www.youtube.com/watch?v=jVjcCjfGOxU) * YouTube Followers - 116K Subscribers * Video views: 6,218 views * Publish date: April 20th @@ -131,26 +131,25 @@ Proposal 34 - Results Summary - 2021-01-20 to 2021-03-31 * Video views: 4,499 views * Publish date: April 14th * Delphi Digital podcasts & Brand Sponsor - * Podcast ads are just starting, clubhouse (later aired as podcast) w/ key cosmonauts soon - * Total Spent on Influencers (Twitter &YouTube): *25,462 ATOMS* + * Podcast ads are just starting, clubhouse (later aired as podcast) w/ key cosmonauts soon + * Total Spent on Influencers (Twitter &YouTube): _25,462 ATOMS_ And many more videos to be dropping soon Cosmonauts! - ## SECTION IV - Public Relations Hired GFCA - work begins 2021-04-07, placements were done in April 2021: + * [Peng Zhong featured in Business Insider](https://www.businessinsider.com/crypto-investing-experts-bitcoin-price-drop-explainer-charts-data-watch-2021-4) - - Notes: world's favorite business brand — by a wide margin. With over 70 million unique visitors a month. + * Notes: world's favorite business brand — by a wide margin. With over 70 million unique visitors a month. * [Garrette Furo featured in Finance Magnates](https://www.financemagnates.com/cryptocurrency/news/are-nfts-a-good-long-term-investment-on-ownership-long-term-viability/) - - Notes: global business news outlet that focuses on alternatives and trading industries with 553,507 unique monthly visitors. -Spend: *990 ATOM* - + * Notes: global business news outlet that focuses on alternatives and trading industries with 553,507 unique monthly visitors. +Spend: _990 ATOM_ ## SECTION V - MEME Competition 2021 Start 22nd of March (3 Total stages) -Spend total: *3915 ATOM* (Split up for each stage) +Spend total: _3915 ATOM_ (Split up for each stage) Stage 1 accepted entries for prizes (so far): 170+ - Total valid entries: 2000+ - Cosmonaut Telegram channel growth: 700+ new people in 2 weeks (organic) diff --git a/docs/governance/proposals/2021-05-gravity-bridge-deployment/README.md b/docs/governance/proposals/2021-05-gravity-bridge-deployment/README.md index 3f642349de3..6c57e30db4c 100644 --- a/docs/governance/proposals/2021-05-gravity-bridge-deployment/README.md +++ b/docs/governance/proposals/2021-05-gravity-bridge-deployment/README.md @@ -29,7 +29,7 @@ Cosmos Hub validators will run three key software components of the Gravity brid - The Gravity bridge Orchestrator - A Geth light client or any Ethereum full node implementing the JSON-rpc standard -### Cosmos to Ethereum: +### Cosmos to Ethereum To send transactions from Cosmos to Ethereum, the Gravity Bridge module of a validator's Gaia instance first packages the transaction data, and makes it available on an endpoint. The Orchestrator then signs this data with the validator’s Ethereum key, and submits it as a message to the Ethereum network. The Ethereum signature of each Cosmos validator needs to be assembled and submitted to the Ethereum chain by relayers. @@ -41,7 +41,7 @@ Validators may also be slashed if they sign a message with their Ethereum key th Gravity bridge has no other slashing conditions. -### Ethereum to Cosmos: +### Ethereum to Cosmos The Orchestrator also monitors the Ethereum chain, submitting events that occur on Ethereum to Cosmos as messages. When more than 2/3 of the active voting power has sent a message observing the same Ethereum event, the Gravity module will take action. @@ -51,7 +51,7 @@ The oracle was designed to adhere to the Cosmos Hub validator security model wit ### Slashing Conditions Spec -https://github.com/cosmos/gravity-bridge/blob/main/spec/slashing-spec.md + ## How does it work? @@ -103,7 +103,7 @@ The Gravity Bridge has been continuously tested throughout Q1/Q2 2021 by multipl The Althea team is committed to playing a long-term role in upgrading, documenting, and supporting Gravity over the coming years. The Gravity bridge is currently live and running in a testnet, which validators can join by following the instructions [here](https://github.com/althea-net/althea-chain/blob/main/docs/althea/testnet-2.md) -### Audit: +### Audit The Gravity bridge module is currently undergoing an audit with Informal Systems estimated to be completed by the end of July, 2021. @@ -111,7 +111,7 @@ Phase one of the audit has been completed, which resulted in the addition of evi The phase two design audit will be completed by the end of June. To be followed by phrase three, an implementation audit to be completed by the end of July. -### Conclusion: +### Conclusion With this proposal, the Althea team, together with Cosmos ecosystem partners, will expedite the development of the Gravity Bridge with an incentivized testnet and launch in Q3 2021. Althea will be closely shepherding the Gravity Bridge throughout all phases related to the testing, audit, and implementation process on the Cosmos Hub. diff --git a/docs/governance/proposals/2021-07-atom-liquidity-incentives/README.md b/docs/governance/proposals/2021-07-atom-liquidity-incentives/README.md index e182e270a7d..101cdd03a93 100644 --- a/docs/governance/proposals/2021-07-atom-liquidity-incentives/README.md +++ b/docs/governance/proposals/2021-07-atom-liquidity-incentives/README.md @@ -13,7 +13,7 @@ Osmosis has already helped in establishing ATOM as the Schelling Point of the Co Osmosis has the ability to incentivize AMM liquidity, a feature not available on any other IBC-enabled DEX. Osmosis already uses its own native OSMO liquidity rewards to incentivize ATOMs to be one of the main base pairs, leading to ~2.2 million ATOMs already providing liquidity on the platform. -In addition to these native OSMO LP Rewards, the platform also includes a feature called “external incentives” that allows anyone to permissionlessly add additional incentives in any token to the LPs of any AMM pools they wish. You can read more about this mechanism here: https://medium.com/osmosis/osmosis-liquidity-mining-101-2fa58d0e9d4d#f413 . Pools containing Cosmos assets such as AKT and XPRT are already planned to receive incentives from their respective community pools and/or foundations. +In addition to these native OSMO LP Rewards, the platform also includes a feature called “external incentives” that allows anyone to permissionlessly add additional incentives in any token to the LPs of any AMM pools they wish. You can read more about this mechanism here: . Pools containing Cosmos assets such as AKT and XPRT are already planned to receive incentives from their respective community pools and/or foundations. We propose the Cosmos Hub dedicate 100,000 ATOMs from its Community Pool to be allocated towards liquidity incentives on Osmosis over the next 3 months. This community fund proposal will transfer 100,000 ATOMs to a multisig group who will then allocate the ATOMs to bonded liquidity gauges on Osmosis on a biweekly basis, according to direction given by Cosmos Hub governance. For simplicity, we propose setting the liquidity incentives to initially point to Osmosis Pool #1, the ATOM/OSMO pool, which is the pool with by far the highest TVL and Volume. Cosmos Hub governance can then use Text Proposals to further direct the multisig members to reallocate incentives to new pools. diff --git a/docs/governance/proposals/2021-09-hub-ibc-router/README.md b/docs/governance/proposals/2021-09-hub-ibc-router/README.md index 78775efa7cf..89cff327666 100644 --- a/docs/governance/proposals/2021-09-hub-ibc-router/README.md +++ b/docs/governance/proposals/2021-09-hub-ibc-router/README.md @@ -13,7 +13,7 @@ Any of the zones can themselves be hubs to form an acyclic graph, but for the sa The Hub has long been envisioned as a central point in the IBC architecture. In the battle to build and ship IBC this central vision has remained unchanged, but with so much focus on the need to build out other zones with real economies to support this network (the CosmosSDK is the result of this effort), the idea of the hub as an Interchain Router hasn't been discussed in a serious context for quite a while. -This is understandable: Cosmos needed so many other pieces to come together before the Hub had a chance to even start performing this function. Those other zones have been created, they each have products and economies. The bootstrapping era of IBC is well underway. +This is understandable: Cosmos needed so many other pieces to come together before the Hub had a chance to even start performing this function. Those other zones have been created, they each have products and economies. The bootstrapping era of IBC is well underway. These new zones joining are noticing a problem: they need to maintain a large amount of infrastructure (archive nodes and relayers for each counterparty chain) to connect with all the chains in the ecosystem, a number that is continuing to increase quickly. diff --git a/docs/governance/proposals/previous-proposals/README.md b/docs/governance/proposals/previous-proposals/README.md index f91361b9e3f..8ba3d254c98 100644 --- a/docs/governance/proposals/previous-proposals/README.md +++ b/docs/governance/proposals/previous-proposals/README.md @@ -9,7 +9,7 @@ This is a record of past proposals, including ones that weren't drafted in the g * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -This governance proposal is for adjustment of blocks_per_year parameter to normalize the inflation rate and reward rate.\n ipfs link: https://ipfs.io/ipfs/QmXqEBr56xeUzFpgjsmDKMSit3iqnKaDEL4tabxPXoz9xc +This governance proposal is for adjustment of blocks_per_year parameter to normalize the inflation rate and reward rate.\n ipfs link: ## 2 ATOM Transfer Enablement @@ -17,7 +17,7 @@ This governance proposal is for adjustment of blocks_per_year parameter to norma * **Status:** PROPOSAL_STATUS_REJECTED * **Type:** /cosmos.gov.v1beta1.TextProposal -A plan is proposed to set up a testnet using the Cosmos SDK v0.34.0 release, along with mainnet conditions, plus transfer enablement and increased block size, as a testing ground. Furthermore, a path for upgrading the cosmoshub-1 chain to use the Cosmos SDK release v0.34.0, along with the necessary updates to the genesis file, at block 425000, is outlined. IPFS: https://ipfs.io/ipfs/QmaUaMjXPE6i4gJR1NakQc15TZpSqjSrXNmrS1vA5veF9W +A plan is proposed to set up a testnet using the Cosmos SDK v0.34.0 release, along with mainnet conditions, plus transfer enablement and increased block size, as a testing ground. Furthermore, a path for upgrading the cosmoshub-1 chain to use the Cosmos SDK release v0.34.0, along with the necessary updates to the genesis file, at block 425000, is outlined. IPFS: ## 3 ATOM Transfer Enablement v2 @@ -25,7 +25,7 @@ A plan is proposed to set up a testnet using the Cosmos SDK v0.34.0 release, alo * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -A plan for enabling ATOM transfers is being proposed, which involves the release and test of Cosmos SDK v0.34.0 and a strategy for the network to accept the release and upgrade the mainnet once testing has been deemed to be successful. Read the full proposal at https://ipfs.io/ipfs/Qmam1PU39qmLBzKv3eYA3kMmSJdgR6nursGwWVjnmovpSy or formatted at https://ipfs.ink/e/Qmam1PU39qmLBzKv3eYA3kMmSJdgR6nursGwWVjnmovpSy +A plan for enabling ATOM transfers is being proposed, which involves the release and test of Cosmos SDK v0.34.0 and a strategy for the network to accept the release and upgrade the mainnet once testing has been deemed to be successful. Read the full proposal at or formatted at ## 4 Proposal for issuance of fungible tokens directly on the Cosmos Hub @@ -33,7 +33,7 @@ A plan for enabling ATOM transfers is being proposed, which involves the release * **Status:** PROPOSAL_STATUS_REJECTED * **Type:** /cosmos.gov.v1beta1.TextProposal -This proposal is a first step towards enabling fungible token issuance on the Cosmos Hub, with listing of new tokens requiring governance approval. Read the full proposal at https://github.com/validator-network/cosmoshub-proposals/blob/0d306f1fcc841a0ac6ed1171af96e6869d6754b6/issuance-proposal.md +This proposal is a first step towards enabling fungible token issuance on the Cosmos Hub, with listing of new tokens requiring governance approval. Read the full proposal at ## 5 Expedited Cosmos Upgrade Proposal @@ -41,7 +41,7 @@ This proposal is a first step towards enabling fungible token issuance on the Co * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -Proposal to upgrade the Cosmos Hub at block 500,000 on April 22nd 5pm GMT. Details:https://ipfs.io/ipfs/QmS13GPNs1cRKSojete5y9RgW7wyf1sZ1BGqX3zjTGs7sX +Proposal to upgrade the Cosmos Hub at block 500,000 on April 22nd 5pm GMT. Details: ## 6 Don't Burn Deposits for Rejected Governance Proposals Unless Vetoed @@ -49,7 +49,7 @@ Proposal to upgrade the Cosmos Hub at block 500,000 on April 22nd 5pm GMT. Detai * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -Read here, or on https://ipfs.ink/e/QmRtR7qkeaZCpCzHDwHgJeJAZdTrbmHLxFDYXhw7RoF1ppnnThe Cosmos Hub's state machine handles spam prevention of governance proposals by means of a deposit system. A governance proposal is only considered eligible for voting by the whole validator set if a certain amount of staking token is deposited on the proposal. The intention is that the deposit will be burned if a proposal is spam or has caused a negative externality to the Cosmos community (such as wasting stakeholders’ time having to review the proposal).nnIn the current implementation of the governance module used in the Cosmos Hub, the deposit is burned if a proposal does not pass, regardless of how close the final tally result may have been. For example, if 49% of stake votes in favor of a proposal while 51% votes against it, the deposit will still be burned. This seems to be an undesirable behavior as it disincentivizes anyone from creating or depositing on a proposal that might be slightly contentious but not spam, due to fear of losing the deposit minimum (currently 512 atoms). This will especially be the case as TextProposals will be used for signaling purposes, to gauge the sentiment of staked Atom holders. Disincentivizing proposals for which the outcome is uncertain would undermine that effort.nnWe instead propose that the deposit be returned on failed votes, and that the deposit only be burned on vetoed votes. If a proposal seems to be spam or is deemed to have caused a negative externality to Cosmos communninty, voters should vote NoWithVeto on the proposal. If >33% of the stake chooses to Veto a proposal, the deposits will then be burned. However, if a proposal gets rejected without being vetoed, the deposits should be returned to the depositors. This proposal does not make any change to the current behavior for proposals that fail to meet quorum; if a proposal fails to meet quorum its deposit will be burned. +Read here, or on Cosmos Hub's state machine handles spam prevention of governance proposals by means of a deposit system. A governance proposal is only considered eligible for voting by the whole validator set if a certain amount of staking token is deposited on the proposal. The intention is that the deposit will be burned if a proposal is spam or has caused a negative externality to the Cosmos community (such as wasting stakeholders’ time having to review the proposal).nnIn the current implementation of the governance module used in the Cosmos Hub, the deposit is burned if a proposal does not pass, regardless of how close the final tally result may have been. For example, if 49% of stake votes in favor of a proposal while 51% votes against it, the deposit will still be burned. This seems to be an undesirable behavior as it disincentivizes anyone from creating or depositing on a proposal that might be slightly contentious but not spam, due to fear of losing the deposit minimum (currently 512 atoms). This will especially be the case as TextProposals will be used for signaling purposes, to gauge the sentiment of staked Atom holders. Disincentivizing proposals for which the outcome is uncertain would undermine that effort.nnWe instead propose that the deposit be returned on failed votes, and that the deposit only be burned on vetoed votes. If a proposal seems to be spam or is deemed to have caused a negative externality to Cosmos communninty, voters should vote NoWithVeto on the proposal. If >33% of the stake chooses to Veto a proposal, the deposits will then be burned. However, if a proposal gets rejected without being vetoed, the deposits should be returned to the depositors. This proposal does not make any change to the current behavior for proposals that fail to meet quorum; if a proposal fails to meet quorum its deposit will be burned. ## 7 Activate the Community Pool @@ -57,7 +57,7 @@ Read here, or on https://ipfs.ink/e/QmRtR7qkeaZCpCzHDwHgJeJAZdTrbmHLxFDYXhw7RoF1 * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -Enable governance to spend funds from the community pool. Full proposal: https://ipfs.io/ipfs/QmNsVCsyRmEiep8rTQLxVNdMHm2uiZkmaSHCR6S72Y1sL1 +Enable governance to spend funds from the community pool. Full proposal: ## 8 Notification for Security Critical Hard Fork at Block 482100 @@ -65,7 +65,7 @@ Enable governance to spend funds from the community pool. Full proposal: https:/ * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -As described by user @Jessysaurusrex on Cosmos Forum in https://forum.cosmos.network/t/critical-cosmossdk-security-advisory/2211, All in Bits has learned of a critical security vulnerability in the codebase for the Cosmos Hub. We deem the issue to be of high severity, as if exploited it can potentially degrade the security model of the chain's Proof of Stake system. This vulnerability CANNOT lead to the theft of Atoms or creation of Atoms out of thin air. nn All in Bits has released a source code patch, Gaia v0.34.6, that closes the exploitable code path starting at block 482100. nn The proposed upgrade code Git hash is: 80234baf91a15dd9a7df8dca38677b66b8d148c1 nn As a proof of stake, we are putting some collateral behind this legitimacy of this bug and patch and encourage others familiar with the report to do so as well. If the disclosed bug turns out to be fabricated or malicious in some way, we urge the Cosmos Hub governance to slash these Atoms by voting NoWithVeto on this proposal. nn We encourage validators and all users to upgrade their nodes to Gaia v0.34.6 before block 482100. In the absence of another public bulletin board, we request validators to please vote Yes on this proposal AFTER they have upgraded their nodes to v0.34.6, as a method of signalling the readiness of the network for the upgrade. +As described by user @Jessysaurusrex on Cosmos Forum in , All in Bits has learned of a critical security vulnerability in the codebase for the Cosmos Hub. We deem the issue to be of high severity, as if exploited it can potentially degrade the security model of the chain's Proof of Stake system. This vulnerability CANNOT lead to the theft of Atoms or creation of Atoms out of thin air. nn All in Bits has released a source code patch, Gaia v0.34.6, that closes the exploitable code path starting at block 482100. nn The proposed upgrade code Git hash is: 80234baf91a15dd9a7df8dca38677b66b8d148c1 nn As a proof of stake, we are putting some collateral behind this legitimacy of this bug and patch and encourage others familiar with the report to do so as well. If the disclosed bug turns out to be fabricated or malicious in some way, we urge the Cosmos Hub governance to slash these Atoms by voting NoWithVeto on this proposal. nn We encourage validators and all users to upgrade their nodes to Gaia v0.34.6 before block 482100. In the absence of another public bulletin board, we request validators to please vote Yes on this proposal AFTER they have upgraded their nodes to v0.34.6, as a method of signalling the readiness of the network for the upgrade. ## 10 Increase Max Validator Set Size to 125 @@ -73,7 +73,7 @@ As described by user @Jessysaurusrex on Cosmos Forum in https://forum.cosmos.net * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -Read here, or on https://ipfs.ink/e/QmRhQycV19QiTQGLuPzPHfJwCioj1wDeHHtZvxiHegTFDd nnThis proposal supercedes proposal number 9, which contains conflicting numbers in the title and body. nnIn the Cosmos Hub, the total number of active validators is currently capped at 100, ordered by total delegated Atoms. This number was originally proposed in the Cosmos whitepaper section titled [Limitations on the Number of Validators](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#limitations-on-the-number-of-validators 4). This number was chosen as a relatively conservative estimate, as at the time of writing, it was unclear how many widely distributed nodes Tendermint consensus could scale to over the public internet. nnHowever, since then, we have seen empirically through the running of the Game of Stakes incentivized testnet that Tendermint Core with Gaia state machine can operate with over 180 validators at reasonable average block times of <7 seconds. The Game of Stakes results empirically show that adding validators should not delay consensus at small block sizes. At large block sizes, the time it takes for the block to gossip to all validators may increase depending on the newfound network topology. However we view this as unlikely, and if it did become a problem, it could later be solved by known improvements at the p2p layer. The other tradeoff to increasing the number of validators is that the size of commits becomes ~25% larger due to more precommits being included, increasing the network and storage costs for nodes. This can also be resolved in the future with the integration of aggregate signatures. At the time of submission of this proposal, the minimum delegation to become a top 100 validator is 30,600 Atoms, a fairly high barrier to entry for new validators looking to enter the active validator set. nnIn the Cosmos whitepaper, it states that the number of validators on the Hub will increase at a rate of 13% a year until it hits a cap of 300 validators. We propose scrapping this mechanism and instead increasing the max validators to 125 validators in the next chain upgrade with no further planned increases. Future increases to the validator set size will be originated through governance. +Read here, or on nnThis proposal supercedes proposal number 9, which contains conflicting numbers in the title and body. nnIn the Cosmos Hub, the total number of active validators is currently capped at 100, ordered by total delegated Atoms. This number was originally proposed in the Cosmos whitepaper section titled [Limitations on the Number of Validators]( 4). This number was chosen as a relatively conservative estimate, as at the time of writing, it was unclear how many widely distributed nodes Tendermint consensus could scale to over the public internet. nnHowever, since then, we have seen empirically through the running of the Game of Stakes incentivized testnet that Tendermint Core with Gaia state machine can operate with over 180 validators at reasonable average block times of <7 seconds. The Game of Stakes results empirically show that adding validators should not delay consensus at small block sizes. At large block sizes, the time it takes for the block to gossip to all validators may increase depending on the newfound network topology. However we view this as unlikely, and if it did become a problem, it could later be solved by known improvements at the p2p layer. The other tradeoff to increasing the number of validators is that the size of commits becomes ~25% larger due to more precommits being included, increasing the network and storage costs for nodes. This can also be resolved in the future with the integration of aggregate signatures. At the time of submission of this proposal, the minimum delegation to become a top 100 validator is 30,600 Atoms, a fairly high barrier to entry for new validators looking to enter the active validator set. nnIn the Cosmos whitepaper, it states that the number of validators on the Hub will increase at a rate of 13% a year until it hits a cap of 300 validators. We propose scrapping this mechanism and instead increasing the max validators to 125 validators in the next chain upgrade with no further planned increases. Future increases to the validator set size will be originated through governance. ## 12 Are Validators Charging 0% Commission Harmful to the Success of the Cosmos Hub? @@ -81,7 +81,7 @@ Read here, or on https://ipfs.ink/e/QmRhQycV19QiTQGLuPzPHfJwCioj1wDeHHtZvxiHegTF * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -This governance proposal is intended to act purely as a signalling proposal. Throughout this history of the Cosmos Hub, there has been much debate about the impact that validators charging 0% commission has on the Cosmos Hub, particularly with respect to the decentralization of the Cosmos Hub and the sustainability for validator operations. nn Discussion around this topic has taken place in many places including numerous threads on the Cosmos Forum, public Telegram channels, and in-person meetups. Because this has been one of the primary discussion points in off-chain Cosmos governance discussions, we believe it is important to get a signal on the matter from the on-chain governance process of the Cosmos Hub. nn There have been past discussions on the Cosmos Forum about placing an in-protocol restriction on validators from charging 0% commission. https://forum.cosmos.network/t/governance-limit-validators-from-0-commission-fee/2182 nn This proposal is NOT proposing a protocol-enforced minimum. It is merely a signalling proposal to query the viewpoint of the bonded Atom holders as a whole. nn We encourage people to discuss the question behind this governance proposal in the associated Cosmos Hub forum post here: https://forum.cosmos.network/t/proposal-are-validators-charging-0-commission-harmful-to-the-success-of-the-cosmos-hub/2505 nn Also, for voters who believe that 0% commission rates are harmful to the network, we encourage optionally sharing your belief on what a healthy minimum commission rate for the network using the memo field of their vote transaction on this governance proposal or linking to a longer written explanation such as a Forum or blog post. nn The question on this proposal is “Are validators charging 0% commission harmful to the success of the Cosmos Hub?”. A Yes vote is stating that they ARE harmful to the network's success, and a No vote is a statement that they are NOT harmful. +This governance proposal is intended to act purely as a signalling proposal. Throughout this history of the Cosmos Hub, there has been much debate about the impact that validators charging 0% commission has on the Cosmos Hub, particularly with respect to the decentralization of the Cosmos Hub and the sustainability for validator operations. nn Discussion around this topic has taken place in many places including numerous threads on the Cosmos Forum, public Telegram channels, and in-person meetups. Because this has been one of the primary discussion points in off-chain Cosmos governance discussions, we believe it is important to get a signal on the matter from the on-chain governance process of the Cosmos Hub. nn There have been past discussions on the Cosmos Forum about placing an in-protocol restriction on validators from charging 0% commission. nn This proposal is NOT proposing a protocol-enforced minimum. It is merely a signalling proposal to query the viewpoint of the bonded Atom holders as a whole. nn We encourage people to discuss the question behind this governance proposal in the associated Cosmos Hub forum post here: nn Also, for voters who believe that 0% commission rates are harmful to the network, we encourage optionally sharing your belief on what a healthy minimum commission rate for the network using the memo field of their vote transaction on this governance proposal or linking to a longer written explanation such as a Forum or blog post. nn The question on this proposal is “Are validators charging 0% commission harmful to the success of the Cosmos Hub?”. A Yes vote is stating that they ARE harmful to the network's success, and a No vote is a statement that they are NOT harmful. ## 13 Cosmos Hub 3 Upgrade Proposal A @@ -89,7 +89,7 @@ This governance proposal is intended to act purely as a signalling proposal. Thr * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -This is a proposal to approve these high-level changes for a final vote for what will become Cosmos Hub 3. Please read them carefully: nhttps://github.com/cosmos/cosmos-sdk/blob/rc1/v0.36.0/CHANGELOG.mdnn-=-=-nnIf approved, and assuming that testing is successful, there will be a second proposal called Cosmos Hub 3 Upgrade Proposal B. Cosmos Hub 3 Upgrade Proposal B should specify 1) the software hash; 2) the block height state export from cosmoshub-2; 3) the genesis time; 4) instructions for generating the new genesis file.nn-=-=-nnFull proposal: nhttps://ipfs.io/ipfs/QmbXnLfx9iSDH1rVSkW5zYC8ErRZHUK4qUPfaGs4ZdHdc7n +This is a proposal to approve these high-level changes for a final vote for what will become Cosmos Hub 3. Please read them carefully: n approved, and assuming that testing is successful, there will be a second proposal called Cosmos Hub 3 Upgrade Proposal B. Cosmos Hub 3 Upgrade Proposal B should specify 1) the software hash; 2) the block height state export from cosmoshub-2; 3) the genesis time; 4) instructions for generating the new genesis file.nn-=-=-nnFull proposal: n ## 14 Cosmos Hub 3 Upgrade Proposal B @@ -97,7 +97,7 @@ This is a proposal to approve these high-level changes for a final vote for what * **Status:** PROPOSAL_STATUS_REJECTED * **Type:** /cosmos.gov.v1beta1.TextProposal -This proposal is intended to signal acceptance/rejection of the precise software release that will contain the changes to be included in the Cosmos Hub 3 upgrade. A high level overview of these changes was successfully approved by the voters signalling via Cosmos Hub 3 Upgrade Proposal A: https://hubble.figment.io/cosmos/chains/cosmoshub-2/governance/proposals/13nnWe are proposing to use this code https://github.com/cosmos/gaia/releases/tag/v2.0.0 to upgrade the Cosmos Hub. We are proposing to export the ledger's state at Block Height 1823000, which we expect to occur on Sunday, September 15, 2019 at or around 2:00 pm UTC. We are proposing to launch Cosmos Hub 3 at 3:57 pm UTC on Sunday, September 15, 2019. nnInstructions for migration: https://github.com/cosmos/gaia/wiki/Cosmos-Hub-2-UpgradennFull proposal: https://ipfs.io/ipfs/Qmf54mwb8cSRf316jS4by96dL91fPCabvB9V5i2Sa1hxdznn +This proposal is intended to signal acceptance/rejection of the precise software release that will contain the changes to be included in the Cosmos Hub 3 upgrade. A high level overview of these changes was successfully approved by the voters signalling via Cosmos Hub 3 Upgrade Proposal A: are proposing to use this code to upgrade the Cosmos Hub. We are proposing to export the ledger's state at Block Height 1823000, which we expect to occur on Sunday, September 15, 2019 at or around 2:00 pm UTC. We are proposing to launch Cosmos Hub 3 at 3:57 pm UTC on Sunday, September 15, 2019. nnInstructions for migration: proposal: ## 16 Cosmos Hub 3 Upgrade Proposal D @@ -105,7 +105,7 @@ This proposal is intended to signal acceptance/rejection of the precise software * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -Figment Networks (https://figment.io)nn-=-=-nnThis proposal is intended to supersede flawed Cosmos Hub 3 Upgrade Proposal B (https://hubble.figment.io/cosmos/chains/cosmoshub-2/governance/proposals/14) and Cosmos Hub 3 Upgrade Proposal C (https://hubble.figment.io/cosmos/chains/cosmoshub-2/governance/proposals/15), regardless of their outcomes. This proposal will make both Proposal 14 and 15 void.nnThis proposal is intended to signal acceptance/rejection of the precise software release that will contain the changes to be included in the Cosmos Hub 3 upgrade. A high overview of these changes was successfully approved by the voters signalling via Cosmos Hub 3 Upgrade Proposal A:nhttps://hubble.figment.io/cosmos/chains/cosmoshub-2/governance/proposals/13nn-=-=-nnWe are proposing to use this code https://github.com/cosmos/gaia/releases/tag/v2.0.0 to upgrade the Cosmos Hub. We are proposing to export the ledger’s state at Block Height 1,933,000, which we expect to occur on September 24, 2019 at or around 1:53 pm UTC. Please note that there will likely be a variance from this target time, due to changes in block time (https://forum.cosmos.network/t/cosmos-hub-3-upgrade-proposal-d/2675/18?u=gavin). We are proposing to launch Cosmos Hub 3 at 60 minutes after Block Height 1,933,000.nn-=-=-nnInstructions for migration: https://github.com/cosmos/gaia/wiki/Cosmos-Hub-2-UpgradenPlease note the recovery scenario in the case that the chain fails to start.nn-=-=-nnFull proposal:nhttps://ipfs.io/ipfs/QmPbSLvAgY8m7zAgSLHzKHfDtV4wx5XaGt1S1cDzqvXqJg +Figment Networks ( proposal is intended to supersede flawed Cosmos Hub 3 Upgrade Proposal B () and Cosmos Hub 3 Upgrade Proposal C (), regardless of their outcomes. This proposal will make both Proposal 14 and 15 void.nnThis proposal is intended to signal acceptance/rejection of the precise software release that will contain the changes to be included in the Cosmos Hub 3 upgrade. A high overview of these changes was successfully approved by the voters signalling via Cosmos Hub 3 Upgrade Proposal A:n are proposing to use this code to upgrade the Cosmos Hub. We are proposing to export the ledger’s state at Block Height 1,933,000, which we expect to occur on September 24, 2019 at or around 1:53 pm UTC. Please note that there will likely be a variance from this target time, due to changes in block time (). We are proposing to launch Cosmos Hub 3 at 60 minutes after Block Height 1,933,000.nn-=-=-nnInstructions for migration: note the recovery scenario in the case that the chain fails to start.nn-=-=-nnFull proposal:n ## 19 Cosmos Hub 3 Upgrade Proposal E @@ -113,7 +113,7 @@ Figment Networks (https://figment.io)nn-=-=-nnThis proposal is intended to super * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -Figment Networks (https://figment.io)nn-=-=-nnFull proposal:nhttps://ipfs.io/ipfs/QmfJyd64srJSX824WoNnF6BbvF4wvPGqVBynZeN98C7ygqnn-=-=-nn_Decision_nnWe are signalling that:nn1. The Gaia 2.0.3 implementation is aligned with the list of high-level changes approved in Cosmos Hub 3 Upgrade Proposal A.nn2. We are prepared to upgrade the Cosmos Hub to cosmoshub-3 based uponnta. Commit hash: 2f6783e298f25ff4e12cb84549777053ab88749a;ntb. The state export from cosmoshub-2 at Block Height 2902000;ntc. Genesis time: 60 minutes after the timestamp at Block Height 2902000.nn3. We are prepared to relaunch cosmoshub-2nta. In the event of:ntti. A non-trivial error in the migration procedure and/ornttii. A need for ad-hoc genesis file changesnttiii. The failure of cosmoshub-3 to produce two (2) blocks by 180 minutes after the timestamp of Block Height 2902000;ntb. Using:ntti. The starting block height: 2902000nttii. Software version: Cosmos SDK v0.34.6+ https://github.com/cosmos/cosmos-sdk/releases/tag/v0.34.10nttiii. The full data snapshot at export Block Height 2902000;ntc. And will consider the relaunch complete after cosmoshub-2 has reached consensus on Block 2902001.nn4. The upgrade will be considered complete after cosmoshub-3 has reached consensus on Block Height 2 within 120 minutes of genesis time.nn5. This proposal is void if the voting period has not concluded by Block Height 2852202.nn-=-=-nn_Context_nThis proposal follows Cosmos Hub 3 Upgrade Proposal D (https://hubble.figment.io/cosmos/chains/cosmoshub-2/governance/proposals/16) aka Prop 16, which passed in vote, but failed in execution (https://forum.cosmos.network/t/cosmos-hub-3-upgrade-post-mortem/2772). This proposal is intended to succeed where Prop 16 failed.nnThis proposal is intended to signal acceptance/rejection of the precise software release that will contain the changes to be included in the Cosmos Hub 3 upgrade. A high level overview of these changes was successfully approved by the voters signalling via Cosmos Hub 3 Upgrade Proposal A:nhttps://hubble.figment.io/cosmos/chains/cosmoshub-2/governance/proposals/13nnWe are proposing to use this code https://github.com/cosmos/gaia/releases/tag/v2.0.3 to upgrade the Cosmos Hub.nWe are proposing to export the ledger’s state at Block Height 2,902,000, which we expect to occur on December 11, 2019 at or around 14:27 UTC assuming an average of 6.94 seconds per block. Please note that there will likely be a variance from this target time, due to deviations in block time.nnWe are proposing that the Cosmos Hub 3 genesis time be set to 60 minutes after Block Height 2,902,000.nn-=-=-nnCo-ordination in case of failure will happen in this channel: https://riot.im/app/#/room/#cosmos_validators_technical_updates:matrix.org +Figment Networks ( proposal:n are signalling that:nn1. The Gaia 2.0.3 implementation is aligned with the list of high-level changes approved in Cosmos Hub 3 Upgrade Proposal A.nn2. We are prepared to upgrade the Cosmos Hub to cosmoshub-3 based uponnta. Commit hash: 2f6783e298f25ff4e12cb84549777053ab88749a;ntb. The state export from cosmoshub-2 at Block Height 2902000;ntc. Genesis time: 60 minutes after the timestamp at Block Height 2902000.nn3. We are prepared to relaunch cosmoshub-2nta. In the event of:ntti. A non-trivial error in the migration procedure and/ornttii. A need for ad-hoc genesis file changesnttiii. The failure of cosmoshub-3 to produce two (2) blocks by 180 minutes after the timestamp of Block Height 2902000;ntb. Using:ntti. The starting block height: 2902000nttii. Software version: Cosmos SDK v0.34.6+ . The full data snapshot at export Block Height 2902000;ntc. And will consider the relaunch complete after cosmoshub-2 has reached consensus on Block 2902001.nn4. The upgrade will be considered complete after cosmoshub-3 has reached consensus on Block Height 2 within 120 minutes of genesis time.nn5. This proposal is void if the voting period has not concluded by Block Height 2852202.nn-=-=-nn_Context_nThis proposal follows Cosmos Hub 3 Upgrade Proposal D () aka Prop 16, which passed in vote, but failed in execution (). This proposal is intended to succeed where Prop 16 failed.nnThis proposal is intended to signal acceptance/rejection of the precise software release that will contain the changes to be included in the Cosmos Hub 3 upgrade. A high level overview of these changes was successfully approved by the voters signalling via Cosmos Hub 3 Upgrade Proposal A:n are proposing to use this code to upgrade the Cosmos Hub.nWe are proposing to export the ledger’s state at Block Height 2,902,000, which we expect to occur on December 11, 2019 at or around 14:27 UTC assuming an average of 6.94 seconds per block. Please note that there will likely be a variance from this target time, due to deviations in block time.nnWe are proposing that the Cosmos Hub 3 genesis time be set to 60 minutes after Block Height 2,902,000.nn-=-=-nnCo-ordination in case of failure will happen in this channel: ## 23 Cosmos Governance Working Group - Q1 2020 @@ -121,7 +121,7 @@ Figment Networks (https://figment.io)nn-=-=-nnFull proposal:nhttps://ipfs.io/ipf * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.distribution.v1beta1.CommunityPoolSpendProposal -Cosmos Governance Working Group - Q1 2020 fundingnnCommunity-spend proposal submitted by Gavin Birch (https://twitter.com/Ether_Gavin) of Figment Networks (https://figment.io)nn-=-=-nnFull proposal: https://ipfs.io/ipfs/QmSMGEoY2dfxADPfgoAsJxjjC6hwpSNx1dXAqePiCEMCbYnn-=-=-nnAmount to spend from the community pool: 5250 ATOMsnnTimeline: Q1 2020nnDeliverables:n1. A governance working group community & chartern2. A template for community spend proposalsn3. A best-practices document for community spend proposalsn4. An educational wiki for the Cosmos Hub parametersn5. A best-practices document for parameter changesn6. Monthly governance working group community calls (three)n7. Monthly GWG articles (three)n8. One Q2 2020 GWG recommendations articlennMilestones:nBy end of Month 1, the Cosmos Governance Working Group (GWG) should have been initiated and led by Gavin Birch of Figment Networks.nBy end of Month 2, Gavin Birch is to have initiated and led GWG’s education, best practices, and Q2 recommendations.nBy end of Month 3, Gavin Birch is to have led and published initial governance education, best practices, and Q2 recommendations.nnDetailed milestones and funding:nhttps://docs.google.com/spreadsheets/d/1mFEvMSLbiHoVAYqBq8lo3qQw3KtPMEqDFz47ESf6HEg/edit?usp=sharingnnBeyond the milestones, Gavin will lead the GWG to engage in and answer governance-related questions on the Cosmos Discourse forum, Twitter, the private Cosmos VIP Telegram channel, and the Cosmos subreddit. The GWG will engage with stake-holders to lower the barriers to governance participation with the aim of empowering the Cosmos Hub’s stakeholders. The GWG will use this engagement to guide recommendations for future GWG planning.nnRead more about the our efforts to launch the Cosmos GWG here: https://figment.io/resources/introducing-the-cosmos-governance-working-group/nn-=-=-nn_Problem_nPerhaps the most difficult barrier to effective governance is that it demands one of our most valuable and scarce resources: our attention. Stakeholders may be disadvantaged by informational or resource-based asymmetries, while other entities may exploit these same asymmetries to capture value controlled by the Cosmos Hub’s governance mechanisms.nnWe’re concerned that without establishing community standards, processes, and driving decentralized delegator-based participation, the Cosmos Hub governance mechanism could be co-opted by a centralized power. As governance functionality develops, potential participants will need to understand how to assess proposals by knowing what to pay attention to.nn_Solution_nWe’re forming a focused, diverse group that’s capable of assessing and synthesizing the key parts of a proposal so that the voting community can get a fair summary of what they need to know before voting.nnOur solution is to initiate a Cosmos governance working group that develops decentralized community governance efforts alongside the Hub’s development. We will develop and document governance features and practices, and then communicate these to the broader Cosmos community.nn_Future_nAt the end of Q1, we’ll publish recommendations for the future of the Cosmos GWG, and ideally we’ll be prepared to submit a proposal based upon those recommendations for Q2 2020. We plan to continue our work in blockchain governance, regardless of whether the Hub passes our proposals.nn-=-=-nnCosmos forum: https://forum.cosmos.network/c/governancenCosmos GWG Telegram channel: https://t.me/hubgovnTwitter: https://twitter.com/CosmosGov +Cosmos Governance Working Group - Q1 2020 fundingnnCommunity-spend proposal submitted by Gavin Birch () of Figment Networks ( proposal: to spend from the community pool: 5250 ATOMsnnTimeline: Q1 2020nnDeliverables:n1. A governance working group community & chartern2. A template for community spend proposalsn3. A best-practices document for community spend proposalsn4. An educational wiki for the Cosmos Hub parametersn5. A best-practices document for parameter changesn6. Monthly governance working group community calls (three)n7. Monthly GWG articles (three)n8. One Q2 2020 GWG recommendations articlennMilestones:nBy end of Month 1, the Cosmos Governance Working Group (GWG) should have been initiated and led by Gavin Birch of Figment Networks.nBy end of Month 2, Gavin Birch is to have initiated and led GWG’s education, best practices, and Q2 recommendations.nBy end of Month 3, Gavin Birch is to have led and published initial governance education, best practices, and Q2 recommendations.nnDetailed milestones and funding:n the milestones, Gavin will lead the GWG to engage in and answer governance-related questions on the Cosmos Discourse forum, Twitter, the private Cosmos VIP Telegram channel, and the Cosmos subreddit. The GWG will engage with stake-holders to lower the barriers to governance participation with the aim of empowering the Cosmos Hub’s stakeholders. The GWG will use this engagement to guide recommendations for future GWG planning.nnRead more about the our efforts to launch the Cosmos GWG here: the most difficult barrier to effective governance is that it demands one of our most valuable and scarce resources: our attention. Stakeholders may be disadvantaged by informational or resource-based asymmetries, while other entities may exploit these same asymmetries to capture value controlled by the Cosmos Hub’s governance mechanisms.nnWe’re concerned that without establishing community standards, processes, and driving decentralized delegator-based participation, the Cosmos Hub governance mechanism could be co-opted by a centralized power. As governance functionality develops, potential participants will need to understand how to assess proposals by knowing what to pay attention to.nn_Solution_nWe’re forming a focused, diverse group that’s capable of assessing and synthesizing the key parts of a proposal so that the voting community can get a fair summary of what they need to know before voting.nnOur solution is to initiate a Cosmos governance working group that develops decentralized community governance efforts alongside the Hub’s development. We will develop and document governance features and practices, and then communicate these to the broader Cosmos community.nn_Future_nAt the end of Q1, we’ll publish recommendations for the future of the Cosmos GWG, and ideally we’ll be prepared to submit a proposal based upon those recommendations for Q2 2020. We plan to continue our work in blockchain governance, regardless of whether the Hub passes our proposals.nn-=-=-nnCosmos forum: GWG Telegram channel: : ## 25 CosmWasm Integration 1 - Permissions and Upgrades @@ -129,7 +129,7 @@ Cosmos Governance Working Group - Q1 2020 fundingnnCommunity-spend proposal subm * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.distribution.v1beta1.CommunityPoolSpendProposal -CosmWasm Integration 1 - Permissions and UpgradesnnCommunity-spend proposal submitted by Ethan Frey (https://github.com/ethanfrey) of Confio UO (http://confio.tech/) and CosmWasm (https://www.cosmwasm.com)nn-=-=-nnFull proposal: https://ipfs.io/ipfs/QmbD3bMajQCFmtDmkuRVWhmMWVdN2sK8QP2FoFCz9cjPiCnForum Post: https://forum.cosmos.network/t/proposal-cosmwasm-on-cosmos-hub/3629nn-=-=-nnAmount to spend from the community pool: 25000 ATOMsnnTimeline: 2-4 months from approvalnnDeliverables:n1. Adding governance control to all aspects of the CosmWasm contract lifecycle to make it compatible with the hub. Allowing governance to control code upload, contract instantiation, upgrades, and destruction (if needed).n2. Adding ability to upgrade contracts along with migrations (also allowing orderly shutdowns). This controlled by a governance vote.n3. Launch a testnet with working version of this code (Cosmos SDK 0.38 or 0.39) to enable all interested parties to trial the process and provide feedback.n4. Provide sample contracts to demo on the testnet, along with some migration scenariosnnWithin 2 months, the working code and binaries should be delivered and open for public review. Within 4 months, these binaries will be used on a testnet, with sufficient staking tokens given to all active voters on the Cosmos Hub, and we will go through a few governance voting cycles to trial contract deployment and migrations (with a shorter voting cycles, eg. 3 days)nnDetailed milestones in the full proposal:nhttps://ipfs.io/ipfs/QmbD3bMajQCFmtDmkuRVWhmMWVdN2sK8QP2FoFCz9cjPiCnnBeyond the milestones, CosmWasm will enhance documentation of the platform and offer technical support on our Telegram channel.nn-=-=-nn_Problem_nWith the upcoming launch of IBC, the hub will need to adapt more rapidly to the needs of the ecosystem, while also limiting chain restarts, which may be detrimental to IBC connections. In particular support for relaying Dynamic IBC Protocols and Rented Security, using ATOMs as collateral for smaller zones, would greatly benefit from CosmWasm's flexibility.nn_Solution_nWe’re adding some key features to CosmWasm to convert it from a permissionless, immutable smart contract platform to a permissioned platform with governance control for upgrading or shutting down contracts. This is a key requirement to be able to integrate CosmWasm to the Cosmos Hub with minimal disruption.nn_Future_nWe will continue development of CosmWasm, especially adding IBC integration as well as working towards a stable 1.0 release that can be audited and safely deployed (Q3/Q4 2020).nn-=-=-nnTwitter: https://twitter.com/CosmWasmnMedium: https://medium.com/confionTelegram: https://t.me/joinchat/AkZriEhk9qcRw5A5U2MapAnWebsite: https://www.cosmwasm.comnGithub: https://github.com/CosmWasm +CosmWasm Integration 1 - Permissions and UpgradesnnCommunity-spend proposal submitted by Ethan Frey () of Confio UO () and CosmWasm ( proposal: Post: to spend from the community pool: 25000 ATOMsnnTimeline: 2-4 months from approvalnnDeliverables:n1. Adding governance control to all aspects of the CosmWasm contract lifecycle to make it compatible with the hub. Allowing governance to control code upload, contract instantiation, upgrades, and destruction (if needed).n2. Adding ability to upgrade contracts along with migrations (also allowing orderly shutdowns). This controlled by a governance vote.n3. Launch a testnet with working version of this code (Cosmos SDK 0.38 or 0.39) to enable all interested parties to trial the process and provide feedback.n4. Provide sample contracts to demo on the testnet, along with some migration scenariosnnWithin 2 months, the working code and binaries should be delivered and open for public review. Within 4 months, these binaries will be used on a testnet, with sufficient staking tokens given to all active voters on the Cosmos Hub, and we will go through a few governance voting cycles to trial contract deployment and migrations (with a shorter voting cycles, eg. 3 days)nnDetailed milestones in the full proposal:n the milestones, CosmWasm will enhance documentation of the platform and offer technical support on our Telegram channel.nn-=-=-nn_Problem_nWith the upcoming launch of IBC, the hub will need to adapt more rapidly to the needs of the ecosystem, while also limiting chain restarts, which may be detrimental to IBC connections. In particular support for relaying Dynamic IBC Protocols and Rented Security, using ATOMs as collateral for smaller zones, would greatly benefit from CosmWasm's flexibility.nn_Solution_nWe’re adding some key features to CosmWasm to convert it from a permissionless, immutable smart contract platform to a permissioned platform with governance control for upgrading or shutting down contracts. This is a key requirement to be able to integrate CosmWasm to the Cosmos Hub with minimal disruption.nn_Future_nWe will continue development of CosmWasm, especially adding IBC integration as well as working towards a stable 1.0 release that can be audited and safely deployed (Q3/Q4 2020).nn-=-=-nnTwitter: : : : : ## 26 Takeoff Proposal from Cyber to Cosmos @@ -137,7 +137,7 @@ CosmWasm Integration 1 - Permissions and UpgradesnnCommunity-spend proposal subm * **Status:** PROPOSAL_STATUS_REJECTED * **Type:** /cosmos.distribution.v1beta1.CommunityPoolSpendProposal -cyber Congress (https://cybercongress.ai) developed Cyber (https://github.com/cybercongress/go-cyber): a software for replacing existing internet behemoth monopolies, such as Google, which exploited outdated internet protocols using the common patterns of our semantic interaction. These corps lock the information, produced by the users, from search, social and commercial knowledge graphs in private databases, and then sell this knowledge back as advertisement. They stand as an insurmountable wall between content creators and consumers extracting an overwhelming majority of the created value.nnWe propose ATOM holders to invest 10,000 ATOM from the community pool into the Takeoff of Cyber. In exchange, at the end of its donation round (https://cyber.page/gol/takeoff), and when an IBC connection will become possible, cyber Congress will transfer CYB tokens back to the community pool. Passing this proposal will transfer 10,000 ATOMs from the community pool to cyber Congress multisig (https://www.mintscan.io/account/cosmos1latzme6xf6s8tsrymuu6laf2ks2humqv2tkd9a).nnFull Proposal-Manifest text: https://ipfs.io/ipfs/QmUYDQt9tqLQJwxnUck7dQY3XmZA3tDtpFh3Hchkg7oH46nnor at https://cyber.page/gol/takeoffnnThe software we offer resembles a decentralized google (https://github.com/cybercongress):n- A protocol spec and the rationale behind itn- go-cyber: our implementation using cosmos-sdkn- cyber.page: PoC reference web interfacen- launch-kit: useful tools for launching cosmos-sdk based chainsn- cyberindex: GraphQL middleware for cybern- euler Foundation: mainnet predecessor of cyber Foundation: the DAO, which will handle all the donated ETHn- documentation and various side toolsnnCyber solves the problem of opening up the centralised semantics core of the Internet. It does so by opening up access to evergrowing semantics core taught to it by the users.nnEconomics of the protocol are built around the idea that feedback loops between the number of links and the value of the knowledge graph exist. The more usage => the bigger the knowledge graph => the more value => the better the quality of the knowledge => the more usage. Transaction fees for basic operations are replaced by lifetime bandwidth, which means usability for both, end-users and developers. You can think of Cyber as a shared ASIC for search.nnYou already see that the idea of Cyber evolves around content identifiers and its ranks. From here, welcome to Decentralized Marketing, or DeMa. You've certainly heard of DeFi. DeFi is built around a simple idea that you can use a collateral for something that will be settled based on a provided price feed. Here comes the systematic problem of DeFi: price oracles. DeMa is based on the same idea of using collateral, but the input for settlement can be information regarding the content identifier itself.nnWith the help of DeMa and IBC chains will be able to prove relevance using content identifiers and their ranks one to another. This will help to grow the IBC ecosystem, where each chain has multiple possibilities to exchange data, which is provably valued.nnCosmos was created to become the internet of blockchains. A protocol that propagates the spirit of decentralization and governed by the community. For such technology to succeed, a lot is required. One thing is a solid foundation it can build on. One virtue of such foundation is monetary flow of income that has to feed this machine for as long as it exists.nnA good question that arises is how to turn the community pool into a pool that isn’t (a) a pot of money which goes solely to network security, (b) a pool that isn’t solely a build-up of inflationary rewards and (с) has long term prosperity value (its value rises).nnThe solution to the above problem is to establish a fund, that is managed and processed collectively and consists of a diversified number of assets that can bring long term value to its stakeholders.nnThis means using the funds to support exceptional projects that are building with Tendermint and Cosmos-SDK. After all, is we want to glorify the ecosystem, we need for it to grow. How will it grow? It will have projects with a clear utility, amazing a product and provable distribution. This will attract users, developers and large stakeholders to the ecosystem. Together we already did one very successful investment decision. We all participated in cosmos fundraizer. So let us move the idea forward.nnIf this proposal is successful and stands for more demand from the public, we will open another proposal using the community pool. However, anyone can participate in Game of Links (https://cyber.page/gol/) or Takeoff https://cyber.page/gol/takeoff independently. If you have question you can ask them either on Cyber topic on Cosmos forum (https://forum.cosmos.network/t/cyber-a-decentralized-google-for-provable-and-relevant-answers) or Cyber forum (https://ai.cybercongress.ai).nnProposal results: https://www.mintscan.io/proposals/26 +cyber Congress () developed Cyber (): a software for replacing existing internet behemoth monopolies, such as Google, which exploited outdated internet protocols using the common patterns of our semantic interaction. These corps lock the information, produced by the users, from search, social and commercial knowledge graphs in private databases, and then sell this knowledge back as advertisement. They stand as an insurmountable wall between content creators and consumers extracting an overwhelming majority of the created value.nnWe propose ATOM holders to invest 10,000 ATOM from the community pool into the Takeoff of Cyber. In exchange, at the end of its donation round (), and when an IBC connection will become possible, cyber Congress will transfer CYB tokens back to the community pool. Passing this proposal will transfer 10,000 ATOMs from the community pool to cyber Congress multisig ( Proposal-Manifest text: at software we offer resembles a decentralized google (- A protocol spec and the rationale behind itn- go-cyber: our implementation using cosmos-sdkn- cyber.page: PoC reference web interfacen- launch-kit: useful tools for launching cosmos-sdk based chainsn- cyberindex: GraphQL middleware for cybern- euler Foundation: mainnet predecessor of cyber Foundation: the DAO, which will handle all the donated ETHn- documentation and various side toolsnnCyber solves the problem of opening up the centralised semantics core of the Internet. It does so by opening up access to evergrowing semantics core taught to it by the users.nnEconomics of the protocol are built around the idea that feedback loops between the number of links and the value of the knowledge graph exist. The more usage => the bigger the knowledge graph => the more value => the better the quality of the knowledge => the more usage. Transaction fees for basic operations are replaced by lifetime bandwidth, which means usability for both, end-users and developers. You can think of Cyber as a shared ASIC for search.nnYou already see that the idea of Cyber evolves around content identifiers and its ranks. From here, welcome to Decentralized Marketing, or DeMa. You've certainly heard of DeFi. DeFi is built around a simple idea that you can use a collateral for something that will be settled based on a provided price feed. Here comes the systematic problem of DeFi: price oracles. DeMa is based on the same idea of using collateral, but the input for settlement can be information regarding the content identifier itself.nnWith the help of DeMa and IBC chains will be able to prove relevance using content identifiers and their ranks one to another. This will help to grow the IBC ecosystem, where each chain has multiple possibilities to exchange data, which is provably valued.nnCosmos was created to become the internet of blockchains. A protocol that propagates the spirit of decentralization and governed by the community. For such technology to succeed, a lot is required. One thing is a solid foundation it can build on. One virtue of such foundation is monetary flow of income that has to feed this machine for as long as it exists.nnA good question that arises is how to turn the community pool into a pool that isn’t (a) a pot of money which goes solely to network security, (b) a pool that isn’t solely a build-up of inflationary rewards and (с) has long term prosperity value (its value rises).nnThe solution to the above problem is to establish a fund, that is managed and processed collectively and consists of a diversified number of assets that can bring long term value to its stakeholders.nnThis means using the funds to support exceptional projects that are building with Tendermint and Cosmos-SDK. After all, is we want to glorify the ecosystem, we need for it to grow. How will it grow? It will have projects with a clear utility, amazing a product and provable distribution. This will attract users, developers and large stakeholders to the ecosystem. Together we already did one very successful investment decision. We all participated in cosmos fundraizer. So let us move the idea forward.nnIf this proposal is successful and stands for more demand from the public, we will open another proposal using the community pool. However, anyone can participate in Game of Links () or Takeoff independently. If you have question you can ask them either on Cyber topic on Cosmos forum () or Cyber forum ( results: ## 27 Stargate Upgrade Proposal 1 @@ -145,7 +145,7 @@ cyber Congress (https://cybercongress.ai) developed Cyber (https://github.com/cy * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -Stargate is our name for the process of ensuring that the widely integrated public network known as the Cosmos Hub is able to execute the cosmoshub-3 -> cosmoshub-4 upgrade with the minimum disruption to its existing ecosystem. This upgrade will also realize the Internet of Blockchains vision from the Cosmos whitepaper.nIntegrations from ecosystem partners are at risk of breaking changes due to the Stargate changes. These changes drive the need for substantial resource and time requirements to ensure successful migration. Stargate represents a unique set of circumstances and is not intended to set precedent for future upgrades which are expected to be less dramatic.nThere is a widespread consensus from many Cosmos stakeholders that these changes to core software components will enhance the performance and composability of the software and the value of the Cosmos Hub in a world of many blockchains.nA Yes result on this proposal provides a clear signal that the Cosmos Hub accepts and understands the Stargate process and is prepared to approve an upgrade with proposed changes if the plan below is executed successfully.nA No result would force a reconsideration of the tradeoffs in the Alternatives section and the forming a new plan to deliver IBC.nSee the full proposal here: https://ipfs.io/ipfs/Qmbo3fF54tX3JdoHZNVLcSBrdkXLie56Vh2u29wLfs4PnW +Stargate is our name for the process of ensuring that the widely integrated public network known as the Cosmos Hub is able to execute the cosmoshub-3 -> cosmoshub-4 upgrade with the minimum disruption to its existing ecosystem. This upgrade will also realize the Internet of Blockchains vision from the Cosmos whitepaper.nIntegrations from ecosystem partners are at risk of breaking changes due to the Stargate changes. These changes drive the need for substantial resource and time requirements to ensure successful migration. Stargate represents a unique set of circumstances and is not intended to set precedent for future upgrades which are expected to be less dramatic.nThere is a widespread consensus from many Cosmos stakeholders that these changes to core software components will enhance the performance and composability of the software and the value of the Cosmos Hub in a world of many blockchains.nA Yes result on this proposal provides a clear signal that the Cosmos Hub accepts and understands the Stargate process and is prepared to approve an upgrade with proposed changes if the plan below is executed successfully.nA No result would force a reconsideration of the tradeoffs in the Alternatives section and the forming a new plan to deliver IBC.nSee the full proposal here: ## 29 Genesis fund recovery proposal on behalf of fundraiser participants unable to access their ATOMs @@ -153,8 +153,7 @@ Stargate is our name for the process of ensuring that the widely integrated publ * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -The purpose of this proposal is to restore access to geneis ATOMs for a subset of donors who have been active participants in our community through the last year.n The view of iqlusion is that this is an important moment for the Cosmos Hub. Stargate brings the fundraiser period to the end with delivery of IBC. This proposal resolves the open business of active members of our community who cannot access their ATOM. This is an opportunity is opporunity to bring this business to a close and setup the agenda for IBC powered innovation comming in 2021.We strongly encourage the Cosmos Community to verify the cryptographic evidence and bring these community members to full ATOM holder status.nnnFull Proposal:https://ipfs.io/ipfs/QmV6pBgDppN7X3BdVW197EUe7dpcmcdLMivPa6xxtPj3aW nThe original authors of the proposal will be available to answer questions on the Cosmos forum.nhttps://forum.cosmos.network/t/updated-genesis-atoms-recovery-request-proposal/3905 - +The purpose of this proposal is to restore access to geneis ATOMs for a subset of donors who have been active participants in our community through the last year.n The view of iqlusion is that this is an important moment for the Cosmos Hub. Stargate brings the fundraiser period to the end with delivery of IBC. This proposal resolves the open business of active members of our community who cannot access their ATOM. This is an opportunity is opporunity to bring this business to a close and setup the agenda for IBC powered innovation comming in 2021.We strongly encourage the Cosmos Community to verify the cryptographic evidence and bring these community members to full ATOM holder status.nnnFull Proposal: nThe original authors of the proposal will be available to answer questions on the Cosmos forum.n ## 31 Governance Split Votes @@ -162,7 +161,7 @@ The purpose of this proposal is to restore access to geneis ATOMs for a subset o * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -In the Cosmos Hub governance system, each address can only cast a vote for one option (Yes/No/Abstain/NoWithVeto) which uses their full voting power behind that choice.nnThis proposal proposes an upgrade to the Cosmos Hub governance module that would allow a staker to optionally split their votes into several voting options. For example, a single address could use 70% of its voting power to vote Yes and 30% of its voting power to vote No. Clients may opt into supporting this feature, as the existing UX of voting for a single option is preserved.nnThis is beneficial because oftentimes the entity owning that address might not be a single individual. For example, a company or organization that owns an address might have different stakeholders who want to vote differently, and so it makes sense to allow them to split their voting power.nnAnother example use case is exchanges and custodians. Many custodians and exchanges custody multiple customers’ ATOMs in the same address and use this address to stake on behalf of them. However, because of this, it makes it infeasible to do 'passthrough voting' and give their customers voting rights over their tokens, if different customers have different voting preferences. With this new proposal, custodians can use split votes to accurately reflect the preferences of their customers in on-chain governance.nnThe technical architecture for this feature can be seen in ADR 037 to the Cosmos SDK: https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-037-gov-split-vote.md nnAcceptance of this governance proposal is signalling approval to adopt this feature in a future upgrade of the Cosmos Hub. +In the Cosmos Hub governance system, each address can only cast a vote for one option (Yes/No/Abstain/NoWithVeto) which uses their full voting power behind that choice.nnThis proposal proposes an upgrade to the Cosmos Hub governance module that would allow a staker to optionally split their votes into several voting options. For example, a single address could use 70% of its voting power to vote Yes and 30% of its voting power to vote No. Clients may opt into supporting this feature, as the existing UX of voting for a single option is preserved.nnThis is beneficial because oftentimes the entity owning that address might not be a single individual. For example, a company or organization that owns an address might have different stakeholders who want to vote differently, and so it makes sense to allow them to split their voting power.nnAnother example use case is exchanges and custodians. Many custodians and exchanges custody multiple customers’ ATOMs in the same address and use this address to stake on behalf of them. However, because of this, it makes it infeasible to do 'passthrough voting' and give their customers voting rights over their tokens, if different customers have different voting preferences. With this new proposal, custodians can use split votes to accurately reflect the preferences of their customers in on-chain governance.nnThe technical architecture for this feature can be seen in ADR 037 to the Cosmos SDK: nnAcceptance of this governance proposal is signalling approval to adopt this feature in a future upgrade of the Cosmos Hub. ## 32 Funding for Development of Governance Split Votes @@ -170,7 +169,7 @@ In the Cosmos Hub governance system, each address can only cast a vote for one o * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.distribution.v1beta1.CommunityPoolSpendProposal -Sikka is requesting 1776 ATOMs from the community pool to architect and implement the Governance Split Votes feature proposed in Cosmos Hub Proposal #31. This community fund proposal is dependent on the passing of Proposal #31 and thus should only be approved if Proposal #31 is approved. We request 1776 ATOMs, valuing each atom at $5.1 nnSikka has already begun the design of this feature and submitted it as ADR 037 to the Cosmos Hub: https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-037-gov-split-vote.md nn As past contributors to the codebase that runs the Cosmos Hub, we are familiar with the security and code quality requirements to be included in the Cosmos Hub. Sikka will implement & test this feature and will work with the maintainers of the github.com/cosmos/cosmos-sdk repo to get it merged into the x/gov module. +Sikka is requesting 1776 ATOMs from the community pool to architect and implement the Governance Split Votes feature proposed in Cosmos Hub Proposal #31. This community fund proposal is dependent on the passing of Proposal #31 and thus should only be approved if Proposal #31 is approved. We request 1776 ATOMs, valuing each atom at $5.1 nnSikka has already begun the design of this feature and submitted it as ADR 037 to the Cosmos Hub: nn As past contributors to the codebase that runs the Cosmos Hub, we are familiar with the security and code quality requirements to be included in the Cosmos Hub. Sikka will implement & test this feature and will work with the maintainers of the github.com/cosmos/cosmos-sdk repo to get it merged into the x/gov module. ## 34 Luna Mission - Funding $ATOM @@ -178,15 +177,15 @@ Sikka is requesting 1776 ATOMs from the community pool to architect and implemen * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.distribution.v1beta1.CommunityPoolSpendProposal -The Cosmos Hub (ATOM) community is requesting a community pool spend amount of 129,208 ATOM in order to implement a comprehensive ATOM marketing plan that will be executed in collaboration with AiB (Tendermint). The marketing efforts will be initiated immediately upon passing of proposal #34.nn The distribution of funds will be administered by 5 community members, that have been carefully selected by the community via the Cosmos governance working group to administer the marketing plan and release funds to either AiB that will act as a liaison between Cosmos Hub community and third parties or directly to parties that will be in charge of executing the marketing plan based on a majority multisignature approval. At least 3 members will have to approve each milestone-spend for it to be released to AiB based on the expected proposal scope &completion. nn More details can be found in the long form proposal here: https://cloudflare-ipfs.com/ipfs/QmWAxtxf7fUprPVWx1jWyxSKjBNqkcbA3FG6hRps7QTu3k and https://github.com/cosmos/governance/pull/10 and https://forum.cosmos.network/t/draft-governance-proposal-for-a-community-pool-spend-proposal-33-luna-mission-funding-atom/4244/15 nn The multisig administration includes: n @johnniecosmos, @JoeDirtay, @jackzampolin (Jack Zampolin, Pylon Validator), @immasssi (SG-1 Validator), @zakimanian (Zaki Manian, Iqlusion Validator). +The Cosmos Hub (ATOM) community is requesting a community pool spend amount of 129,208 ATOM in order to implement a comprehensive ATOM marketing plan that will be executed in collaboration with AiB (Tendermint). The marketing efforts will be initiated immediately upon passing of proposal #34.nn The distribution of funds will be administered by 5 community members, that have been carefully selected by the community via the Cosmos governance working group to administer the marketing plan and release funds to either AiB that will act as a liaison between Cosmos Hub community and third parties or directly to parties that will be in charge of executing the marketing plan based on a majority multisignature approval. At least 3 members will have to approve each milestone-spend for it to be released to AiB based on the expected proposal scope &completion. nn More details can be found in the long form proposal here: and and nn The multisig administration includes: n @johnniecosmos, @JoeDirtay, @jackzampolin (Jack Zampolin, Pylon Validator), @immasssi (SG-1 Validator), @zakimanian (Zaki Manian, Iqlusion Validator). -## 35 Cosmos Stargate Hub Upgrade Proposal 2: Time to Upgrade. +## 35 Cosmos Stargate Hub Upgrade Proposal 2: Time to Upgrade * **Submitted:** 2021-01-12T01:37:07.471992293Z * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -Proposal to complete the Stargate upgrade, halt `cosmoshub-3` at 06:00 UTC on Jan 28th, export the state and start `cosmoshub-4` based on gaia 3.0.nn Gaia Commit hash: n d974b27a8caf8cad3b06fbe4678871e4b0b69a51 Proposal details can be found on n github: https://github.com/cosmos/governance/pull/5 n ipfs: https://cloudflare-ipfs.com/ipfs/QmPww2PSmkmuLLu12GGwRdu5ur1Etf9u3Nt3Z6NqB7BQP1 n sia: https://siasky.net/EAALGMzFCafvbKkQjnAieo2cA1mpxk-JLpKsiC4XxuM6eQ +Proposal to complete the Stargate upgrade, halt `cosmoshub-3` at 06:00 UTC on Jan 28th, export the state and start `cosmoshub-4` based on gaia 3.0.nn Gaia Commit hash: n d974b27a8caf8cad3b06fbe4678871e4b0b69a51 Proposal details can be found on n github: n ipfs: n sia: ## 36 Delay of Hub Stargate Upgrade for approximately 2 weeks @@ -194,14 +193,14 @@ Proposal to complete the Stargate upgrade, halt `cosmoshub-3` at 06:00 UTC on Ja * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -The Stargate team is recommending that the Cosmos Hub reschedule the next upgrade to a new commit hash. The new commit hash is expected to be available on Tuesday Jan 26th with a new upgrade proposal immediately after.nnThis governance proposal will signal that [proposal 35](https://www.mintscan.io/cosmos/proposals/35) will not be executed. The Hub governance will vote on the forthcoming proposal aiming for a final upgrade. The earliest target date would be February 11th. Given that Lunar New Year is on Feb 12th. The next best date is Feb 18th 06:00UTC.nnWe are recommending the delay for the following reasons.nn* Bugs have been identified in the Proposal 29 implementation. They are resolved in this pull request[Additional review of prop 29 and migration testing by zmanian · Pull Request #559 · cosmos/gaia · GitHub](https://github.com/cosmos/gaia/pull/559)n* A balance validation regression was identified during Prop 29 code review. [x/bank: balance and metadata validation by fedekunze · Pull Request #8417 · cosmos/cosmos-sdk · GitHub](https://github.com/cosmos/cosmos-sdk/pull/8417)n* The IBC Go To Market Working Group has [identified Ledger hardware wallet](https://github.com/cosmos/cosmos-sdk/issues/8266) support as a necessary feature for the initial launch of IBC on the Hub. We have an opportunity to provide this support in this upgrade. The SDK believes this can be quickly remediated in the time available with merged PRs on Monday.n* The number of Stargate related support requests from integrators has increased significantly since the governance proposal went live but some teams have already announced a period of reduced $ATOM support while they upgrade like . The additional time should minimize the disruption for $ATOM holders. Thank so much to the $IRIS team whom is fielding a similar request volume among our non-English community. +The Stargate team is recommending that the Cosmos Hub reschedule the next upgrade to a new commit hash. The new commit hash is expected to be available on Tuesday Jan 26th with a new upgrade proposal immediately after.nnThis governance proposal will signal that [proposal 35](https://www.mintscan.io/cosmos/proposals/35) will not be executed. The Hub governance will vote on the forthcoming proposal aiming for a final upgrade. The earliest target date would be February 11th. Given that Lunar New Year is on Feb 12th. The next best date is Feb 18th 06:00UTC.nnWe are recommending the delay for the following reasons.nn*Bugs have been identified in the Proposal 29 implementation. They are resolved in this pull request[Additional review of prop 29 and migration testing by zmanian · Pull Request #559 · cosmos/gaia · GitHub](https://github.com/cosmos/gaia/pull/559)n* A balance validation regression was identified during Prop 29 code review. [x/bank: balance and metadata validation by fedekunze · Pull Request #8417 · cosmos/cosmos-sdk · GitHub](https://github.com/cosmos/cosmos-sdk/pull/8417)n*The IBC Go To Market Working Group has [identified Ledger hardware wallet](https://github.com/cosmos/cosmos-sdk/issues/8266) support as a necessary feature for the initial launch of IBC on the Hub. We have an opportunity to provide this support in this upgrade. The SDK believes this can be quickly remediated in the time available with merged PRs on Monday.n* The number of Stargate related support requests from integrators has increased significantly since the governance proposal went live but some teams have already announced a period of reduced $ATOM support while they upgrade like . The additional time should minimize the disruption for $ATOM holders. Thank so much to the $IRIS team whom is fielding a similar request volume among our non-English community. -## 37 Stargate Upgrade- Second time is a charm! +## 37 Stargate Upgrade- Second time is a charm * **Submitted:** 2021-01-28T21:07:30.044676129Z * **Status:** PROPOSAL_STATUS_PASSED * **Type:** /cosmos.gov.v1beta1.TextProposal -Proposal to complete the Stargate upgrade, halt `cosmoshub-3` at 06:00 UTC on Feb 18th, export the state and start `cosmoshub-4` based on gaia 4.0.nn Gaia Commit hash: n a279d091c6f66f8a91c87943139ebaecdd84f689 Proposal details can be found on n github: https://github.com/cosmos/governance/pull/13 n Rendered: https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/QmYn2SxCMYk5SWs5GMcXdbXR8wMCCXRmCyW19SFyzSeZp1 n ipfs: https://cloudflare-ipfs.com/ipfs/QmYn2SxCMYk5SWs5GMcXdbXR8wMCCXRmCyW19SFyzSeZp1 n sia: https://siasky.net/EACAsPcUjpTEpQlG9_nRI1OR07gNeRiudfEWAvKnf0tj_Q n +Proposal to complete the Stargate upgrade, halt `cosmoshub-3` at 06:00 UTC on Feb 18th, export the state and start `cosmoshub-4` based on gaia 4.0.nn Gaia Commit hash: n a279d091c6f66f8a91c87943139ebaecdd84f689 Proposal details can be found on n github: n Rendered: n ipfs: n sia: n diff --git a/docs/governance/proposals/proposal-template.md b/docs/governance/proposals/proposal-template.md index c1ac0d376f2..6c9f1636ba1 100644 --- a/docs/governance/proposals/proposal-template.md +++ b/docs/governance/proposals/proposal-template.md @@ -4,11 +4,11 @@ - {date}: {changelog} -## Authors and Credit +## Authors and Credit {Name}: {link e.g., github, discord, twitter} -## Status +## Status {DRAFT | PROPOSED} @@ -20,13 +20,13 @@ ## Context -> A complete, yet brief account of the current sitation the proposal aims to address. It should clear explain the motivation, goals, and expected outcomes of the proposal as well as how the proposal addresses the situation better than other options. +> A complete, yet brief account of the current sitation the proposal aims to address. It should clear explain the motivation, goals, and expected outcomes of the proposal as well as how the proposal addresses the situation better than other options. ## Governance Votes The following items summarize the voting options and what it means for this proposal. -- **YES**: You approve the {type} proposal to...{one sentence summary}. +- **YES**: You approve the {type} proposal to...{one sentence summary}. - **NO**: You disapprove of the proposal in its current form. The NO vote can be a request for improvements or adjustments, please indicated them in the relevant topic in the [Cosmos forum](https://forum.cosmos.network/). You agree that this proposal's motivation is valuable and that the team should create a follow-up proposal once the amendments are included. - **NO (VETO)**: You veto the entire motivation for the proposal, are strongly opposed to its implementation, and will exit the network if passed. You are signalling the proposers should not create a follow-up proposal. - **ABSTAIN**: You are impartial to the outcome of the proposal. @@ -35,8 +35,6 @@ The following items summarize the voting options and what it means for this prop ## Conclusion - - ## References - {reference link} diff --git a/docs/governance/state-of-cosmos-governance-2021.md b/docs/governance/state-of-cosmos-governance-2021.md index afe72698746..134098762be 100644 --- a/docs/governance/state-of-cosmos-governance-2021.md +++ b/docs/governance/state-of-cosmos-governance-2021.md @@ -13,7 +13,7 @@ Reviewing existing governance documentation and discussion, a few key themes sur ### Emphasis on Self-governance and Sovereignty -On-chain governance standardizes forms of coordination but leaves many governance decisions to each application-specific blockchain or zone. Sunny Aggarwal [uses the analogy](https://blog.cosmos.network/deep-dive-how-will-ibc-create-value-for-the-cosmos-hub-eedefb83c7a0) that IBC as a form of standardization allows for "economic integration without political integration." Sunny also [talks about](https://www.youtube.com/watch?v=LApEkXJR_0M) how governance controlled by a community that shares culture and trust can "achieve greater security than economic incentives alone." For example, the Regen Network has a [governance model](https://medium.com/regen-network/community-stake-governance-model-b949bcb1eca3) that identifies multiple constituencies that require representation in governance. This allows diverse chains to exchange value while retaining the ability to self-govern. +On-chain governance standardizes forms of coordination but leaves many governance decisions to each application-specific blockchain or zone. Sunny Aggarwal [uses the analogy](https://blog.cosmos.network/deep-dive-how-will-ibc-create-value-for-the-cosmos-hub-eedefb83c7a0) that IBC as a form of standardization allows for "economic integration without political integration." Sunny also [talks about](https://www.youtube.com/watch?v=LApEkXJR_0M) how governance controlled by a community that shares culture and trust can "achieve greater security than economic incentives alone." For example, the Regen Network has a [governance model](https://medium.com/regen-network/community-stake-governance-model-b949bcb1eca3) that identifies multiple constituencies that require representation in governance. This allows diverse chains to exchange value while retaining the ability to self-govern. ### Flexibility through On-chain Parameters @@ -23,7 +23,6 @@ Each blockchain in the Cosmos ecosystem can be tailored to a specific applicatio The existing [governance module](https://docs.cosmos.network/main/modules/gov) is described as a minimum viable product for the governance module, with [ideas for future improvement](https://docs.cosmos.network/main/modules/gov#future-improvements) . For example an active product team is currently aligning [groups and governance functionality](https://docs.google.com/document/d/1w-fwa8i8kkgirbn9DOFklHwcu9xO_IdbMN910ASr2oQ/edit#) will change current governance practices and open up new avenues to explore and support through on- and off- chain processes - ## On- and off-chain Governance Structure ### Communication @@ -31,7 +30,7 @@ The existing [governance module](https://docs.cosmos.network/main/modules/gov) Governance practices and decisions are communicated through different types of documents and design artefacts: - On-chain governance [proposals](https://cosmoscan.net/governance-stats) -- Decision records +- Decision records - Cosmos Improvement Proposals ([CIPs](https://cips.cosmos.network/)) - Cosmos SDK's [ADRs](https://docs.cosmos.network/main/architecture/) - Tendermint's [ADRs](https://github.com/tendermint/tendermint/tree/master/docs/architecture) @@ -50,24 +49,24 @@ Venues involve community members to different degrees and individuals often perf - **[All in Bits Cosmos Forum](http://forum.cosmos.network/)** - For long form discussion. Cosmos core developers have an active presence (e.g., Ethan, Zaki, Sunny) - Cosmos Hub governance topics and proposals have a governance tag and usually get the most activity and substantive feedback, especially from validators (e.g., [direct conversations](https://forum.cosmos.network/t/proposal-are-validators-charging-0-commission-harmful-to-the-success-of-the-cosmos-hub/2505/8), ones that [spin out](https://forum.cosmos.network/t/on-the-interrelationship-between-the-security-budget-and-the-business-prospects-of-the-cosmos-network/2547) of proposals, and [meta discussions on process](https://forum.cosmos.network/t/streamline-the-gov-process/3997)) - - Developing and sharing of opinion pieces, light papers, hot takes etc., also happens on the forum (e.g., [Where I see the Cosmos at Present](https://forum.cosmos.network/t/where-i-see-cosmos-at-present/5022)) + - Developing and sharing of opinion pieces, light papers, hot takes etc., also happens on the forum (e.g., [Where I see the Cosmos at Present](https://forum.cosmos.network/t/where-i-see-cosmos-at-present/5022)) - [Chinese language discussion](https://forum.cosmos.network/c/chinese/9) is one of the largest categories with 269 posts - - There are still some old links to [Matrix chat](https://riot.im/app/#/room/#cosmos_validators:matrix.org), which has been deprecated + - There are still some old links to [Matrix chat](https://riot.im/app/#/room/#cosmos_validators:matrix.org), which has been deprecated - **[/r/cosmonetwork Subreddit](http://reddit.com/r/cosmosnetwork)** - Venue primarily for ATOM holders to discuss ATOM and other ecosystem coins - - Discussion topics mostly about investing in the ecosystem and include: [investment theses](https://www.reddit.com/r/cosmosnetwork/comments/o38psh/i_think_atom_is_undervalued/), where to buy tokens, wallets to use, how to stake, and more recently, how to get involved with DeFi in the ecosystem (e.g., with Osmosis) + - Discussion topics mostly about investing in the ecosystem and include: [investment theses](https://www.reddit.com/r/cosmosnetwork/comments/o38psh/i_think_atom_is_undervalued/), where to buy tokens, wallets to use, how to stake, and more recently, how to get involved with DeFi in the ecosystem (e.g., with Osmosis) - Community managers use it for announcements (e.g., catdotfish) - **[Cosmos Community Discord](https://discord.gg/W8trcGV)** - - For ecosystem cross-pollination with an active developer presence. Older Riot chats have moved here. + - For ecosystem cross-pollination with an active developer presence. Older Riot chats have moved here. - `#validator-verified` channel for example discussing proposals, upgrades etc. - - Major ecosystem chains all have a presence here, cross-validator convo, artefacts like: [Citadel.one Validator Constitution](https://drive.google.com/file/d/1wDTqro208y_1q3zF6rt39QjwYkcvVd7P/view) + - Major ecosystem chains all have a presence here, cross-validator convo, artefacts like: [Citadel.one Validator Constitution](https://drive.google.com/file/d/1wDTqro208y_1q3zF6rt39QjwYkcvVd7P/view) - **Cosmos Hub Discord (semi-private)** - For [core development teams](https://cosmos.network/learn/faq/who-is-building-cosmos/) to have multi-team discussions that are mature - Internal org channels (e.g., Interchain Slack) and slack-connect (private) - For internal team coordinating, 1-1s between specific core development teams, multi-team discussions that are early stage, have private or strategic team info too early to share out - **[Telegram (Governance Working Group)](https://t.me/hubgov)** - For coordinating a working group that: "develops decentralized community governance efforts alongside the Hub's governance development." - - Working Group came out of [a community pool proposal](https://www.figment.io/resources/introducing-the-cosmos-governance-working-group). + - Working Group came out of [a community pool proposal](https://www.figment.io/resources/introducing-the-cosmos-governance-working-group). - Some interest in deprecating but remains actives - **GitHub repositories** for governance processes ([Cosmos governance](https://github.com/cosmos/governance), [Cosmos cips](https://github.com/cosmos/cips), [Cosmos ibc](https://github.com/cosmos/ibc)) - For discussing meta aspects of governance processes, discussion and development of specific off-chain design records and technical specs, and repository for on-chain proposals @@ -88,7 +87,7 @@ What roles can each stakeholder take up in current governance? **Active Participant (P)** - Regularly providing input or helping to move governance decisions forward, but does not drive them or necessarily initiate **Governance Proposer (I)** - Initiates a proposal for updating Cosmos Hub governance **Decision Maker (DM)** - Can vote or be part of the final governance decision -**Process Owner (PO)** - Owns the creation, refinement, and execution of the governance mechanism +**Process Owner (PO)** - Owns the creation, refinement, and execution of the governance mechanism | **Role** | **Cosmos Hub
On-chain** | **CIPs** | **Cosmos SDK
ADRs** | **Tendermint
RFCs** | **ICSs** | |---|:-:|:-:|:-:|:-:|:-:| @@ -102,10 +101,9 @@ What roles can each stakeholder take up in current governance? | Cosmos Integrators (wallets,
exchanges, services) | DM | P | ? | ? | ? | | Other zones and hubs members | DM | P? | P? | P? | P? | - #### Role Ability to Govern -What aspects of the Cosmos ecosystem does each role have the ability to govern? +What aspects of the Cosmos ecosystem does each role have the ability to govern? | **Role** | **Cosmos Hub
Blockchain
(through on-chain proposals)** | **Cosmos Hub
Community Pool (treasury)** | **Cosmos Hub On-chain
governance processes** | **Cosmos
Ecosystem Tech Decision Records, Specs, Standards Development** | **Cosmos Ecosystem
Off-chain governance processes** | |---|:-:|:-:|:-:|:-:|:-:| @@ -187,7 +185,7 @@ On-chain governance on the hub is implemented in Gaia using the x/gov module in Participants in the process include: - The proposal creator: develops the proposal, solicits feedback, submits and socializes the on-chain proposal -- Validators: vote on behalf of delegators. Voting power of validators is equivalent to total ATOMS delegated to them. There are currently 125 active validators in the validator set, updated from 100 validators through governance [proposal #10](https://cosmoscan.net/proposal/10). +- Validators: vote on behalf of delegators. Voting power of validators is equivalent to total ATOMS delegated to them. There are currently 125 active validators in the validator set, updated from 100 validators through governance [proposal #10](https://cosmoscan.net/proposal/10). - Delegators: can cast their own vote, otherwise they inherit the vote of their delegates ### Process owners @@ -199,7 +197,6 @@ Participants in the process include: - 37 proposals that have been voted on so far. The latest proposal as of July 2nd, 2021 is proposal ID #51 (proposals that don't meet minimum deposit don't count towards the 37) - [Cosmoscan's governance charts](https://cosmoscan.net/governance-charts) provide insight on turnout and voter activity. [Mintscan](https://www.mintscan.io/cosmos/proposals) can be used to fill in any gaps. - ## Cosmos Improvement Proposals (CIPs) CIPs serve as the process for describing major changes or providing info about the protocol and APIs or processes of the Cosmos ecosystem. @@ -209,25 +206,22 @@ CIPs serve as the process for describing major changes or providing info about t "This CIP process aims to subsume, but not necessarily to replace" the RFC and ADR processes. 🔗 -### User Story: Governing Technical Direction +### User Story: Governing Technical Direction Alice, a member of one core development team, submits a PR to the Cosmos cips repo after a recurring issue is identified in the standing GAIA / ATOM call. There has been a recurring discussion about how to formalize emerging agreement on a distinctive Cosmos interpretation of a technical feature common to blockchains. There are existing prior specifications in the bitcoin ecosystem that were the direct inspiration for Cosmos development, but over time the core development teams have developed a contrasting understanding of how their implementation provides a pathway to future specification development. At the end of last call, Alice decides this was important enough to step forward and take a first pass at drafting the spec based on the current roadmap. Alice follows the template from the repo to draft an early CIP and updates the frontmatter of the file to indicate the status is "draft." Once the PR is submitted, Alice pings a few developers who mentioned they would provide feedback in Discord and Slack bridge channels. The developers review the PR and leave inline comments and suggestions. Alice incorporates this feedback and requests the CIP be discussed at the next GAIA / ATOM call. In the meantime, Alice solicits community feedback on the PR, sharing it to the Cosmos Hub Discord and a relevant Slack connect channel. Once again Alice is asked to make minor changes, which are completed before the PR is finalized, the cip status is updated to "living" and it is merged by the cips repo owner. - ### Process overview ![Diagram of standarization process for CIPS](https://github.com/cosmos/cips/raw/main/assets/cip-1/CIP-process.png) - Ideas are ideally socialized first: "It is thus recommended to open a discussion thread on the Cosmos forum to do this, but you can also use the Cosmos Discord, the Cosmos subreddit or the Issues section of this repository." If the author decides to proceed, CIPs are drafted and submitted using the [cosmos/cips](https://github.com/cosmos/cips/) GitHub repo. - When a CIP reaches the "Final" state, it represents a completed standard that is ready to be adopted. -- CIPs do not represent the views of the wider Cosmos community. CIP-1 states that "finalization of a CIP does not equate to acceptance into Cosmos. For that, CIP authors must turn to Cosmos Governance." +- CIPs do not represent the views of the wider Cosmos community. CIP-1 states that "finalization of a CIP does not equate to acceptance into Cosmos. For that, CIP authors must turn to Cosmos Governance." - Not all CIPS are taken through an on-chain vote - A situation where CIPs interact with Cosmos Governance is while coordinating a software upgrade among validators. [CIP-5](https://github.com/cosmos/cips/blob/17a9ffc1cc40933ea3cf4460849ae713e6c244e3/CIPS/cip-5.md) [PR not merged], which offers guidelines for new modules to be integrated into Cosmos Hub ensuring safety and robustness, states "motivated by decentralization and the Cosmos community's decisions, a module's code is activated by submitting a parameter change proposal." - - ### Process owners CIP editor: Ethan Buchman ([@ebuchman](https://github.com/ebuchman)) @@ -236,7 +230,6 @@ CIP editor: Ethan Buchman ([@ebuchman](https://github.com/ebuchman)) - There are 12 CIPs proposed to date, none are living, have been finalized, or taken through the on-chain governance process to be widely adopted. - ## Cosmos SDK Architecture Decision Records (ADR) ADRs serve as the main way to propose new feature designs, new processes, and to document design decisions for the Cosmos SDK. @@ -247,15 +240,16 @@ ADRs serve as the main way to propose new feature designs, new processes, and to ### Process overview -- Ideas are socialized on GitHub first: "Every proposal SHOULD start with a new GitHub Issue or be a result of existing Issues. The Issue should contain just a brief proposal summary. Once the motivation is validated, a GitHub Pull Request (PR) is created" +- Ideas are socialized on GitHub first: "Every proposal SHOULD start with a new GitHub Issue or be a result of existing Issues. The Issue should contain just a brief proposal summary. Once the motivation is validated, a GitHub Pull Request (PR) is created" - If the author decides to proceed, ADRs are drafted and submitted using the [cosmos/cosmos-sdk](https://github.com/cosmos/cosmos-sdk/tree/master/docs/architecture) GitHub repo. - 1. Copy the adr-template.md file. Use the following filename pattern: adr-next_number-title.md - 1. Create a draft Pull Request if you want to get an early feedback. - 1. Make sure the context and a solution is clear and well documented. - 1. Add an entry to a list in the [README](https://docs.cosmos.network/main/architecture/) file. - 1. Create a Pull Request to propose a new ADR. + 1. Copy the adr-template.md file. Use the following filename pattern: adr-next_number-title.md + 1. Create a draft Pull Request if you want to get an early feedback. + 1. Make sure the context and a solution is clear and well documented. + 1. Add an entry to a list in the [README](https://docs.cosmos.network/main/architecture/) file. + 1. Create a Pull Request to propose a new ADR. `` - ADRs go through a lifecycle: + ``` DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEEDED by ADR-xxx @@ -276,7 +270,6 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEEDED - A bunch have passed, many are proposed: - ## Tendermint Request for Comments (RFC) RFCs are ways to both investigate and develop an idea prior to formalizing for inclusion in the Tendermint Spec, they also describe proposals to change the spec. @@ -299,8 +292,7 @@ RFCs are ways to both investigate and develop an idea prior to formalizing for i - 5 RFCs have been merged to the repo with an active pull request for adding one more - -## Interchain Standards (ICS) +## Interchain Standards (ICS) ICSs are standards that document a particular protocol, standard, or feature of use to the Cosmos Ecosystem. @@ -330,7 +322,6 @@ ICSs are standards that document a particular protocol, standard, or feature of - 16 have been merged into the repo with at least one more under active discussion: - --- ## Observations and Discussion @@ -342,7 +333,7 @@ This report provides a descriptive account of the existing governance documentat - UX limits who can create and vote for proposals, currently requiring the use of the CLI. If Cosmos Hub sees [itself as a port city](https://blog.cosmos.network/the-cosmos-hub-is-a-port-city-5b7f2d28debf), offering the best possible services, there is an argument to be made that it should extend that commitment to governance to ensure a diverse range of city dwellers and visitors can participate. - Some validators feel that active participation in governance is a bottleneck to setting up validator businesses. I.e., that there are already a number of proposals they are asked to vote on. - Cosmos Hub governance documentation is out of date, challenging to maintain, and difficult to discover. Current governance documentation is in the [`governance` repo as markdown](https://github.com/cosmos/governance), the [`gaia` documentation as vuepress](https://hub.cosmos.network/main/), and [`cosmos-sdk` documentation as vuepress](https://docs.cosmos.network/). -- Assessing this and making improvements is work that Hypha is currently undertaking, but there can be ongoing improvements +- Assessing this and making improvements is work that Hypha is currently undertaking, but there can be ongoing improvements - The [upcoming x/gov and x/group alignment](https://docs.google.com/document/d/1w-fwa8i8kkgirbn9DOFklHwcu9xO_IdbMN910ASr2oQ/edit#) will allow for permissions related to governance to be delegated to other groups, opening up possibilities for multi-stakeholder governance approaches and products (see [related links](https://linktr.ee/cosmos_gov)). ### Off-chain processes diff --git a/docs/governance/submitting.md b/docs/governance/submitting.md index 9984c81384d..e97e5a8f5c3 100644 --- a/docs/governance/submitting.md +++ b/docs/governance/submitting.md @@ -10,7 +10,6 @@ If you have a final draft of your proposal ready to submit, you may want to push 2. [Formatting the JSON file](#formatting-the-json-file-for-the-governance-proposal) for the governance proposal transaction that will be on-chain 3. [Sending the transaction](#sending-the-transaction-that-submits-your-governance-proposal) that submits your governance proposal on-chain - ## Hosting supplementary materials In general we try to minimize the amount of data pushed to the blockchain. @@ -24,15 +23,15 @@ can upload it to the IPFS network: 2. using a service such as [https://pinata.cloud](https://pinata.cloud) -Ensure that you "pin" the file so that it continues to be available on the network. You should get a URL like this: https://ipfs.io/ipfs/QmbkQNtCAdR1CNbFE8ujub2jcpwUcmSRpSCg8gVWrTHSWD +Ensure that you "pin" the file so that it continues to be available on the network. You should get a URL like this: The value QmbkQNtCAdR1CNbFE8ujub2jcpwUcmSRpSCg8gVWrTHSWD is called the `CID` of your file - it is effectively the file's hash. If you uploaded a markdown file, you can use the IPFS markdown viewer to render the document for better viewing. Links for the markdown viewer look like -`https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/`, where `` is your CID. For instance the link above would be: -https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/QmbkQNtCAdR1CNbFE8ujub2jcpwUcmSRpSCg8gVWrTHSWD +`https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/`, where `` is your CID. For instance the link above would be: + Share the URL with others and verify that your file is publicly accessible. @@ -53,7 +52,6 @@ Once on-chain, most people will rely upon network explorers to interpret this in **Note**: In future, this formatting [may be changed to be more standardized](https://github.com/cosmos/cosmos-sdk/issues/5783) with other the types of governance proposals. - ## Sending the transaction that submits your governance proposal For information on how to use gaiad (the command line interface) to submit an on-chain proposal through the governance module, please refer to the [gaiad resource](../hub-tutorials/gaiad.md) for the Cosmos Hub documentation. @@ -104,6 +102,7 @@ After posting your transaction, your command line interface (gaiad) will provide ### Troubleshooting a failed transaction There are a number of reasons why a transaction may fail. Here are two examples: + 1. **Running out of gas** - The more data there is in a transaction, the more gas it will need to be processed. If you don't specify enough gas, the transaction will fail. 2. **Incorrect denomination** - You may have specified an amount in 'utom' or 'atom' instead of 'uatom', causing the transaction to fail. @@ -111,6 +110,7 @@ There are a number of reasons why a transaction may fail. Here are two examples: If you encounter a problem, try to troubleshoot it first, and then ask for help on the Cosmos Hub forum: [https://forum.cosmos.network](https://forum.cosmos.network/c/hub-proposals/25). We can learn from failed attempts and use them to improve upon this guide. ### Depositing funds after a proposal has been submitted + Sometimes a proposal is submitted without having the minimum token amount deposited yet. In these cases you would want to be able to deposit more tokens to get the proposal into the voting stage. In order to deposit tokens, you'll need to know what your proposal ID is after you've submitted your proposal. You can query all proposals by the following command: ``` @@ -135,12 +135,14 @@ The `` is written as `500000uatom`, just like the example above. ### Submitting your proposal to the testnet You may want to submit your proposal to the testnet chain before the mainnet for a number of reasons: + 1. To see what the proposal description will look like 2. To signal that your proposal is about to go live on the mainnet 3. To share what the proposal will look like in advance with stakeholders 4. To test the functionality of the governance features Submitting your proposal to the testnet increases the likelihood that you will discover a flaw before deploying your proposal on mainnet. A few things to keep in mind: + - you'll need testnet tokens for your proposal (ask around for a faucet) - the parameters for testnet proposals are different (eg. voting period timing, deposit amount, deposit denomination) - the deposit denomination is in 'muon' instead of 'uatom' diff --git a/docs/gtm-interchain.md b/docs/gtm-interchain.md index 56c496798a1..2f908340629 100644 --- a/docs/gtm-interchain.md +++ b/docs/gtm-interchain.md @@ -8,7 +8,7 @@ This is an evolving document and process. Please feel free to contribute where y These discussions will take place during weekly Gaia team calls. The Hub will determine the value proposition of IBC and how it is integrated into Gaia and how it will serve the larger ecosystem of interconnected blockchains. These discussions will continue to take place with key stakeholders during the bi-weekly Cosmos multi entity call. Importantly, the purpose of the bi-weekly multi entity call will be to consider all technical aspects of IBC launch from a strategic perspective (outlined in 'What's Needed to Successfully Go to Market?'). This will inform the agenda. -Leading up to Stargate, IBC Development was led by Chris Goes (Interchain Berlin), while Gaia did not have a maintainer. Go-to-market for Stargate was led by Zaki (Iqlusion). Moving forward, we are aiming to organize Cosmos Hub leadership under Shahan Khatchadourian (Interchain Berlin) and go-to-market led by Jelena Djuric (Informal Systems). Both Shahan and Jelena are being onboarded into these roles with the support of previous leads. +Leading up to Stargate, IBC Development was led by Chris Goes (Interchain Berlin), while Gaia did not have a maintainer. Go-to-market for Stargate was led by Zaki (Iqlusion). Moving forward, we are aiming to organize Cosmos Hub leadership under Shahan Khatchadourian (Interchain Berlin) and go-to-market led by Jelena Djuric (Informal Systems). Both Shahan and Jelena are being onboarded into these roles with the support of previous leads. Execution and completion will be tracked via a meta-project dashboard ([Gaia Roadmap](https://github.com/cosmos/gaia/projects/6)) that incorporates the high level objectives for each phase roll out. Each phase (i.e. Phase 1 - Accounts UX, Phase 2 - Interchain Interchange, etc) will have their own project dashboard that will link to the repos, issues, PRs, etc, where development is taking place. @@ -29,12 +29,12 @@ In sum, project management will focus on surfacing issues, dependencies, relativ The user is paramount. For Gaia and IBC, we see the users being: - - ATOM holders - - Existing zones - - New zones - - Validators on hub and zones - - Nodes on hub and zones - - Other service providers on hubs and zones (wallets, explorers, exchanges, etc.) +- ATOM holders +- Existing zones +- New zones +- Validators on hub and zones +- Nodes on hub and zones +- Other service providers on hubs and zones (wallets, explorers, exchanges, etc.) We will also want to be tracking outreach to the relevant users per phase to ensure that Hub utility (and IBC where appropriate) are being validated. Spotlights on experiments will continue to validate the utility of the Hub and IBC (i.e. bridge to Ethereum, AMM, etc). We will also be conducting continous outbound outreach to look for partners that are aligned with the interchain mission. diff --git a/docs/hub-overview/overview.md b/docs/hub-overview/overview.md index 31181da4d39..a1b9456a102 100644 --- a/docs/hub-overview/overview.md +++ b/docs/hub-overview/overview.md @@ -39,7 +39,6 @@ These community-maintained web and mobile wallets allow you to store & transfer * [Trust Wallet](https://trustwallet.com/) Android, iOS * [Wetez](https://www.wetez.io/pc/homepage) - Android, iOS - ## Cosmos Hub Explorers These block explorers allow you to search, view and analyze Cosmos Hub data—like blocks, transactions, validators, etc. @@ -58,7 +57,6 @@ These block explorers allow you to search, view and analyze Cosmos Hub data&mdas * [Stargazer](https://stargazer.certus.one) * [Union Market](https://union.market/token/cosmos) - ## Cosmos Hub CLI `gaiad` is a command-line interface that lets you interact with the Cosmos Hub. `gaiad` is the only tool that supports 100% of the Cosmos Hub features, including accounts, transfers, delegation, and governance. Learn more about `gaiad` with the [delegator's CLI guide](../delegators/delegator-guide-cli.md). diff --git a/docs/hub-tutorials/gaiad.md b/docs/hub-tutorials/gaiad.md index 371948e40c6..e15d84c8a52 100644 --- a/docs/hub-tutorials/gaiad.md +++ b/docs/hub-tutorials/gaiad.md @@ -60,7 +60,7 @@ There are three types of key representations that are used: - Used to receive funds - e.g. `cosmos15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc` -* `cosmosvaloper` +- `cosmosvaloper` - Used to associate a validator to it's operator - Used to invoke staking commands - e.g. `cosmosvaloper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah` diff --git a/docs/hub-tutorials/join-mainnet.md b/docs/hub-tutorials/join-mainnet.md index 9713a69a725..4859e61220c 100644 --- a/docs/hub-tutorials/join-mainnet.md +++ b/docs/hub-tutorials/join-mainnet.md @@ -9,7 +9,6 @@ The current Cosmos Hub mainnet, `cosmoshub-4`, has been performing in place stor **This guide includes full instructions for joining the mainnet either as an archive/full node or a pruned node.** - For instructions to boostrap a node via Quicksync or State Sync, see the [Quickstart Guide](https://hub.cosmos.network/main/getting-started/quickstart.html) For instructions to join as a validator, please also see the [Validator Guide](https://hub.cosmos.network/main/validators/overview.html#). @@ -20,17 +19,17 @@ For instructions to join as a validator, please also see the [Validator Guide](h - [Getting Started](#getting-started) - [Hardware Requirements](#hardware) - [General Configuration](#general-configuration) - - [Initialize Chain](#initialize-chain) - - [Genesis File](#genesis-file) - - [Seeds & Peers](#seeds-amp-peers) - - [Gas & Fees](#gas-amp-fees) - - [Pruning of State](#pruning-of-state) - - [REST API](#rest-api) - - [GRPC](#grpc) + - [Initialize Chain](#initialize-chain) + - [Genesis File](#genesis-file) + - [Seeds & Peers](#seeds-amp-peers) + - [Gas & Fees](#gas-amp-fees) + - [Pruning of State](#pruning-of-state) + - [REST API](#rest-api) + - [GRPC](#grpc) - [Sync Options](#sync-options) - - [Blocksync](#blocksync) - - [State Sync](#state-sync) - - [Quicksync](#quicksync) + - [Blocksync](#blocksync) + - [State Sync](#state-sync) + - [Quicksync](#quicksync) - [Snapshots](#snapshots)= - [Releases](#releases-amp-upgrades) - [Cosmovisor](#cosmovisor) @@ -42,7 +41,6 @@ For instructions to join as a validator, please also see the [Validator Guide](h The current Cosmos Hub mainnet `cosmoshub-4`. Visit the [migration section](https://github.com/cosmos/gaia/tree/main/docs/migration) of the Hub's docs for more information on previous chain migrations. - ## Explorers There are many explorers for the Cosmos Hub. For reference while setting up a node, here are a few recommendations: @@ -53,16 +51,16 @@ There are many explorers for the Cosmos Hub. For reference while setting up a no - [Stake ID](https://cosmos.stake.id/) - ## Getting Started Make sure the following prerequisites are completed: + - Choose the proper hardware/server configuration. See the [hardware guide](#hardware). - Ensure Gaia is properly installed. See the [installation guide](https://hub.cosmos.network/main/getting-started/installation.html) for a walkthrough. - Follow the [configuration guide](#General-Configuration) to intialize and prepare the node to sync with the network. - ## Hardware + Running a full archive node can be resource intensive as the full current `cosmoshub-4` state is over `1.4TB`. For those who wish to run state sync or use quicksync, the following hardware configuration is recommended: | Node Type | RAM | Storage | @@ -73,7 +71,6 @@ Running a full archive node can be resource intensive as the full current `cosm \* Storage size for validators will depend on level of pruning. - ## General Configuration Make sure to walk through the basic setup and configuration. Operators will need to initialize `gaiad`, download the genesis file for `cosmoshub-4`, and set persistent peers and/or seeds for startup. @@ -81,6 +78,7 @@ Make sure to walk through the basic setup and configuration. Operators will need ### Initialize Chain Choose a custom moniker for the node and initialize. By default, the `init` command creates the `~/.gaia` directory with subfolders `config` and `data`. In the `/config` directory, the most important files for configuration are `app.toml` and `config.toml`. + ```bash gaiad init ``` @@ -97,6 +95,7 @@ moniker = "" ### Genesis File Once the node is initialized, download the genesis file and move to the `/config` directory of the Gaia home directory. + ```bash wget https://raw.githubusercontent.com/cosmos/mainnet/master/genesis/genesis.cosmoshub-4.json.gz gzip -d genesis.cosmoshub-4.json.gz @@ -146,7 +145,6 @@ minimum-gas-prices = "0.0025uatom" The initial recommended `min-gas-prices` is `0.0025uatom`, but this can be changed later. - ### Pruning of State > **Note**: This is an optional configuration. @@ -165,6 +163,7 @@ By default, every node is in `default` mode which is the recommended setting for If a node operator wants to change their node's pruning strategy then this **must** be done before the node is initialized. In `~/.gaia/config/app.toml` + ``` # default: the last 100 states are kept in addition to every 500th state; pruning at 10 block intervals # nothing: all historic states will be saved, nothing will be deleted (i.e. archiving node) @@ -221,7 +220,6 @@ enable = true address = "0.0.0.0:9090" ``` - ## Sync Options There are three main ways to sync a node on the Cosmos Hub; Blocksync, State Sync, and Quicksync. See the matrix below for the Hub's recommended setup configuration. This guide will focus on syncing two types of common nodes; full and pruned. For further information on syncing to run a validator node, see the section on [Validators](https://hub.cosmos.network/main/validators/overview.html). @@ -234,24 +232,17 @@ There are two types of concerns when deciding which sync option is right. _Data | Moderate Historical Data | Quicksync - Default | | | Full Historical Data | Quicksync - Archive | Blocksync | - - If a node operator wishes to run a full node, it is possible to start from scratch but will take a significant amount of time to catch up. Node operators not concerned with rebuilding original state from the beginning of `cosmoshub-4` can also leverage [Quicksync](#Quicksync)'s available archive history. For operators interested in bootstrapping a pruned node, either [Quicksync](#Quicksync) or [State Sync](#State-Sync) would be sufficient. - - - - Make sure to consult the [hardware](#Hardware) section for guidance on the best configuration for the type of node operating. - - ::::::: tabs :options="{ useUrlFragment: false }" :::::: tab Blocksync + ### Blocksync Blocksync is faster than traditional consensus and syncs the chain from genesis by downloading blocks and verifying against the merkle tree of validators. For more information see [Tendermint's Fastsync Docs](https://docs.tendermint.com/v0.34/tendermint-core/fast-sync.html) @@ -272,6 +263,7 @@ It is possible to sync from previous versions of the Cosmos Hub. See the matrix ##### Getting Started Start Gaia to begin syncing with the `skip-invariants` flag. For more information on this see [Verify Mainnet](#Verify-Mainnet). + ```bash gaiad start --x-crisis-skip-assert-invariants @@ -281,6 +273,7 @@ The node will begin rebuilding state until it hits the first upgrade height at b :::::: :::::: tab "State Sync" + ### State Sync State Sync is an efficient and fast way to bootstrap a new node, and it works by replaying larger chunks of application state directly rather than replaying individual blocks or consensus rounds. For more information, see [Tendermint's State Sync docs](https://github.com/tendermint/tendermint/blob/v0.34.x/spec/p2p/messages/state-sync.md). @@ -334,7 +327,9 @@ Once state sync successfully completes, the node will begin to process blocks no :::::: :::::: tab Quicksync + ### Quicksync + Quicksync.io offers several daily snapshots of the Cosmos Hub with varying levels of pruning (`archive` 1.4TB, `default` 540GB, and `pruned` 265GB). For downloads and installation instructions, visit the [Cosmos Quicksync guide](https://quicksync.io/networks/cosmos.html). :::::: @@ -343,6 +338,7 @@ Quicksync.io offers several daily snapshots of the Cosmos Hub with varying leve ## Snapshots + Saving and serving snapshots helps nodes rapidly join the network. Snapshots are now enabled by default effective `1/20/21`. While not advised, if a node operator needs to customize this feature, it can be configured in `~/.gaia/config/app.toml`. The Cosmos Hub recommends setting this value to match `pruning-keep-every` in `config.toml`. @@ -350,6 +346,7 @@ While not advised, if a node operator needs to customize this feature, it can be > **Note**: It is highly recommended that node operators use the same value for snapshot-interval in order to aid snapshot discovery. Discovery is easier when more nodes are serving the same snapshots. In `app.toml` + ``` ############################################################################### ### State Sync Configuration ### @@ -368,6 +365,7 @@ snapshot-keep-recent = 10 ``` ## Releases & Upgrades + **See all [Gaia Releases](https://github.com/cosmos/gaia/releases)** The most up to date release of Gaia is [`V6.0.0`](https://github.com/cosmos/gaia/releases/tag/v6.0.0). For those that want to use state sync or quicksync to get their node up to speed, starting with the most recent version of Gaia is sufficient. @@ -378,6 +376,7 @@ The process is summarized below but make sure to follow the manual upgrade instr **[Delta Instructions](https://github.com/cosmos/gaia/blob/main/docs/migration/cosmoshub-4-delta-upgrade.md#Upgrade-will-take-place-July-12,-2021)** Once `V4` reaches the upgrade block height, expect the chain to halt and to see the following message: + ```bash ERR UPGRADE "Gravity-DEX" NEEDED at height: 6910000: v5.0.0-4760cf1f1266accec7a107f440d46d9724c6fd08 ``` @@ -386,10 +385,10 @@ Make sure to save a backup of `~/.gaia` in case rolling back is necessary. Install Gaia [`V5.0.0`](https://github.com/cosmos/gaia/releases/tag/v5.0.0) and restart the daemon. - **[Vega Instructions](https://github.com/cosmos/gaia/blob/main/docs/migration/cosmoshub-4-vega-upgrade.md)** Once `V5` reaches the upgrade block height, the chain will halt and display the following message: + ```bash ERR UPGRADE "Vega" NEEDED at height: 8695000 @@ -399,14 +398,12 @@ Again, make sure to backup `~/.gaia` Install Gaia [`V6.0.0`](https://github.com/cosmos/gaia/releases/tag/v6.0.0) and restart the daemon. - ## Cosmovisor Cosmovisor is a process manager developed to relieve node operators of having to manually intervene every time there is an upgrade. Cosmovisor monitors the governance module for upgrade proposals; it will take care of downloading the new binary, stopping the old one, switching to the new one, and restarting. For more information on how to run a node via Cosmovisor, check out the [docs](https://github.com/cosmos/cosmos-sdk/blob/v0.45.0/cosmovisor/README.md). - ## Running via Background Process To run the node in a background process with automatic restarts, it's recommended to use a service manager like `systemd`. To set this up run the following: @@ -455,7 +452,6 @@ sudo -S systemctl start sudo service status ``` - ## Exporting State Gaia can dump the entire application state into a JSON file. This application state dump is useful for manual analysis and can also be used as the genesis file of a new network. @@ -480,7 +476,6 @@ If planning 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 diff --git a/docs/hub-tutorials/join-testnet.md b/docs/hub-tutorials/join-testnet.md index 678ba07e8a5..be0f8af18a7 100644 --- a/docs/hub-tutorials/join-testnet.md +++ b/docs/hub-tutorials/join-testnet.md @@ -9,13 +9,14 @@ title: Joining Testnet | --------------- | -------------- | -------------------- | ---------------- | | Theta | `theta-testnet-001` | 9283650 | March 17 2021 | - ## Background + The current Cosmos Hub Testnet is running on the [Theta Upgrade](https://interchain-io.medium.com/preparing-for-the-cosmos-hub-v7-theta-upgrade-2fc41ce34787). Visit the [testnet explorer](https://explorer.theta-testnet.polypore.xyz/) to view all on chain activity. For those who just need instructions on performing the upgrade, see the [Upgrade](#upgrading) section. ## Releases + If syncing before the Theta update, checkout [`v6.0.0`](https://github.com/cosmos/gaia/tree/v6.0.0). Until a release is cut for the upgrade, feel free to track the `theta-prepare` branch (deleted). ## Prerequisites @@ -26,10 +27,10 @@ It's recommended that public testnet nodes are running on machines with at least **Make sure Go & Gaia are [properly installed](../getting-started/installation.md). The most recent Gaia version for the Theta Testnet is [`v7.0.0-rc0`](https://github.com/cosmos/gaia/tree/v7.0.0-rc0).** - This tutorial will provide all necessary instructions for joining the current public testnet. If you're interested in more advanced configuration and synchronization options, see [Join Mainnet](./join-mainnet.md) for a detailed walkthrough. ## Sync Options + There are two ways to sync a testnet node, Fastsync and State Sync. [Fastsync](https://docs.tendermint.com/v0.34/tendermint-core/fast-sync.html) syncs the chain from genesis by downloading blocks in paralell and then verifying them. [State Sync](https://docs.tendermint.com/v0.34/tendermint-core/state-sync.html) will look for snapshots from peers at a trusted height and then verifying a minimal set of snapshot chunks against the network. State Sync is far faster and more efficient than Blocksync, but Blocksync offers higher data integrity and more robust history. For those who are concerned about storage and costs, State Sync can be the better option as it minimizes storage usage when rebuilding initial state. @@ -92,6 +93,7 @@ Cosmovisor is a process manager that monitors the governance module for incoming Cosmovisor can be used when syncing with Blocksync or State Sync. Make sure to follow the Cosmovisor setup below, and then run `cosmovisor start` in place of `gaiad start`. Cosmovisor requires the creation the following directory structure: + ```shell . ├── current -> genesis or upgrades/ @@ -113,6 +115,7 @@ The following script installs, configures and starts Cosmovisor: # Install Cosmovisor go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor ``` + > NOTE: If you ran a full node on a previous testnet, please skip to [Upgrading From Previous Testnet](#upgrading-from-previous-testnet). To start a new node, the mainnet instructions apply: @@ -127,6 +130,7 @@ The only difference is the SDK version and genesis file. See the [testnet repo]( These instructions are for full nodes that have ran on previous versions of and would like to upgrade to the latest testnet. When the chain reaches the upgrade block height, the chain will halt and you will have to download the new binary and move it to the correct folder. For the `Theta` upgrade, this would look like: + ``` # Prepare Theta upgrade directory mkdir -p ~/.gaia/cosmovisor/upgrades/Theta/bin @@ -146,6 +150,7 @@ your node will still try to connect to them, but may fail if they haven't also been upgraded. ### Blocksync + Blocksync will require navigating the Theta upgrade either via [Cosmovisor](#using-cosmovisor) or manually. Manually updating `gaiad` will require stopping the chain and installing the new binary once it halts at the expected block height (some time on March 17, TBA). diff --git a/docs/interchain-security.md b/docs/interchain-security.md index 96d4b981f33..881dbd023bb 100644 --- a/docs/interchain-security.md +++ b/docs/interchain-security.md @@ -1,28 +1,23 @@ # Interchain Security - # Introduction Interchain Security has been referred to in many different ways: Shared Security, Cross Chain Validation, Cross Chain Collateralization, Shared Staking. This document will restrict use to the following three terms: - - -* **Shared Security** - * Shared security is a family of technologies that include optimistic rollups, zk-rollups, sharding and interchain security. -* **Interchain Security** - * Interchain Security is the Cosmos specific category of Shared Security that uses IBC (Inter-Blockchain Communication). -* **Cross Chain Validation** - * Cross Chain Validation is the specific IBC level protocol that enables Interchain Security. +* **Shared Security** + * Shared security is a family of technologies that include optimistic rollups, zk-rollups, sharding and interchain security. +* **Interchain Security** + * Interchain Security is the Cosmos specific category of Shared Security that uses IBC (Inter-Blockchain Communication). +* **Cross Chain Validation** + * Cross Chain Validation is the specific IBC level protocol that enables Interchain Security. While there are many ways that Interchain Security could take place, this document will focus on one instance of Interchain Security that has particularly valuable attributes for the ATOM token and the Cosmos Hub. The resulting technology may be applied to other scenarios with little to no modification, but I will leave those out for now (or only dedicate a small section) since the current priority is to implement this feature for the Cosmos Hub. At a very high level, Interchain Security is the ability for staking tokens that have been delegated to validators on a Provider Chain to inform the composition of a validator set on a Consumer Chain. Inter-Blockchain Communication is utilized to relay updates of validator stake delegations from the Provider Chain to the Consumer Chain so that the Consumer Chain will have an up-to-date model of which validators can produce blocks on the Consumer Chain. The inclusion of Provider Chain validators can be mandatory or opt-in depending on the requirements of the Consumer Chain. The Provider Chain will honor any proof of validator misbehavior produced by the Consumer Chain as evidence that results in slashing the stake of misbehaving validators on the Provider Chain. In this way the security gained from the value of the stake locked on the Provider Chain will be shared with the Consumer Chain. - # Cosmos Hub User Story -There are two primary reasons that Interchain Security is valuable to the Cosmos Hub. The first reason is because it allows for hub minimalism and the second is to lower the barrier to launching and running secure sovereign decentralized public blockchains. - +There are two primary reasons that Interchain Security is valuable to the Cosmos Hub. The first reason is because it allows for hub minimalism and the second is to lower the barrier to launching and running secure sovereign decentralized public blockchains. ## Practical Hub Minimalism @@ -30,19 +25,16 @@ Hub Minimalism is the strategic philosophy that posits that the Cosmos Hub shoul The current Cosmos Hub is adding more features, which carries some of the risks that hub minimalism is concerned with. Should Interchain Security become available, it would be possible to satisfy hub minimalists by allowing for each distinct feature of the Cosmos Hub to be an independent chain validated by the same set of ATOM delegated validators. This way the operation of each function could occur independently without affecting the operation of other ATOM secured hub-specific applications. - ## Lowering the Barrier to Security The security of a network is often described as a function of the cost for attacking that network. In Tendermint consensus we target ⅓ and ⅔ of locked stake for various guarantees about liveness and correctness. This means that in order to do any of a variety of attacks against the network, you would need to acquire ⅓+ or ⅔+ of all stake. The crude way to calculate the cost of an attack is to take the quantity of tokens needed to achieve these proportions and multiply it by the current market price for that token. We'll call this the Cost of Corruption. The Cost of Corruption calculation doesn't account for the availability of any specific token but it does give a very rough estimate for how secure a chain is. It's important that the total value locked (TVL) on a chain remains less than the Cost of Corruption, otherwise the chain should be considered insecure. Since the ability of a chain to serve a valuable purpose is often dependent on the TVL it can handle, it's important to find ways to increase the Cost of Corruption for chains in the Cosmos ecosystem. One method of doing this is to lend the value of the Cosmos ATOM to the Cost of Corruption of any chain. This becomes possible with Interchain Security as the ATOM, which already has a sizeable market cap, can increase the Cost of Corruption of a new chain. - # The Interchain Security Stack How Interchain Security works at a technical level is still in the process of development but the stack at a high level is well mapped out. It requires new functionality and modifications to current functionality on both Provider Chain and Consumer Chains. The technology can be developed progressively so that a minimum viable set of functionality can be launched as a V1 before an extended set of functionality is launched at a later date. - ## Chain Registry ### V1 - Full Validator Set @@ -59,23 +51,20 @@ The final piece of information relevant to the Chain Registry is the Time Til La It will be possible for a Validator to join an already running Interchain Secured network but if they intend to be part of the original genesis validator set they should join before the TTL. A chain within the registry may not produce a TTL until there is a threshold number of validators or amount of stake reached. Future versions of Interchain Security may help automate these thresholds but an initial version will be manually controlled. - ## Provider Chain Staking Module -Tendermint uses ABCI to get a set of validators and voting powers from the state machine in order to perform consensus on block production. This information is stored within the staking module of the Cosmos SDK application. In the configuration of Interchain Security, the Consumer Chain also has an instance of Tendermint that uses ABCI to ask for a set of validators and their voting powers. However instead of coming directly from the staking module of the Consumer Chain, in a sense it needs to come from the staking module of the Provider Chain. Practically speaking the state of the staking module of the Provider Chain is relayed periodically via IBC to the Consumer Chain, where it is stored in the Consumer Chain staking module and accessible to Tendermint via ABCI. +Tendermint uses ABCI to get a set of validators and voting powers from the state machine in order to perform consensus on block production. This information is stored within the staking module of the Cosmos SDK application. In the configuration of Interchain Security, the Consumer Chain also has an instance of Tendermint that uses ABCI to ask for a set of validators and their voting powers. However instead of coming directly from the staking module of the Consumer Chain, in a sense it needs to come from the staking module of the Provider Chain. Practically speaking the state of the staking module of the Provider Chain is relayed periodically via IBC to the Consumer Chain, where it is stored in the Consumer Chain staking module and accessible to Tendermint via ABCI. In order for the Provider Chain to relay validator sets and voting powers to the Consumer Chain, it needs to be able to distinguish between validator sets relevant to different networks. In V2, not all validators within a Provider Chain staking module will have opted-in to being part of each Consumer Chain set. In order to support Interchain Security, the Provider Chain will need to be extended to differentiate between sets of validators and their voting powers with respect to various chains as designated within the Chain Registry. To provide the necessary functionality on the Provider Chain, a wrapper module may need to be implemented that will collate staking module validators with regard to their inclusion in sets stored within the Chain Registry. A module like this will need to import both the Chain Registry Keeper and the Staking Keeper in order to make chain specific staking queries. These queries will be requested periodically by the Cross Chain Validation module and relayed to the Consumer Chain via IBC. This module can be referred to as the "xStaking Module". - ### Validator set limits The current Cosmos Hub has a limit of 175 validators. This limit is imposed on validators who are interested in producing blocks as part of a validator set of the Cosmos Hub itself. This limits the number of eligible validators for Consumer Chains to the same top 175 Cosmos Hub participants. However, just because a validator doesn't have enough staked ATOM to be eligible to validate on the Cosmos Hub, doesn't mean that they shouldn't qualify to validate on another Consumer Chain. Interchain Security should increase the diversity of the validator ecosystem by lowering the barrier to running a profitable validator business. This will go far in creating a healthy ecosystem of diverse validators that will result in anti-fragile and robustly operated networks. In order to make it possible for the top 175 validators to remain eligible as block producers for the Cosmos Hub while increasing the number of eligible validators for Consumer Chains, the Staking Module needs to stop forcing validators to undelegate when they leave the top set of 175 validators. This will result in a longer list of validators with ATOM delegations that are not participating in block production on the Provider Chain (Cosmos Hub). These extra validators will however be eligible to produce blocks on Consumer Chains and use their delegated ATOMs to earn rewards on the Consumer Chains as well as risk their Provider Chain ATOMs to slashable events should they misbehave on Consumer Chains. - ### Chain-Specific Delegations In order to further fulfil the goal of creating a diverse set of validators with healthy competition it is important to work towards chain-specific delegations. As described above and for the initial version of Interchain Security, the chain-specific validation calculation is determined by the validator being included in the Consumer Chain validator set. That means that all the individual delegations made to that validator are included as part of the decision. Similar to how a validator is able to decide its own commission rate, one may decide that it is the prerogative of that validator to make this decision on behalf of its delegators. Luckily if a delegator disagrees with the choice a validator has made on their behalf, they can redelegate to a validator that is better aligned with the wishes of the delegator. @@ -86,12 +75,10 @@ Initially the cost to validators to operate a new node instance on a new network The optionality around complex delegations would eventually increase the possible diversity of validator operations. However due to the complexity of such delegations, this functionality is assumed to be part of a future version of Interchain Security. - ### Epoch Staking The current Staking Module of the Cosmos SDK is moving towards Epoch based staking. This means that instead of validator set delegation amounts being calculated on a per block basis, they will be calculated over some length of time (or blocks) called an Epoch. This will decrease the number of times staking is calculated and generally decrease the complexity involved in staking. The additional complexity of chain relevant stake calculations will similarly benefit from a general simplification of stake calculations, and it will require less packets to be sent between the chains. - ## Provider Chain Distribution Module The distribution module of the Cosmos SDK uses a system called F1 to keep track of how many staking tokens that delegators have bonded to different validators and for how long they've been doing it. Block production rewards and all transaction fees are pooled into the distribution module account at the end of each block, and then distributed to each validator account based on their total voting power. When a delegator wants to withdraw rewards, the distribution module calculates the number of rewards received by their validator on their behalf since the delegator last withdrew, and calculates the outcome based on the amount of stake that belongs to the delegator compared to the total stake of the validator. @@ -100,36 +87,31 @@ Luckily, this system is sufficient to handle the distribution of rewards that co To distinguish fees in a Partial Validator Set (Opt-In), the distribution module will need to be extended to contain a chain-id as recorded in the Chain Registry in order to differentiate which pool of rewards are being distributed. If and when the xStaking module contains complex delegations, the stakingKeeper method for calculating delegations would also need to include the Chain Registry reference to chain-id in order to properly calculate the delegation rewards with regard to the specific Consumer Chain. In the meantime, for Interchain Security V1 this is unnecessary. - ## IBC & Cross Chain Validation There are a number of IBC application layer modules and packets that need to be developed to fully realize the IBC component of Interchain Security. This work has begun with a spec draft from Informal Systems that is visible at [@ibc/cross-chain-validation](https://github.com/cosmos/ibc/tree/main/spec/app/ics-028-cross-chain-validation). Instead of diving into the details of what they are and exactly how they work this section will be reserved for high level responsibilities of these mechanisms. There are three types of operations within Cross Chain Validation which must be present for Interchain Security to take place: - -* Validator Set Updates -* Evidence - +* Validator Set Updates +* Evidence ### Validator Set Updates The primary duty of Cross Chain Validation is to relay the set of validators and their voting power. The inclusion of a validator within a set relevant to a specific Consumer Chain is designated within the Chain Registry. The voting power denominated in Provider Chain staking token is designated within the staking module. The xStaking module allows for the collation of validators and their delegations on a chain specific designation. This collation is what must be relayed to the Consumer Chain via Cross Chain Validation. -The rate at which these validator set updates are relayed is a function of safety. At one extreme you could imagine the validator set being collated and relayed with every single epoch that is produced on the Provider Chain. This would ensure that the Consumer Chain has an absolutely accurate representation of validator weights at every potential state update within the Provider Chain. However, since delegations are subject to unbonding periods it is possible to approach state updates more conservatively. At another extreme, one may reason that if there is no active stake unbonding happening on the Provider Chain, it may be assumed that a validator set update will not be possible within a maximum duration of that unbonding period and so a validator set update can wait until just before that moment. Based on the possibility of instant redelegations this assumption may need to be further adjusted. +The rate at which these validator set updates are relayed is a function of safety. At one extreme you could imagine the validator set being collated and relayed with every single epoch that is produced on the Provider Chain. This would ensure that the Consumer Chain has an absolutely accurate representation of validator weights at every potential state update within the Provider Chain. However, since delegations are subject to unbonding periods it is possible to approach state updates more conservatively. At another extreme, one may reason that if there is no active stake unbonding happening on the Provider Chain, it may be assumed that a validator set update will not be possible within a maximum duration of that unbonding period and so a validator set update can wait until just before that moment. Based on the possibility of instant redelegations this assumption may need to be further adjusted. The process of recording and relaying validator set updates within safe and correct periods is the focus of the spec and research at Informal Systems. We can assume that the design will be aware of the necessary cadence that validator set updates must take place to ensure safe operation. When there are no updates it may be necessary to simply acknowledge this with something like a heartbeat IBC packet. - ### Reward Distribution While Interchain Security may remove the necessity for a staking token to play a role in the token design of new blockchains, it can be assumed that there will be some sort of economic system in place to reward validators for producing blocks. To follow the default capabilities of the Cosmos SDK one would assume that there is a simple inflationary reward token attached to the production of blocks. This token may also be a governance token and the value may be implied by the ability to govern an otherwise useful and valuable network. The token could have many uses or reasons to exist, but being the responsibility of each blockchain to design its own purpose, we will assume some sort of reward token exists and is used to reward validators for the production of blocks. -In the current system rewards are pooled into the distribution module account. The distribution module imports the staking module to keep track of validator weights in order to calculate and distribute rewards on a per-delegator basis. For this to take place on the Consumer Chain it would be necessary for not only the validator set and validator voting power to be relayed with cross chain validation, but also all constituent delegators that compose each validator. This would result in an extremely large IBC packet which would make regular communication difficult if not impossible. Rather than relay all delegators, this information should stay on the Provider Chain within the Provider Chain staking module. +In the current system rewards are pooled into the distribution module account. The distribution module imports the staking module to keep track of validator weights in order to calculate and distribute rewards on a per-delegator basis. For this to take place on the Consumer Chain it would be necessary for not only the validator set and validator voting power to be relayed with cross chain validation, but also all constituent delegators that compose each validator. This would result in an extremely large IBC packet which would make regular communication difficult if not impossible. Rather than relay all delegators, this information should stay on the Provider Chain within the Provider Chain staking module. Instead of distributing rewards on the Consumer Chain, the rewards collected for each block produced should be transferred to the Provider Chain at some interval. It may be a regular interval or a user initiated IBC packet, but would be similar to an ics-20 token transfer from the distribution module account of the Consumer Chain to the distribution module account of the Provider Chain. The difference between a standard ics-20 transfer being that the Provider Chain distribution module account needs to know which chain the rewards came from and over which period they were collected if this was not using V1 Full Validator Set Interchain Security. This information will be necessary to perform the Provider Chain distribution module's responsibility of distributed rewards to delegators and validators on a per chain basis informed by the Chain Registry. - ### Evidence In a single chain system, a validator may misbehave in various ways that result in the stake attached to that validator being slashed. This can occur automatically within the state machine or only after evidence of the misbehaviour has been collected and submitted to the chain. In a scenario where the validator set for a Consumer Chain is secured by stake that exists only on the Provider Chain, the evidence of misbehaviour needs to be submitted to the Provider Chain, where the tokens at stake are able to be slashed. Similar to a single chain system, this may take place automatically or only with the manual submission of evidence. If it were to occur automatically it would mean an outgoing IBC packet could be automatically generated but would still need to be manually relayed to the Provider Chain where punishment could follow. The more manual scenario would mean that the misbehaviour on the Consumer Chain results in evidence which is submitted directly to the Provider Chain, or submitted to the Consumer Chain which if successfully processed would result in an outgoing IBC packet containing the instruction to slash at the level of the Provider Chain. @@ -140,7 +122,6 @@ Limits on a Consumer Chain's ability to slash a Provider Chain validator may als Consideration should be made to the incentives around submitting evidence in order to ensure that punishable offenses do not go unnoticed. This is a similar issue to Relayer Incentivization, where currently it costs some fee to relay IBC packets but there is no reward or payment possible as part of the core IBC logic. As a result IBC packets are currently relayed in an altruistic manner. It's important to ensure that for integrity of the operation of the child and Provider Chain that slashable offenses are always submitted. It may be that the slashable amounts of tokens are used as rewards for submitting the evidence (assuming it's possible to ensure it is not the culprit submitting their own evidence and regaining their stake). Maybe some flat fee to at least pay for the transactions are required, although this may become redundant with the addition of any Relayer incentivizations into core IBC. - ## Consumer Chain Staking Module With Interchain Security, the Consumer Chain receives updates of the Provider Chain's set of validator's voting power via cross chain validation IBC packets. These updates are used to populate the Consumer Chain's staking module. On the Consumer Chain, Tendermint consensus is running which asks the Consumer Chain staking module for the current list of validators and their voting power. This could work virtually the same as a traditional configuration without Interchain Security, as from the perspective of Tendermint the flow is the same (ABCI asks the staking module for this information). @@ -149,7 +130,6 @@ With Interchain Security, the Consumer Chain receives updates of the Provider Ch Instead of aligning as closely as possible with the current staking module, a wrapper staking module could be made with additional functionality. This would allow Consumer Chains to create their own staking design that extends the validator set received from the Provider Chain. For example the validator set from the Provider Chain could be stored as it is received in a staking-like module. In addition another module could be used to track delegations to an overlapping set of validators using a secondary local staking token. The actual set of validators and their voting power could be a combination of these two sets and passed to Tendermint via ABCI. This combination could be customized per chain or as per need, for instance it may just boost the power of the Provider Chain validators or eclipse the set as desired. This set of functionality is possible but should not be considered for V1 or V2 of Interchain Security, but rather a V3 called Layered Security. - ## Consumer Chain Distribution Module Delegators and validators on the Provider Chain would likely not risk their ATOMs in order to be included in the validator set on a Consumer Chain unless there was some incentive to do so. At a minimum, transaction fees gained from processing transactions could be considered as a possible incentive. There may also be incentives completely outside the state machine, like a service agreement that comes with regular payments through traditional means of money transmission. More likely it is expected that Consumer Chains include some type of block reward as seen in traditional validation schemes. This could be in a child-chain specific token used for gas, governance or some other use. @@ -158,27 +138,24 @@ Regardless of how exactly a reward is calculated it is left up to the Consumer C In order to allow delegators to have a similar reward distribution as they currently experience, rewards should be regularly transferred to the Provider Chain where they can utilize the Provider Chain Distribution Module that tracks Cross Chain Validation client connections. These would be sent to the Provider Chain via a CCV IBC transaction similar to a traditional IBC Transfer packet but send to the Distribution Module Account with relevant information as to which validator and chain they were earned on and over what period of time. This information would allow the Provider Chain Distribution Module to distribute the rewards to the constituent delegators of each validator. - # Roll-Out and Open Questions Interchain Security consists of many moving pieces, each of which has a variable scope of functionality. Throughout this document the various capabilities are referred to as V1, V2 and V3. There are further outstanding questions including the exact implementation details for each of the modules included in the Interchain Security stack. These further give rise to expected user flows for each step as well as edge cases like: - -* Child or Provider Chain halting -* Child of Provider Chain upgrading -* Contentious forks of either Provider Chain or Consumer Chain -* Versions of IBC on each side fall out of sync +* Child or Provider Chain halting +* Child of Provider Chain upgrading +* Contentious forks of either Provider Chain or Consumer Chain +* Versions of IBC on each side fall out of sync Other open questions include addressing the degree of risk this configuration adds to the Provider Chain. Should it be possible for a Provider Chain validator to validate on a large number of Consumer Chains? To what extent should this be a choice of the Validator or a limit imposed by the Provider Chain state machine? If the Validator is exposed to slashing conditions of too many Consumer Chains, could this endanger the security of the Provider Chain or is it the responsibility of the delegator to take that risk into account? The economic cost of validating a new chain is another open question that will be important in determining the viability of this offering. Will the cost to validate on a large number of Consumer Chains be prohibitive to smaller validators, or will it be the edge that smaller validators can take to compete against larger validators and exchanges? - # Conclusion Interchain Security is a new shared security primitive that has implications for the security and scalability of single blockchains like the Cosmos Hub as well as the potential to dramatically lower the barrier to running secure public blockchains for new applications. It could be thought of as a competitive configuration to sharding and put the Cosmos Hub on par with Eth 2.0 or Polkadot in terms of their security offerings to applications included in their environment. The design philosophy around the Cosmos ecosystem has always prioritized autonomy and sovereignty over guarantees around security—"Bring your own security" is a term that has been used in the past. The design of Interchain Security discussed here tries to incorporate the Cosmos design philosophy of autonomy and sovereignty with the offering of shared security. Even within the balance between those considerations there is a spectrum of possibilities and it might be the case that multiple versions and configurations are implemented in parallel in order to satisfy as many needs as possible. # Further Reading - * [Interchain Security is Coming to the Cosmos Hub](https://blog.cosmos.network/interchain-security-is-coming-to-the-cosmos-hub-f144c45fb035) - Billy Rennekamp - * [Interchain Security Slidedeck from Cosmoverse Community Conference](https://docs.google.com/presentation/d/1XaPrbcNksnVdhZO1eyshyDDDQkA6buvKt90yxRF7sLs/edit?usp=sharing) - Billy Rennekamp +* [Interchain Security is Coming to the Cosmos Hub](https://blog.cosmos.network/interchain-security-is-coming-to-the-cosmos-hub-f144c45fb035) - Billy Rennekamp +* [Interchain Security Slidedeck from Cosmoverse Community Conference](https://docs.google.com/presentation/d/1XaPrbcNksnVdhZO1eyshyDDDQkA6buvKt90yxRF7sLs/edit?usp=sharing) - Billy Rennekamp diff --git a/docs/ko/delegators/delegator-guide-cli.md b/docs/ko/delegators/delegator-guide-cli.md index 57873254c26..297d8cb9f13 100644 --- a/docs/ko/delegators/delegator-guide-cli.md +++ b/docs/ko/delegators/delegator-guide-cli.md @@ -5,7 +5,7 @@ 또한 계정 관리, 코스모스 펀드레이저로 받은 계정을 복구하는 방법, 그리고 렛저 나노 하드웨어 지갑 사용법 또한 포함되어있습니다. -__중요__: 이 문서에 설명되어있는 모든 단계를 신중하게 진행하십시오. 특정 행동의 실수는 소유하고 있는 아톰의 손실을 초래할 수 있습니다. 진행 전 이 문서에 있는 모든 절차를 자세히 확인하시고 필요시 코스모스 팀에게 연락하십시오. **이 문서는 참고용 정보를 제공하기 위해 번역된 영어 원문의 번역본입니다. 이 문서에 포함되어있는 정보의 완결성은 보장되지 않으며, 개인의 행동에 따른 손실을 책임지지 않습니다. 꼭 영어 원문을 참고하시기 바랍니다. 만약 이 문서의 정보와 영어 원문의 정보가 다른 경우, 영어 문서의 정보가 상위 권한을 가지게 됩니다.** +__중요__: 이 문서에 설명되어있는 모든 단계를 신중하게 진행하십시오. 특정 행동의 실수는 소유하고 있는 아톰의 손실을 초래할 수 있습니다. 진행 전 이 문서에 있는 모든 절차를 자세히 확인하시고 필요시 코스모스 팀에게 연락하십시오. __이 문서는 참고용 정보를 제공하기 위해 번역된 영어 원문의 번역본입니다. 이 문서에 포함되어있는 정보의 완결성은 보장되지 않으며, 개인의 행동에 따른 손실을 책임지지 않습니다. 꼭 영어 원문을 참고하시기 바랍니다. 만약 이 문서의 정보와 영어 원문의 정보가 다른 경우, 영어 문서의 정보가 상위 권한을 가지게 됩니다.__ CLI를 사용하는 위임자는 매우 실험적인 블록체인 기술이 사용되고 있는 코스모스 허브를 사용하게됩니다. 코스모스 허브는 우수한 기술을 기반으로 다수의 보안 감사를 진행했으나 문제, 업데이트 그리고 버그가 존재할 수 있습니다. 또한 블록체인 기술을 사용하는 것은 상당한 기술적 배경을 필요로 하며, 공식 팀의 컨트롤 밖에 있는 리스크가 따릅니다. 유저는 이 소프트웨어를 사용함으로써 암호학 기반 소프트웨어를 사용하는 리스크를 인지하고 있음을 인정하는 것입니다. (참고 문서: [인터체인 코스모스 펀드레이저 약관](https://github.com/cosmos/cosmos/blob/master/fundraiser/Interchain%20Cosmos%20Contribution%20Terms%20-%20FINAL.pdf)). @@ -17,36 +17,36 @@ CLI를 사용하는 위임자는 매우 실험적인 블록체인 기술이 사 - [`gaiad` 설치하기](#installing-gaiad) - [코스모스 계정](#cosmos-accounts) - + [펀드레이저 계정 복구하기](#restoring-an-account-from-the-fundraiser) - + [계정 생성하기](#creating-an-account) + - [펀드레이저 계정 복구하기](#restoring-an-account-from-the-fundraiser) + - [계정 생성하기](#creating-an-account) - [코스모스 허브 네트워크 액세스하기](#accessing-the-cosmos-hub-network) - + [자체 풀노드 운영하기](#running-your-own-full-node) - + [원격 풀노드 연결하기](#connecting-to-a-remote-full-node) + - [자체 풀노드 운영하기](#running-your-own-full-node) + - [원격 풀노드 연결하기](#connecting-to-a-remote-full-node) - [`gaiad` 설정하기](#setting-up-gaiad) - [상태(state) 조회하기](#querying-the-state) - [트랜잭션 전송하기](#sending-transactions) - + [가스(Gas)와 수수료 관련 정보](#a-note-on-gas-and-fees) - + [아톰 위임 및 위임 보상 수령하기](#bonding-atoms-and-withdrawing-rewards) - + [거버넌스에 참여하기](#participating-in-governance) - + [오프라인 컴퓨터에서 트랜잭션 서명하기](#signing-transactions-from-an-offline-computer) + - [가스(Gas)와 수수료 관련 정보](#a-note-on-gas-and-fees) + - [아톰 위임 및 위임 보상 수령하기](#bonding-atoms-and-withdrawing-rewards) + - [거버넌스에 참여하기](#participating-in-governance) + - [오프라인 컴퓨터에서 트랜잭션 서명하기](#signing-transactions-from-an-offline-computer) ## `gaiad` 설치하기 -`gaiad`: `gaiad`는 `gaiad` 풀노드와 소통하기 위해 사용되는 명령어 기반 인터페이스입니다. +`gaiad`: `gaiad`는 `gaiad` 풀노드와 소통하기 위해 사용되는 명령어 기반 인터페이스입니다. ::: 경고 **추가적인 행동을 진행하기 전 최신 `gaiad` 클라이언트를 다운로드 하셨는지 확인하십시오** ::: -[**바이너리 설치하기**] +[__바이너리 설치하기__] -[**소스에서 설치하기**](https://cosmos.network/docs/gaia/installation.html) +[__소스에서 설치하기__](https://cosmos.network/docs/gaia/installation.html) ::: tip `gaiad`는 터미널 환경에서 사용됩니다. 다음과 같이 터미널을 실행하세요: -- **윈도우**: `시작` > `모든 프로그램` > `악세서리` > `명령 프롬프트` -- **맥OS**: `파인더` > `애플리케이션` > `유틸리티` > `터미널` -- **리눅스**: `Ctrl` + `Alt` + `T`::: +- __윈도우__: `시작` > `모든 프로그램` > `악세서리` > `명령 프롬프트` +- __맥OS__: `파인더` > `애플리케이션` > `유틸리티` > `터미널` +- __리눅스__: `Ctrl` + `Alt` + `T`::: ## 코스모스 계정 @@ -88,7 +88,7 @@ CLI를 사용하는 위임자는 매우 실험적인 블록체인 기술이 사 특정 계좌에 보관된 자산은 프라이빗 키에 의해 관리됩니다. 이 프라이빗 키는 시드의 일방적 기능(one-way function)을 통해 생성됩니다. 프라이빗 키를 분실한 경우, 시드 키를 사용하여 프라이빗 키를 다시 복구하는 것이 가능합니다. 하지만 시드 키를 분실한 경우, 모든 프라이빗 키에 대한 사용권을 잃게 됩니다. 누군가 본인의 시드 키를 가진 경우, 해당 키와 연관된 모든 계정의 소유권을 가진 것과 동일합니다. ::: warning -**12 단어 시드키를 분실하거나 그 누구와도 공유하지 마세요. 자금 탈취와 손실을 예방하기 위해서는 다수의 시드키 사본을 만드시고 금고 같이 본인만이 알 수 있는 안전한 곳에 보관하는 것을 추천합니다. 누군가 시드키를 가지게 된 경우, 관련 프라이빗 키와 모든 계정의 소유권을 가지게 됩니다.** +__12 단어 시드키를 분실하거나 그 누구와도 공유하지 마세요. 자금 탈취와 손실을 예방하기 위해서는 다수의 시드키 사본을 만드시고 금고 같이 본인만이 알 수 있는 안전한 곳에 보관하는 것을 추천합니다. 누군가 시드키를 가지게 된 경우, 관련 프라이빗 키와 모든 계정의 소유권을 가지게 됩니다.__ ::: 주소는 특정 계정을 구분하는 용도로 사용되며, 단어로 이루어진 특정 프리픽스(예, cosmos10)와 스트링 값을 조합한 값입니다 (예, `cosmos10snjt8dmpr5my0h76xj48ty80uzwhraqalu4eg`). 주소는 누군가 자산을 특정 계정으로 전송할때 사용되며, 퍼블릭키를 사용해 프라이빗 키를 추출하는 것은 불가능합니다. @@ -106,18 +106,17 @@ CLI를 사용하는 위임자는 매우 실험적인 블록체인 기술이 사 모든 렛저 기기에는 (코스모스 허브를 포함한) 다수의 블록체인에서 계정을 생성하기 위해 사용되는 시드키가 있습니다. 통상 시드키는 렛저 기기를 처음 활성화 할때 생성하지만, 유저가 시드키를 직접 입력하는 것 또한 가능합니다. 이제 펀드레이저를 통해 받은 시드키를 어떻게 렛저 하드웨어 지갑에 입력하는지 알아보겠습니다. ::: warning -*참고: 이번 단계를 진행하실때 **신규 기기를 사용하는 것을 권장합니다**. 한 렛저 기기에는 하나의 시드키만을 입력할 수 있습니다. 만약 이미 사용하시던 하드웨어 지갑을 사용하시기를 바라는 경우, `Settings`>`Device`>`Reset All`를 통해 리셋을 진행한 후 펀드레이저 시드를 입력할 수 있습니다. **렛저 기기를 리셋할 경우, 기존에 사용했던 시드키는 기기에서 삭제됩니다. 리셋을 진행하기 전 기존 기기의 시드키를 백업하셨는지 확인하신 후 진행하시기 바랍니다.** 백업 되지 않은 상태로 기기를 리셋하는 경우, 관련 계정의 자산을 잃을 수 있습니다.* +*참고: 이번 단계를 진행하실때 __신규 기기를 사용하는 것을 권장합니다__. 한 렛저 기기에는 하나의 시드키만을 입력할 수 있습니다. 만약 이미 사용하시던 하드웨어 지갑을 사용하시기를 바라는 경우, `Settings`>`Device`>`Reset All`를 통해 리셋을 진행한 후 펀드레이저 시드를 입력할 수 있습니다. __렛저 기기를 리셋할 경우, 기존에 사용했던 시드키는 기기에서 삭제됩니다. 리셋을 진행하기 전 기존 기기의 시드키를 백업하셨는지 확인하신 후 진행하시기 바랍니다.__ 백업 되지 않은 상태로 기기를 리셋하는 경우, 관련 계정의 자산을 잃을 수 있습니다.* ::: - -다음 단계는 신규 렛저 기기 또는 초기화 된 렛저 기기에서 진행되어야 합니다: +다음 단계는 신규 렛저 기기 또는 초기화 된 렛저 기기에서 진행되어야 합니다: 1. USB를 사용해 렛저 기기를 컴퓨터에 연결하세요 2. 두개의 버튼을 동시에 누르세요 -3. "Restore Configuration"을 선택하세요. **"Config as a new device"를 선택하시면 안됩니다** +3. "Restore Configuration"을 선택하세요. __"Config as a new device"를 선택하시면 안됩니다__ 4. 원하시는 핀 번호를 입력하세요 5. 12-words 옵션을 선택하세요 -6. 코스모스 펀드레이저에서 부여 받은 시드키를 차례대로 정확하게 입력하세요 +6. 코스모스 펀드레이저에서 부여 받은 시드키를 차례대로 정확하게 입력하세요 이제 렛저 하드웨어 지갑 기기가 펀드레이저 시드로 활성화되었습니다. 기존의 펀드레이저 시드를 파기하지 마십시오! 만약 렛저 기기가 고장나거나 분실된 경우, 동일한 시드키를 이용해 복구가 가능합니다. @@ -126,8 +125,8 @@ CLI를 사용하는 위임자는 매우 실험적인 블록체인 기술이 사 #### 컴퓨터 사용하기 ::: warning -**참고: 다음 행동은 오프라인 상태인 컴퓨터에서 진행하는 것이 더욱 안전합니다.** -::: +__참고: 다음 행동은 오프라인 상태인 컴퓨터에서 진행하는 것이 더욱 안전합니다.__ +::: 컴퓨터를 이용해 펀드레이저 시드키를 복구하시고 컴퓨터에 프라이빗 키를 저장사기 위해서는 다음 명령어를 실행하세요: @@ -147,7 +146,7 @@ gaiad keys add <키_명칭(YourKeyName)> --recover #### 렛저(Ledger) 하드웨어 월렛 기기 사용하기 ::: warning -**새로 주문한 렛저 기기 또는 신뢰할 수 있는 렛저 기기만을 사용하세요** +__새로 주문한 렛저 기기 또는 신뢰할 수 있는 렛저 기기만을 사용하세요__ ::: 렛저 기기를 처음 활성화할때 24개 단어로 구성된 시드키가 생성되고 기기에 저장됩니다. 렛저 기기의 시드키는 코스모스와 코스모스 계정과 호환이 되며, 해당 시드키를 기반으로 계정을 생성할 수 있습니다. 렛저 기기는 `gaiad`와 호환될 수 있게 설정이 되어야 합니다. 렛저 기기를 설정하는 방법은 다음과 같습니다: @@ -164,12 +163,12 @@ gaiad keys add <키_명칭(yourKeyName)> --ledger ``` - `` 은 계정의 이름입니다. 이는 시드키로부터 키 페어를 파생할때 레퍼런스로 사용됩니다. 이 이름은 토큰을 전송할때 보내는 계정을 구분하기 위해서 사용됩니다. -- 추가적인 선택 사항으로 명령어에 `--account` 플래그를 추가해 특정 패스(`0`, `1`, `2`, 등)를 지정할 수 있습니다. 기본적으로 `0`을 사용하여 계정이 생성됩니다. +- 추가적인 선택 사항으로 명령어에 `--account` 플래그를 추가해 특정 패스(`0`, `1`, `2`, 등)를 지정할 수 있습니다. 기본적으로 `0`을 사용하여 계정이 생성됩니다. #### 컴퓨터 사용하기 ::: warning -**참고: 다음 행동은 오프라인 상태인 컴퓨터에서 진행하는 것이 더욱 안전합니다.** +__참고: 다음 행동은 오프라인 상태인 컴퓨터에서 진행하는 것이 더욱 안전합니다.__ ::: 계정을 생성하기 위해서는 다음 명령어를 입력하세요: @@ -181,8 +180,8 @@ gaiad keys add <키_명칭(yourKeyName)> 위 명령어는 새로운 24단어로 구성된 시드키를 생성하고, 계정 `0`의 프라이빗 키와 퍼블릭 키를 저장합니다. 이후, 디스크에 저장될 계정 `0`의 프라이빗 키를 암호화할때 사용될 비밀번호를 입력할 것을 요청합니다. 해당 계정을 이용해 트랜잭션을 보낼때마다 이 비밀번호를 입력하셔야 합니다. 만약 비밀번호를 잃어버리셨다면 시드키를 사용해 계정을 다시 복구할 수 있습니다. ::: danger -**경고: 12 단어 시드키를 분실하거나 그 누구와도 공유하지 마세요. 자금 탈취와 손실을 예방하기 위해서는 다수의 시드키 사본을 만드시고 금고 같이 본인만이 알 수 있는 안전한 곳에 보관하는 것을 추천합니다. 누군가 시드키를 가지게 된 경우, 관련 프라이빗 키와 모든 계정의 소유권을 가지게 됩니다.** -::: +__경고: 12 단어 시드키를 분실하거나 그 누구와도 공유하지 마세요. 자금 탈취와 손실을 예방하기 위해서는 다수의 시드키 사본을 만드시고 금고 같이 본인만이 알 수 있는 안전한 곳에 보관하는 것을 추천합니다. 누군가 시드키를 가지게 된 경우, 관련 프라이빗 키와 모든 계정의 소유권을 가지게 됩니다.__ +::: ::: warning 시드키를 안전하게 보관하셨다면 (두번 세번씩이라도 정확하게 작성되었는지 확인하셔야 합니다!) 커맨드 라인의 기록을 다음과 같이 삭제하시면 됩니다: @@ -191,11 +190,11 @@ gaiad keys add <키_명칭(yourKeyName)> history -c rm ~/.bash_history ``` + ::: - `` 은 계정의 이름입니다. 이는 시드키로부터 키 페어를 파생할때 레퍼런스로 사용됩니다. 이 이름은 토큰을 전송할때 보내는 계정을 구분하기 위해서 사용됩니다. -- 추가적인 선택 사항으로 명령어에 `--account` 플래그를 추가해 특정 패스(`0`, `1`, `2`, 등)를 지정할 수 있습니다. 기본적으로 `0`을 사용하여 계정이 생성됩니다. - +- 추가적인 선택 사항으로 명령어에 `--account` 플래그를 추가해 특정 패스(`0`, `1`, `2`, 등)를 지정할 수 있습니다. 기본적으로 `0`을 사용하여 계정이 생성됩니다. 동일한 시드키로 추가적인 계정을 생성하기 원한다면, 다음 명령어를 사용하세요: @@ -205,14 +204,13 @@ gaiad keys add <키_명칭(yourKeyName)> --recover --account 1 해당 명령어는 비밀번호와 시드키를 입력할 것을 요청할 것입니다. 이 외에 추가적인 계정을 생성하시기 원한다면 account 플래그의 번호를 바꾸십시오. - ## 코스모스 허브 네트워크 사용하기 블록체인의 상태(state)를 확인하거나 트랜잭션을 전송하기 위해서는 직접 풀노드를 운영하거나 다른 사람이 운영하는 풀노드에 연결할 수 있습니다. ::: danger -**경고: 12개 단어 / 24개 단어 시드키를 그 누구와도 공유하지 마세요. 시드키는 본인만이 알고있어야 합니다. 특히 이메일, 메시지 등의 수단으로 블록체인 서비스 지원을 사칭해 시드키를 요청할 수 있으니 주의를 바랍니다. 코스모스 팀, 텐더민트 팀 그리고 인터체인 재단은 절대로 이메일을 통해 개인 정보 또는 시드키를 요청하지 않습니다.**. -::: +__경고: 12개 단어 / 24개 단어 시드키를 그 누구와도 공유하지 마세요. 시드키는 본인만이 알고있어야 합니다. 특히 이메일, 메시지 등의 수단으로 블록체인 서비스 지원을 사칭해 시드키를 요청할 수 있으니 주의를 바랍니다. 코스모스 팀, 텐더민트 팀 그리고 인터체인 재단은 절대로 이메일을 통해 개인 정보 또는 시드키를 요청하지 않습니다.__. +::: ### 직접 풀노드 운영하기 @@ -242,7 +240,6 @@ gaiad config <플래그(flag)> <값(value)> 해당 명령어는 각 플래그에 대한 값을 설정할 수 있게 합니다. 우선 연결하고 싶은 풀노드의 주소를 입력하겠습니다: - ```bash gaiad config node <호스트(host)>:<포트(port)> @@ -308,7 +305,6 @@ gaiad query 코스모스 허브 네트워크는 트랜잭션 처리를 위해 트랜잭션 수수료를 부과합니다. 해당 수수료는 트랜잭션을 실행하기 위한 가스로 사용됩니다. 공식은 다음과 같습니다: - ``` 수수료(Fee) = 가스(Gas) * 가스 값(GasPrices) ``` @@ -339,7 +335,6 @@ gaiad tx bank send <수신자_주소> <보내는_수량> --from <키_이름> --g ### 아톰 위임하기 / 리워드 수령하기 - ::: tip **아톰을 위임하거나 위임 보상을 수령하기 전에 `gaiad`를 설치하시고 계정을 만드셔야 합니다**::: ::: warning @@ -348,7 +343,7 @@ gaiad tx bank send <수신자_주소> <보내는_수량> --from <키_이름> --g ::: warning **참고: 다음 명령어는 온라인 상태인 컴퓨터에서 실행되어야 합니다. 해당 명령은 렛저 하드웨어 월렛 기기를 사용해 실행하는 것을 추천드립니다. 오프라인으로 트랜잭션을 발생하는 방법을 확인하기 위해서는 [여기](#signing-transactions-from-an-offline-computer)를 참고하세요.** -::: +::: ```bash // 특정 검증인에게 아톰 위임하기 @@ -408,7 +403,7 @@ gaiad query tx <트랜잭션_해시(txHash)> 모든 아톰 보유자는 프로포절을 제안할 수 있습니다. 특정 프로포절의 투표가 활성화되기 위해서는 `minDeposit`값에 정의된 보증금 보다 높은 `deposit` 비용이 예치되어야 합니다. `deposit`은 프로포절 제안자 외에도 보증금을 추가할 수 있습니다. 만약 제안자가 필요한 보증금 보다 낮은 보증금을 입금한 경우, 프로포절은 `deposit_period` 상태로 들어가 추가 보증금 입금을 대기합니다. 모든 아톰 보유자는 `depositTx` 트랜잭션을 통해 보증금을 추가할 수 있습니다. -프로포절의 `deposit`이 `minDeposit`을 도달하게 되면 해당 프로포절의 2주 간의 `voting_period`(투표 기간)이 시작됩니다. **위임된 아톰**의 보유자는 해당 프로포절에 투표를 행사할 수 있으며, `Yes`, `No`, `NoWithVeto` 또는 `Abstain` 표를 선택할 수 있습니다. 각 표는 투표자의 위임된 아톰 수량을 반영하게 됩니다. 만약 위임자가 직접 투표를 진행하지 않은 경우, 위임자는 검증인의 표를 따르게 됩니다. 하지만 모든 위임자는 직접 투표를 행사하여 검증인의 표와 다른 표를 행사할 수 있습니다. +프로포절의 `deposit`이 `minDeposit`을 도달하게 되면 해당 프로포절의 2주 간의 `voting_period`(투표 기간)이 시작됩니다. __위임된 아톰__의 보유자는 해당 프로포절에 투표를 행사할 수 있으며, `Yes`, `No`, `NoWithVeto` 또는 `Abstain` 표를 선택할 수 있습니다. 각 표는 투표자의 위임된 아톰 수량을 반영하게 됩니다. 만약 위임자가 직접 투표를 진행하지 않은 경우, 위임자는 검증인의 표를 따르게 됩니다. 하지만 모든 위임자는 직접 투표를 행사하여 검증인의 표와 다른 표를 행사할 수 있습니다. 투표 기간이 끝난 후, 프로포절이 50% 이상의 `Yes`표를 받았고 (`Abstain` 표를 제외하고) `NoWithVeto` (`Abstain` 표를 제외하고) 표가 33.33% 이하일 경우 통과하게 됩니다. @@ -416,7 +411,7 @@ gaiad query tx <트랜잭션_해시(txHash)> ::: warning **참고: 다음 명령어는 온라인 상태인 컴퓨터에서만 진행이 가능합니다. 해당 명령은 렛저 하드웨어 월렛 기기를 사용해 실행하는 것을 추천드립니다. 오프라인으로 트랜잭션을 발생하는 방법을 확인하기 위해서는 [여기](#signing-transactions-from-an-offline-computer)를 참고하세요.** -::: +::: ```bash // 프로포절 제안하기 @@ -440,7 +435,7 @@ gaiad tx gov vote <프로포절_ID(proposalID)> <표_선택(option)> --gas auto ## 오프라인 컴퓨터에서 트랜잭션 서명하기 -렛저 기기가 없거나 오프라인 컴퓨터에서 프라이빗 키를 관리하고 싶으신 경우, 다음 절차를 따라하세요. 우선 **온라인** 컴퓨터에서 미서명 트랜잭션을 다음과 같이 생성하십시오 (다음 예시에서는 위임 트랜잭션을 예시로 사용합니다): +렛저 기기가 없거나 오프라인 컴퓨터에서 프라이빗 키를 관리하고 싶으신 경우, 다음 절차를 따라하세요. 우선 __온라인__ 컴퓨터에서 미서명 트랜잭션을 다음과 같이 생성하십시오 (다음 예시에서는 위임 트랜잭션을 예시로 사용합니다): ```bash // 아톰 본딩하기 diff --git a/docs/ko/gaia-tutorials/installation.md b/docs/ko/gaia-tutorials/installation.md index 45cb05a8fa7..1e4382e15c7 100755 --- a/docs/ko/gaia-tutorials/installation.md +++ b/docs/ko/gaia-tutorials/installation.md @@ -47,8 +47,8 @@ LDFLAGS="" make install 위 절차를 따라하시면 `gaiad`와 `gaiad` 바이너리가 설치될 것입니다. 설치가 잘 되어있는지 확인하십시오: ```bash -$ gaiad version --long -$ gaiad version --long +gaiad version --long +gaiad version --long ``` `gaiad` 명령어는 다음과 비슷한 아웃풋을 내보냅니다: diff --git a/docs/ko/gaia-tutorials/join-mainnet.md b/docs/ko/gaia-tutorials/join-mainnet.md index c83aa246bd5..1c0ebf5ee65 100644 --- a/docs/ko/gaia-tutorials/join-mainnet.md +++ b/docs/ko/gaia-tutorials/join-mainnet.md @@ -11,12 +11,10 @@ ## 새로운 노드 세팅하기 - 다음 절차는 새로운 풀노드를 처음부터 세팅하는 절차입니다. 우선 노드를 실행하고 필요한 config 파일을 생성합니다: - ```bash gaiad init ``` @@ -60,7 +58,7 @@ mkdir -p $HOME/.gaia/config curl https://raw.githubusercontent.com/cosmos/launch/master/genesis.json > $HOME/.gaia/config/genesis.json ``` -위 예시에서는 최신 테스트넷에 대한 정보가 포함되어있는 [launch repo](https://github.com/cosmos/launch)의 `latest` 디렉토리를 이용하는 것을 참고하세요. +위 예시에서는 최신 테스트넷에 대한 정보가 포함되어있는 [launch repo](https://github.com/cosmos/launch)의 `latest` 디렉토리를 이용하는 것을 참고하세요. ::: tip 만약 다른 퍼블릭 테스트넷에 연결하신다면 [여기](./join-testnet.md)에 있는 정보를 확인하세요. @@ -71,6 +69,7 @@ curl https://raw.githubusercontent.com/cosmos/launch/master/genesis.json > $HOME ```bash gaiad start ``` + ### 시드 노드 추가하기 이제 노드가 다른 피어들을 찾는 방법을 알아야합니다. `$HOME/.gaia/config/config.toml`에 안정적인 시드 노드들을 추가할 차례입니다. [`launch`](https://github.com/cosmos/launch) repo에 몇 개 시드 노드 링크가 포함되어있습니다. @@ -89,7 +88,6 @@ gaiad start 코스모스 허브 네트워크는 트랜잭션 처리를 위해 트랜잭션 수수료를 부과합니다. 해당 수수료는 트랜잭션을 실행하기 위한 가스로 사용됩니다. 공식은 다음과 같습니다: - ``` 수수료(Fee) = 가스(Gas) * 가스 값(GasPrices) ``` @@ -108,7 +106,7 @@ gaiad start 풀노드는 컨펌되지 않은 트랜잭션을 멤풀에 보관합니다. 스팸 트랜잭션으로부터 풀노드를 보호하기 위해서 노드 멤풀에 보관되기 위한 트랜잭션의 최소 가스 가격(`minimum-gas-prices`)을 설정할 것을 권장합니다. 해당 파라미터는 `~/.gaia/config/gaiad.toml`에서 설정하실 수 있씁니다. -기본 권장 `minimum-gas-prices`는 `0.0025uatom`이지만, 추후 바꾸실 수 있습니다. +기본 권장 `minimum-gas-prices`는 `0.0025uatom`이지만, 추후 바꾸실 수 있습니다. ## 풀노드 운영하기 diff --git a/docs/ko/gaia-tutorials/join-testnet.md b/docs/ko/gaia-tutorials/join-testnet.md index 2d2ca1ed9d5..0cfcb442723 100755 --- a/docs/ko/gaia-tutorials/join-testnet.md +++ b/docs/ko/gaia-tutorials/join-testnet.md @@ -107,7 +107,7 @@ gaiad start 이제 노드가 다른 피어들을 찾는 방법을 알아야합니다. `$HOME/.gaia/config/config.toml`에 안정적인 시드 노드들을 추가할 차례입니다. `testnets` repo에 각 테스트넷에 대한 시드 노드 링크가 포함되어있습니다. 만약 현재 운영되고 있는 테스트넷을 참가하고 싶으시다면 [여기](https://github.com/cosmos/testnets)에서 어떤 노드를 이용할지 확인하세요. -만약 해당 시드가 작동하지 않는다면, 추가적인 시드와 피어들을 [코스모스 익스플로러](https://explorer.cosmos.network/nodes)를 통해 확인하실 수 있습니다. `Full Nodes` 탭을 들어가셔서 프라이빗(`10.x.x.x`) 또는 로컬 IP 주소(https://en.wikipedia.org/wiki/Private_network)가 _아닌_ 노드를 열어보세요. `Persistent Peer` 값에 연결 스트링(connection string)이 표기되어 있습니다. 가장 최적화된 결과를 위해서는 4-6을 이용하세요. +만약 해당 시드가 작동하지 않는다면, 추가적인 시드와 피어들을 [코스모스 익스플로러](https://explorer.cosmos.network/nodes)를 통해 확인하실 수 있습니다. `Full Nodes` 탭을 들어가셔서 프라이빗(`10.x.x.x`) 또는 로컬 IP 주소()가 _아닌_ 노드를 열어보세요. `Persistent Peer` 값에 연결 스트링(connection string)이 표기되어 있습니다. 가장 최적화된 결과를 위해서는 4-6을 이용하세요. 이 외에도 [밸리데이터 라이엇 채팅방](https://riot.im/app/#/room/#cosmos-validators:matrix.org)을 통해서 피어 요청을 할 수 있습니다. diff --git a/docs/ko/gaia-tutorials/what-is-gaia.md b/docs/ko/gaia-tutorials/what-is-gaia.md index 27a6121b115..a14a2f45e4a 100644 --- a/docs/ko/gaia-tutorials/what-is-gaia.md +++ b/docs/ko/gaia-tutorials/what-is-gaia.md @@ -18,7 +18,5 @@ - `ibc-go/modules`: 인터블록체인 전송 - `x/params`: 앱레벨 파라미터 관리 - - >코스모스 허브에 대해서: 코스모스 허브는 코스모스 네트워크의 최초 허브입니다. 허브는 블록체인 간 전송을 수행하는 역할을 합니다. IBC를 통해 특정 허브에 연결된 블록체인은 해당 허브에 연결되어있는 모든 블록체인과 함께 연결됩니다. 코스모스 허브는 지분증명 기반 퍼블릭 블록체인이며, 고유 토큰은 아톰(Atom)입니다. 다음은 Gaia를 [설치하는 방법](./installation.md)을 알아보겠습니다. \ No newline at end of file diff --git a/docs/ko/launch/blog-1-kr.md b/docs/ko/launch/blog-1-kr.md index 921d92a5f41..d6ea039a230 100644 --- a/docs/ko/launch/blog-1-kr.md +++ b/docs/ko/launch/blog-1-kr.md @@ -24,23 +24,29 @@ 🚦메인넷 런칭 프로세스를 확인하기 위해서는 다음 링크를 참고하세요: [cosmos.network/launch](https://cosmos.network/launch) ### 5: 코스모스 SDK 보안 감사 ✔ + 지난 1월, 코스모스 SDK는 다수의 외부 보안 감사 절차의 첫 단계를 진행했습니다. 보안 감사는 약 2주 반 기간에 걸려 진행되었습니다. 현재 두 개의 기관이 코스모스 SDK 코드를 검증한 상태이며, 다른 한 개 기관의 보안 감사가 진행 중입니다. ### 4: 코스모스 SDK 기능 동결 (feature freeze) + 코스모스 SDK의 최종 주요 수정 사항은 [SDK v0.31.0 RC에](https://github.com/cosmos/cosmos-sdk/projects/27) 반영되었습니다. 해당 RC(Release candidate)가 완료된 후, 코스모스 SDK 팀은 추가적인 디버깅을 진행하여 런칭 전 보안성 확보를 위해 노력을 기울일 예정입니다. 코스모스 SDK v0.31.0이 릴리즈된 후, 혹시라도 발견되지 않은 버그를 검증하기 위해 Gaia 테스트넷을 추가로 진행할 계획입니다. ### 3: 게임 오브 스테이크 완료 + 지난 2018년 12월, 사상 최초의 경쟁적 테스트넷인 게임 오브 스테이크(GoS, Game of Stakes)가 시작되었습니다. GoS의 목표는 경제적 인센티브 검증, 지분증명으로 보안이 유지되는 블록체인의 사회적 요소를 검증하기 위해 진행되었습니다. 이후, GoS는 무려 3번의 하드 포크를 성공적으로 진행했습니다. GoS가 완료된 후, 점수 측정 기준을 기반으로 우승자를 발표하게 될 계획입니다. ### 2: 제네시스 트랜잭션 모으기 + 제네시스 시점에서 인터체인 재단은 아톰 분배 권고를 작성합니다. 여기에는 코스모스 펀드레이저 참가자, 초기 기여자, 게임 오브 스테이크 우승자 등이 포함됩니다. 아톰 분배 권고 목록에 포함된 인원은 `gentx`를 제출할 수 있으며, 제네시스 검증인이 되기 위해서 `gentx` 제출은 필수입니다. 이후 모든 `gentx` 파일이 모이게 되면 최종 제네시스 파일이 만들어집니다. ### 1: 코스모스 허브 메인넷 런칭 🔥 🚀 🌔🔥 + +⅔의 보팅 파워가 온라인 상태가 되고, 커뮤니티가 제네시스 파일을 승인하게 된다면 코스모스 메인넷이 시작됩니다. ## 공식 코스모스 소통 채널 + 런칭 관련 소식을 전하는 공식 소통 채널은 다음과 같습니다: * 코스모스 트위터 (twitter.com/cosmos) @@ -61,7 +67,7 @@ 이런 공격을 대비하는 것은 벅차게 느껴질 수 있지만 몇 가지 유의 사항을 참고하신다면 공격의 위험을 크게 낮출 수 있습니다. 메인넷 런칭 준비에 관련해서는 다음 가이드라인이 보안적 리스크를 줄이고 정보를 검증하는데 도움이 될 수 있을 것입니다. -## 다음은 코스모스 메인넷 런칭 준비 유의사항입니다: +## 다음은 코스모스 메인넷 런칭 준비 유의사항입니다 * 모든 소프트웨어는 공식 채널을 통해서만 다운로드를 하십시오. 또한, 12개 시드키가 입력될 수 있는 모든 작업은 최신 `gaiad` 버전만을 사용하시기 바랍니다. 텐더민트, 코스모스 SDK 그리고 `gaiad` 최신 버전은 공식 코스모스 깃허브를 통해서 배포됩니다. 공식 깃허브를 통해서 소프트웨어를 다운로드 함으로써 악의적으로 수정된 소프트웨어를 사용하는 것을 방지할 수 있습니다. * 12개 시드 단어(시드 키)를 그 누구에게도 알려주지 마십시오. 시드 키는 오직 본인만이 관리해야 합니다. 특히 아톰 보관, 거래 등을 대행해주는 행위를 사칭하여 접근하는 사람들을 유의하십시오. 시드키를 안전하게 관리하기 위해서는 도난으로부터 안전한 오프라인 장소에 보관하시고, 혹시 모를 상황을 대비한 백업 수단을 유지하십시오. *시드키를 절대로 제삼자와 공유하지 마십시오.* @@ -76,9 +82,10 @@ 코스모스 팀, 텐더민트 팀 그리고 인터체인 팀은 개인 정보를 요청하거나 12개 시드키를 요구하는 이메일을 보내지 않습니다. 코스모스 팀은 언제나 공식 블로그, 트위터 그리고 깃허브를 통해서만 소통을 진행합니다. -#### Thank you to Cosmos Korea! -* 텔레그램: https://t.me/cosmoskr -* 페이스북 : https://facebook.com/groups/cosmoskorea +#### Thank you to Cosmos Korea + +* 텔레그램: +* 페이스북 : 참고: 이 글은 정보 제공을 위하여 번역된 글입니다. 내용/해석에 차이가 있을 수 있으며, 이 경우 영문 원문이 상위 권한을 가집니다. diff --git a/docs/ko/launch/blog-2-kr.md b/docs/ko/launch/blog-2-kr.md index 6ab3cf5bb83..1a6d62e5b28 100644 --- a/docs/ko/launch/blog-2-kr.md +++ b/docs/ko/launch/blog-2-kr.md @@ -1,5 +1,6 @@ # 코스모스 허브 메인넷의 세 가지 단계 + ## 메인넷 후 개발 로드맵과 유저들을 위한 필수 정보 코스모스 허브의 런칭은 단계별로 나뉘어 진행될 계획입니다. 다음은 각 단계별로 어떤 사항들이 진행될지에 대한 요약입니다. diff --git a/docs/ko/resources/gaiad.md b/docs/ko/resources/gaiad.md index d12f9554639..e43b2f5189b 100755 --- a/docs/ko/resources/gaiad.md +++ b/docs/ko/resources/gaiad.md @@ -42,7 +42,7 @@ gaiad config chain-id cosmoshub-2 - 자금을 받는데 사용 - 예시) `cosmos15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc` -* `cosmosvaloper` +- `cosmosvaloper` - 특정 검증인을 운영자와 연관하는데 사용됨 - 스테이킹 명령 요청에 이용됨 - 예시) `cosmosvaloper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah` @@ -222,7 +222,6 @@ gaiad tx bank send <보내는이_주소(sender_address)> <수신자_주소(desti `--generate-only` 명령어는 `gaiad`가 로컬 키베이스를 액세스하지 않습니다. `--generate-only` 플래그를 사용하시는 경우, `<보내는_사람_키_명칭_또는_주소(sender_key_name_or_address)>` 값은 키 명칭이 아닌 주소 값을 입력하세요. ::: - 이제 `--generate-only`를 통해 프린트된 트랜잭션 파일을 서명하시려면 다음 명령어를 통해 키를 입력하시면 됩니다: ```bash @@ -341,6 +340,7 @@ gaiad query minting annual-provisions ### 스테이킹 #### 검증인 세팅하기 + 검증인 후보가 되기 위한 가이드는 [검증인 세팅](../validators/validator-setup.md) 문서를 참고하세요. #### 검증인에게 위임하기 @@ -365,7 +365,6 @@ gaiad query staking validator 코스모스 허브 메인넷에서는 `uatom` 단위로 위임이 가능하며 `1atom = 1000000uatom`입니다. 테스트넷 검증인에게 위임하는 방법은 다음과 같습니다. - ```bash gaiad tx staking delegate \ --amount=10000000uatom \ @@ -495,6 +494,7 @@ gaiad query staking pool ``` `pool` 명령은 다음과 같은 정보에 대한 현재 값을 제공합니다: + - 본딩된 토큰 / 본딩 되어있지 않은 토큰 - 총 토큰 수량 - 연 인플레이션 비율과 가장 최근에 인플레이션이 변경된 블록 높이 @@ -637,7 +637,6 @@ gaiad query gov deposit <프로포절_ID(proposal_id)> <보증금_제공자_주 프로포절의 보증금이 `MinDeposit` 값에 도달하면 투표 기간이 시작됩니다. 본딩된 `Atom`을 보유한 홀더들은 각자 투표를 할 수 있습니다: - ```bash gaiad tx gov vote <프로포절_ID(proposal_id)> \ --from=<키_명칭(key_name)> \ @@ -651,6 +650,7 @@ gaiad tx gov vote <프로포절_ID(proposal_id)> <투표자_주소(voter_address)> ``` + 과거 프로포절에 대한 표 정보를 확인하기 위해서는: ```bash diff --git a/docs/ko/resources/genesis.md b/docs/ko/resources/genesis.md index dc0578717b3..8856a3433f3 100644 --- a/docs/ko/resources/genesis.md +++ b/docs/ko/resources/genesis.md @@ -36,12 +36,12 @@ gaiad init <명칭(moniker)> --chain-id <체인_아이디(chain-id)> 이후 제네시스 파일은 컨센서스 파라미터 값을 정의합니다. 컨센서스 파라미터는 모든 합의 계층(`gaia`의 경우 `Tendermint` 계층) 관련 값을 리그룹(regroup)합니다. 파라미터 값에 대해 알아보겠습니다: - `block` - + `max_bytes`: 블록 최대 바이트 크기 - + `max_gas`: 블록 가스 한도(gas limit). 블록에 포함되는 모든 트랜잭션은 가스를 소모합니다. 블록에 포함되어있는 트랜잭션들의 총 가스 사용량은 이 한도를 초과할 수 없습니다. + - `max_bytes`: 블록 최대 바이트 크기 + - `max_gas`: 블록 가스 한도(gas limit). 블록에 포함되는 모든 트랜잭션은 가스를 소모합니다. 블록에 포함되어있는 트랜잭션들의 총 가스 사용량은 이 한도를 초과할 수 없습니다. - `evidence` - + `max_age`: 증거(evidence)는 검증인이 동일한 블록 높이와 합의 라운드(round)에서 두개의 블록을 동시했다는 증거입니다. 위와 같은 행동은 명백한 악의적 행동으로 간주되며 스테이트 머신 계층에서 페널티를 부과합니다. `max_age` 값은 증거 유효성이 유지되는 최대 _블록_ 개수를 의미합니다. + - `max_age`: 증거(evidence)는 검증인이 동일한 블록 높이와 합의 라운드(round)에서 두개의 블록을 동시했다는 증거입니다. 위와 같은 행동은 명백한 악의적 행동으로 간주되며 스테이트 머신 계층에서 페널티를 부과합니다. `max_age` 값은 증거 유효성이 유지되는 최대 _블록_ 개수를 의미합니다. - `validator` - + `pub_key_types`: 검증인이 사용할 수 있는 pubkey 형태입니다(`ed25519`, `secp256k1`, ...). 현재 `ed25519`만 지원됩니다. + - `pub_key_types`: 검증인이 사용할 수 있는 pubkey 형태입니다(`ed25519`, `secp256k1`, ...). 현재 `ed25519`만 지원됩니다. ```json "consensus_params": { @@ -151,13 +151,13 @@ gaiad add-genesis-account <계정_주소(account_address)> <수량(amount)> <단 각 파라미터 값에 대해 알아보겠습니다: - `pool` - + `not_bonded_tokens`: 제네시스 시점에서 위임되지 않은 토큰의 수량을 정의합니다. 대부분의 상황에서 이 값은 스테이킹 토큰의 총 발행량을 뜻합니다 (이 예시에서는 `uatom` 단위로 정의됩니다). - + `bonded_tokens`: 제네시스 시점에서 위임된 토큰의 수량입니다. 대부분 상황에서 이 값은 `0`입니다. + - `not_bonded_tokens`: 제네시스 시점에서 위임되지 않은 토큰의 수량을 정의합니다. 대부분의 상황에서 이 값은 스테이킹 토큰의 총 발행량을 뜻합니다 (이 예시에서는 `uatom` 단위로 정의됩니다). + - `bonded_tokens`: 제네시스 시점에서 위임된 토큰의 수량입니다. 대부분 상황에서 이 값은 `0`입니다. - `params` - + `unbonding_time`: 토큰의 언본딩이 완료될 때까지의 기간을 _나노초(nanosecond)_ 단위로 정의합니다. - + `max_validators`: 최대 검증인 수입니다. - + `max_entries`: 특정 검증인/위임자 쌍에서 동시에 진행될 수 있는 최대 언본딩/재위임 회수. - + `bond_denom`: 스테이킹 토큰 단위. + - `unbonding_time`: 토큰의 언본딩이 완료될 때까지의 기간을 _나노초(nanosecond)_ 단위로 정의합니다. + - `max_validators`: 최대 검증인 수입니다. + - `max_entries`: 특정 검증인/위임자 쌍에서 동시에 진행될 수 있는 최대 언본딩/재위임 회수. + - `bond_denom`: 스테이킹 토큰 단위. - `last_total_power`: 보팅 파워 수치. 통상 제네시스 시점에서 `0`입니다 (다만, 과거 블록체인 상태를 기반으로 제네시스가 생성되었을 경우 다를 수 있습니다). - `last_validator_powers`: 각 검증인의 가장 최근 보팅 파워 수치입니다. 통상 제네시스 시점에서 `null`입니다. (다만, 과거 블록체인 상태를 기반으로 제네시스가 생성되었을 경우 다를 수 있습니다). - `validators`: 가장 최근 검증인 목록. 통상 제네시스 시점에서 `null`입니다. (다만, 과거 블록체인 상태를 기반으로 제네시스가 생성되었을 경우 다를 수 있습니다). @@ -190,15 +190,15 @@ gaiad add-genesis-account <계정_주소(account_address)> <수량(amount)> <단 각 파라미터 값에 대해 알아보겠습니다: - `minter` - + `inflation`: 토큰 총 발행량의 기본 연간 인플레이션 % (주 단위 복리 기준). `0.070000000000000000` 값은 주 단위 복리 기준으로 연간 `7%` 인플레이션을 뜻합니다. - + `annual_provisions`: 매 블록마다 계산됨. 기본 값은 `0.000000000000000000`으로 시작합니다. + - `inflation`: 토큰 총 발행량의 기본 연간 인플레이션 % (주 단위 복리 기준). `0.070000000000000000` 값은 주 단위 복리 기준으로 연간 `7%` 인플레이션을 뜻합니다. + - `annual_provisions`: 매 블록마다 계산됨. 기본 값은 `0.000000000000000000`으로 시작합니다. - `params` - + `mint_denom`: 인플레이션 대상 스테이킹 토큰의 단위. - + `inflation_rate_change`: 연간 인플레이션 변화율. - + `inflation_max`: 인플레이션 최대 수치. - + `inflation_min`: 인플레이션 최소 수치. - + `goal_bonded`: 총 발행량 중 위임 목표 % 수치. 만약 현재 위임 비율이 해당 이 값보다 낮은 경우, 인플레이션은 `inflation_rate_change` 값을 따라 `inflation_max`까지 증가합니다. 반대로 현재 위임 비율이 이 수치보다 높을 경우 `inflation_rate_change` 값을 따라 `inflation_min`까지 감소합니다. - + `blocks_per_year`: 연간 생성되는 블록 예상 수치. 스테이킹 토큰 인플레이션으로 발생하는 토큰을 각 블록당 지급(블록 프로비젼, block provisions)하는데 계산하는 용도로 사용됩니다. + - `mint_denom`: 인플레이션 대상 스테이킹 토큰의 단위. + - `inflation_rate_change`: 연간 인플레이션 변화율. + - `inflation_max`: 인플레이션 최대 수치. + - `inflation_min`: 인플레이션 최소 수치. + - `goal_bonded`: 총 발행량 중 위임 목표 % 수치. 만약 현재 위임 비율이 해당 이 값보다 낮은 경우, 인플레이션은 `inflation_rate_change` 값을 따라 `inflation_max`까지 증가합니다. 반대로 현재 위임 비율이 이 수치보다 높을 경우 `inflation_rate_change` 값을 따라 `inflation_min`까지 감소합니다. + - `blocks_per_year`: 연간 생성되는 블록 예상 수치. 스테이킹 토큰 인플레이션으로 발생하는 토큰을 각 블록당 지급(블록 프로비젼, block provisions)하는데 계산하는 용도로 사용됩니다. ### 분배(distribution) @@ -227,7 +227,7 @@ gaiad add-genesis-account <계정_주소(account_address)> <수량(amount)> <단 각 파라미터 값에 대해 알아보겠습니다: - `fee_pool` - + `community_pool`: 커뮤니티 풀은 임무 수행(개발, 커뮤니티 빌딩, 등)의 보상으로 제공될 수 있는 토큰 자금입니다. 토큰 풀의 사용은 거버넌스 프로포절을 통해 결정됩니다. 통상 제네시스 시점에서 `null`입니다. + - `community_pool`: 커뮤니티 풀은 임무 수행(개발, 커뮤니티 빌딩, 등)의 보상으로 제공될 수 있는 토큰 자금입니다. 토큰 풀의 사용은 거버넌스 프로포절을 통해 결정됩니다. 통상 제네시스 시점에서 `null`입니다. - `community_tax`: 블록 보상과 수수료 중 커뮤니티 풀로 예치될 '세금' %. - `base_proposer_reward`: 유효한 블록의 트랜잭션 수수료 중 블록 프로포저에게 지급될 리워드. 값이 `0.010000000000000000`인 경우, 수수료의 1%가 블록 프로포저에게 지급됩니다. - `bonus_proposer_reward`: 유효한 블록의 트랜잭션 수수료 중 블록 프로포저에게 지급될 리워드의 _최대 한도_. 보너스 수량은 블록 프로포저가 포함한 `precommit` 수량에 비례합니다. 만약 프로포저가 보팅 파워 기준으로`precommit`의 2/3을 포함한 경우 (2/3는 유효한 블록을 생성하기 위한 최소 한도입니다), `base_proposer_reward` 만큼의 보너스를 지급 받습니다. 보너스는 블록 프로포저가 `precommit`의 100%를 포함하는 경우 최대 `bonus_proposer_reward`까지 선의적(linearly)으로 증가합니다. @@ -278,19 +278,19 @@ gaiad add-genesis-account <계정_주소(account_address)> <수량(amount)> <단 - `deposits`: 각 프로포절 ID에 대한 보증금 목록입니다. 과거 상태에서 제네시스가 생성되지 않은 경우 `null` 값이 기본 설정입니다. - `votes`: 각 프로포절 ID에 대한 투표 목록입니다. 과거 상태에서 제네시스가 생성되지 않은 경우 `null` 값이 기본 설정입니다. - `votes`: 각 프로포절 ID에 대한 투표 목록입니다. 과거 상태에서 제네시스가 생성되지 않은 경우 `null` 값이 기본 설정입니다. -- `proposals`: 각 프로포절 ID에 대한 프로포절 목록입니다. +- `proposals`: 각 프로포절 ID에 대한 프로포절 목록입니다. - `deposit_params` - + `min_deposit`: 프로포절의 `voting period` 단계를 시작하기 위해 필요한 최소 보증금 수량입니다. 만약 다수 단위를 적용할 경우 `OR` 연산자를 사용하세요. - + `max_deposit_period`: 프로포절 보증금 추가가 가능한 기간 (**나노초(nanosecond)** 단위로 입력). 이 기간이 지난 이후에는 프로포절 보증금 추가가 불가능합니다. + - `min_deposit`: 프로포절의 `voting period` 단계를 시작하기 위해 필요한 최소 보증금 수량입니다. 만약 다수 단위를 적용할 경우 `OR` 연산자를 사용하세요. + - `max_deposit_period`: 프로포절 보증금 추가가 가능한 기간 (**나노초(nanosecond)** 단위로 입력). 이 기간이 지난 이후에는 프로포절 보증금 추가가 불가능합니다. - `voting_params` - + `voting_period`: 프로포절의 투표 기간(**나노초(nanosecond)** 단위로 입력). + - `voting_period`: 프로포절의 투표 기간(**나노초(nanosecond)** 단위로 입력). - `tally_params` - + `quorum`: 프로포절 투표 결과가 유효하기 위한 위임된 스테이킹 토큰의 투표율. - + `threshold`: 프로포절 투표가 통과하기 위해 필요한 최소 `YES` 투표 %. - + `veto`: 프로포절 투표 결과가 유효하기 위한 `NO_WITH_VETO` 투표 %의 최대 한도. - + `governance_penalty`: 프로포절 투표에 참여하지 않은 검증인들에 부과하는 페널티. + - `quorum`: 프로포절 투표 결과가 유효하기 위한 위임된 스테이킹 토큰의 투표율. + - `threshold`: 프로포절 투표가 통과하기 위해 필요한 최소 `YES` 투표 %. + - `veto`: 프로포절 투표 결과가 유효하기 위한 `NO_WITH_VETO` 투표 %의 최대 한도. + - `governance_penalty`: 프로포절 투표에 참여하지 않은 검증인들에 부과하는 페널티. -### 슬래싱(slashing) +### 슬래싱(slashing) `slashing` 모듈은 검증인의 악의적인 행동으로 발생하는 위임자 슬래싱 페널티 로직을 처리합니다. @@ -312,12 +312,12 @@ gaiad add-genesis-account <계정_주소(account_address)> <수량(amount)> <단 각 파라미터 값에 대해 알아보겠습니다: - `params` - + `max_evidence_age`: 증거 최대 유효기간 (**나노초(nanosecond)** 단위) - + `signed_blocks_window`: 오프라인 검증인 판단을 위해 검토되는 최근 블록 개수. - + `min_signed_per_window`: 검증인이 온라인으로 간주되기 위해`singed_blocks_window` 내에 포함되어야하는 최소 `precommit` %. - + `downtime_jail_duration`: 다운 타임 슬래싱으로 발생하는 제일(jail) 기간(**나노초(nanosecond)** 단위. - + `slash_fraction_double_sign`: 검증인이 더블 사이닝을 할 경우 슬래싱되는 위임자 위임량의 % 단위. - + `slash_fraction_downtime`: 검증인이 오프라인인 경우 슬래싱되는 위임자 워임량의 % 단위. + - `max_evidence_age`: 증거 최대 유효기간 (**나노초(nanosecond)** 단위) + - `signed_blocks_window`: 오프라인 검증인 판단을 위해 검토되는 최근 블록 개수. + - `min_signed_per_window`: 검증인이 온라인으로 간주되기 위해`singed_blocks_window` 내에 포함되어야하는 최소 `precommit` %. + - `downtime_jail_duration`: 다운 타임 슬래싱으로 발생하는 제일(jail) 기간(**나노초(nanosecond)** 단위. + - `slash_fraction_double_sign`: 검증인이 더블 사이닝을 할 경우 슬래싱되는 위임자 위임량의 % 단위. + - `slash_fraction_downtime`: 검증인이 오프라인인 경우 슬래싱되는 위임자 워임량의 % 단위. - `signing_infos`: `slashing` 모듈이 사용하는 각 검증인의 정보. 과거 상태에서 제네시스가 생성되지 않은 경우 `{}` 값이 기본 설정입니다. - `missed_blocks`: `slashing` 모듈이 사용하는 missed blocks 정보. 과거 상태에서 제네시스가 생성되지 않은 경우 `{}` 값이 기본 설정입니다. diff --git a/docs/ko/resources/hd-wallets.md b/docs/ko/resources/hd-wallets.md index da258b155fd..46409967143 100644 --- a/docs/ko/resources/hd-wallets.md +++ b/docs/ko/resources/hd-wallets.md @@ -16,7 +16,6 @@ 예를 들어, `path` 값이 `0`으로 지정된 경우, 지갑은 시드로부터 `Private Key 0`을 생성합니다. 이후 `Private Key 0`으로부터 `Public Key 0`을 생성하며, 마지막으로 `Public Key 0`으로 부터`Address 0`가 생성됩니다. 이 모든 과정을 일방적으로만 진행될 수 있습니다. 즉, `Address`로 부터 `Public Key`를 찾을 수 없고, `Public Key`로 부터 `Private Key` 값을 찾을 수 없스비낟. - ``` Account 0 Account 1 Account 2 diff --git a/docs/ko/resources/ledger.md b/docs/ko/resources/ledger.md index aa549397a93..8b388e285a0 100755 --- a/docs/ko/resources/ledger.md +++ b/docs/ko/resources/ledger.md @@ -142,7 +142,7 @@ gaiad tx --help # Lunie.io -Lunie 웹 지갑은 렛저 나노 S 기기를 사용해 서명하는 것을 지원합니다. 다음은 (Lunie.io)[https://lunie.io] 지갑을 Ledger 기기로 사용하는 방법을 정리합니다. +Lunie 웹 지갑은 렛저 나노 S 기기를 사용해 서명하는 것을 지원합니다. 다음은 [Lunie.io](https://lunie.io) 지갑을 Ledger 기기로 사용하는 방법을 정리합니다. ### 기기 연결하기 diff --git a/docs/ko/validators/security.md b/docs/ko/validators/security.md index e011b7c27e3..e81ca8ab9a0 100755 --- a/docs/ko/validators/security.md +++ b/docs/ko/validators/security.md @@ -53,5 +53,4 @@ private_peer_ids = "프라이빗_피어_노드_ID" 예를들어 `GA_CHAIN_ID` 환경 변수는 `--chain-id` 커맨드라인 플래그에 매핑됩니다. 명백한(explicit) 커맨드라인 플래그는 환경 변수 보다 상위에 속하며, 환경 변수는 모든 설정 파일 보다 상위에 속합니다. 중요한 파라미터는 CLI의 플래그로 정의되어야 하며 환경 변수의 수정 가능성을 줄이는 것이 중요합니다. - \ No newline at end of file diff --git a/docs/ko/validators/validator-faq.md b/docs/ko/validators/validator-faq.md index 447b8b021da..9e1519a3ac0 100755 --- a/docs/ko/validators/validator-faq.md +++ b/docs/ko/validators/validator-faq.md @@ -88,14 +88,13 @@ `create-validator` 트랜잭션을 통해 만들어진 검증인은 총 3개의 상태가 있을 수 있습니다: -- `bonded`: 검증인은 현재 합의에 참가하고 있는 활성화된 검증인입니다. 이 검증인은 블록 보상을 받을 수 있으며, 악의적인 행동에 대한 슬래싱 페널티를 받을 수도 있습니다. -- `unbonding`: 검증인은 현재 합의에 참가하고 있지 않으면 활성화된 검증인 세트에 포함되어있지 않습니다. 검증인은 블록 생성을 받지 않지만 악의적인 행동에 대한 슬래싱 페널티는 적용될 수 있습니다. 이 상태는 `bonded` 상태인 검증인이 `unbonded`으로 전환되는 중간 상태이며, 만약 `unbonding` 상태에서 `rebond` 트랜잭션을 발생하지 않으면 최대 3주간 중간 단계에 머무를 수 있습니다. -- `unbonded`: 검증인은 합의에 참가하고 있지 않은 검증인이며, 활성화된 검증인 세트에 포함되어있지 않습니다. 이 검증인은 블록 생성 보상을 받지 않으며 슬래싱 페널티도 적용되지도 않습니다. 이 검증인에게 아톰을 위임하는 것은 가능합니다. `unbonded` 상태인 검증인으로 부터의 언본딩은 바로 처리 됩니다. +* `bonded`: 검증인은 현재 합의에 참가하고 있는 활성화된 검증인입니다. 이 검증인은 블록 보상을 받을 수 있으며, 악의적인 행동에 대한 슬래싱 페널티를 받을 수도 있습니다. +* `unbonding`: 검증인은 현재 합의에 참가하고 있지 않으면 활성화된 검증인 세트에 포함되어있지 않습니다. 검증인은 블록 생성을 받지 않지만 악의적인 행동에 대한 슬래싱 페널티는 적용될 수 있습니다. 이 상태는 `bonded` 상태인 검증인이 `unbonded`으로 전환되는 중간 상태이며, 만약 `unbonding` 상태에서 `rebond` 트랜잭션을 발생하지 않으면 최대 3주간 중간 단계에 머무를 수 있습니다. +* `unbonded`: 검증인은 합의에 참가하고 있지 않은 검증인이며, 활성화된 검증인 세트에 포함되어있지 않습니다. 이 검증인은 블록 생성 보상을 받지 않으며 슬래싱 페널티도 적용되지도 않습니다. 이 검증인에게 아톰을 위임하는 것은 가능합니다. `unbonded` 상태인 검증인으로 부터의 언본딩은 바로 처리 됩니다. 위임인들은 관련 검증인들과 동일한 상태를 가지게 됩니다. -*Note that delegation are not necessarily bonded. Atoms can be delegated and bonded, delegated and unbonding, delegated and unbonded, or liquid* - +_Note that delegation are not necessarily bonded. Atoms can be delegated and bonded, delegated and unbonding, delegated and unbonded, or liquid_ ### 셀프본딩은 무엇이며 어떻게 셀프본딩을 늘릴 수 있나요? @@ -149,7 +148,7 @@ 검증인에게 위임을 하는 위임인은 '스테이킹 파워(staking power)'를 위임하는 것입니다. 검증인의 스테이킹 파워가 많을수록 해당 검증인은 합의 절차와 거버넌스 절차에서 가지는 힘이 커집니다. 하지만 검증인은 위임인의 아톰의 소유권을 가지지는 앖습니다. 코스모스 허브의 설계는 검증인이 위임인들의 아톰을 탈취할 수 없게 설계되었습니다. -검증인들은 위임인들의 자산을 직접적으로 탈취할 수 없지만, 검증인들의 악의적인 행동으로 발생하는 페널티에 대한 슬래싱은 검증인과 위임인들에게 동일하게 적용됩니다. +검증인들은 위임인들의 자산을 직접적으로 탈취할 수 없지만, 검증인들의 악의적인 행동으로 발생하는 페널티에 대한 슬래싱은 검증인과 위임인들에게 동일하게 적용됩니다. ### 검증인들은 얼마나 자주 블록 생성 제안을 할 수 있는건가요? 확률은 스테이킹된 아톰에 비례해서 올라가나요? @@ -169,7 +168,7 @@ * **블록 리워드:**: 이더민트 존의 경우, 블록 생성 보상은 포톤(photon) 토큰으로 지급됩니다. 포톤은 초기에 이더리움에서 '하드 스푼(hard spoon)'을 통해 분배되며 이더리움 수량의 1:1 비율로 지급될 예정입니다(거버넌스에 따라 해당 사항은 변경될 수 있습니다). * **트랜잭션 수수료:** 코스모스 허브는 트랜잭션 수수료로 지불이 가능한 토큰들의 화이트리스트를 관리합니다. -위에 나열된 보상과 수수료로 발생하는 수익은 각 검증인의 총 스테이킹 물량에 비례하여 지급되며, 각 검증인 풀에 위임한 위임인들은 이 수익을 분배받습니다. 보상 수익은 각 검증인의 커미션을 차감한 후 지급된다는 점을 참고하시기 바랍니다. +위에 나열된 보상과 수수료로 발생하는 수익은 각 검증인의 총 스테이킹 물량에 비례하여 지급되며, 각 검증인 풀에 위임한 위임인들은 이 수익을 분배받습니다. 보상 수익은 각 검증인의 커미션을 차감한 후 지급된다는 점을 참고하시기 바랍니다. ### 검증인을 운영할 인센티브는 무엇이 있나요? @@ -235,7 +234,7 @@ ### 검증인은 꼭 자체 위임(셀프본딩)을 해야하나요? -검증인은 자체 위임을 하지 않아도 검증인을 할 수 있습니다. 검증인의 총 스테이킹 수량은 셀프본딩 수량과 위임 수량의 합입니다. 셀프본딩이 낮은 검증인은 많은 위임인들의 스테이크를 통해 총 스테이킹 수량을 늘릴수 있습니다. 이런 이유로 검증인의 평판은 중요한 요소로 적용합니다. +검증인은 자체 위임을 하지 않아도 검증인을 할 수 있습니다. 검증인의 총 스테이킹 수량은 셀프본딩 수량과 위임 수량의 합입니다. 셀프본딩이 낮은 검증인은 많은 위임인들의 스테이크를 통해 총 스테이킹 수량을 늘릴수 있습니다. 이런 이유로 검증인의 평판은 중요한 요소로 적용합니다. 검증인이 셀프본딩 할 의무는 없을 수 있지만, 위임인들의 대다수는 검증인들이 셀프본딩을 하는 것을 선호할 수 있습니다. 본인에 행동에 대한 책임감을 보여줄 수 있기 때문입니다. diff --git a/docs/ko/validators/validator-setup.md b/docs/ko/validators/validator-setup.md index 2f5b5fa0152..98d183eaffc 100755 --- a/docs/ko/validators/validator-setup.md +++ b/docs/ko/validators/validator-setup.md @@ -2,10 +2,10 @@ # 퍼블릭 테스트넷에서 밸리데이터 운영하기 ::: tip -현재 테스트넷을 참가하는 방법은 [`testnet` repo](https://github.com/cosmos/testnets/tree/master/latest)에 있습니다. 최신 테스트넷에 대한 정보를 확인하시려면 해당 링크를 확인해주세요. +현재 테스트넷을 참가하는 방법은 [`testnet` repo](https://github.com/cosmos/testnets/tree/master/latest)에 있습니다. 최신 테스트넷에 대한 정보를 확인하시려면 해당 링크를 확인해주세요. ::: -__Note__: 이 문서는 **퍼블릭 테스트넷** 검증인들을 위해서만 작성되었습니다. +__Note__: 이 문서는 __퍼블릭 테스트넷__ 검증인들을 위해서만 작성되었습니다. 밸리데이터 노드를 세팅하기 전, [풀노드 세팅](../join-testnet.md) 가이드를 먼저 확인해주세요. @@ -13,7 +13,6 @@ __Note__: 이 문서는 **퍼블릭 테스트넷** 검증인들을 위해서만 [밸리데이터](./overview.md)는 블록체인의 투표를 통해서 새로운 블록은 생성하는 역할을 합니다. 만약 특정 밸리데이터가 오프라인이 되거나, 같은 블록높이에서 중복 사이닝을 한 경우 해당 밸리데이터의 지분은 삭감(슬래싱, slashing) 됩니다. 노드를 DDOS 공격에서 보호하고 높은 접근성을 유지하기 위해서는 [센트리노드 아키텍쳐](./validator-faq.md#how-can-validators-protect-themselves-from-denial-of-service-attacks)에 대해서 읽어보세요. - ::: danger 경고 코스모스 허브의 검증인이 되는 것을 검토하신다면, [보안에 대한 분석](./security.md)을 사전에 하시기를 바랍니다. ::: @@ -24,7 +23,6 @@ __Note__: 이 문서는 **퍼블릭 테스트넷** 검증인들을 위해서만 토큰 스테이킹을 통해 `cosmosvalconspub`로 새로운 밸리데이터를 생성할 수 있습니다. 본인의 밸리데이터 pubkey를 확인하기 위해서는 다음 명령어를 입력하세요: - ```bash gaiad tendermint show-validator ``` @@ -55,7 +53,6 @@ __참고__: `consensus_pubkey` 값이 지정되지 않은 경우, 기본적으 __참고__: 이 문항은 제네시스 파일에 참가하려는 밸리데이터에게만 해당됩니다. 만약 검증을 하려는 체인이 이미 작동되고 있는 상태라면 이 항목을 건너뛰셔도 좋습니다. - 밸리데이터로써 제네시스에 참가하고 싶으시다면 우선 본인(또는 위임자)가 stake를 보유하고 있다는 것을 증명해야 합니다. 스테이크를 검증인에게 본딩하는 하나 이상의 트랜잭션을 발생하신 후, 해당 트랜잭션을 제네시스 파일에 추가하시기 바랍니다. 이런 경우에는 `gentx`를 생성하셔야 합니다: @@ -101,7 +98,7 @@ gaiad collect-gentxs __참고:__ `gentx`에서 위임을 하는 계정에 스테이크(stake) 토큰이 있는 것을 확인하세요. 만약 해당 계정에 토큰이 없다면 `collect-gentx`가 실패하게 됩니다. -이전에 실행하신 명령어는 모든 제네시스 트랜잭션을 모으고 `genesis.json`을 파이널라이즈(finalize)합니다. 설정이 올바르게 되었는지 확인하기 위해서는 노드를 시작하십시오: +이전에 실행하신 명령어는 모든 제네시스 트랜잭션을 모으고 `genesis.json`을 파이널라이즈(finalize)합니다. 설정이 올바르게 되었는지 확인하기 위해서는 노드를 시작하십시오: ```bash gaiad start @@ -152,8 +149,8 @@ gaiad query slashing signing-info \ ```bash gaiad tx slashing unjail \ - --from= \ - --chain-id= + --from= \ + --chain-id= ``` ## 밸리데이터 작동상태 확인 diff --git a/docs/launch/blog-2-en.md b/docs/launch/blog-2-en.md index e70fbe10433..a2e1194e34e 100644 --- a/docs/launch/blog-2-en.md +++ b/docs/launch/blog-2-en.md @@ -1,16 +1,17 @@ # The 3 Phases of the Cosmos Hub Mainnet + ## Post-Mainnet Development Roadmap & Expectations for Users The launch of the Cosmos Hub mainnet is expected to happen in phases. Here we outline what to expect in each phase. # 🚨Phase I: Network Gains Stability 🚨 -In the first phase, the network is likely to be unstable; it may experience halts or other forms of failure requiring intervention and coordination among Cosmos Hub validators and full node operators to deploy a fix. This type of failure is not unexpected while the network gains stability. +In the first phase, the network is likely to be unstable; it may experience halts or other forms of failure requiring intervention and coordination among Cosmos Hub validators and full node operators to deploy a fix. This type of failure is not unexpected while the network gains stability. ## State Reversions and Mainnet launch -One of the core ideologies around blockchains is immutability. This is the idea that we don't go +One of the core ideologies around blockchains is immutability. This is the idea that we don't go back and edit past state transitions. While this notion of immutability is implemented directly via consensus protocols in the software, it is ultimately upheld by social contract among participants. That said, the technology underlying the Cosmos Hub was intentionally developed to enable low-friction forks and rollbacks. We’ve seen the community practice these techniques numerous times on the test networks. It’s likely they will need to be used on a mainnet as well. Ultimately, they are a countervailing force to the risk of cartel takeover. @@ -21,7 +22,7 @@ Once governance chooses to enable transfers, the importance of economic finality To summarize, if there are errors or vulnerabilities in the Cosmos Hub in the days before transfers are enabled, users should expect arbitrary state rollbacks even to genesis. -Once transfers are enabled, state rollbacks will be much more difficult to justify. +Once transfers are enabled, state rollbacks will be much more difficult to justify. **What this means for developers:** The Cosmos mainnet launch is the first phase in which fundraiser participants will be working together to operate the software. As a decentralized application developer, you are likely a user of either the [Cosmos-SDK framework](https://cosmos.network/docs/) or [Tendermint Core](https://tendermint.com/docs/). The progress of your Cosmos-SDK or Tendermint-based application should be independent of the Cosmos Hub roadmap. However, if your project requires the use of [Inter-Blockchain Communication][blog post], you must wait until Phase III, or participate in the IBC testnets that will begin shortly. @@ -37,17 +38,17 @@ You can, however, safely delegate Atoms to validators in this phase by following **Summary:** Once mainnet is deemed sufficiently stable, bonded Atom holders will vote to decide whether or not Atom transfers should be enabled. This procedure will happen through on-chain governance. -The best way to check on the status of governance proposals is to view them through Cosmos explorers. A list of explorers can be found on the launch page: [cosmos.network/launch](https://cosmos.network/launch). +The best way to check on the status of governance proposals is to view them through Cosmos explorers. A list of explorers can be found on the launch page: [cosmos.network/launch](https://cosmos.network/launch). **What this means for users:** If the proposal is accepted and transfers are enabled, then it becomes possible to transfer Atoms. # Phase III: IBC Enabled -**Summary:** In Phase III, the [IBC protocol][ibc] is released and Atom holders vote via on-chain governance on whether or not to enable it as part of the core module library within the Cosmos-SDK. +**Summary:** In Phase III, the [IBC protocol][ibc] is released and Atom holders vote via on-chain governance on whether or not to enable it as part of the core module library within the Cosmos-SDK. **What this means for developers:** Application-specific blockchains that are built using the Cosmos-SDK or Tendermint BFT will be able to connect to the Hub and interoperate/compose with all of the other blockchains that are connected to it. -**What this means for users:** You will be able to transfer various tokens and NFTs directly from one IBC-connected chain to another IBC-connected chain without going through a centralized +**What this means for users:** You will be able to transfer various tokens and NFTs directly from one IBC-connected chain to another IBC-connected chain without going through a centralized third-party platform. # Housekeeping for Validators: Submitting a `gentx` for mainnet @@ -57,13 +58,13 @@ third-party platform. 3. We will begin collecting Gentxs for mainnet once the recommended genesis allocations are published. # In Closing + The Cosmos mission is to build bridges to connect all blockchains—to build an Internet of Blockchains. Clearly, we have a long road of development ahead of us. And after mainnet, the real work to a world of deeply integrated token economies is still ahead of us. But as John Fitzgerald Kennedy once said in the face of adversity: *“We choose to go to the moon...not because they are easy, but because they are hard….”* To the Moon 🚀 - [blog post]: [https://blog.cosmos.network/developer-deep-dive-cosmos-ibc-5855aaf183fe] [ibc]: [https://docs.cosmos.network/main/ibc/overview.html] diff --git a/docs/migration/cosmoshub-2.md b/docs/migration/cosmoshub-2.md index b4d360cd3e5..e96ded44451 100644 --- a/docs/migration/cosmoshub-2.md +++ b/docs/migration/cosmoshub-2.md @@ -14,12 +14,12 @@ There is a strong social consensus around proposal `Cosmos Hub 3 Upgrade Proposa on `cosmoshub-2`. This indicates that the upgrade procedure should be performed on `December 11, 2019 at or around 14:27 UTC` on block `2,902,000`. - - [Preliminary](#preliminary) - - [Major Updates](#major-updates) - - [Risks](#risks) - - [Recovery](#recovery) - - [Upgrade Procedure](#upgrade-procedure) - - [Notes for Service Providers](#notes-for-service-providers) +- [Preliminary](#preliminary) +- [Major Updates](#major-updates) +- [Risks](#risks) +- [Recovery](#recovery) +- [Upgrade Procedure](#upgrade-procedure) +- [Notes for Service Providers](#notes-for-service-providers) ## Preliminary @@ -52,12 +52,12 @@ are discussed at a high level in July's Cosmos development update found Some of the biggest changes to take note on when upgrading as a developer or client are the the following: -- **Tagging/Events**: The entire system of what we used to call tags has been replaced by a more +- __Tagging/Events__: The entire system of what we used to call tags has been replaced by a more robust and flexible system called events. Any client that depended on querying or subscribing to tags should take note on the new format as old queries will not work and must be updated. More in depth docs on the events system can be found [here](https://github.com/tendermint/tendermint/blob/master/rpc/core/events.go). In addition, each module documents its own events in the specs (e.g. [slashing](https://github.com/cosmos/cosmos-sdk/blob/v0.36.0/docs/spec/slashing/06_events.md)). -- **Height Queries**: Both the CLI and REST clients now (re-)enable height queries via the +- __Height Queries__: Both the CLI and REST clients now (re-)enable height queries via the `--height` and `?height` arguments respectively. An important note to keep in mind are that height queries against pruning nodes will return errors when a pruned height is queried against. When no height is provided, the latest height will be used by default keeping current behavior intact. In @@ -92,7 +92,7 @@ v0.34.6+ of the _Cosmos SDK_ and restore to their latest snapshot before restart __Note__: It is assumed you are currently operating a full-node running v0.34.6+ of the _Cosmos SDK_. - The version/commit hash of Gaia v2.0.3: `2f6783e298f25ff4e12cb84549777053ab88749a` -- The upgrade height as agreed upon by governance: **2,902,000** +- The upgrade height as agreed upon by governance: __2,902,000__ - You may obtain the canonical UTC timestamp of the exported block by any of the following methods: - Block explorer (e.g. [Hubble](https://hubble.figment.io/cosmos/chains/cosmoshub-2/blocks/2902000?format=json&kind=block)) - Through manually querying an RPC node (e.g. `/block?height=2902000`) @@ -111,7 +111,7 @@ __Note__: It is assumed you are currently operating a full-node running v0.34.6+ 2. Export existing state from `cosmoshub-2`: - **NOTE**: It is recommended for validators and operators to take a full data snapshot at the export + __NOTE__: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating `cosmoshub-2`. See [Recovery](#recovery) for details on how to proceed. @@ -119,7 +119,7 @@ __Note__: It is assumed you are currently operating a full-node running v0.34.6+ Before exporting state via the following command, the `gaiad` binary must be stopped! ```bash - $ gaiad export --for-zero-height --height=2902000 > cosmoshub_2_genesis_export.json + gaiad export --for-zero-height --height=2902000 > cosmoshub_2_genesis_export.json ``` 3. Verify the SHA256 of the (sorted) exported genesis file: @@ -132,10 +132,10 @@ __Note__: It is assumed you are currently operating a full-node running v0.34.6+ 4. At this point you now have a valid exported genesis state! All further steps now require v2.0.3 of [Gaia](https://github.com/cosmos/gaia). - **NOTE**: Go [1.13+](https://golang.org/dl/) is required! + __NOTE__: Go [1.13+](https://golang.org/dl/) is required! ```bash - $ git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v2.0.3; make install + git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v2.0.3; make install ``` 5. Verify you are currently running the correct version (v2.0.3) of the _Gaia_: @@ -154,10 +154,10 @@ v2.0.3 of [Gaia](https://github.com/cosmos/gaia). 6. Migrate exported state from the current v0.34.6+ version to the new v2.0.3 version: ```bash - $ gaiad migrate v0.36 cosmoshub_2_genesis_export.json --chain-id=cosmoshub-3 --genesis-time=[PLACEHOLDER]> genesis.json + gaiad migrate v0.36 cosmoshub_2_genesis_export.json --chain-id=cosmoshub-3 --genesis-time=[PLACEHOLDER]> genesis.json ``` - **NOTE**: The `migrate` command takes an input genesis state and migrates it to a targeted version. + __NOTE__: The `migrate` command takes an input genesis state and migrates it to a targeted version. Both v0.36 and v0.37 are compatible as far as state structure is concerned. Genesis time should be computed relative to the blocktime of `2,902,000`. The genesis time @@ -173,7 +173,7 @@ v2.0.3 of [Gaia](https://github.com/cosmos/gaia). single parameter, `max_validators`, that we're upgrading based on [proposal 10](https://www.mintscan.io/proposals/10) ```bash - $ cat genesis.json | jq '.app_state["staking"]["params"]["max_validators"]=125' > tmp_genesis.json && mv tmp_genesis.json genesis.json + cat genesis.json | jq '.app_state["staking"]["params"]["max_validators"]=125' > tmp_genesis.json && mv tmp_genesis.json genesis.json ``` 8. Verify the SHA256 of the final genesis JSON: @@ -185,11 +185,11 @@ single parameter, `max_validators`, that we're upgrading based on [proposal 10]( 9. Reset state: - **NOTE**: Be sure you have a complete backed up state of your node before proceeding with this step. + __NOTE__: Be sure you have a complete backed up state of your node before proceeding with this step. See [Recovery](#recovery) for details on how to proceed. ```bash - $ gaiad unsafe-reset-all + gaiad unsafe-reset-all ``` 10. Move the new `genesis.json` to your `.gaia/config/` directory @@ -202,7 +202,7 @@ single parameter, `max_validators`, that we're upgrading based on [proposal 10]( 12. Note, if you have any application configuration in `gaiad.toml`, that file has now been renamed to `app.toml`: ```bash - $ mv .gaia/config/gaiad.toml .gaia/config/app.toml + mv .gaia/config/gaiad.toml .gaia/config/app.toml ``` ## Notes for Service Providers diff --git a/docs/migration/cosmoshub-3.md b/docs/migration/cosmoshub-3.md index 79f840e3085..246565b4b1d 100644 --- a/docs/migration/cosmoshub-3.md +++ b/docs/migration/cosmoshub-3.md @@ -14,38 +14,39 @@ There is a strong social consensus around proposal `Cosmos Hub 4 Upgrade Proposa on `cosmoshub-3`. Following proposals #[27](https://www.mintscan.io/cosmos/proposals/27), #[35](https://www.mintscan.io/cosmos/proposals/35) and #[36](https://www.mintscan.io/cosmos/proposals/36). This indicates that the upgrade procedure should be performed on `February 18, 2021 at 06:00 UTC`. - - [Summary](#summary) - - [Migrations](#migrations) - - [Preliminary](#preliminary) - - [Major Updates](#major-updates) - - [Risks](#risks) - - [Recovery](#recovery) - - [Upgrade Procedure](#upgrade-procedure) - - [Guidance for Full Node Operators](#guidance-for-full-node-operators) - - [Notes for Service Providers](#notes-for-service-providers) - +- [Summary](#summary) +- [Migrations](#migrations) +- [Preliminary](#preliminary) +- [Major Updates](#major-updates) +- [Risks](#risks) +- [Recovery](#recovery) +- [Upgrade Procedure](#upgrade-procedure) +- [Guidance for Full Node Operators](#guidance-for-full-node-operators) +- [Notes for Service Providers](#notes-for-service-providers) + # Summary The Cosmoshub-3 will undergo a scheduled upgrade to Cosmoshub-4 on Feb 18, 2021 at 6 UTC. The following is a short summary of the upgrade steps: - 1. Stopping the running Gaia v2.0.x instance + 1. Stopping the running Gaia v2.0.x instance 1. Backing up configs, data, and keys used for running Cosmoshub-3 1. Resetting state to clear the local Cosmoshub-3 state 1. Copying the cosmoshub-4 genesis file to the Gaia config folder (either after migrating an existing cosmoshub-3 genesis export, or downloading the cosmoshub-4 genesis from the mainnet github) 1. Installing the Gaia v4.0.x release 1. Starting the Gaia v4.0.x instance to resume the Cosmos hub chain at a height of + 1. -Specific instructions for validators are available in [Upgrade Procedure](#upgrade-procedure), +Specific instructions for validators are available in [Upgrade Procedure](#upgrade-procedure), and specific instructions for full node operators are available in [Guidance for Full Node Operators](#guidance-for-full-node-operators). Upgrade coordination and support for validators will be available on the #validators-verified channel of the [Cosmos Discord](https://discord.gg/cosmosnetwork). The network upgrade can take the following potential pathways: + 1. Happy path: Validator successfully migrates the cosmoshub-3 genesis file to a cosmoshub-4 genesis file, and the validator can successfully start Gaia v4 with the cosmoshub-4 genesis within 1-2 hours of the scheduled upgrade. 1. Not-so-happy path: Validators have trouble migrating the cosmoshub-3 genesis to a cosmoshub-4 genesis, but can obtain the genesis file from the Cosmos mainnet github repo and can successfully start Gaia v4 within 1-2 hours of the scheduled upgrade. -1. Abort path: In the rare event that the team becomes aware of critical issues, which result in an unsuccessful migration within a few hours, the upgrade will be announced as aborted - on the #validators-verified channel of [Discord](https://discord.gg/cosmosnetwork), and validators will need to resume running cosmoshub-3 network without any updates or changes. +1. Abort path: In the rare event that the team becomes aware of critical issues, which result in an unsuccessful migration within a few hours, the upgrade will be announced as aborted + on the #validators-verified channel of [Discord](https://discord.gg/cosmosnetwork), and validators will need to resume running cosmoshub-3 network without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community. # Migrations @@ -66,7 +67,7 @@ If you’re running a block explorer, wallet, exchange, validator, or any other If you want to test the procedure before the update happens on 18th of February, please see this post accordingly: -https://github.com/cosmos/gaia/issues/569#issuecomment-767910963 + ## Preliminary @@ -75,8 +76,8 @@ major upgrade (`cosmoshub-3`). These changes notably consist of many new feature protocol changes, and application structural changes that favor developer ergonomics and application development. -First and foremost, [IBC](https://docs.cosmos.network/main/ibc/overview.html) following -the [Interchain Standads](https://github.com/cosmos/ics#ibc-quick-references) will be enabled. +First and foremost, [IBC](https://docs.cosmos.network/main/ibc/overview.html) following +the [Interchain Standads](https://github.com/cosmos/ics#ibc-quick-references) will be enabled. This upgrade comes with several improvements in efficiency, node synchronization and following blockchain upgrades. More details on the [Stargate Website](https://stargate.cosmos.network/). @@ -89,20 +90,20 @@ Validators should expect that at least 16GB of RAM needs to be provisioned to pr ## Major Updates There are many notable features and changes in the upcoming release of the SDK. Many of these -are discussed at a high level +are discussed at a high level [here](https://github.com/cosmos/stargate). Some of the biggest changes to take note on when upgrading as a developer or client are the the following: -- **Protocol Buffers**: Initially the Cosmos SDK used Amino codecs for nearly all encoding and decoding. +- __Protocol Buffers__: Initially the Cosmos SDK used Amino codecs for nearly all encoding and decoding. In this version a major upgrade to Protocol Buffers have been integrated. It is expected that with Protocol Buffers applications gain in speed, readability, convinience and interoperability with many programming languages. [Read more](https://github.com/cosmos/cosmos-sdk/blob/master/docs/migrations/app_and_modules.md#protocol-buffers) -- **CLI**: The CLI and the daemon for a blockchain were seperated in previous versions of the Cosmos SDK. This +- __CLI__: The CLI and the daemon for a blockchain were seperated in previous versions of the Cosmos SDK. This led to a `gaiad` and `gaiacli` binary which were seperated and could be used for different interactions with the blockchain. Both of these have been merged into one `gaiad` which now supports the commands the `gaiacli` previously supported. -- **Node Configuration**: Previously blockchain data and node configuration was stored in `~/.gaia/`, these will +- __Node Configuration__: Previously blockchain data and node configuration was stored in `~/.gaia/`, these will now reside in `~/.gaia/`, if you use scripts that make use of the configuration or blockchain data, make sure to update the path. ## Risks @@ -154,13 +155,13 @@ The version/commit hash of Gaia v2.0.15: `89cf7e6fc166eaabf47ad2755c443d455feda0 perl -i -pe 's/^halt-time =.*/halt-time = 1613628000/' ~/.gaia/config/app.toml ``` - 1. After the chain has halted, make a backup of your `.gaia` directory +1. After the chain has halted, make a backup of your `.gaia` directory ```bash mv ~/.gaia ./gaiad_backup ``` - **NOTE**: It is recommended for validators and operators to take a full data snapshot at the export + __NOTE__: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating `cosmoshub-3`. See [Recovery](#recovery) for details on how to proceed. @@ -168,7 +169,7 @@ The version/commit hash of Gaia v2.0.15: `89cf7e6fc166eaabf47ad2755c443d455feda0 1. Export existing state from `cosmoshub-3`: Before exporting state via the following command, the `gaiad` binary must be stopped! - As a validator, you can see the last block height created in the + As a validator, you can see the last block height created in the `~/.gaia/data/priv_validator_state.json` - or now residing in `gaiad_backup` when you made a backup as in the last step - and obtain it with @@ -177,13 +178,14 @@ The version/commit hash of Gaia v2.0.15: `89cf7e6fc166eaabf47ad2755c443d455feda0 ``` ```bash - $ gaiad export --height= > cosmoshub_3_genesis_export.json + gaiad export --height= > cosmoshub_3_genesis_export.json ``` + _this might take a while, you can expect an hour for this step_ 1. Verify the SHA256 of the (sorted) exported genesis file: - Compare this value with other validators / full node operators of the network. + Compare this value with other validators / full node operators of the network. Going forward it will be important that all parties can create the same genesis file export. ```bash @@ -192,13 +194,13 @@ The version/commit hash of Gaia v2.0.15: `89cf7e6fc166eaabf47ad2755c443d455feda0 ``` 1. At this point you now have a valid exported genesis state! All further steps now require -v4.0.2 of [Gaia](https://github.com/cosmos/gaia). +v4.0.2 of [Gaia](https://github.com/cosmos/gaia). Cross check your genesis hash with other peers (other validators) in the chat rooms. - **NOTE**: Go [1.15+](https://golang.org/dl/) is required! + __NOTE__: Go [1.15+](https://golang.org/dl/) is required! ```bash - $ git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v4.0.2; make install + git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v4.0.2; make install ``` 1. Verify you are currently running the correct version (v4.0.2) of the _Gaia_: @@ -211,12 +213,13 @@ Cross check your genesis hash with other peers (other validators) in the chat ro build_tags: netgo,ledger ... ``` + The version/commit hash of Gaia v4.0.2: `6d46572f3273423ad9562cf249a86ecc8206e207` 1. Migrate exported state from the current v2.0.15 version to the new v4.0.2 version: ```bash - $ gaiad migrate cosmoshub_3_genesis_export.json --chain-id=cosmoshub-4 --initial-height [last_cosmoshub-3_block+1] > genesis.json + gaiad migrate cosmoshub_3_genesis_export.json --chain-id=cosmoshub-4 --initial-height [last_cosmoshub-3_block+1] > genesis.json ``` This will migrate our exported state into the required `genesis.json` file to start the cosmoshub-4. @@ -228,16 +231,16 @@ Cross check your genesis hash with other peers (other validators) in the chat ro [SHA256_VALUE] genesis.json ``` - Compare this value with other validators / full node operators of the network. + Compare this value with other validators / full node operators of the network. It is important that each party can reproduce the same genesis.json file from the steps accordingly. 1. Reset state: - **NOTE**: Be sure you have a complete backed up state of your node before proceeding with this step. + __NOTE__: Be sure you have a complete backed up state of your node before proceeding with this step. See [Recovery](#recovery) for details on how to proceed. ```bash - $ gaiad unsafe-reset-all + gaiad unsafe-reset-all ``` 1. Move the new `genesis.json` to your `.gaia/config/` directory @@ -246,13 +249,13 @@ Cross check your genesis hash with other peers (other validators) in the chat ro cp genesis.json ~/.gaia/config/ ``` -1. Start your blockchain +1. Start your blockchain ```bash gaiad start ``` - Automated audits of the genesis state can take 30-120 min using the crisis module. This can be disabled by + Automated audits of the genesis state can take 30-120 min using the crisis module. This can be disabled by `gaiad start --x-crisis-skip-assert-invariants`. # Guidance for Full Node Operators @@ -278,9 +281,9 @@ Cross check your genesis hash with other peers (other validators) in the chat ro mv ~/.gaia ./gaiad_backup ``` - **NOTE**: It is recommended for validators and operators to take a full data snapshot at the export + __NOTE__: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power - comes online in a sufficient and agreed upon amount of time. That means the backup of `.gaia` should + comes online in a sufficient and agreed upon amount of time. That means the backup of `.gaia` should only take place once the chain has halted at UNIX time `1613628000`. In such a case, the chain will fallback to continue operating `cosmoshub-3`. See [Recovery](#recovery) for details on how to proceed. @@ -292,10 +295,10 @@ Cross check your genesis hash with other peers (other validators) in the chat ro 1. Install v4.0.2 of [Gaia](https://github.com/cosmos/gaia). - **NOTE**: Go [1.15+](https://golang.org/dl/) is required! + __NOTE__: Go [1.15+](https://golang.org/dl/) is required! ```bash - $ git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v4.0.2; make install + git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v4.0.2; make install ``` 1. Verify you are currently running the correct version (v4.0.2) of the _Gaia_: @@ -308,16 +311,16 @@ Cross check your genesis hash with other peers (other validators) in the chat ro build_tags: netgo,ledger ... ``` - + The version/commit hash of Gaia v4.0.2: `6d46572f3273423ad9562cf249a86ecc8206e207` 1. Reset state: - **NOTE**: Be sure you have a complete backed up state of your node before proceeding with this step. + __NOTE__: Be sure you have a complete backed up state of your node before proceeding with this step. See [Recovery](#recovery) for details on how to proceed. ```bash - $ gaiad unsafe-reset-all + gaiad unsafe-reset-all ``` 1. Move the new `genesis.json` to your `.gaia/config/` directory @@ -334,7 +337,7 @@ Cross check your genesis hash with other peers (other validators) in the chat ro Automated audits of the genesis state can take 30-120 min using the crisis module. This can be disabled by `gaiad start --x-crisis-skip-assert-invariants`. - + ## Notes for Service Providers # REST server diff --git a/docs/migration/cosmoshub-3[ES_es].md b/docs/migration/cosmoshub-3[ES_es].md index c9a2ade47d5..831b395ae93 100644 --- a/docs/migration/cosmoshub-3[ES_es].md +++ b/docs/migration/cosmoshub-3[ES_es].md @@ -48,9 +48,9 @@ Hay muchas características y cambios notables en la próxima versión del SDK. Algunos de los principales cambios que hay que tener en cuenta a la hora de actualizar como desarrollador o cliente son los siguientes: -- **Protocol Buffers**: Inicialmente el SDK de Cosmos utilizaba _codecs_ de Amino para casi toda la codificación y decodificación. En esta versión se ha integrado una importante actualización de los Protocol Buffers. Se espera que con los Protocol Buffers las aplicaciones ganen en velocidad, legibilidad, conveniencia e interoperabilidad con muchos lenguajes de programación. Para más información consulta [aquí](https://github.com/cosmos/cosmos-sdk/blob/master/docs/migrations/app_and_modules.md#protocol-buffers). -- **CLI**: El CLI y el commando de full node para la cadena de bloques estaban separados en las versiones anteriores del SDK de Cosmos. Esto dio lugar a dos binarios, `gaiad` y `gaiacli`, que estaban separados y podían utilizarse para diferentes interacciones con la cadena de bloques. Ambos se han fusionado en un solo comando `gaiad` que ahora soporta los comandos que antes soportaba el `gaiacli`. -- **Configuración del nodo**: Anteriormente los datos de la cadena de bloques y la configuración de los nodos se almacenaban en `~/.gaia/`, ahora residirán en `~/.gaia/`, si utilizas scripts que hacen uso de la configuración o de los datos de la cadena de bloques, asegúrate de actualizar la ruta. +- __Protocol Buffers__: Inicialmente el SDK de Cosmos utilizaba _codecs_ de Amino para casi toda la codificación y decodificación. En esta versión se ha integrado una importante actualización de los Protocol Buffers. Se espera que con los Protocol Buffers las aplicaciones ganen en velocidad, legibilidad, conveniencia e interoperabilidad con muchos lenguajes de programación. Para más información consulta [aquí](https://github.com/cosmos/cosmos-sdk/blob/master/docs/migrations/app_and_modules.md#protocol-buffers). +- __CLI__: El CLI y el commando de full node para la cadena de bloques estaban separados en las versiones anteriores del SDK de Cosmos. Esto dio lugar a dos binarios, `gaiad` y `gaiacli`, que estaban separados y podían utilizarse para diferentes interacciones con la cadena de bloques. Ambos se han fusionado en un solo comando `gaiad` que ahora soporta los comandos que antes soportaba el `gaiacli`. +- __Configuración del nodo__: Anteriormente los datos de la cadena de bloques y la configuración de los nodos se almacenaban en `~/.gaia/`, ahora residirán en `~/.gaia/`, si utilizas scripts que hacen uso de la configuración o de los datos de la cadena de bloques, asegúrate de actualizar la ruta. ## Riesgos @@ -92,12 +92,14 @@ El hash de la versión/commit de Gaia v2.0.15: `89cf7e6fc166eaabf47ad2755c443d45 ```bash perl -i -pe 's/^halt-time =.*/halt-time = 1613628000/' ~/.gaia/config/app.toml ``` + 1. Después de que la cadena se haya detenido, haz una copia de seguridad de tu directorio `.gaia`. ```bash mv ~/.gaia ./gaiad_backup ``` - **NOTA**: Se recomienda a los validadores y operadores que tomen una instantánea completa de los datos a la altura de la exportación antes de proceder en caso de que la actualización no vaya según lo previsto o si no se pone en línea suficiente poder de voto en un tiempo determinado y acordado. En tal caso, la cadena volverá a funcionar con `cosmoshub-3`. Consulte [Recuperación](#recuperación) para saber cómo proceder. + + __NOTA__: Se recomienda a los validadores y operadores que tomen una instantánea completa de los datos a la altura de la exportación antes de proceder en caso de que la actualización no vaya según lo previsto o si no se pone en línea suficiente poder de voto en un tiempo determinado y acordado. En tal caso, la cadena volverá a funcionar con `cosmoshub-3`. Consulte [Recuperación](#recuperación) para saber cómo proceder. 1. Exportar el estado existente de `cosmoshub-3`: @@ -106,10 +108,11 @@ El hash de la versión/commit de Gaia v2.0.15: `89cf7e6fc166eaabf47ad2755c443d45 ```bash cat ~/.gaia/config/data/priv_validator_state.json | jq '.height' ``` - + ```bash - $ gaiad export --for-zero-height --height= > cosmoshub_3_genesis_export.json + gaiad export --for-zero-height --height= > cosmoshub_3_genesis_export.json ``` + _esto puede llevar un tiempo, puede esperar una hora para este paso_ 1. Verifique el SHA256 del archivo génesis exportado (ordenado): @@ -125,10 +128,10 @@ El hash de la versión/commit de Gaia v2.0.15: `89cf7e6fc166eaabf47ad2755c443d45 1. En este punto, ya tiene un estado de génesis exportado válido. Todos los pasos posteriores requieren ahora v4.0.0 de [Gaia](https://github.com/cosmos/gaia). Compruebe el hash de su génesis con otros compañeros (otros validadores) en las salas de chat. - **NOTA**: Go [1.15+](https://golang.org/dl/) es necesario! + __NOTA__: Go [1.15+](https://golang.org/dl/) es necesario! ```bash - $ git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v4.0.0; make install + git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v4.0.0; make install ``` 1. Verifique que está ejecutando la versión correcta (v4.0.0) de _Gaia_: @@ -144,12 +147,13 @@ Compruebe el hash de su génesis con otros compañeros (otros validadores) en la build_deps: ... ``` + El hash y versión/commit de Gaia v4.0.0: `2bb04266266586468271c4ab322367acbf41188f` 1. Migrar el estado exportado de la versión actual v2.0.15 a la nueva versión v4.0.0: ```bash - $ gaiad migrate cosmoshub_3_genesis_export.json --chain-id=cosmoshub-4 --initial-height [last_cosmoshub-3_block+1] > genesis.json + gaiad migrate cosmoshub_3_genesis_export.json --chain-id=cosmoshub-4 --initial-height [last_cosmoshub-3_block+1] > genesis.json ``` Esto migrará nuestro estado exportado del archivo `genesis.json` requerido para iniciar el cosmoshub-4. @@ -161,16 +165,16 @@ Compruebe el hash de su génesis con otros compañeros (otros validadores) en la [SHA256_VALUE] genesis.json ``` - Compare este valor con otros validadores / operadores de nodos de la red. + Compare este valor con otros validadores / operadores de nodos de la red. Es importante que cada parte pueda reproducir el mismo archivo genesis.json de los pasos correspondientes. 1. Reinicio del estado: - **NOTA**: Asegúrese de tener una copia de seguridad completa de su nodo antes de proceder con este paso. + __NOTA__: Asegúrese de tener una copia de seguridad completa de su nodo antes de proceder con este paso. Consulte [Recuperación](#recuperación) para obtener detalles sobre cómo proceder. ```bash - $ gaiad unsafe-reset-all + gaiad unsafe-reset-all ``` 1. Mueve el nuevo `genesis.json` a tu directorio `.gaia/config/`. @@ -185,7 +189,7 @@ Compruebe el hash de su génesis con otros compañeros (otros validadores) en la gaiad start ``` - Las auditorías automatizadas del estado de génesis pueden durar entre 30 y 120 minutos utilizando el módulo de crisis. Esto se puede desactivar mediante + Las auditorías automatizadas del estado de génesis pueden durar entre 30 y 120 minutos utilizando el módulo de crisis. Esto se puede desactivar mediante `gaiad start --x-crisis-skip-assert-invariants`. ## Notas para los proveedores de servicios diff --git a/docs/migration/cosmoshub-3[KR_kr].md b/docs/migration/cosmoshub-3[KR_kr].md index 7c1e43a2ed0..8b27038f042 100644 --- a/docs/migration/cosmoshub-3[KR_kr].md +++ b/docs/migration/cosmoshub-3[KR_kr].md @@ -10,13 +10,13 @@ order: false 현재 `cosmoshub-3`에서는 `Cosmos Hub 4 Upgrade Proposal`에 대한 사회적 합의가 도달된 것으로 판단됩니다. 프로포절 #[27](https://www.mintscan.io/cosmos/proposals/27), #[35](https://www.mintscan.io/cosmos/proposals/35) and #[36](https://www.mintscan.io/cosmos/proposals/36)의 내용에 따라 업그레이드 과정은 `2021년 2월 18일, 06:00 UTC`에 진행될 예정입니다. - - [마이그레이션](#마이그레이션) - - [사전 정보](#사전-정보) - - [주요 업데이트](#주요-업데이트) - - [위험 고지](#위험-고지) - - [복구](#복구) - - [업그레이드 절차](#업그레이드-절차) - - [서비스 제공자에 대한 공지](#서비스-제공자에-대한-공지) +- [마이그레이션](#마이그레이션) +- [사전 정보](#사전-정보) +- [주요 업데이트](#주요-업데이트) +- [위험 고지](#위험-고지) +- [복구](#복구) +- [업그레이드 절차](#업그레이드-절차) +- [서비스 제공자에 대한 공지](#서비스-제공자에-대한-공지) # 마이그레이션 @@ -56,15 +56,12 @@ __이번 업그레이드에서 풀 노드 운영자 업그레이드를 진행하 - **CLI**: 이전 버전의 코스모스 SDK에서는 블록체인의 CLI와 데몬은 별도의 바이너리로 구성되었으며, 실행하는 블록체인 인터랙션에 따라 `gaiad`와 `gaiacli` 바이너리가 구분되었습니다. 이번 버전의 코스모스 SDK에서는 두 바이너리가 하나의 `gaiad` 바이너리로 통합되었으며 해당 바이너리 내에서 기존에 `gaiacli`에서 사용했던 명령어를 지원합니다. - **노드 구성**: 이전 버전의 코스모스 SDK에서는 블록체인 데이터와 노드 설정이 `~/.gaia/`에 저장되었지만, 이번 버전에서는 해당 정보다 `~/.gaia/` 디렉토리에 보관됩니다. 만약 블록체인 데이터 또는 노드 설정을 관리하는 스크립트를 사용하시는 경우 해당 스크립트에서 패스를 변경해야합니다. - ## 위험 고지 검증인이 컨센서스 노드 업그레이드를 진행하는 절차에서 이중서명에 따른 슬래싱의 위험이 존재합니다. 이 과정에서 가장 중요한 것은 검증인을 가동하고 서명을 시작하기 전 소프트웨어 버전을 확인하고 제네시스 파일의 해시를 확인하시기를 바랍니다. 블록체인 검증인이 할 수 있는 가장 위험한 행동은 네트워크 시작 과정에서 존재했던 실수를 인지하고 업그레이드 과정을 처음부터 다시 시작하는 것입니다. 만약 업그레이드 과정에서 실수가 발생했다면 네트워크가 시작되는 것을 기다린 후에 실수를 고치는 것을 권장합니다. 만약 네트워크가 중단되었고 본인의 검증인을 실제 시작된 네트워크가 아닌 다른 제네시스 파일로 가동한 경우, 검증인을 리셋하는 과정에 대해 텐더민트 검증인으로 부터 조언을 구할 것을 권장합니다. - - ## 복구 각 검증인은 `cosmoshub-3` 상태를 내보내기(export) 전에 내보내는 블록 하이트의 풀 데이터 스냅샷을 진행할 것을 권장합니다. 스냅샷 과정은 각 검증인의 인프라에 따라 다를 수 있지만, 통상 `.gaia` 디렉토리를 백업하는 것으로 진행합니다. @@ -73,10 +70,9 @@ __이번 업그레이드에서 풀 노드 운영자 업그레이드를 진행하 만약 업그레이드 과정이 실패하는 경우, 검증인과 노드 운영자는 gaia v2.0.15(코스모스 SDK v0.37.15 기반)으로 다운그레이드를 진행하고 가장 최근 진행했던 스냅샷을 복구한 이후에 노드를 시작해야합니다. +## 업그레이드 -## 업그레이드 - -__참고__: 이 가이드는 코스모스 SDK의 v0.37.15 기반의 gaia v2.0.15를 운영한다는 가정에 작성된 가이드입니다. +**참고**: 이 가이드는 코스모스 SDK의 v0.37.15 기반의 gaia v2.0.15를 운영한다는 가정에 작성된 가이드입니다. Gaia v2.0.15의 버전/커밋 해시값: `89cf7e6fc166eaabf47ad2755c443d455feda02e` @@ -101,27 +97,27 @@ Gaia v2.0.15의 버전/커밋 해시값: `89cf7e6fc166eaabf47ad2755c443d455feda0 perl -i -pe 's/^halt-time =.*/halt-time = 1613628000/' ~/.gaia/config/app.toml ``` - 1. 체인이 멈춘 후 `.gaia` 디렉토리를 백업하세요 - +1. 체인이 멈춘 후 `.gaia` 디렉토리를 백업하세요 ```bash mv ~/.gaia ./gaiad_backup ``` **참고**: 업그레이드 과정이 예상 외로 실패하거나 합의된 시간 내에 새로운 체인에 충분한 보팅 파워가 참여하지 않는 경우를 대비해 검증인과 노드 운영자는 export height의 풀 데이터 스냅샷을 진행하는 것을 권장합니다. 이 경우에는 체인 업그레이드 과정은 보류되고 `cosmoshub-3`의 운영이 재개됩니다. 해당 과정에 대해서는 [복구](#복구) 항목을 참고하세요. - + 1. 기존 `cosmoshub-3`의 상태를 내보내기: 다음 명령어를 사용하여 상태를 내보내기 전 `gaiad` 바이너리가 꼭 멈춰있어야 합니다! 검증인으로서 가장 최근 생성된 블록은 `~/.gaia/config/data/priv_validator_state.json`에서 확인하실 수 있습니다 (또는 이전 과정에서 백업을 진행한 경우 `gaiad_backup`). 블록 높이는 다음과 같이 확인하세요 - + ```bash cat ~/.gaia/config/data/priv_validator_state.json | jq '.height' ``` ```bash - $ gaiad export --for-zero-height --height= > cosmoshub_3_genesis_export.json + gaiad export --for-zero-height --height= > cosmoshub_3_genesis_export.json ``` + _이 과정은 상당한 시간이 (약 1시간) 소요될 수 있습니다_ 1. 내보낸 제네시스 파일의 SHA256 값을 검증하세요: @@ -139,7 +135,7 @@ Gaia v2.0.15의 버전/커밋 해시값: `89cf7e6fc166eaabf47ad2755c443d455feda0 **참고**: Go [1.15+](https://golang.org/dl/) 버전이 설치되어야 합니다! ```bash - $ git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v4.0.0; make install + git clone https://github.com/cosmos/gaia.git && cd gaia && git checkout v4.0.0; make install ``` 1. _Gaia_의 올바른 버전(v4.0.0)을 운영하고 있는 것을 확인하세요: @@ -155,12 +151,13 @@ Gaia v2.0.15의 버전/커밋 해시값: `89cf7e6fc166eaabf47ad2755c443d455feda0 build_deps: ... ``` + Gaia v4.0.0 버전/커밋 해시 : `2bb04266266586468271c4ab322367acbf41188f` 1. 내보낸 상태를 기존 v2.0.15 버전에서 v4.0.0 버전으로 마이그레이션 하세요: ```bash - $ gaiad migrate cosmoshub_3_genesis_export.json --chain-id=cosmoshub-4 --initial-height [last_cosmoshub-3_block+1] > genesis.json + gaiad migrate cosmoshub_3_genesis_export.json --chain-id=cosmoshub-4 --initial-height [last_cosmoshub-3_block+1] > genesis.json ``` 이 과정은 이전 체인에서 내보낸 상태를 기반으로 `cosmoshub-4`로 시작하기 위한 `genesis.json` 파일을 생성합니다. @@ -180,7 +177,7 @@ Gaia v2.0.15의 버전/커밋 해시값: `89cf7e6fc166eaabf47ad2755c443d455feda0 **참고**: 이 과정을 진행하기 전에 꼭 노드의 상태를 백업하세요. 백업 과정은 [복구](#복구) 항복을 참고하세요 ```bash - $ gaiad unsafe-reset-all + gaiad unsafe-reset-all ``` 1. 새로운 `genesis.json`을 `.gaia/config/` 디렉토리로 옮기세요: diff --git a/docs/migration/cosmoshub-4-delta-upgrade.md b/docs/migration/cosmoshub-4-delta-upgrade.md index ed99260299e..5144ae5f0c4 100644 --- a/docs/migration/cosmoshub-4-delta-upgrade.md +++ b/docs/migration/cosmoshub-4-delta-upgrade.md @@ -5,9 +5,10 @@ order: 4 # Cosmos Hub 4, Delta Upgrade, Instructions -This document describes the steps for validator and full node operators for the successful execution of the [Delta Upgrade](https://github.com/cosmos/gaia/blob/main/docs/roadmap/cosmos-hub-roadmap-2.0.md#Delta-Upgrade), which adds the __Gravity DEX__ to the Cosmos Hub. +This document describes the steps for validator and full node operators for the successful execution of the [Delta Upgrade](https://github.com/cosmos/gaia/blob/main/docs/roadmap/cosmos-hub-roadmap-2.0.md#Delta-Upgrade), which adds the __Gravity DEX__ to the Cosmos Hub. TOC: + - [On-chain governance proposal attains consensus](#on-chain-governance-proposal-attains-consensus) - [Upgrade will take place July 12, 2021](#upgrade-will-take-place-july-12-2021) - [Chain-id will remain the same](#chain-id-will-remain-the-same) @@ -54,11 +55,11 @@ Validator and full node operators that wish to test their systems on a public te ### Current runtime, cosmoshub-4 (pre-Delta upgrade) is running Gaia v4.2.1 -The Cosmos Hub mainnet network, `cosmoshub-4`, is currently running [Gaia v4.2.1](https://github.com/cosmos/gaia/releases/tag/v4.2.1). We anticipate that operators who are running earlier versions of Gaia, e.g., v4.2.x, will be able to upgrade successfully; however, this is untested and it is up to operators to ensure that their systems are capable of performing the upgrade. +The Cosmos Hub mainnet network, `cosmoshub-4`, is currently running [Gaia v4.2.1](https://github.com/cosmos/gaia/releases/tag/v4.2.1). We anticipate that operators who are running earlier versions of Gaia, e.g., v4.2.x, will be able to upgrade successfully; however, this is untested and it is up to operators to ensure that their systems are capable of performing the upgrade. ### Target runtime, cosmoshub-4 (post-Delta upgrade) will run Gaia v5.0.0 -The Comsos Hub mainnet network, `cosmoshub-4`, will run [Gaia v5.0.0](https://github.com/cosmos/gaia/releases/tag/v5.0.0). Operators _MUST_ use this version post-upgrade to remain connected to the network. +The Comsos Hub mainnet network, `cosmoshub-4`, will run [Gaia v5.0.0](https://github.com/cosmos/gaia/releases/tag/v5.0.0). Operators _MUST_ use this version post-upgrade to remain connected to the network. ## Delta upgrade steps @@ -71,7 +72,7 @@ The following steps assume that an operator is running v4.2.1 (running an earlie > > panic: UPGRADE "Gravity-DEX" NEEDED at height: 6910000: v5.0.0-4760cf1f1266accec7a107f440d46d9724c6fd08 -**IMPORTANT: PLEASE WAIT FOR THE BINARY TO HALT ON ITS OWN**. Do NOT shutdown the node yourself. If the node shuts down before the panic message, start the node and let it run until the panic stops the node for you. +__IMPORTANT: PLEASE WAIT FOR THE BINARY TO HALT ON ITS OWN__. Do NOT shutdown the node yourself. If the node shuts down before the panic message, start the node and let it run until the panic stops the node for you. 3. Important note to all validators: Although the upgrade path is essentially to replace the binary when the software panics and halts at the upgrade height, an important disaster recovery operation is to take a snapshot of your state after the halt and before starting v5.0.0. @@ -79,8 +80,8 @@ The following steps assume that an operator is running v4.2.1 (running an earlie cp -r ~/.gaia ./gaia_backup ``` -Note: use the home directory relevant to your node's Gaia configuration (if different from `~/.gaia`). - +Note: use the home directory relevant to your node's Gaia configuration (if different from `~/.gaia`). + 4. Replace the Gaia v4.2.1 binary with the Gaia v5.0.0 binary 5. Start the Gaia v5.0.0 binary using the following command (also applying any additional flags and parameters to the binary needed by the operator, e.g., `--home $HOME`): @@ -91,8 +92,8 @@ IMPORTANT: The flag `--x-crisis-skip-assert-invariants` is optional and can be u 5. Wait until 2/3+ of voting power has upgraded for the network to start producing blocks 6. You can use the following commands to check peering status and state: -> curl -s http://127.0.0.1:26657/net_info | grep n_peers -> +> curl -s | grep n_peers +> > curl -s localhost:26657/consensus_state | jq -r .result.round_state.height_vote_set[].prevotes_bit_array ## Upgrade duration @@ -101,7 +102,7 @@ The upgrade may take several hours to complete because cosmoshub-4 participants ## Rollback plan -During the network upgrade, core Cosmos teams will be keeping an ever vigilant eye and communicating with operators on the status of their upgrades. During this time, the core teams will listen to operator needs to determine if the upgrade is experiencing unintended challenges. In the event of unexpected challenges, the core teams, after conferring with operators and attaining social consensus, may choose to declare that the upgrade will be skipped. +During the network upgrade, core Cosmos teams will be keeping an ever vigilant eye and communicating with operators on the status of their upgrades. During this time, the core teams will listen to operator needs to determine if the upgrade is experiencing unintended challenges. In the event of unexpected challenges, the core teams, after conferring with operators and attaining social consensus, may choose to declare that the upgrade will be skipped. Steps to skip this upgrade proposal are simply to resume the cosmoshub-4 network with the (downgraded) v4.2.1 binary using the following command: @@ -119,15 +120,16 @@ Operators are encouraged to join the `#validators-verified` channel of the Cosmo As a validator performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing. -The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. +The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. ## FAQ 1. If I am a new operator and I want to join the network, what should I do? In order to join the cosmoshub-4 network after the Delta upgrade, you have two options: - - Use a post-delta upgrade state snapshot, such as one provided by [quicksync](https://cosmos.quicksync.io/) and start a node using the gaia v5.0.0 binary. - - If not using a snapshot, or using a pre-delta upgrade snapshot, sync with the network using the gaia v4.2.1 binary until the upgrade height and panic, then switch the gaia binary for v5.0.0. + +- Use a post-delta upgrade state snapshot, such as one provided by [quicksync](https://cosmos.quicksync.io/) and start a node using the gaia v5.0.0 binary. +- If not using a snapshot, or using a pre-delta upgrade snapshot, sync with the network using the gaia v4.2.1 binary until the upgrade height and panic, then switch the gaia binary for v5.0.0. 2. Does the post-Delta upgrade introduce any changes of note? diff --git a/docs/migration/cosmoshub-4-v7-Theta-upgrade.md b/docs/migration/cosmoshub-4-v7-Theta-upgrade.md index 5703b62a566..996dcd2932b 100644 --- a/docs/migration/cosmoshub-4-v7-Theta-upgrade.md +++ b/docs/migration/cosmoshub-4-v7-Theta-upgrade.md @@ -5,8 +5,8 @@ order: 2 # Cosmos Hub 4, v7-Theta Upgrade, Instructions - This document describes the steps for validator and full node operators for the successful execution of the [v7-Theta Upgrade](https://github.com/cosmos/gaia/blob/main/docs/roadmap/cosmos-hub-roadmap-2.0.md#v7-theta-upgrade-expected-q1-2022), which contains the following main new features/improvement: + - [cosmos-sdk](https://github.com/cosmos/cosmos-sdk) to [v0.45.1](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.1). See [CHANGELOG.md](https://github.com/cosmos/cosmos-sdk/blob/v0.45.1/CHANGELOG.md#v0451---2022-02-03) for details. - [ibc-go](https://github.com/cosmos/ibc-go) module to [v3.0.0](https://github.com/cosmos/ibc-go/releases/tag/v3.0.0). See [CHANGELOG.md](https://github.com/cosmos/ibc-go/blob/v3.0.0/CHANGELOG.md#v300---2022-03-15) for details. - [interchain account](https://github.com/cosmos/ibc-go/tree/main/modules/apps/27-interchain-accounts) module (interhchain-account module is part of ibc-go module). @@ -15,6 +15,7 @@ This document describes the steps for validator and full node operators for the - Migration logs for upgrade process. TOC: + - [Cosmos Hub 4, v7-Theta Upgrade, Instructions](#cosmos-hub-4-v7-theta-upgrade-instructions) - [On-chain governance proposal attains consensus](#on-chain-governance-proposal-attains-consensus) - [Upgrade will take place April 12, 2022](#upgrade-will-take-place-april-12-2022) @@ -39,7 +40,6 @@ TOC: - [Risks](#risks) - [Reference](#reference) - ## On-chain governance proposal attains consensus [Proposal #65](https://www.mintscan.io/cosmos/proposals/65) is the reference on-chain governance proposal for this upgrade, which has passed with overwhleming community support. Neither core developers nor core funding entities control the governance, and this governance proposal has passed in a _fully decentralized_ way. @@ -55,6 +55,7 @@ The chain-id of the network will remain the same, `cosmoshub-4`. This is because ## Preparing for the upgrade ### System requirement + 32GB RAM is recommended to ensure a smooth upgrade. If you have less than 32GB RAM, you might try creating a swapfile to swap an idle program onto the hard disk to free up memory. This can @@ -87,7 +88,9 @@ The Cosmos Hub mainnet network, `cosmoshub-4`, is currently running [Gaia v6.0.4 The Comsos Hub mainnet network, `cosmoshub-4`, will run [Gaia v7.0.0](https://github.com/cosmos/gaia/releases/tag/v7.0.0). Operators _MUST_ use this version post-upgrade to remain connected to the network. ## v7-Theta upgrade steps + There are 2 major ways to upgrade a node: + - Manual upgrade - Upgrade using [Cosmovisor](https://github.com/cosmos/cosmos-sdk/tree/master/cosmovisor) - Either by manually preparing the new binary @@ -96,38 +99,47 @@ There are 2 major ways to upgrade a node: If you prefer to use Cosmovisor to upgrade, some preparation work is needed before upgrade. ### Method I: manual upgrade + Run Gaia v6.0.x till upgrade height, the node will panic: + ```shell ERR UPGRADE "v7-Theta" NEEDED at height: 10085397 panic: UPGRADE "v7-Theta" NEEDED at height: 10085397 ``` + Stop the node, and install Gaia v7.0.0 and re-start by `gaiad start`. It may take 7 minutes to a few hours until validators with a total sum voting power > 2/3 to complete their nodes upgrades. After that, the chain can continue to produce blocks. ### Method II: upgrade using Cosmovisor by manually preparing the Gaia v7.0.0 binary + #### Preparation Install the latest version of Cosmovisor: + ```shell go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@latest ``` Create a cosmovisor folder: -create a Cosmovisor folder inside `$GAIA_HOME` and move Gaia v6.0.4 into ` $GAIA_HOME/cosmovisor/genesis/bin` +create a Cosmovisor folder inside `$GAIA_HOME` and move Gaia v6.0.4 into `$GAIA_HOME/cosmovisor/genesis/bin` + ```shell mkdir -p $GAIA_HOME/cosmovisor/genesis/bin cp $(which gaiad) $GAIA_HOME/cosmovisor/genesis/bin ```` + build Gaia v7.0.0, and move gaiad v7.0.0 to `$GAIA_HOME/cosmovisor/upgrades/v7-Theta/bin` ```shell mkdir -p $GAIA_HOME/cosmovisor/upgrades/v7-Theta/bin cp $(which gaiad) $GAIA_HOME/cosmovisor/upgrades/v7-Theta/bin ``` + Then you should get the following structure: + ```shell . ├── current -> genesis or upgrades/ @@ -139,7 +151,9 @@ Then you should get the following structure: └── bin └── gaiad #v7.0.0 ``` + Export the environmental variables: + ```shell export DAEMON_NAME=gaiad # please change to your own gaia home dir @@ -148,29 +162,38 @@ export DAEMON_RESTART_AFTER_UPGRADE=true ``` Start the node: + ```shell cosmovisor start --x-crisis-skip-assert-invariants ``` + Skipping the invariant checks is strongly encouraged since it decreases the upgrade time significantly and since there are some other improvements coming to the crisis module in the next release of the Cosmos SDK. #### Expected ugprade result + When the upgrade block height is reached, you can find the following information in the log: + ```shell ERR UPGRADE "v7-Theta" NEEDED at height: 10085397: upgrade to v7-Theta and applying upgrade "v7-Theta" at height:10085397. ``` + This may take 7 minutes to a few hours. After upgrade, the chain will continue to produce blocks when validators with a total sum voting power > 2/3 complete their nodes upgrades. ### Method III: upgrade using Cosmovisor by auto-downloading the Gaia v7.0.0 binary (not recommended!) + #### Preparation + Install Cosmovisor v1.1.0 + ```shell go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@latest ``` Create a cosmovisor folder: -create a cosmovisor folder inside gaia home and move gaiad v6.0.4 into ` $GAIA_HOME/cosmovisor/genesis/bin` +create a cosmovisor folder inside gaia home and move gaiad v6.0.4 into `$GAIA_HOME/cosmovisor/genesis/bin` + ```shell mkdir -p $GAIA_HOME/cosmovisor/genesis/bin cp $(which gaiad) $GAIA_HOME/cosmovisor/genesis/bin @@ -183,7 +206,9 @@ cp $(which gaiad) $GAIA_HOME/cosmovisor/genesis/bin └── bin └── gaiad #v6.0.4 ``` + Export the environmental variables: + ```shell export DAEMON_NAME=gaiad # please change to your own gaia home dir @@ -191,22 +216,27 @@ export DAEMON_HOME= $GAIA_HOME export DAEMON_RESTART_AFTER_UPGRADE=true export DAEMON_ALLOW_DOWNLOAD_BINARIES=true ``` + Start the node: + ```shell cosmovisor start --x-crisis-skip-assert-invariants ``` -Skipping the invariant checks is strongly encouraged since it decreases the upgrade time significantly and since there are some other improvements coming to the crisis module in the next release of the Cosmos SDK. +Skipping the invariant checks is strongly encouraged since it decreases the upgrade time significantly and since there are some other improvements coming to the crisis module in the next release of the Cosmos SDK. #### Expected result + When the upgrade block height is reached, you can find the following information in the log: + ```shell ERR UPGRADE "v7-Theta" NEEDED at height: 10085397: upgrade to v7-Theta and applying upgrade "v7-Theta" at height:10085397 ``` -Then the Cosmovisor will create `$GAIA_HOME/cosmovisor/upgrades/v7-Theta/bin` and download Gaia v7.0.0 binary to this folder according to links in the ` --info` field of the upgrade proposal 65. + +Then the Cosmovisor will create `$GAIA_HOME/cosmovisor/upgrades/v7-Theta/bin` and download Gaia v7.0.0 binary to this folder according to links in the `--info` field of the upgrade proposal 65. This may take 7 minutes to a few hours, afterwards, the chain will continue to produce blocks once validators with a total sum voting power > 2/3 complete their nodes upgrades. -*Please Note:* +_Please Note:_ - In general, auto-download comes with the risk that the verification of correct download is done automatically. If users want to have the highest guarantee users should confirm the check-sum manually. We hope more node operators will use the auto-download for this release but please be aware this is a risk and users should take at your own discretion. - Users should use run node on v6.0.4 if they use the cosmovisor v1.1.0 with auto-download enabled for upgrade process. @@ -238,6 +268,7 @@ As a validator performing the upgrade procedure on your consensus nodes carries The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. ## Reference + [cosmos/v7-Theta-test](https://github.com/cosmos/testnets/tree/master/v7-theta) [join Cosmos Hub Mainnet](https://github.com/cosmos/mainnet) diff --git a/docs/migration/cosmoshub-4-vega-upgrade.md b/docs/migration/cosmoshub-4-vega-upgrade.md index 45b342bf55e..aba45b3ac74 100644 --- a/docs/migration/cosmoshub-4-vega-upgrade.md +++ b/docs/migration/cosmoshub-4-vega-upgrade.md @@ -5,25 +5,26 @@ order: 3 # Cosmos Hub 4, Vega Upgrade, Instructions - This document describes the steps for validator and full node operators for the successful execution of the [Vega Upgrade](https://github.com/cosmos/gaia/blob/main/docs/roadmap/cosmos-hub-roadmap-2.0.md#vega-upgrade-expected-q4-2021), which contains the following main new features: -- [authz](https://github.com/cosmos/cosmos-sdk/tree/v0.44.3/x/authz/spec) and [feegrant modules](https://github.com/cosmos/cosmos-sdk/tree/v0.44.3/x/feegrant/spec) + +- [authz](https://github.com/cosmos/cosmos-sdk/tree/v0.44.3/x/authz/spec) and [feegrant modules](https://github.com/cosmos/cosmos-sdk/tree/v0.44.3/x/feegrant/spec) - [packet-forward-middleware](https://github.com/strangelove-ventures/packet-forward-middleware) -- [IBC](https://github.com/cosmos/ibc-go) as a standalone module +- [IBC](https://github.com/cosmos/ibc-go) as a standalone module TOC: + - [On-chain governance proposal attains consensus](#on-chain-governance-proposal-attains-consensus) - [Upgrade will take place December 14, 2021](#upgrade-will-take-place-december-14-2021) - [Chain-id will remain the same](#chain-id-will-remain-the-same) - [Preparing for the upgrade](#preparing-for-the-upgrade) - - [System requirement](#system-requirement) - - [Backups](#backups) - - [Testing](#testing) - - [Current runtime, cosmoshub-4 (pre-Vega upgrade) is running Gaia v5.0.0](#current-runtime-cosmoshub-4-pre-vega-upgrade-is-running-gaia-v500) - - [Target runtime, cosmoshub-4 (post-Vega upgrade) will run Gaia v6.0.4](#target-runtime-cosmoshub-4-post-vega-upgrade-will-run-gaia-v604) + - [System requirement](#system-requirement) + - [Backups](#backups) + - [Testing](#testing) + - [Current runtime, cosmoshub-4 (pre-Vega upgrade) is running Gaia v5.0.0](#current-runtime-cosmoshub-4-pre-vega-upgrade-is-running-gaia-v500) + - [Target runtime, cosmoshub-4 (post-Vega upgrade) will run Gaia v6.0.4](#target-runtime-cosmoshub-4-post-vega-upgrade-will-run-gaia-v604) - [Vega upgrade steps](#vega-upgrade-steps) - - [Method I: manual upgrade](#method-i-manual-upgrade) - - - [Method II: upgrade using Cosmovisor by manually preparing the Gaia v6.0.4 binary](#method-ii-upgrade-using-cosmovisor-by-manually-preparing-the-gaia-v604-binary) + - [Method I: manual upgrade](#method-i-manual-upgrade) + - - [Method II: upgrade using Cosmovisor by manually preparing the Gaia v6.0.4 binary](#method-ii-upgrade-using-cosmovisor-by-manually-preparing-the-gaia-v604-binary) - [Method III: upgrade using Cosmovisor by auto-downloading the Gaia v6.0.4 binary (not recommended!)](#method-iii-upgrade-using-cosmovisor-by-auto-downloading-the-gaia-v604-binary-not-recommended) - [Upgrade duration](#upgrade-duration) - [Rollback plan](#rollback-plan) @@ -31,7 +32,6 @@ TOC: - [Risks](#risks) - [Reference](#reference) - ## On-chain governance proposal attains consensus [Proposal #59](https://www.mintscan.io/cosmos/proposals/59) is the reference on-chain governance proposal for this upgrade, which has passed with overwhleming community support. Neither core developers nor core funding entities control the governance, and this governance proposal has passed in a _fully decentralized_ way. @@ -47,6 +47,7 @@ The chain-id of the network will remain the same, `cosmoshub-4`. This is because ## Preparing for the upgrade ### System requirement + 32GB RAM is recommended to ensure a smooth upgrade. If you have less than 32GB RAM, you might try creating a swapfile to swap an idle program onto the hard disk to free up memory. This can @@ -79,7 +80,9 @@ The Cosmos Hub mainnet network, `cosmoshub-4`, is currently running [Gaia v5.0.0 The Comsos Hub mainnet network, `cosmoshub-4`, will run [Gaia v6.0.4](https://github.com/cosmos/gaia/releases/tag/v6.0.4). Operators _MUST_ use this version post-upgrade to remain connected to the network. ## Vega upgrade steps + There are 2 major ways to upgrade a node: + - Manual upgrade - Upgrade using [Cosmovisor](https://github.com/cosmos/cosmos-sdk/tree/master/cosmovisor) - Either by manually preparing the new binary @@ -88,38 +91,47 @@ There are 2 major ways to upgrade a node: If you prefer to use Cosmovisor to upgrade, some preparation work is needed before upgrade. ### Method I: manual upgrade + Run Gaia v5.0.x till upgrade height, the node will panic: + ```shell ERR UPGRADE "Vega" NEEDED at height: 8695000 panic: UPGRADE "Vega" NEEDED at height: 8695000 ``` + Stop the node, and install Gaia v6.0.4 and re-start by `gaiad start`. It may take 20 min to a few hours until validators with a total sum voting power > 2/3 to complete their nodes upgrades. After that, the chain can continue to produce blocks. ### Method II: upgrade using Cosmovisor by manually preparing the Gaia v6.0.4 binary + #### Preparation Install the latest version of Cosmovisor: + ```shell go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@latest ``` Create a cosmovisor folder: -create a Cosmovisor folder inside `$GAIA_HOME` and move Gaia v5.0.0 into ` $GAIA_HOME/cosmovisor/genesis/bin` +create a Cosmovisor folder inside `$GAIA_HOME` and move Gaia v5.0.0 into `$GAIA_HOME/cosmovisor/genesis/bin` + ```shell mkdir -p $GAIA_HOME/cosmovisor/genesis/bin cp $(which gaiad) $GAIA_HOME/cosmovisor/genesis/bin ```` + build Gaia v6.0.4, and move gaiad v6.0.4 to `$GAIA_HOME/cosmovisor/upgrades/Vega/bin` ```shell mkdir -p $GAIA_HOME/cosmovisor/upgrades/Vega/bin cp $(which gaiad) $GAIA_HOME/cosmovisor/upgrades/Vega/bin ``` + Then you should get the following structure: + ```shell . ├── current -> genesis or upgrades/ @@ -131,7 +143,9 @@ Then you should get the following structure: └── bin └── gaiad #v6.0.4 ``` + Export the environmental variables: + ```shell export DAEMON_NAME=gaiad # please change to your own gaia home dir @@ -140,28 +154,38 @@ export DAEMON_RESTART_AFTER_UPGRADE=true ``` Start the node: + ```shell cosmovisor start --x-crisis-skip-assert-invariants ``` + Skipping the invariant checks is strongly encouraged since it decreases the upgrade time significantly and since there are some other improvements coming to the crisis module in the next release of the Cosmos SDK. #### Expected ugprade result + When the upgrade block height is reached, you can find the following information in the log: + ```shell ERR UPGRADE "Vega" NEEDED at height: 8695000: upgrade to Vega and applying upgrade "Vega" at height:8695000. ``` + This may take 20 min to a few hours. After this, the chain will continue to produce blocks when validators with a total sum voting power > 2/3 complete their nodes upgrades. ### Method III: upgrade using Cosmovisor by auto-downloading the Gaia v6.0.4 binary (not recommended!) + #### Preparation + Install Cosmovisor v0.1 + ```shell go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@v0.1.0 ``` + Create a cosmovisor folder: -create a cosmovisor folder inside gaia home and move gaiad v5.0.0 into ` $GAIA_HOME/cosmovisor/genesis/bin` +create a cosmovisor folder inside gaia home and move gaiad v5.0.0 into `$GAIA_HOME/cosmovisor/genesis/bin` + ```shell mkdir -p $GAIA_HOME/cosmovisor/genesis/bin cp $(which gaiad) $GAIA_HOME/cosmovisor/genesis/bin @@ -174,7 +198,9 @@ cp $(which gaiad) $GAIA_HOME/cosmovisor/genesis/bin └── bin └── gaiad #v5.0.x ``` + Export the environmental variables: + ```shell export DAEMON_NAME=gaiad # please change to your own gaia home dir @@ -182,23 +208,30 @@ export DAEMON_HOME= $GAIA_HOME export DAEMON_RESTART_AFTER_UPGRADE=true export DAEMON_ALLOW_DOWNLOAD_BINARIES=true ``` + Start the node: + ```shell cosmovisor start --x-crisis-skip-assert-invariants ``` + Skipping the invariant checks is strongly encouraged since it decreases the upgrade time significantly and since there are some other improvements coming to the crisis module in the next release of the Cosmos SDK. #### Expected result + When the upgrade block height is reached, you can find the following information in the log: + ```shell ERR UPGRADE "Vega" NEEDED at height: 8695000: upgrade to Vega and applying upgrade "Vega" at height:8695000 ``` -Then the Cosmovisor will create `$GAIA_HOME/cosmovisor/upgrades/Vega/bin` and download Gaia v6.0.4 binary to this folder according to links in the ` --info` field of the upgrade proposal 59. + +Then the Cosmovisor will create `$GAIA_HOME/cosmovisor/upgrades/Vega/bin` and download Gaia v6.0.4 binary to this folder according to links in the `--info` field of the upgrade proposal 59. This may take 20 min to a few hours, afterwards, the chain will continue to produce blocks once validators with a total sum voting power > 2/3 complete their nodes upgrades. -*Please Note:* +_Please Note:_ Auto-download the new binary is not recommended for the following reasons: + - In general, auto-download comes with the risk that the verification of correct download is done automatically. If you want to have the highest guarantee you should confirm the check-sum manually. We hope more node operators will use the auto-download for this release but please be aware this is a risk you should take at your own discretion. - For the Vega upgrade, Gaia will upgrade its dependency on Cosmos SDK v0.42 to Cosmos SDK v0.44, this will require [Cosmovisor v0.1](https://github.com/cosmos/cosmos-sdk/releases/tag/cosmovisor%2Fv0.1.0). Later versions of Cosmovisor do not support Cosmos SDK v0.42 or earlier if the auto-download option is enabled. - By using Cosmovisor v0.1 you might experience a [node hanging issue](https://github.com/cosmos/cosmos-sdk/issues/9875) when querying a result with a large output size. For example, `gaiad q gov proposals` will hang the node being queried, this issue will not appear for Cosmovisor versions newer than v0.1. @@ -230,6 +263,7 @@ As a validator performing the upgrade procedure on your consensus nodes carries The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. ## Reference + [cosmos/vega-test](https://github.com/cosmos/vega-test) [Delta upgrade instruction](https://github.com/cosmos/gaia/blob/main/docs/migration/cosmoshub-4-delta-upgrade.md) diff --git a/docs/modules/README.md b/docs/modules/README.md index 03d4a8f1468..2ead2a97f63 100644 --- a/docs/modules/README.md +++ b/docs/modules/README.md @@ -4,5 +4,5 @@ Here you can find an overview of the modules included on the Cosmos Hub (gaia) b links for each one. ## New Modules in Rho V8 -- [Global Fee](./globalfee.md) +- [Global Fee](./globalfee.md) diff --git a/docs/modules/globalfee.md b/docs/modules/globalfee.md index 876a333b73f..a4d2a863720 100644 --- a/docs/modules/globalfee.md +++ b/docs/modules/globalfee.md @@ -3,40 +3,52 @@ ## Gaia Fees The CosmosHub has two types of fees, both of which, are the [sdk.DecCoins](https://github.com/cosmos/cosmos-sdk/blob/a1143138716b64bc4fa0aa53c0f0fa59eb675bb7/types/dec_coin.go#L158) type: + - global fees (are defined at the network level, via [Gov Proposals](https://hub.cosmos.network/main/governance/proposals/)) - min_gas_prices (are specified validator node, in the `config/app.toml` configuration file) ### Global Fees + #### Global Fees Concept -Global fees are the fees that each transaction incurs—except [bypass fee message types](###Bypass Fees Message Types). Global fees are set up through a governance proposal which must be voted on by validators. + +Global fees are the fees that each transaction incurs—except [bypass fee message types](###Bypass Fees Message Types). Global fees are set up through a governance proposal which must be voted on by validators. For [global fees](https://github.com/cosmos/gaia/blob/82c4353ab1b04cf656a8c95d226c30c7845f157b/x/globalfee/types/params.go#L54-L99) to be valid: + - fees have to be alphabetically sorted by denomination (denom) - fees must have non-negative amount, with a valid and unique denom (i.e. no duplicate denoms are allowed). Global fees allow denoms with zero coins or value. Zero value coins are used to define fee denoms, when the chain does not charge fees. Each transaction (except bypass transactions) have to meet the following global fee requirements: + - All denoms of the paid fees (except zero coins) have to be a subset of the global fee's denom set. - All paidfees' contain at least one denom that is present and greater than/or equal to the amount of the same denom in globalfee. #### Query Global Fees + CLI queries to retrieve the global fee value: + ```shell gaiad q globalfee minimum-gas-prices # or gaiad q params subspace globalfee MinimumGasPricesParam ``` + #### Empty Global Fees and Default Global Fees + When the global fee is not setup, the query will return an empty globalfee list: `minimum_gas_prices: []`. Gaiad will use `0uatom` as global fee in this case. This is due to the CosmosHub accepting uatom as fee denom by default. #### Setting Up Global Fees via Gov Proposals + An example of setting up a global fee by a gov proposals is shown below. ```shell gov submit-proposal param-change proposal.json ```` + A `proposal.json` example: + ``` { "title": "Global fees Param Change", @@ -51,16 +63,20 @@ A `proposal.json` example: "deposit": "1000stake" } ``` + Please note: in the above "value" field, coins must sorted alphabetically by denom. ### Min_gas_prices + min_gas_prices are a node's further requirement of fees. Zero coins are removed from min_gas_prices when [parsing min_gas_prices](https://github.com/cosmos/cosmos-sdk/blob/3a097012b59413641ac92f18f226c5d6b674ae42/baseapp/options.go#L27), this is different from global fees. + - If the min_gas_prices set a denom that is not global fees's denom set. This min_gas_prices denom will not be considered when paying fees. - If the min_gas_prices have a denom in global fees's denom set, and the min_gas_prices are lower than global fees, the fee still need to meet the global fees. - If the min_gas_prices have a denom in global fees's denom set, and the min_gas_prices are higher than global fees, the fee need to meet the min_gas_prices. ## Fee Checks -Global fees, min_gas_prices and the paid fees all allow zero coins setup. After parsing the fee coins, zero coins and paid fees will be removed from the min_gas_prices and paid fees. + +Global fees, min_gas_prices and the paid fees all allow zero coins setup. After parsing the fee coins, zero coins and paid fees will be removed from the min_gas_prices and paid fees. Only global fees might contain zero coins, which is used to define the allowed denoms of paid fees. @@ -69,11 +85,13 @@ The [Fee AnteHandle](../../x/globalfee/ante/fee.go) will take global fees and mi If the paid fee is a subset of the combined fees set and the paid fee amount is greater than or equal to the required fees amount, the transaction can pass the fee check, otherwise an error will occur. ### Bypass Fees Message Types + The above global fee and min_as_prices fee checks do not apply to bypass message types. Transactions of bypass message types are free of fee charge. However, if the bypass type transactions still carry nonzero fees, the denom has to be a subset of denoms that global fees defined. A node can set up its own bypass message types by modify the configuration parameter `bypass-min-fee-msg-types` in `config/app.toml` file. Nodes using `app.toml` files initialized by gaiad version of v7.0.1 or earlier might not have `bypass-min-fee-msg-types`, users can insert it before the field `[telemetry]` in `app.toml`. An example: + ```shell ############################################################################### @@ -90,17 +108,18 @@ bypass-min-fee-msg-types = ["/ibc.core.channel.v1.MsgRecvPacket", "/ibc.core.cha Even though each node can set its own `min_gas_prices` and `bypass-min-fee-msg-types`, when the transactions enters a validator's mempool, the transactions carried fees have to satisfy the validator's `min_gas_prices` and `bypass-min-fee-msg-types`'s requirement in order for the validators to process the transactions. ## Examples + Here are a few examples to clarify the relationship between global fees, min_gas_prices and paid fees. + - **Case 1**: globalfee=[], min_gas_prices=0.0001uatom, gas=2000000 This is the same case as globalfee=0uatom, min_gas_prices=0.0001uatom, gas=2000000. - paidfee = "2000000 * 0.0001uatom", pass - paidfee = "2000000 * 0.0001uatom, 0stake", pass - - paidfee = "2000000 * 0.0001uatom, 1stake", fail + - paidfee = "2000000 * 0.0001uatom, 1stake", fail - paidfee = "2000000 * 0.0001/2uatom", fail - paidfee = "", pass - - **Case 2**: globalfee=[], min_gas_prices="", gas=2000000 - paidfee = "", pass - paidfee = "0uatom", pass @@ -108,7 +127,6 @@ Here are a few examples to clarify the relationship between global fees, min_gas - paidfee = "0uatom, 0stake", pass - paidfee = "0uatom, 1stake", fail - - **Case 3**: globalfee=0.0002uatom, min_gas_prices=0.0001uatom, gas=2000000 (global fee is lower than min_as_price) - paidfee = "2000000 * 0.0002uatom", pass - paidfee = "2000000 * 0.0001uatom", fail @@ -118,7 +136,6 @@ Here are a few examples to clarify the relationship between global fees, min_gas - paidfee = "", fail - paidfee = 0uatom, fail - - **Case 4**: globalfee=0.0001uatom, min_gas_prices=0.0002uatom, gas=2000000 (global fee is higher than min_as_price) - paidfee = "2000000 * 0.0002uatom", pass - paidfee = "2000000 * 0.0001uatom", fail @@ -128,32 +145,30 @@ Here are a few examples to clarify the relationship between global fees, min_gas - paidfee = "", fail - paidfee = 0uatom, fail - - **Case 5**: globalfee=[0uatom, 1stake], min_gas_prices="", gas=200000. - - fees="2000000 * 0uatom, 2000000 * 0.5stake", fail, (this is due to [fee parsing, zero coins are removed](https://github.com/cosmos/cosmos-sdk/blob/e716e4103e934344aa7be6dc9b5c453bdec5f225/client/tx/factory.go#L144), it equals to paidfees = 0.5stake in this case) - - paidfees="", pass - - paidfees="2000000 * 1uatom, 0.5stake", pass - - paidfees="0uatom, 0stake" pass, (due to the parsing of paidfees, it makes paidfees="") - - paidfees="2000000 * 1stake", pass - +- fees="2000000 *0uatom, 2000000* 0.5stake", fail, (this is due to [fee parsing, zero coins are removed](https://github.com/cosmos/cosmos-sdk/blob/e716e4103e934344aa7be6dc9b5c453bdec5f225/client/tx/factory.go#L144), it equals to paidfees = 0.5stake in this case) +- paidfees="", pass +- paidfees="2000000 * 1uatom, 0.5stake", pass +- paidfees="0uatom, 0stake" pass, (due to the parsing of paidfees, it makes paidfees="") +- paidfees="2000000 * 1stake", pass - **Case 6**: globalfee=[0.001uatom, 1stake], min_gas_prices=0.002uatom, gas=200000. - paidfee = "2000000 * 0.0002uatom", pass - paidfee = "2000000 * 0.0001uatom", fail - paidfee = "2000000 * 1stake", pass - paidfee = "2000000 * 1/2stake", fail - - paidfee = "2000000 * 0.0001uatom, 2000000*1stake", pass - - paidfee = "2000000 * 0.0002atom, 2000000*1/2stake", pass - - paidfee = "2000000 * 0.0001uatom, 2000000*1/2stake", fail + - paidfee = "2000000 *0.0001uatom, 2000000*1stake", pass + - paidfee = "2000000 *0.0002atom, 2000000*1/2stake", pass + - paidfee = "2000000 *0.0001uatom, 2000000*1/2stake", fail - - **Case 7**:globalfee=[0.0001uatom], min_gas_prices=0.0002uatom,1stake, gas=200000. `bypass-min-fee-msg-types = ["/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward"]` - - msg withdraw-all-rewards with paidfee=0uatom, pass + - msg withdraw-all-rewards with paidfee=0uatom, pass - msg withdraw-all-rewards with paidfee=200000 * 0.0001/2uatom, pass - msg withdraw-all-rewards with paidfee=0stake,0photon, pass - msg withdraw-all-rewards with paidfee=200000 * 1stake, 0photon, fail ## Reference + - [Fee caculations: fee and gas](https://docs.cosmos.network/main/basics/gas-fees.html) diff --git a/docs/proto/proto-docs.md b/docs/proto/proto-docs.md index 78e40d6f6bd..42172f01b1e 100644 --- a/docs/proto/proto-docs.md +++ b/docs/proto/proto-docs.md @@ -1,66 +1,55 @@ # Protobuf Documentation + ## Table of Contents - [gaia/globalfee/v1beta1/query.proto](#gaia/globalfee/v1beta1/query.proto) - - [QueryMinimumGasPricesRequest](#gaia.globalfee.v1beta1.QueryMinimumGasPricesRequest) - - [QueryMinimumGasPricesResponse](#gaia.globalfee.v1beta1.QueryMinimumGasPricesResponse) + - [QueryMinimumGasPricesRequest](#gaia.globalfee.v1beta1.QueryMinimumGasPricesRequest) + - [QueryMinimumGasPricesResponse](#gaia.globalfee.v1beta1.QueryMinimumGasPricesResponse) - - [Query](#gaia.globalfee.v1beta1.Query) + - [Query](#gaia.globalfee.v1beta1.Query) - [gaia/globalfee/v1beta1/genesis.proto](#gaia/globalfee/v1beta1/genesis.proto) - - [GenesisState](#gaia.globalfee.v1beta1.GenesisState) - - [Params](#gaia.globalfee.v1beta1.Params) + - [GenesisState](#gaia.globalfee.v1beta1.GenesisState) + - [Params](#gaia.globalfee.v1beta1.Params) - [Scalar Value Types](#scalar-value-types) - -

Top

## gaia/globalfee/v1beta1/query.proto - - ### QueryMinimumGasPricesRequest + QueryMinimumGasPricesRequest is the request type for the Query/MinimumGasPrices RPC method. - - - - - ### QueryMinimumGasPricesResponse + QueryMinimumGasPricesResponse is the response type for the Query/MinimumGasPrices RPC method. - | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | | `minimum_gas_prices` | [cosmos.base.v1beta1.DecCoin](#cosmos.base.v1beta1.DecCoin) | repeated | | - - - - - ### Query + Query defines the gRPC querier service. | Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | @@ -69,43 +58,30 @@ Query defines the gRPC querier service. - -

Top

## gaia/globalfee/v1beta1/genesis.proto - - ### GenesisState -GenesisState - initial state of module +GenesisState - initial state of module | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | | `params` | [Params](#gaia.globalfee.v1beta1.Params) | | Params of this module | - - - - - ### Params -Params defines the set of module parameters. +Params defines the set of module parameters. | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | -| `minimum_gas_prices` | [cosmos.base.v1beta1.DecCoin](#cosmos.base.v1beta1.DecCoin) | repeated | Minimum stores the minimum gas price(s) for all TX on the chain. When multiple coins are defined then they are accepted alternatively. The list must be sorted by denoms asc. No duplicate denoms or zero amount values allowed. For more information see https://docs.cosmos.network/main/modules/auth#concepts | - - - - +| `minimum_gas_prices` | [cosmos.base.v1beta1.DecCoin](#cosmos.base.v1beta1.DecCoin) | repeated | Minimum stores the minimum gas price(s) for all TX on the chain. When multiple coins are defined then they are accepted alternatively. The list must be sorted by denoms asc. No duplicate denoms or zero amount values allowed. For more information see | @@ -115,8 +91,6 @@ Params defines the set of module parameters. - - ## Scalar Value Types | .proto Type | Notes | C++ | Java | Python | Go | C# | PHP | Ruby | @@ -136,4 +110,3 @@ Params defines the set of module parameters. | bool | | bool | boolean | boolean | bool | bool | boolean | TrueClass/FalseClass | | string | A string must always contain UTF-8 encoded or 7-bit ASCII text. | string | String | str/unicode | string | string | string | String (UTF-8) | | bytes | May contain any arbitrary sequence of bytes. | string | ByteString | str | []byte | ByteString | string | String (ASCII-8BIT) | - diff --git a/docs/readiness/README.md b/docs/readiness/README.md index be58a5bc38e..3d2813eaba3 100644 --- a/docs/readiness/README.md +++ b/docs/readiness/README.md @@ -36,6 +36,7 @@ If recorded decisions turned out to be lacking, convene a discussion, record the ## Creating new ADR ### Process + 1. Copy the `template.md` file. Use the following filename pattern: `adr-next_number-title.md` 2. Link the ADR in the related [feature epic](../../.github/ISSUE_TEMPLATE/feature-readiness.md) 2. Create a draft Pull Request if you want to get early feedback. @@ -79,18 +80,18 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b ABANDONED ``` -+ `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form. -+ `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet. -+ `LAST CALL `: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos Hub maintainers) has been reached and we still want to give it a time to let the community react or analyze. -+ `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design. -+ `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so. -+ `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR. -+ `ABANDONED`: the ADR is no longer pursued by the original authors. +- `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form. +- `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet. +- `LAST CALL `: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos Hub maintainers) has been reached and we still want to give it a time to let the community react or analyze. +- `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design. +- `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so. +- `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR. +- `ABANDONED`: the ADR is no longer pursued by the original authors. ### Language used in ADR -+ The context/background should be written in the present tense. -+ Avoid using a first, personal form. +- The context/background should be written in the present tense. +- Avoid using a first, personal form. **Use RFC 2119 Keywords** @@ -106,7 +107,6 @@ When writing ADRs, follow the same best practices for writing RFCs. When writing - n/a - ### Draft - [ADR 001: Interchain Accounts](./adr-001-interchain-accounts.md) diff --git a/docs/readiness/adr-001-interchain-accounts.md b/docs/readiness/adr-001-interchain-accounts.md index 121c6f5b3f0..c73c97c5d71 100644 --- a/docs/readiness/adr-001-interchain-accounts.md +++ b/docs/readiness/adr-001-interchain-accounts.md @@ -3,6 +3,7 @@ order: 2 --> --- + ADR: 001 Title: Interchain Accounts Status: Draft Implements @@ -27,24 +28,31 @@ Implements: Interchain Accounts This is the Core Interchain Accounts Module. It allows the Cosmos Hub to act as a host chain with interchain accounts that are controlled by external IBC connected "Controller" blockchains. Candidate chains include Umee, Quicksilver, Sommelier. It is also a necessary component for a Authentication Module that allows the Cosmos Hub to act as a Controller chain as well. This will be recorded in a separate ADR. ## Rationale + This allows the Hub to participate in advanced cross-chain defi operations, like Liquid Staking and various protocol controlled value applications. ## Desired Outcome + The hub can be used trustlessly as a host chain in the configuration of Interchain Accounts. ## Consequences + There has been preliminary work done to understand if this increases any security feature of the Cosmos Hub. One thought was that this capability is similar to contract to contract interactions which are possible on virtual machine blockchains like EVM chains. Those interactions introduced a new attack vector, called a re-entrancy bug, which was the culprit of "The DAO hack on Ethereum". We believe there is no risk of these kinds of attacks with Interchain Accounts because they require the interactions to be atomic and Interchain Accounts are asynchronous. #### Backwards Compatibility + This is the first of its kind. #### Forward Compatibility + There are future releases of Interchain Accounts which are expected to be backwards compatible. ## Technical Specification + [ICS-27 Spec](https://github.com/cosmos/ibc/blob/master/spec/app/ics-027-interchain-accounts/README.md) ## Development + - Integration requirements - Development has occured in [IBC-go](https://github.com/cosmos/ibc-go) and progress tracked on the project board there. - Testing (Simulations, Core Team Testing, Partner Testing) @@ -55,32 +63,39 @@ There are future releases of Interchain Accounts which are expected to be backwa - Testnets ## Governance [optional] + - **Needs Signaling Proposal** - Core Community Governance - - N/A + - N/A - Steering Community - - N/A. Possibly Aditya Srinpal, Sean King, Bez? + - N/A. Possibly Aditya Srinpal, Sean King, Bez? - Timelines & Roadmap - Expected to be released as part of IBC 3.0 in Feb 2022 (currently in [beta release](https://github.com/cosmos/ibc-go/releases/tag/v3.0.0-beta1)) ## Project Integrations [optional] + - Gaia Integrations - [PR](https://github.com/cosmos/gaia/pull/1150) - Integration Partner - IBC Team #### Downstream User Impact Report + (Needs to be created) #### Upstream Partner Impact Report + (Needs to be created) #### Inter-module Dependence Report + (Needs to be created) ## Support + [Documentation](https://ibc.cosmos.network/main/apps/interchain-accounts/overview.html) ## Additional Research & References - * [Why Interchain Accounts Change Everything for Cosmos Interoperability](https://medium.com/chainapsis/why-interchain-accounts-change-everything-for-cosmos-interoperability-59c19032bf11) - * [Interchain Account Auth Module Demo Repo](https://github.com/cosmos/interchain-accounts) + +- [Why Interchain Accounts Change Everything for Cosmos Interoperability](https://medium.com/chainapsis/why-interchain-accounts-change-everything-for-cosmos-interoperability-59c19032bf11) +- [Interchain Account Auth Module Demo Repo](https://github.com/cosmos/interchain-accounts) diff --git a/docs/readiness/template.md b/docs/readiness/template.md index 642b1f60c4e..e7f148a2b98 100644 --- a/docs/readiness/template.md +++ b/docs/readiness/template.md @@ -3,6 +3,7 @@ order: false --> --- + ADR: (number) Title: (short title) Status: (current ADR status) @@ -26,51 +27,69 @@ Implements: (optional list of component ADRs) > "If you can't explain it simply, you don't understand it well enough." Provide a short (~200 word) high level description of the issue being addressed and rationale for such. ## Rationale + > Describe the context and rationale for proposing a new feature or module. The language in this section is value-neutral and should clearly explain the problem and motivation that the proposal aims to resolve. ## Desired Outcome + > Provides succinct answers to the issues documented above. Response should include desired characteristics / properties of feature/protocol, and effects if properties are violated. ## Consequences + > This section describes the resulting context, after applying the decision (positive, neutral, and negative). #### Backwards Compatibility + > Discussion of compatibility or lack thereof with previous standards. #### Forward Compatibility + > Discussion of compatibility or lack thereof with expected future standards. ## Technical Specification + > Details main technical standard, may include some of the following: syntax, semantics, sub-protocols, algorithms, data structures, etc. ## Development + > Documents the following for readiness/deployment milestones + - Integration requirements (CLI) - Testing (Simulations, Core Team Testing, Partner Testing) - Audits (Internal Dev review, Third-party review, Bug Bounty) - Networks (Testnets, Productionnets, Mainnets) ### Backwards Compatibility + > Discussion of compatibility or lack thereof with expected future standards. ## Governance [optional] + > If relevant, will include: + - Linked Hub Governance proposal - Core Community Governance - Steering Community - Timelines & Roadmap ## Project Integrations [optional] + > Document internal and/or external integration partners + - Gaia Integrations - Integration Partner - IBC Readiness + #### Downstream User Impact Report + #### Upstream Partner Impact Report + #### Inter-module Dependence ## Support + > Includes additional technical, marketing, educational, etc support ## Additional Research & References + > Additional links or sections to address diff --git a/docs/resources/ledger.md b/docs/resources/ledger.md index 06d70226e48..47722fa1f22 100644 --- a/docs/resources/ledger.md +++ b/docs/resources/ledger.md @@ -17,14 +17,14 @@ Do not lose or share your 24 words with anyone. To prevent theft or loss of fund Installing the `Cosmos` application on your ledger device is required before you can use either [Keplr](#keplr-+-ledger-nano) or [`gaiad`](#gaia-cli-+-ledger-nano). To do so, you need to: -1. Install [Ledger Live](https://shop.ledger.com/pages/ledger-live) on your machine. +1. Install [Ledger Live](https://shop.ledger.com/pages/ledger-live) on your machine. 2. Using Ledger Live, [update your Ledger Nano S with the latest firmware](https://support.ledger.com/hc/en-us/articles/360002731113?docs=true). -3. On the Ledger Live application, navigate to the `Manager` menu . +3. On the Ledger Live application, navigate to the `Manager` menu . ![manager](../images/ledger-tuto-manager.png) -4. Connect your Ledger Nano device and allow Ledger Manager from it. -5. On the Ledger Live application, Search for `Cosmos`. +4. Connect your Ledger Nano device and allow Ledger Manager from it. +5. On the Ledger Live application, Search for `Cosmos`. ![search](../images/ledger-tuto-search.png) 6. Install the Cosmos application by clicking on `Install`. @@ -53,9 +53,9 @@ You can double check that Keplr is displaying the correct address directly on yo 1. Connect your Ledger to your computer and open the Cosmos application on the device. 2. Once the Cosmos app is open, click on the right button to access the `Show Address` option. -3. Click on both button, then select `Account 0` and `Index 0`. +3. Click on both button, then select `Account 0` and `Index 0`. -You should now see the same address that is displayed on the Keplr extension. +You should now see the same address that is displayed on the Keplr extension. To learn more about using Keplr, we suggest you have a look at their [support documentation](https://keplr.crunch.help). @@ -190,6 +190,7 @@ Or to print the `tx` (transaction) commands: ```bash gaiad tx --help ``` + ::: ## The Cosmos Standard Transaction diff --git a/docs/resources/reproducible-builds.md b/docs/resources/reproducible-builds.md index 935b801c664..3b96795b627 100644 --- a/docs/resources/reproducible-builds.md +++ b/docs/resources/reproducible-builds.md @@ -29,6 +29,7 @@ git checkout v4.2.1 ``` The buildsystem supports and produces binaries for the following architectures: + * **darwin/amd64** * **linux/amd64** * **linux/arm64** diff --git a/docs/resources/service-providers.md b/docs/resources/service-providers.md index 7b8a61c149d..a8311b553a3 100644 --- a/docs/resources/service-providers.md +++ b/docs/resources/service-providers.md @@ -25,7 +25,6 @@ This document describes: - [REST API](#rest-api) - [Listen for incoming transactions](#listen-for-incoming-transaction) - ## Connection Options There are four main technologies to consider to connect to the Cosmos Hub: @@ -184,8 +183,6 @@ You can run these commands as remote control or when you are running it on your The default key is `secp256k1 elliptic curve`. Use the `gaiad keys` command to list the keys and generate a new key. - - ```bash gaiad keys add ``` diff --git a/docs/roadmap/README.md b/docs/roadmap/README.md index 1302562f5d5..9664a2eadc3 100644 --- a/docs/roadmap/README.md +++ b/docs/roadmap/README.md @@ -12,6 +12,7 @@ parent: For current roadmap, check out the Cosmos 2.0 [Roadmap](./cosmos-hub-roadmap-2.0.md). ## Cosmos Hub History + | Upgrade Name | Date | Height | Chain Identifier | Tm | Cosmos SDK | Gaia | IBC | |---------------------|---------------|-----------|---------------|------------|------------|--------------------------|--------------------------| | Mainnet Launch | 13/03/19 | 0 | `cosmoshub-1` | [v0.31.x](https://github.com/tendermint/tendermint/releases/tag/v0.31.11) | [v0.33.x](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.33.2) | _Included in Cosmos SDK_ | n/a | diff --git a/docs/roadmap/cosmos-hub-roadmap-2.0.md b/docs/roadmap/cosmos-hub-roadmap-2.0.md index a884d1490f1..11afa473cc5 100644 --- a/docs/roadmap/cosmos-hub-roadmap-2.0.md +++ b/docs/roadmap/cosmos-hub-roadmap-2.0.md @@ -7,6 +7,7 @@ This roadmap gives a one-year guideline in which stakeholders can anticipate upd The upgrades aim to add features such as liquidity, economic security, usability, and participation. To highlight our focus on DeFi, we have chosen to use the [Greeks from Finance](https://en.wikipedia.org/wiki/Greeks_(finance)) in naming upcoming upgrades. ## Delta Upgrade (Completed July 12, 2021) + - Gaia v5.0.x - Gravity DEX: - A scalable AMM model for token swaps @@ -14,12 +15,13 @@ The upgrades aim to add features such as liquidity, economic security, usability - Delivers price consistency and order execution ## Vega Upgrade (Completed December 14, 2021) - - Gaia v6.0.x - - Cosmos SDK v0.44 - - Fee grant module: - - Allows paying fees on behalf of another account - - Authz module: - - Provide governance functions to execute transactions on behalf of another account + +- Gaia v6.0.x +- Cosmos SDK v0.44 + - Fee grant module: + - Allows paying fees on behalf of another account + - Authz module: + - Provide governance functions to execute transactions on behalf of another account - Liquidity Module v1.4.2 - The Gravity DEX with updates for dependencies - IBC v2.0.0 @@ -33,6 +35,7 @@ The upgrades aim to add features such as liquidity, economic security, usability - Fee and reward model hosted across Cosmos and Ethereum ## v7-Theta Upgrade (Completed March 25, 2022) + - Gaia v7.0.x - Cosmos SDK v0.45 - Minimal update with small fixes @@ -45,6 +48,7 @@ The upgrades aim to add features such as liquidity, economic security, usability - Uses ordered IBC channels, one per account. ## v8-Rho Upgrade (expected H2 2022) + - Gaia v8.0.x - Cosmos SDK v0.46 - Groups module: @@ -62,8 +66,8 @@ The upgrades aim to add features such as liquidity, economic security, usability - Allows denoms and min-fees to be governance parameters so gas can be paid in various denoms. - Visible on [tgrade](https://github.com/confio/tgrade/tree/main/x/globalfee) already and enabled in [ante.go](https://github.com/confio/tgrade/blob/main/app/ante.go#L72-L92) - ## v9-Lambda Upgrade (expected Q1 2023) + - Gaia v9.0.x - Cosmos SDK v0.47 - Phasing out broadcast mode @@ -77,23 +81,27 @@ The upgrades aim to add features such as liquidity, economic security, usability - Interchain Security - Required Participation of Provider Chain Validators - The Cosmos solution to shared security that uses IBC Cross Chain Validation (CCV) to relay validator set composition from a Provider Chain (Cosmos Hub) to a Consumer Chain. This validator set is in charge of producing blocks on both networks using separate nodes. Misbehavior on the Consumer Chain results in slashing Provider Chain staking tokens (ATOM). - Bech32 Prefix forwarding - - https://github.com/osmosis-labs/bech32-ibc + - - Liquidity Module Deprecation - Contains forced withdraw of liquidity ## v10-Epsilon (expected Q2 2023) + - Gaia v10.0.x - IBC Queries - Hub ATOM Liquidity (HAL) - Protocol Controlled Value application to acquire ATOM LP tokens with Interchain Security Tokens ## v11-Gamma (expected Q3 2023) + - Gaia v11.0.x - Interchain Security v2 - Layered Security - Where Consumer Chains combine their own staking token validator set with Provider Chain validator set. ## Future Considerations + The Cosmos Hub is a decentralized network with many diverse contributors. As such there is no one authority of what is or can be part of the Cosmos Network. The Cosmos Hub team at Interchain does its best to maintain the Gaia repository, which is the primary codebase that operates the Cosmos Network. The Interchain Foundation is one of the sources of funding for engineering work that may make its way onto the Cosmos Hub. We do our best to participate in ongoing conversations about the mission, vision and purpose of the Cosmos Hub, so that we can best support work to enabling it via funding, engineering, coordination and communication. Some of the topics which have been discussed by contributors inside and outside of Interchain are listed below, although have not been developed to the point of being included in the roadmap: + - Multi-Hop Routing - Simplifies the topography of relayers such that packets from pairwise channels between chains can be routed through the hub while preserving the original channel and more importantly token denom path. - Chain Name Service @@ -105,11 +113,11 @@ The Cosmos Hub is a decentralized network with many diverse contributors. As suc - Bech32 registry - IBC NFT - NFT module - - Enable simple management of NFT identifiers, their owners, and associated data, such as URIs, content, and provenance - - An extensible base module for extensions including collectibles, custody, provenance, and marketplaces - - Unless the Cosmos Hub plans to be a full blown platform for NFT publication, it should pair the inclusion of this module with the IBC NFT module similar to how the Cosmos Hub doesn't allow new Fungible Tokens to be published but does allow them to be transferred via IBC. + - Enable simple management of NFT identifiers, their owners, and associated data, such as URIs, content, and provenance + - An extensible base module for extensions including collectibles, custody, provenance, and marketplaces + - Unless the Cosmos Hub plans to be a full blown platform for NFT publication, it should pair the inclusion of this module with the IBC NFT module similar to how the Cosmos Hub doesn't allow new Fungible Tokens to be published but does allow them to be transferred via IBC. - Privacy - Smart Contracts - Rollups -The Cosmos Hub Roadmap is maintained by the Interchain Cosmos Hub team as a living document, and is updated in collaboration with key stakeholders from the multi-entity Cosmos community. +The Cosmos Hub Roadmap is maintained by the Interchain Cosmos Hub team as a living document, and is updated in collaboration with key stakeholders from the multi-entity Cosmos community. diff --git a/docs/validators/README.md b/docs/validators/README.md index b1fbb4e748d..e3c98d7c2fa 100644 --- a/docs/validators/README.md +++ b/docs/validators/README.md @@ -14,5 +14,5 @@ This folder contains documentation relevant to validators of the Cosmos Hub and - [Validator FAQ](./validator-faq.md) - [Validator Security Notice](./security.md) - Key Management System - + [Intro to KMS](./kms/kms.md) - + [KMS + Ledger](./kms/kms_ledger.md) + - [Intro to KMS](./kms/kms.md) + - [KMS + Ledger](./kms/kms_ledger.md) diff --git a/docs/validators/kms/kms_ledger.md b/docs/validators/kms/kms_ledger.md index 4c48a375484..d907305a472 100644 --- a/docs/validators/kms/kms_ledger.md +++ b/docs/validators/kms/kms_ledger.md @@ -20,7 +20,7 @@ You should be able to find the Tendermint app in Ledger Live. ## KMS configuration -In this section, we will configure a KMS to use a Ledger device running the Tendermint Validator App. +In this section, we will configure a KMS to use a Ledger device running the Tendermint Validator App. ### Config file diff --git a/docs/validators/overview.md b/docs/validators/overview.md index 87d81d636a0..44691d7c877 100644 --- a/docs/validators/overview.md +++ b/docs/validators/overview.md @@ -17,7 +17,7 @@ If validators double sign or are offline for an [extended period](./validator-fa ## Hardware -For validator key management, validators must set up a physical operation that is secured with restricted access. A good starting place, for example, would be co-locating in secure data centers. +For validator key management, validators must set up a physical operation that is secured with restricted access. A good starting place, for example, would be co-locating in secure data centers. Validators are expected to equip their datacenter location with redundant power, connectivity, and storage backups. Expect to have several redundant networking boxes for fiber, firewall, and switching and then small servers with redundant hard drive and failover. diff --git a/docs/validators/security.md b/docs/validators/security.md index 9f0e22b3177..d1143f96ef1 100644 --- a/docs/validators/security.md +++ b/docs/validators/security.md @@ -58,4 +58,4 @@ By default, uppercase environment variables with the following prefixes will rep - `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. - + \ No newline at end of file diff --git a/docs/validators/validator-setup.md b/docs/validators/validator-setup.md index 796f140667b..bdd0abaa651 100644 --- a/docs/validators/validator-setup.md +++ b/docs/validators/validator-setup.md @@ -6,7 +6,7 @@ title: Running a Validator # Running a Validator ::: tip -We suggest you try out joining a public testnet first. Information on how to join the most recent testnet can be found [here](../hub-tutorials/join-testnet.md). +We suggest you try out joining a public testnet first. Information on how to join the most recent testnet can be found [here](../hub-tutorials/join-testnet.md). ::: Before setting up a validator node, make sure to have completed the [Joining Mainnet](../hub-tutorials/join-mainnet.md) guide. @@ -33,8 +33,8 @@ gaiad tendermint show-validator To create your validator, just use the following command: -::: warning -Don't use more `uatom` than you have! +::: warning +Don't use more `uatom` than you have! ::: ```bash @@ -87,7 +87,7 @@ gaiad tx staking edit-validator Please note that some parameters such as `commission-max-rate` and `commission-max-change-rate` cannot be changed once your validator is up and running. ::: -__Note__: The `commission-rate` value must adhere to the following rules: +**Note**: The `commission-rate` value must adhere to the following rules: - Must be between 0 and the validator's `commission-max-rate` - Must not exceed the validator's `commission-max-change-rate` which is maximum @@ -117,8 +117,8 @@ When a validator is "jailed" for downtime, you must submit an `Unjail` transacti ```bash gaiad tx slashing unjail \ - --from= \ - --chain-id= + --from= \ + --chain-id= ``` ## Confirm Your Validator is Running @@ -137,13 +137,14 @@ When attempting to perform routine maintenance or planning for an upcoming coord the block. ## Advanced configuration + You can find more advanced information about running a node or a validator on the [Tendermint Core documentation](https://docs.tendermint.com/v0.34/tendermint-core/validators.html). ## Common Problems ### Problem #1: My validator has `voting_power: 0` -Your validator has become jailed. Validators get jailed, i.e. get removed from the active validator set, if they do not vote on at least `500` of the last `10,000` blocks, or if they double sign. +Your validator has become jailed. Validators get jailed, i.e. get removed from the active validator set, if they do not vote on at least `500` of the last `10,000` blocks, or if they double sign. If you got jailed for downtime, you can get your voting power back to your validator. First, if you're not using [Cosmovisor](https://docs.cosmos.network/v0.45/run-node/cosmovisor.html) and `gaiad` is not running, start it up again: diff --git a/docs/zh/delegator/delegator-guide-cli.md b/docs/zh/delegator/delegator-guide-cli.md index 931490181b5..998153a2fa9 100644 --- a/docs/zh/delegator/delegator-guide-cli.md +++ b/docs/zh/delegator/delegator-guide-cli.md @@ -1,57 +1,53 @@ # 委托人指南 (CLI) +本文介绍了如何使用Cosmos Hub的命令行交互（CLI）程序实现通证委托的相关知识和操作步骤。 -本文介绍了如何使用Cosmos Hub的命令行交互（CLI）程序实现通证委托的相关知识和操作步骤。 - -同时，本文也介绍了如何管理账户，如何从筹款人那里恢复账户，以及如何使用一个硬件钱包的相关知识。 +同时，本文也介绍了如何管理账户，如何从筹款人那里恢复账户，以及如何使用一个硬件钱包的相关知识。 ::: 风险提示 -**重要提示**：请务必按照下面的操作步骤谨慎操作，过程中发生任何错误都有可能导致您永远失去所拥有的通证。因此，请在开始操作之前先仔细阅读全文，如果有任何问题可以联系我们获得支持。 - +**重要提示**：请务必按照下面的操作步骤谨慎操作，过程中发生任何错误都有可能导致您永远失去所拥有的通证。因此，请在开始操作之前先仔细阅读全文，如果有任何问题可以联系我们获得支持。 -另请注意，您即将要与Cosmos Hub进行交互，Cosmos Hub仍然是一个试验型的区块链技术软件。虽然Cosmos Hub区块链是应用现有最新技术开发并经过审核的，但我们仍然可能会在运行时遇到问题，需要不断更新和修复漏洞。此外，使用区块链技术仍然要求有很高的技术能力，并且有可能遇到我们无法预知和控制的风险。使用Cosmos Hub前，您需要充分了解与加密软件相关的潜在风险（请参考[Cosmos跨链贡献条款](https://github.com/cosmos/cosmos/blob/master/fundraiser/Interchain%20Cosmos%20Contribution%20Terms%20-%20FINAL.pdf)中关于风险的部分条款），并且我们跨链基金会和(或)Tendermint团队对于因为使用本产品而可能产生的损失不承担任何责任。使用Cosmos Hub需要遵守Apache 2.0开源软件授权条款，用户需要自己承担所有责任，所使用的软件按“现状”提供且不提供任何形式的保障或条件。 +另请注意，您即将要与Cosmos Hub进行交互，Cosmos Hub仍然是一个试验型的区块链技术软件。虽然Cosmos Hub区块链是应用现有最新技术开发并经过审核的，但我们仍然可能会在运行时遇到问题，需要不断更新和修复漏洞。此外，使用区块链技术仍然要求有很高的技术能力，并且有可能遇到我们无法预知和控制的风险。使用Cosmos Hub前，您需要充分了解与加密软件相关的潜在风险（请参考[Cosmos跨链贡献条款](https://github.com/cosmos/cosmos/blob/master/fundraiser/Interchain%20Cosmos%20Contribution%20Terms%20-%20FINAL.pdf)中关于风险的部分条款），并且我们跨链基金会和(或)Tendermint团队对于因为使用本产品而可能产生的损失不承担任何责任。使用Cosmos Hub需要遵守Apache 2.0开源软件授权条款，用户需要自己承担所有责任，所使用的软件按“现状”提供且不提供任何形式的保障或条件。 ::: - 请务必谨慎行事！ ## 目录 - + - [安装 `gaiad`](#安装-gaiad) - [Cosmos账户](#Cosmos账户) - + [通过募资人恢复一个账户](#通过募资人恢复一个账户) - + [创建一个账户](#创建一个账户) + - [通过募资人恢复一个账户](#通过募资人恢复一个账户) + - [创建一个账户](#创建一个账户) - [访问Cosmos Hub网络](#访问Cosmos-Hub网络) - + [运行您自己的全节点](#运行您自己的全节点) - + [连接到一个远程全节点](#连接到一个远程全节点) + - [运行您自己的全节点](#运行您自己的全节点) + - [连接到一个远程全节点](#连接到一个远程全节点) - [设置`gaiad`](#设置-gaiad) - [状态查询](#状态查询) - [发起交易](#发起交易) - + [关于gas费和手续费](#关于gas费和手续费) - + [抵押Atom通证 & 提取奖励](#抵押atom通证--提取奖励) - + [参与链上治理](#参与链上治理) - + [从一台离线电脑上签署交易](#从一台离线电脑上签署交易) + - [关于gas费和手续费](#关于gas费和手续费) + - [抵押Atom通证 & 提取奖励](#抵押atom通证--提取奖励) + - [参与链上治理](#参与链上治理) + - [从一台离线电脑上签署交易](#从一台离线电脑上签署交易) -## 安装 `gaiad` +## 安装 `gaiad` -`gaiad`: 与`gaiad`全节点交互的命令行用户界面。 +`gaiad`: 与`gaiad`全节点交互的命令行用户界面。 ::: 安全提示 **请检查并且确认你下载的`gaiad`是可获得的最新稳定版本** ::: - [**下载已编译代码**]暂不提供 - [**通过源代码安装**](https://cosmos.network/docs/gaia/installation.html) -::: tip 提示 +::: tip 提示 + +`gaiad` 需要通过操作系统的终端窗口使用，打开步骤如下所示： -`gaiad` 需要通过操作系统的终端窗口使用，打开步骤如下所示： - **Windows**: `开始` > `所有程序` > `附件` > `终端` - **MacOS**: `访达` > `应用程序` > `实用工具` > `终端` - **Linux**: `Ctrl` + `Alt` + `T` @@ -94,7 +90,6 @@ +-------------------+ ``` - 私钥是控制一个账户中所存资产的钥匙。私钥是通过助记词单向产生的。如果您不小心丢失了私钥，你可以通过助记词恢复。 然而，如果你丢失了助记词，那么你就有可能失去对由这个助记词产生的所有私钥的控制。同样，如果有人获得了你的助记词，他们就可以操作所有相关账户。 ::: 警告 @@ -102,7 +97,6 @@ **谨慎保管并不要告诉他人你的助记词。 为了防止资产被盗或者丢失，您最好多备份几份助记词， 并且把它们存放在只有您知道的安全地方，这样做将有助于保障您的私钥以及相关账户的安全。** ::: - Cosmos地址是一个以可读词开头的字符串(比如`cosmos10snjt8dmpr5my0h76xj48ty80uzwhraqalu4eg`) 如果有人想给你转账通证，他们就往这个地址转账。根据给定地址来推算私钥是不可行的。 ### 通过募资人恢复一个账户 @@ -112,12 +106,10 @@ Cosmos地址是一个以可读词开头的字符串(比如`cosmos10snjt8dmpr5my0 *注：这部分内容仅适用于众筹活动参与者* ::: - -如果您是众筹的参与者，你应该有一个助记词。新产生的助记词用24个词，但是12个词的助记词组也兼容所有Cosmos工具。 +如果您是众筹的参与者，你应该有一个助记词。新产生的助记词用24个词，但是12个词的助记词组也兼容所有Cosmos工具。 #### 通过硬件钱包设备进行操作 - 一个数字钱包设备的核心是通过一个助记词在多个区块链上创建账户（包括Cosmos hub）。通常，您会在初始化您的数字钱包设备时创建一个新的助记词,也可以通过已有的助记词进行导入。让我们一起来看如何将您在参与众筹时获得的助记词设定为一个数字钱包设备的seed。 ::: 警告 @@ -125,20 +117,16 @@ Cosmos地址是一个以可读词开头的字符串(比如`cosmos10snjt8dmpr5my0 *注意：**最好使用一个新的钱包设备**来恢复您的Cosmos账户。确实，每个数字钱包设备只能有一个助记词。 当然，您可以通过 `设置`>`设备`>`重置所有` 将一个已经有助记词的（用过的）数字钱包重新初始化。**但请注意，这样会清空您设备中现有的助记词，如果您没有做好备份的话，有可能会丢失您的资产*** ::: - -对于一个没有初始化的数字钱包设备，您需要做如下操作。 - +对于一个没有初始化的数字钱包设备，您需要做如下操作。 1. 将您的数字钱包设备通过USB与电脑链接 2. 同时按下两个按钮 3. **不要**选择“配置一个新设备”选项，而是选择“恢复配置” 4. 选择一个PIN 5. 选择12个词选项 -6. 逐个按顺序输入您在众筹时获得的12个助记词 - - -现在，您的钱包已经正确地设置好您在众筹时获得的助记词，切勿丢失！任何时候您的钱包设备出现问题，您都可以通过助记词在一个新的钱包设备上恢复所有账户。 +6. 逐个按顺序输入您在众筹时获得的12个助记词 +现在，您的钱包已经正确地设置好您在众筹时获得的助记词，切勿丢失！任何时候您的钱包设备出现问题，您都可以通过助记词在一个新的钱包设备上恢复所有账户。 接下来，请点击[这里](#使用硬件钱包设备进行操作)来学习如何生成一个账户。 @@ -147,27 +135,23 @@ Cosmos地址是一个以可读词开头的字符串(比如`cosmos10snjt8dmpr5my0 ::: 警告 **注意： 在一台没有联网的计算机上执行以下操作会更加安全** -::: +::: -如果您希望通过众筹时获得的助记词恢复账户并保存相关私钥，请按以下步骤操作： +如果您希望通过众筹时获得的助记词恢复账户并保存相关私钥，请按以下步骤操作： ```bash gaiad keys add --recover ``` +首先，您需要输入一个密码来对您硬盘上账户`0`的私钥进行加密。每次您发出一笔交易时都将需要输入这个密码。如果您丢失了密码，您可以通过助记词来恢复您的私钥。 -首先，您需要输入一个密码来对您硬盘上账户`0`的私钥进行加密。每次您发出一笔交易时都将需要输入这个密码。如果您丢失了密码，您可以通过助记词来恢复您的私钥。 - - --`` 是账户名称，用来指代用助记词生成私钥/公钥对的Cosmos账户。在您发起交易时，这个账户名称被用来识别您的账户。 +-`` 是账户名称，用来指代用助记词生成私钥/公钥对的Cosmos账户。在您发起交易时，这个账户名称被用来识别您的账户。 - - 您可以通过增加 `--account` 标志来指定您账户生成的路径 (`0`, `1`, `2`, ...)， `0` 是缺省值。 - ### 创建一个账户 -前，您需要先安装`gaiad`，同时，您需要知道你希望在哪里保存和使用您的私钥。 最好的办法是把他们保存在一台没有上网的电脑或者一个硬件钱包设备里面。 将私钥保存在一台联网的电脑里面比较危险，任何人通过网络攻击都有可能获取您的私钥，进而盗取您的资产。 +前，您需要先安装`gaiad`，同时，您需要知道你希望在哪里保存和使用您的私钥。 最好的办法是把他们保存在一台没有上网的电脑或者一个硬件钱包设备里面。 将私钥保存在一台联网的电脑里面比较危险，任何人通过网络攻击都有可能获取您的私钥，进而盗取您的资产。 #### 使用硬件钱包设备进行操作 @@ -178,13 +162,11 @@ gaiad keys add --recover 当您初始化钱包设备时，设备会产生一个24个词的助记词组。这个助记词组和Cosmos是兼容的，我们可以通过这个助记词组创建Cosmos账户。所以，您需要做的是确认您的钱包设备兼容`gaiad`，通过下面的步骤可以帮助您确认您的设备是否兼容： - -1. 下载[Ledger Live应用](https://www.ledger.com/pages/ledger-live). -2. 通过USB将钱包与计算机连接，并且将钱包固件升级到最新版本。 +1. 下载[Ledger Live应用](https://www.ledger.com/pages/ledger-live). +2. 通过USB将钱包与计算机连接，并且将钱包固件升级到最新版本。 3. 到Ledger Live钱包的应用商店下载”Cosmos“应用（这可能需要花些时间）。**下载”Cosmos“应用程序需要在Ledger Live钱包`Settings`选项中激活`Dev Mode`** 4. 在你的钱包设备上操作Cosmos APP。 - 然后，通过以下命令创建账户： ```bash @@ -193,10 +175,8 @@ gaiad keys add --ledger ::: 注意： 该命令仅在硬件钱包已导入并在解锁状态时才有效::: - -- `` 是账户名称，用来指代用助记词生成私钥/公钥对的Cosmos账户。在您发起交易时，这个账户名称被用来识别您的账户。 +- `` 是账户名称，用来指代用助记词生成私钥/公钥对的Cosmos账户。在您发起交易时，这个账户名称被用来识别您的账户。 - - 您可以通过增加 `--account` 标志来指定您账户生成的路径 (`0`, `1`, `2`, ...)， `0` 是缺省值。 #### 使用电脑设备进行操作 @@ -212,60 +192,55 @@ gaiad keys add --ledger gaiad keys add ``` -这个命令会产生一个24个词的助记词组，并且同时保存账户 `0` 的私钥和公钥。 另外，您还需要输入一个密码来对您硬盘上账户`0`的私钥进行加密。 每次您发出一笔交易时都将需要输入这个密码。如果您丢失了密码，您可以通过助记词来恢复您的私钥。 +这个命令会产生一个24个词的助记词组，并且同时保存账户 `0` 的私钥和公钥。 另外，您还需要输入一个密码来对您硬盘上账户`0`的私钥进行加密。 每次您发出一笔交易时都将需要输入这个密码。如果您丢失了密码，您可以通过助记词来恢复您的私钥。 ::: 危险提示 **千万不要丢失或者告诉其他人你的12个词的助记词组。 为了防止资产被盗或者丢失，您最好多备份几份助记词， 并且把它们存放在只有您知道的安全地方，如果有人取得您的助记词，那么他也就取得了您的私钥并且可以控制相关账户。** -::: +::: ::: 警告 -在确认已经安全保存好您的助记词以后（至少3遍！），你可以用如下命令清除终端窗口中的命令历史记录，以防有人通过历史记录获得您的助记词。 +在确认已经安全保存好您的助记词以后（至少3遍！），你可以用如下命令清除终端窗口中的命令历史记录，以防有人通过历史记录获得您的助记词。 ```bash history -c rm ~/.bash_history ``` + ::: -你可以用以下命令使用助记词生成多个账户： +你可以用以下命令使用助记词生成多个账户： ```bash gaiad keys add --recover --account 1 ``` -- - `` 是账户名称，用来指代用助记词生成私钥/公钥对的Cosmos账户。在您发起交易时，这个账户名称用来识别您的账户。 + - - `` 是账户名称，用来指代用助记词生成私钥/公钥对的Cosmos账户。在您发起交易时，这个账户名称用来识别您的账户。 - 您可以通过增加 `--account` 标志来指定您账户生成的路径 (`0`, `1`, `2`, ...)， `0` 是缺省值。 - 这条命令需要您输入一个密码。改变账号就代表生成了一个新的账户。 ## 访问Cosmos Hub网络 - 为了查询网络状态和发起交易，你需要通过自建一个全节点，或者连接到其他人的全节点访问Cosmos Hub网络 ::: 警告 **注意： 请不要与任何人分享您的助记词，您是唯一需要知道这些助记词的人。如果任何人通过邮件或者其他社交媒体向您要求您提供您的助记词，那就需要警惕了。 请记住，Cosmos/Tendermint团队，或跨链基金会永远不会通过邮件要求您提供您的账户密码或助记词。** -::: +::: ### 运行您自己的全节点 - 这是最安全的途径，但需要相当多的资源。您需要有较大的带宽和至少1TB的磁盘容量来运行一个全节点。 - `gaia`的安装教程在[这里](../getting-started/installation.md)， 如何运行一个全节点指导在[这里](../hub-tutorials/join-mainnet.md) - -### 连接到一个远程全节点 +### 连接到一个远程全节点 -如果您不想或没有能力运行一个全节点，您也可以连接到其他人的全节点。您需要谨慎的选择一个可信的运营商，因为恶意的运营商往往会向您反馈错误的查询结果，或者对您的交易进行监控。 然而，他们永远也无法盗取您的资产，因为您的私钥仅保持在您的本地计算机或者钱包设备中。 验证人，钱包供应商或者交易所是可以提供全节点的运营商。 - +如果您不想或没有能力运行一个全节点，您也可以连接到其他人的全节点。您需要谨慎的选择一个可信的运营商，因为恶意的运营商往往会向您反馈错误的查询结果，或者对您的交易进行监控。 然而，他们永远也无法盗取您的资产，因为您的私钥仅保持在您的本地计算机或者钱包设备中。 验证人，钱包供应商或者交易所是可以提供全节点的运营商。 -连接到其他人提供的全节点，你需要一个全节点地址，如`https://77.87.106.33:26657`。这个地址是您的供应商提供的一个可信的接入地址。你会在下一节中用到这个地址。 +连接到其他人提供的全节点，你需要一个全节点地址，如`https://77.87.106.33:26657`。这个地址是您的供应商提供的一个可信的接入地址。你会在下一节中用到这个地址。 ## 设置 `gaiad` @@ -279,8 +254,7 @@ gaiad keys add --recover --account 1 **请确认您使用的`gaiad`是最新的稳定版本** ::: -无论您是否在自己运行一个节点，`gaiad` 都可以帮您实现与Cosmos Hub网络的交互。让我们来完成对它的配置。 - +无论您是否在自己运行一个节点，`gaiad` 都可以帮您实现与Cosmos Hub网络的交互。让我们来完成对它的配置。 您需要用下面的命令行完成对`gaiad`的配置： @@ -288,9 +262,7 @@ gaiad keys add --recover --account 1 gaiad config ``` - -此命名允许您为每个参数设置缺省值。 - +此命名允许您为每个参数设置缺省值。 首先，设置你想要访问的全节点的地址： @@ -300,10 +272,9 @@ gaiad config node : gaiad query ``` -对于每条命令，您都可以使用`-h` 或 `--help` 参数来获得更多的信息。 +对于每条命令，您都可以使用`-h` 或 `--help` 参数来获得更多的信息。 ## 发起交易 ### 关于gas费和手续费 +Cosmos Hub网络上的交易在被执行时需要支付手续费。这个手续费是用于支付执行交易所需的gas。计算公式如下： -Cosmos Hub网络上的交易在被执行时需要支付手续费。这个手续费是用于支付执行交易所需的gas。计算公式如下： ``` fees = gas * gasPrices ``` -`gas` 的多少取决于交易类型，不同的交易类型会收取不同的 `gas` 。每个交易的 `gas` 费是在实际执行过程中计算的，但我们可以通过设置 `gas` 参数中的 `auto` 值实现在交易前对 `gas` 费的估算，但这只是一个粗略的估计，你可以通过 `--gas-adjustment` (缺省值 `1.0`) 对预估的`gas` 值进行调节，以确保为交易支付足够的`gas` 。 +`gas` 的多少取决于交易类型，不同的交易类型会收取不同的 `gas` 。每个交易的 `gas` 费是在实际执行过程中计算的，但我们可以通过设置 `gas` 参数中的 `auto` 值实现在交易前对 `gas` 费的估算，但这只是一个粗略的估计，你可以通过 `--gas-adjustment` (缺省值 `1.0`) 对预估的`gas` 值进行调节，以确保为交易支付足够的`gas` 。 -`gasPrice` 用于设置单位 `gas` 的价格。每个验证人会设置一个最低gas价`min-gas-price`, 并只会将`gasPrice`大于`min-gas-price`的交易打包。 +`gasPrice` 用于设置单位 `gas` 的价格。每个验证人会设置一个最低gas价`min-gas-price`, 并只会将`gasPrice`大于`min-gas-price`的交易打包。 -交易的`fees` 是`gas` 和 `gasPrice`的乘积。作为一个用户，你需要输入3个参数中至少2个， `gasPrice`/`fees`的值越大，您的交易就越有机会被打包执行。 +交易的`fees` 是`gas` 和 `gasPrice`的乘积。作为一个用户，你需要输入3个参数中至少2个， `gasPrice`/`fees`的值越大，您的交易就越有机会被打包执行。 ### 抵押Atom通证 & 提取奖励 @@ -387,7 +357,7 @@ fees = gas * gasPrices ::: 警告 **注意：执行以下命令需要在一台联网的计算机。用一个硬件钱包设备执行这些命令会更安全。关于离线交易过程请看[这里](#从一台离线电脑上签署交易).** -::: +::: ```bash // 向指定验证人绑定一定数量的Atom通证 @@ -410,8 +380,8 @@ gaiad tx staking unbond --from ``` -如果您是连接到一个可信全节点的话，您可以通过一个区块链浏览器做检查。 +如果您是连接到一个可信全节点的话，您可以通过一个区块链浏览器做检查。 ## 参与链上治理 @@ -436,16 +406,15 @@ gaiad query tx Cosmos Hub有一个内建的治理系统，该系统允许抵押通证的持有人参与提案投票。系统现在支持3种提案类型： -- `Text Proposals`: 这是最基本的一种提案类型，通常用于获得大家对某个网络治理意见的观点。 -- `Parameter Proposals`: 这种提案通常用于改变网络参数的设定。 -- `Software Upgrade Proposal`: 这个提案用于升级Hub的软件。 +- `Text Proposals`: 这是最基本的一种提案类型，通常用于获得大家对某个网络治理意见的观点。 +- `Parameter Proposals`: 这种提案通常用于改变网络参数的设定。 +- `Software Upgrade Proposal`: 这个提案用于升级Hub的软件。 -任何Atom通证的持有人都能够提交一个提案。为了让一个提案获准公开投票，提议人必须要抵押一定量的通证 `deposit`，且抵押值必须大于 `minDeposit` 参数设定值. 提案的抵押不需要提案人一次全部交付。如果早期提案人交付的 `deposit` 不足，那么提案进入 `deposit_period` 状态。 此后，任何通证持有人可以通过 `depositTx` 交易增加对提案的抵押。 +任何Atom通证的持有人都能够提交一个提案。为了让一个提案获准公开投票，提议人必须要抵押一定量的通证 `deposit`，且抵押值必须大于 `minDeposit` 参数设定值. 提案的抵押不需要提案人一次全部交付。如果早期提案人交付的 `deposit` 不足，那么提案进入 `deposit_period` 状态。 此后，任何通证持有人可以通过 `depositTx` 交易增加对提案的抵押。 当`deposit` 达到 `minDeposit`，提案进入2周的 `voting_period` 。 任何**抵押了通证**的持有人都可以参与对这个提案的投票。投票的选项有`Yes`, `No`, `NoWithVeto` 和 `Abstain`。投票的权重取决于投票人所抵押的通证数量。如果通证持有人不投票，那么委托人将继承其委托的验证人的投票选项。当然，委托人也可以自己投出与所委托验证人不同的票。 - -当投票期结束后，获得50%（不包括投`Abstain `票）以上 `Yes` 投票权重且少于33.33% 的`NoWithVeto`（不包括投`Abstain `票）提案将被接受， +当投票期结束后，获得50%（不包括投`Abstain`票）以上 `Yes` 投票权重且少于33.33% 的`NoWithVeto`（不包括投`Abstain`票）提案将被接受， #### 实践练习 @@ -456,7 +425,7 @@ Cosmos Hub有一个内建的治理系统，该系统允许抵押通证的持有 ::: 警告 **注意：执行以下命令需要一台联网的计算机。用一个硬件钱包设备执行这些命令会更安全。关于离线交易过程请看[这里](#从一台离线电脑上签署交易).** -::: +::: ```bash // 提交一个提案 @@ -482,7 +451,6 @@ gaiad tx gov vote