certusone
/
cosmos-sdk
mirror of https://github.com/certusone/cosmos-sdk.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

style: lint go and markdown (backport #10060) (#10473) 

* style: lint go and markdown (#10060)

## Description

+ fixing `x/bank/migrations/v44.migrateDenomMetadata` - we could potentially put a wrong data in a new key if the old keys have variable length.
+ linting the code

Putting in the same PR because i found the issue when running a linter.

Depends on: #10112

---

### Author Checklist

*All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.*

I have...

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [ ] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [ ] added a changelog entry to `CHANGELOG.md`
- [ ] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [ ] updated the relevant documentation or specification
- [ ] reviewed "Files changed" and left comments if necessary
- [ ] confirmed all CI checks have passed

### Reviewers Checklist

*All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.*

I have...

- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed `!` in the type prefix if API or client breaking change
- [ ] confirmed all author checklist items have been addressed
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)

(cherry picked from commit 479485f95d)

# Conflicts:
#	CODING_GUIDELINES.md
#	CONTRIBUTING.md
#	STABLE_RELEASES.md
#	contrib/rosetta/README.md
#	cosmovisor/README.md
#	crypto/keyring/keyring.go
#	db/README.md
#	docs/404.md
#	docs/DOCS_README.md
#	docs/architecture/adr-038-state-listening.md
#	docs/architecture/adr-040-storage-and-smt-state-commitments.md
#	docs/architecture/adr-043-nft-module.md
#	docs/architecture/adr-044-protobuf-updates-guidelines.md
#	docs/architecture/adr-046-module-params.md
#	docs/migrations/pre-upgrade.md
#	docs/migrations/rest.md
#	docs/ru/README.md
#	docs/run-node/rosetta.md
#	docs/run-node/run-node.md
#	docs/run-node/run-testnet.md
#	go.mod
#	scripts/module-tests.sh
#	snapshots/README.md
#	store/streaming/README.md
#	store/streaming/file/README.md
#	store/v2/flat/store.go
#	store/v2/smt/store.go
#	x/auth/ante/sigverify.go
#	x/auth/middleware/basic.go
#	x/auth/spec/01_concepts.md
#	x/auth/spec/05_vesting.md
#	x/auth/spec/07_client.md
#	x/authz/spec/05_client.md
#	x/bank/spec/README.md
#	x/crisis/spec/05_client.md
#	x/distribution/spec/README.md
#	x/epoching/keeper/keeper.go
#	x/epoching/spec/03_to_improve.md
#	x/evidence/spec/07_client.md
#	x/feegrant/spec/README.md
#	x/gov/spec/01_concepts.md
#	x/gov/spec/07_client.md
#	x/group/internal/orm/spec/01_table.md
#	x/mint/spec/06_client.md
#	x/slashing/spec/09_client.md
#	x/slashing/spec/README.md
#	x/staking/spec/09_client.md
#	x/upgrade/spec/04_client.md

* fix conflicts

* remove unnecessary files

Co-authored-by: Robert Zaremba <robert@zaremba.ch>
This commit is contained in:
mergify[bot] 2021-11-11 21:29:29 +01:00 committed by GitHub
parent 0ac1f6dd8e
commit 8a9589a8de
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
38 changed files with 5742 additions and 371 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
CODING_GUIDELINES.md Normal file
View File

@ -0,0 +1,89 @@
# Coding Guidelines
This document is an extension to [CONTRIBUTING](./CONTRIBUTING.md) and provides more details about the coding guidelines and requirements.
## API & Design
+ Code must be well structured:
+ packages must have a limited responsibility (different concerns can go to different packages),
+ types must be easy to compose,
+ think about maintainbility and testability.
+ "Depend upon abstractions, [not] concretions".
+ Try to limit the number of methods you are exposing. It's easier to expose something later than to hide it.
+ Take advantage of `internal` package concept.
+ Follow agreed-upon design patterns and naming conventions.
+ publicly-exposed functions are named logically, have forward-thinking arguments and return types.
+ Avoid global variables and global configurators.
+ Favor composable and extensible designs.
+ Minimize code duplication.
+ Limit third-party dependencies.
Performance:
+ Avoid unnecessary operations or memory allocations.
Security:
+ Pay proper attention to exploits involving:
+ gas usage
+ transaction verification and signatures
+ malleability
+ code must be always deterministic
+ Thread safety. If some functionality is not thread-safe, or uses something that is not thread-safe, then clearly indicate the risk on each level.
## Testing
Make sure your code is well tested:
+ Provide unit tests for every unit of your code if possible. Unit tests are expected to comprise 70%-80% of your tests.
+ Describe the test scenarios you are implementing for integration tests.
+ Create integration tests for queries and msgs.
+ Use both test cases and property / fuzzy testing. We use the [rapid](pgregory.net/rapid) Go library for property-based and fuzzy testing.
+ Do not decrease code test coverage. Explain in a PR if test coverage is decreased.
We expect tests to use `require` or `assert` rather than `t.Skip` or `t.Fail`,
unless there is a reason to do otherwise.
When testing a function under a variety of different inputs, we prefer to use
[table driven tests](https://github.com/golang/go/wiki/TableDrivenTests).
Table driven test error messages should follow the following format
`<desc>, tc #<index>, i #<index>`.
`<desc>` is an optional short description of whats failing, `tc` is the
index within the test case table that is failing, and `i` is when there
is a loop, exactly which iteration of the loop failed.
The idea is you should be able to see the
error message and figure out exactly what failed.
Here is an example check:
```go
<some table>
for tcIndex, tc := range cases {
<some code>
resp, err := doSomething()
require.NoError(err)
require.Equal(t, tc.expected, resp, "should correctly perform X")
```
## Quality Assurance
We are forming a QA team that will support the core Cosmos SDK team and collaborators by:
- Improving the Cosmos SDK QA Processes
- Improving automation in QA and testing
- Defining high-quality metrics
- Maintaining and improving testing frameworks (unit tests, integration tests, and functional tests)
- Defining test scenarios.
- Verifying user experience and defining a high quality.
- We want to have **acceptance tests**! Document and list acceptance lists that are implemented and identify acceptance tests that are still missing.
- Acceptance tests should be specified in `acceptance-tests` directory as Markdown files.
- Supporting other teams with testing frameworks, automation, and User Experience testing.
- Testing chain upgrades for every new breaking change.
- Defining automated tests that assure data integrity after an update.
Desired outcomes:
- QA team works with Development Team.
- QA is happening in parallel with Core Cosmos SDK development.
- Releases are more predictable.
- QA reports. Goal is to guide with new tasks and be one of the QA measures.
As a developer, you must help the QA team by providing instructions for User Experience (UX) and functional testing.

316
CONTRIBUTING.md
View File

@ -1,155 +1,167 @@
# Contributing
- [Contributing](#contributing)
- [Dev Calls](#dev-calls)
- [Architecture Decision Records (ADR)](#architecture-decision-records-adr)
- [Pull Requests](#pull-requests)
- [Development Procedure](#development-procedure)
- [Testing](#testing)
- [Pull Requests](#pull-requests)
- [Pull Request Templates](#pull-request-templates)
- [Requesting Reviews](#requesting-reviews)
- [Reviewing Pull Requests](#reviewing-pull-requests)
- [Updating Documentation](#updating-documentation)
- [Forking](#forking)
- [Dependencies](#dependencies)
- [Protobuf](#protobuf)
- [Testing](#testing)
- [Branching Model and Release](#branching-model-and-release)
- [PR Targeting](#pr-targeting)
- [Development Procedure](#development-procedure)
- [Pull Merge Procedure](#pull-merge-procedure)
- [Release Procedure](#release-procedure)
- [Point Release Procedure](#point-release-procedure)
- [Code Owner Membership](#code-owner-membership)
- [Concept & Feature Approval Process](#concept--feature-approval-process)
Thank you for considering making contributions to Cosmos-SDK and related
repositories!
Thank you for considering making contributions to the Cosmos SDK and related repositories!
Contributing to this repo can mean many things such as participating in
discussion or proposing code changes. To ensure a smooth workflow for all
contributors, the general procedure for contributing has been established:
1. Either [open](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or
[find](https://github.com/cosmos/cosmos-sdk/issues) an issue you'd like to help with
2. Participate in thoughtful discussion on that issue
3. If you would like to contribute:
1. If the issue is a proposal, ensure that the proposal has been accepted
1. Start by browsing [new issues](https://github.com/cosmos/cosmos-sdk/issues) and [discussions](https://github.com/cosmos/cosmos-sdk/discussions). If you are looking for something interesting or if you have something in your mind, there is a chance it was has been discussed.
- Looking for a good place to start contributing? How about checking out some [good first issues](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)?
2. Determine whether a GitHub issue or discussion is more appropriate for your needs:
1. If want to propose something new that requires specification or an additional design, or you would like to change a process, start with a [new discussion](https://github.com/cosmos/cosmos-sdk/discussions/new). With discussions, we can better handle the design process using discussion threads. A discussion usually leads to one or more issues.
2. If the issue you want addressed is a specific proposal or a bug, then open a [new issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose).
3. Review existing [issues](https://github.com/cosmos/cosmos-sdk/issues) to find an issue you'd like to help with.
3. Participate in thoughtful discussion on that issue.
4. If you would like to contribute:
1. Ensure that the proposal has been accepted.
2. Ensure that nobody else has already begun working on this issue. If they have,
make sure to contact them to collaborate
make sure to contact them to collaborate.
3. If nobody has been assigned for the issue and you would like to work on it,
make a comment on the issue to inform the community of your intentions
to begin work
4. Follow standard GitHub best practices: fork the repo, branch from the
HEAD of `master`, make some commits, and submit a PR to `master`
- For core developers working within the cosmos-sdk repo, to ensure a clear
ownership of branches, branches must be named with the convention
`{moniker}/{issue#}-branch-name`
5. Be sure to submit the PR in `Draft` mode submit your PR early, even if
it's incomplete as this indicates to the community you're working on
something and allows them to provide comments early in the development process
6. When the code is complete it can be marked `Ready for Review`
7. Be sure to include a relevant change log entry in the `Unreleased` section
of `CHANGELOG.md` (see file for log format)
to begin work.
5. To submit your work as a contribution to the repository follow standard GitHub best practices. See [pull request guideline](#pull-requests) below.
Note that for very small or blatantly obvious problems (such as typos) it is
**Note:** For very small or blatantly obvious problems such as typos, you are
not required to an open issue to submit a PR, but be aware that for more complex
problems/features, if a PR is opened before an adequate design discussion has
taken place in a GitHub issue, that PR runs a high likelihood of being rejected.
Other notes:
## Teams Dev Calls
- Looking for a good place to start contributing? How about checking out some
[good first issues](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
- Please make sure to run `make format` before every commit - the easiest way
to do this is have your editor run it for you upon saving a file. Additionally
please ensure that your code is lint compliant by running `make lint-fix`.
A convenience git `pre-commit` hook that runs the formatters automatically
before each commit is available in the `contrib/githooks/` directory.
The Cosmos SDK has many stakeholders contributing and shaping the project. Regen Network Development leads the Cosmos SDK R&D, and welcomes long-term contributors and additional maintainers from other projects. We use self-organizing principles to coordinate and collaborate across organizations in structured "Working Groups" that focus on specific problem domains or architectural components of the Cosmos SDK.
The developers are organized in working groups which are listed on a ["Working Groups & Arch Process" Github Issue](https://github.com/cosmos/cosmos-sdk/issues/9058) (pinned at the top of the [issues list](https://github.com/cosmos/cosmos-sdk/issues)).
The important development announcements are shared on [Discord](https://discord.com/invite/cosmosnetwork) in the \#dev-announcements channel.
To synchronize we have few major meetings:
+ Architecture calls: bi-weekly on Fridays at 14:00 UTC (alternating with the grooming meeting below).
+ Grooming / Planning: bi-weekly on Fridays at 14:00 UTC (alternating with the architecture meeting above).
+ Cosmos Community SDK Development Call on the last Wednesday of every month at 17:00 UTC.
+ Cosmos Roadmap Prioritization every 4 weeks on Tuesday at 15:00 UTC (limited participation).
If you would like to join one of those calls, then please contact us on [Discord](https://discord.com/invite/cosmosnetwork) or reach out directly to Cory Levinson from Regen Network (cory@regen.network).
## Architecture Decision Records (ADR)
When proposing an architecture decision for the SDK, please create an [ADR](./docs/architecture/README.md)
so further discussions can be made. We are following this process so all involved parties are in
agreement before any party begins coding the proposed implementation. If you would like to see some examples
of how these are written refer to the current [ADRs](https://github.com/cosmos/cosmos-sdk/tree/master/docs/architecture).
When proposing an architecture decision for the Cosmos SDK, please start by opening an [issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or a [discussion](https://github.com/cosmos/cosmos-sdk/discussions/new) with a summary of the proposal. Once the proposal has been discussed and there is rough alignment on a high-level approach to the design, the [ADR creation process](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/PROCESS.md) can begin. We are following this process to ensure all involved parties are in agreement before any party begins coding the proposed implementation. If you would like to see examples of how these are written, please refer to the current [ADRs](https://github.com/cosmos/cosmos-sdk/tree/master/docs/architecture).
## Pull Requests
## Development Procedure
PRs should be categorically broken up based on the type of changes being made (i.e. `fix`, `feat`,
`refactor`, `docs`, etc.). The *type* must be included in the PR title as a prefix (e.g.
`fix: <description>`). This ensures that all changes committed to the base branch follow the
- The latest state of development is on `master`.
- `master` must never fail `make lint test test-race`.
- No `--force` onto `master` (except when reverting a broken commit, which should seldom happen).
- Create a branch to start a wok:
- Fork the repo (core developers must create a branch directly in the Cosmos SDK repo),
branch from the HEAD of `master`, make some commits, and submit a PR to `master`.
- For core developers working within the `cosmos-sdk` repo, follow branch name conventions to ensure a clear
ownership of branches: `{moniker}/{issue#}-branch-name`.
- See [Branching Model](#branching-model-and-release) for more details.
- Be sure to run `make format` before every commit. The easiest way
to do this is have your editor run it for you upon saving a file (most of the editors
will do it anyway using a pre-configured setup of the programming language mode).
Additionally, be sure that your code is lint compliant by running `make lint-fix`.
A convenience git `pre-commit` hook that runs the formatters automatically
before each commit is available in the `contrib/githooks/` directory.
- Follow the [CODING GUIDELINES](CODING_GUIDELINES.md), which defines criteria for designing and coding a software.
Code is merged into master through pull request procedure.
### Testing
Tests can be executed by running `make test` at the top level of the Cosmos SDK repository.
### Pull Requests
Before submitting a pull request:
- merge the latest master `git merge origin/master`,
- run `make lint test` to ensure that all checks and tests pass.
Then:
1. If you have something to show, **start with a `Draft` PR**. It's good to have early validation of your work and we highly recommend this practice. A Draft PR also indicates to the community that the work is in progress.
Draft PRs also helps the core team provide early feedback and ensure the work is in the right direction.
2. When the code is complete, change your PR from `Draft` to `Ready for Review`.
3. Go through the actions for each checkbox present in the PR template description. The PR actions are automatically provided for each new PR.
4. Be sure to include a relevant changelog entry in the `Unreleased` section of `CHANGELOG.md` (see file for log format).
PRs must have a category prefix that is based on the type of changes being made (for example, `fix`, `feat`,
`refactor`, `docs`, and so on). The *type* must be included in the PR title as a prefix (for example,
`fix: <description>`). This convention ensures that all changes that are committed to the base branch follow the
[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification.
Additionally, each PR should only address a single issue.
Pull requests are merged automatically using [`automerge` action](https://mergify.io/features/auto-merge).
NOTE: when merging, GitHub will squash commits and rebase on top of the master.
### Pull Request Templates
There are currently three PR templates. The [default template](./.github/PULL_REQUEST_TEMPLATE.md) is for types `fix`, `feat`, and `refactor`. We also have a [docs template](./.github/PULL_REQUEST_TEMPLATE/docs.md) for documentation changes and an [other template](./.github/PULL_REQUEST_TEMPLATE/other.md) for changes that do not affect production code. When previewing a PR before it has been opened, you can change the template by adding one of the following parameters to the url:
There are three PR templates. The [default template](./.github/PULL_REQUEST_TEMPLATE.md) is for types `fix`, `feat`, and `refactor`. We also have a [docs template](./.github/PULL_REQUEST_TEMPLATE/docs.md) for documentation changes and an [other template](./.github/PULL_REQUEST_TEMPLATE/other.md) for changes that do not affect production code. When previewing a PR before it has been opened, you can change the template by adding one of the following parameters to the url:
- `template=docs.md`
- `template=other.md`
### Requesting Reviews
In order to accomodate the review process, the author of the PR must complete the author checklist
In order to accommodate the review process, the author of the PR must complete the author checklist
(from the pull request template)
to the best of their abilities before marking the PR as "Ready for Review". If you would like to
receive early feedback on the PR, open the PR as a "Draft" and leave a comment in the PR indicating
that you would like early feedback and tagging whoever you would like to receive feedback from.
### Reviewing Pull Requests
Codeowners are marked automatically as the reviewers.
All PRs require at least two reviews before they can be merged (one review might be acceptable in
the case of minor changes to [docs](./.github/PULL_REQUEST_TEMPLATE/docs.md) or [other](./.github/PULL_REQUEST_TEMPLATE/other.md) changes that do not affect production code). Each PR template has a
reviewers checklist that must be completed before the PR can be merged. Each reviewer is responsible
All PRs require at least two review approvals before they can be merged (one review might be acceptable in
the case of minor changes to [docs](./.github/PULL_REQUEST_TEMPLATE/docs.md) or [other](./.github/PULL_REQUEST_TEMPLATE/other.md) changes that do not affect production code). Each PR template has a reviewers checklist that must be completed before the PR can be merged. Each reviewer is responsible
for all checked items unless they have indicated otherwise by leaving their handle next to specific
items. In addition, please use the following review explanations:
items. In addition, use the following review explanations:
- `LGTM` without an explicit approval means that the changes look good, but you haven't thoroughly reviewed the reviewer checklist items.
- `Approval` means that you have completed some or all of the reviewer checklist items. If you only reviewed selected items, you have added your handle next to the items that you have reviewed. In addition, please follow these guidelines:
- `Approval` means that you have completed some or all of the reviewer checklist items. If you only reviewed selected items, you must add your handle next to the items that you have reviewed. In addition, follow these guidelines:
- You must also think through anything which ought to be included but is not
- You must think through whether any added code could be partially combined (DRYed) with existing code
- You must think through any potential security issues or incentive-compatibility flaws introduced by the changes
- Naming must be consistent with conventions and the rest of the codebase
- Code must live in a reasonable location, considering dependency structures (e.g. not importing testing modules in production code, or including example code modules in production code).
- If you approve of the PR, you are responsible for any issues mentioned here and any issues that should have been addressed after thoroughly reviewing the reviewer checklist items in the pull request template.
- If you sat down with the PR submitter and did a pairing review please note that in the `Approval`, or your PR comments.
- If you are only making "surface level" reviews, submit any notes as `Comments` without adding a review.
- Code must live in a reasonable location, considering dependency structures (for example, not importing testing modules in production code, or including example code modules in production code).
- If you approve the PR, you are responsible for any issues mentioned here and any issues that should have been addressed after thoroughly reviewing the reviewer checklist items in the pull request template.
- If you sat down with the PR submitter and did a pairing review, add this information in the `Approval` or your PR comments.
- If you are only making "surface level" reviews, submit notes as a `comment` review.
### Updating Documentation
If you open a PR on the Cosmos SDK, it is mandatory to update the relevant documentation in `/docs`.
- If your change relates to the core SDK (baseapp, store, ...), please update the `docs/basics/`, `docs/core/` and/or `docs/building-modules/` folders.
- If your changes relate to the core of the CLI (not specifically to module's CLI/Rest), please modify the `docs/run-node/` folder.
- If your changes relate to a module, please update the module's spec in `x/moduleName/docs/spec/`.
- If your change relates to the core SDK (baseapp, store, ...), be sure to update the content in `docs/basics/`, `docs/core/` and/or `docs/building-modules/` folders.
- If your changes relate to the core of the CLI (not specifically to module's CLI/Rest), then modify the content in the `docs/run-node/` folder.
- If your changes relate to a module, then be sure to update the module's spec in `x/moduleName/docs/spec/`.
When writing documentation, follow the [Documentation Writing Guidelines](./docs/DOC_WRITING_GUIDELINES.md).
## Forking
Please note that Go requires code to live under absolute paths, which complicates forking.
While my fork lives at `https://github.com/rigeyrigerige/cosmos-sdk`,
the code should never exist at `$GOPATH/src/github.com/rigeyrigerige/cosmos-sdk`.
Instead, we use `git remote` to add the fork as a new remote for the original repo,
`$GOPATH/src/github.com/cosmos/cosmos-sdk`, and do all the work there.
For instance, to create a fork and work on a branch of it, I would:
- Create the fork on GitHub, using the fork button.
- Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/cosmos/cosmos-sdk`)
- `git remote rename origin upstream`
- `git remote add origin git@github.com:rigeyrigerige/cosmos-sdk.git`
Now `origin` refers to my fork and `upstream` refers to the Cosmos-SDK version.
So I can `git push -u origin master` to update my fork, and make pull requests to Cosmos-SDK from there.
Of course, replace `rigeyrigerige` with your git handle.
To pull in updates from the origin repo, run
- `git fetch upstream`
- `git rebase upstream/master` (or whatever branch you want)
Please don't make Pull Requests from `master`.
## Dependencies
We use [Go 1.14 Modules](https://github.com/golang/go/wiki/Modules) to manage
We use [Go Modules](https://github.com/golang/go/wiki/Modules) to manage
dependency versions.
The master branch of every Cosmos repository should just build with `go get`,
@ -161,7 +173,7 @@ build, in which case we can fall back on `go mod tidy -v`.
## Protobuf
We use [Protocol Buffers](https://developers.google.com/protocol-buffers) along with [gogoproto](https://github.com/gogo/protobuf) to generate code for use in Cosmos-SDK.
We use [Protocol Buffers](https://developers.google.com/protocol-buffers) along with [gogoproto](https://github.com/gogo/protobuf) to generate code for use in Cosmos SDK.
For determinstic behavior around Protobuf tooling, everything is containerized using Docker. Make sure to have Docker installed on your machine, or head to [Docker's website](https://docs.docker.com/get-docker/) to install it.
@ -188,125 +200,21 @@ For example, in vscode your `.vscode/settings.json` should look like:
}
```
## Testing
Tests can be ran by running `make test` at the top level of the SDK repository.
We expect tests to use `require` or `assert` rather than `t.Skip` or `t.Fail`,
unless there is a reason to do otherwise.
When testing a function under a variety of different inputs, we prefer to use
[table driven tests](https://github.com/golang/go/wiki/TableDrivenTests).
Table driven test error messages should follow the following format
`<desc>, tc #<index>, i #<index>`.
`<desc>` is an optional short description of whats failing, `tc` is the
index within the table of the testcase that is failing, and `i` is when there
is a loop, exactly which iteration of the loop failed.
The idea is you should be able to see the
error message and figure out exactly what failed.
Here is an example check:
```go
<some table>
for tcIndex, tc := range cases {
<some code>
for i := 0; i < tc.numTxsToTest; i++ {
<some code>
require.Equal(t, expectedTx[:32], calculatedTx[:32],
"First 32 bytes of the txs differed. tc #%d, i #%d", tcIndex, i)
```
## Branching Model and Release
User-facing repos should adhere to the trunk based development branching model: https://trunkbaseddevelopment.com/.
User-facing repos should adhere to the trunk based development branching model: https://trunkbaseddevelopment.com/. User branches should start with a user name, example: `{moniker}/{issue#}-branch-name`.
Libraries need not follow the model strictly, but would be wise to.
The Cosmos SDK repository is a [multi Go module](https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository) repository. It means that we have more than one Go module in a single repository.
The SDK utilizes [semantic versioning](https://semver.org/).
The Cosmos SDK utilizes [semantic versioning](https://semver.org/).
### PR Targeting
Ensure that you base and target your PR on the `master` branch.
All feature additions should be targeted against `master`. Bug fixes for an outstanding release candidate
should be targeted against the release candidate branch.
All feature additions and all bug fixes must be targeted against `master`. Exception is for bug fixes which are only related to a released version. In that case, the related bug fix PRs must target against the release branch.
### Development Procedure
- the latest state of development is on `master`
- `master` must never fail `make lint test test-race`
- `master` should not fail `make lint`
- no `--force` onto `master` (except when reverting a broken commit, which should seldom happen)
- create a development branch either on github.com/cosmos/cosmos-sdk, or your fork (using `git remote add origin`)
- before submitting a pull request, begin `git rebase` on top of `master`
### Pull Merge Procedure
- ensure pull branch is rebased on `master`
- run `make test` to ensure that all tests pass
- merge pull request
### Release Procedure
- Start on `master`
- Create the release candidate branch `rc/v*` (going forward known as **RC**)
and ensure it's protected against pushing from anyone except the release
manager/coordinator
- **no PRs targeting this branch should be merged unless exceptional circumstances arise**
- On the `RC` branch, prepare a new version section in the `CHANGELOG.md`
- All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md`
- Copy the entries into a `RELEASE_CHANGELOG.md`, this is needed so the bot knows which entries to add to the release page on GitHub.
- Kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks)
- If errors are found during the simulation testing, commit the fixes to `master`
and create a new `RC` branch (making sure to increment the `rcN`)
- After simulation has successfully completed, create the release branch
(`release/vX.XX.X`) from the `RC` branch
- Create a PR to `master` to incorporate the `CHANGELOG.md` updates
- Tag the release (use `git tag -a`) and create a release in GitHub
- Delete the `RC` branches
### Point Release Procedure
At the moment, only a single major release will be supported, so all point releases will be based
off of that release.
In order to alleviate the burden for a single person to have to cherry-pick and handle merge conflicts
of all desired backporting PRs to a point release, we instead maintain a living backport branch, where
all desired features and bug fixes are merged into as separate PRs.
Example:
Current release is `v0.38.4`. We then maintain a (living) branch `sru/release/v0.38.N`, given N as
the next patch release number (currently `0.38.5`) for the `0.38` release series. As bugs are fixed
and PRs are merged into `master`, if a contributor wishes the PR to be released as SRU into the
`v0.38.N` point release, the contributor must:
1. Add `0.38.N-backport` label
2. Pull latest changes on the desired `sru/release/vX.X.N` branch
3. Create a 2nd PR merging the respective SRU PR into `sru/release/v0.38.N`
4. Update the PR's description and ensure it contains the following information:
- **[Impact]** Explanation of how the bug affects users or developers.
- **[Test Case]** section with detailed instructions on how to reproduce the bug.
- **[Regression Potential]** section with a discussion how regressions are most likely to manifest, or might
manifest even if it's unlikely, as a result of the change. **It is assumed that any SRU candidate PR is
well-tested before it is merged in and has an overall low risk of regression**.
It is the PR's author's responsibility to fix merge conflicts, update changelog entries, and
ensure CI passes. If a PR originates from an external contributor, it may be a core team member's
responsibility to perform this process instead of the original author.
Lastly, it is core team's responsibility to ensure that the PR meets all the SRU criteria.
Finally, when a point release is ready to be made:
1. Create `release/v0.38.N` branch
2. Ensure changelog entries are verified
1. Be sure changelog entries are added to `RELEASE_CHANGELOG.md`
3. Add release version date to the changelog
4. Push release branch along with the annotated tag: **git tag -a**
5. Create a PR into `master` containing ONLY `CHANGELOG.md` updates
1. Do not push `RELEASE_CHANGELOG.md` to `master`
Note, although we aim to support only a single release at a time, the process stated above could be
used for multiple previous versions.
If needed, we backport a commit from `master` to a release branch (excluding consensus breaking feature, API breaking and similar).
## Code Owner Membership
@ -342,10 +250,10 @@ Other potential removal criteria:
* Violation of Code of Conduct
Earning this privilege should be considered to be no small feat and is by no
means guaranteed by any quantifiable metric. It is a symbol of great trust of
means guaranteed by any quantifiable metric. Serving as a code owner is a symbol of great trust from
the community of this project.
## Concept & Release Approval Process
## Concept & Feature Approval Process
The process for how Cosmos SDK maintainers take features and ADRs from concept to release
is broken up into three distinct stages: **Strategy Discovery**, **Concept Approval**, and
@ -353,7 +261,7 @@ is broken up into three distinct stages: **Strategy Discovery**, **Concept Appro
### Strategy Discovery
* Develop long term priorities, strategy and roadmap for the SDK
* Develop long term priorities, strategy and roadmap for the Cosmos SDK
* Release committee not yet defined as there is already a roadmap that can be used for the time being
### Concept Approval
@ -384,7 +292,7 @@ should convene to rectify the situation by either:
**Approval Committee & Decision Making**
In absense of general consensus, decision making requires 1/2 vote from the two members
In absence of general consensus, decision making requires 1/2 vote from the two members
of the **Concept Approval Committee**.
**Committee Members**
@ -397,7 +305,7 @@ Members must:
* Participate in all or almost all ADR discussions, both on GitHub as well as in bi-weekly Architecture Review
meetings
* Be active contributors to the SDK, and furthermore should be continuously making substantial contributions
* Be active contributors to the Cosmos SDK, and furthermore should be continuously making substantial contributions
to the project's codebase, review process, documentation and ADRs
* Have stake in the Cosmos SDK project, represented by:
* Being a client / user of the Comsos SDK
@ -421,6 +329,6 @@ well as for PRs made as part of a release process:
* Code reviewers should have more senior engineering capability
* 1/2 approval is required from the **primary repo maintainers** in `CODEOWNERS`
*Note: For any major or minor release series denoted as a "Stable Release" (e.g. v0.39 "Launchpad"), a separate release
**Note**: For any major release series denoted as a "Stable Release" (e.g. v0.42 "Stargate"), a separate release
committee is often established. Stable Releases, and their corresponding release committees are documented
separately in [STABLE_RELEASES.md](./STABLE_RELEASES.md)*
separately in [Stable Release Policy](./RELEASE_PROCESS.md#stable-release-policy)*

143
STABLE_RELEASES.md
View File

@ -1,143 +0,0 @@
# Stable Releases
*Stable Release Series* continue to receive bug fixes until they reach **End Of Life**.
Only the following release series are currently supported and receive bug fixes:
* **0.42 «Stargate»** will be supported until 6 months after **0.43.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
* **0.43 «Stargate»** is the latest stable release.
The **0.43 «Stargate»** release series is maintained in compliance with the **Stable Release Policy** as described in this document.
## Stable Release Policy
This policy presently applies *only* to the following release series:
* **0.43 «Stargate»**
### Point Releases
Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances
and must follow the [Point Release Procedure](CONTRIBUTING.md).
### Rationale
Unlike in-development `master` branch snapshots, **Cosmos-SDK** releases are subject to much wider adoption,
and by a significantly different demographic of users. During development, changes in the `master` branch
affect SDK users, application developers, early adopters, and other advanced users that elect to use
unstable experimental software at their own risk.
Conversely, users of a stable release expect a high degree of stability. They build their applications on it, and the
problems they experience with it could be potentially highly disruptive to their projects.
Stable release updates are recommended to the vast majority of developers, and so it is crucial to treat them
with great caution. Hence, when updates are proposed, they must be accompanied by a strong rationale and present
a low risk of regressions, i.e. even one-line changes could cause unexpected regressions due to side effects or
poorly tested code. We never assume that any change, no matter how little or non-intrusive, is completely exempt
of regression risks.
Therefore, the requirements for stable changes are different than those that are candidates to be merged in
the `master` branch. When preparing future major releases, our aim is to design the most elegant, user-friendly and
maintainable SDK possible which often entails fundamental changes to the SDK's architecture design, rearranging and/or
renaming packages as well as reducing code duplication so that we maintain common functions and data structures in one
place rather than leaving them scattered all over the code base. However, once a release is published, the
priority is to minimise the risk caused by changes that are not strictly required to fix qualifying bugs; this tends to
be correlated with minimising the size of such changes. As such, the same bug may need to be fixed in different
ways in stable releases and `master` branch.
### Migrations
To smoothen the update to the latest stable release, the SDK includes a set of CLI commands for managing migrations between SDK versions, under the `migrate` subcommand. Only migration scripts between stable releases are included. For the current release, **0.42 «Stargate»** and later migrations are supported.
### What qualifies as a Stable Release Update (SRU)
* **High-impact bugs**
* Bugs that may directly cause a security vulnerability.
* *Severe regressions* from a Cosmos-SDK's previous release. This includes all sort of issues
that may cause the core packages or the `x/` modules unusable.
* Bugs that may cause **loss of user's data**.
* Other safe cases:
* Bugs which don't fit in the aforementioned categories for which an obvious safe patch is known.
* Relatively small yet strictly non-breaking features with strong support from the community.
* Relatively small yet strictly non-breaking changes that introduce forward-compatible client
features to smoothen the migration to successive releases.
* Relatively small yet strictly non-breaking CLI improvements.
### What does not qualify as SRU
* State machine changes.
* Breaking changes in Protobuf definitions, as specified in [ADR-044](./docs/architecture/adr-044-protobuf-updates-guidelines.md).
* Changes that introduces API breakages (e.g. public functions and interfaces removal/renaming).
* Client-breaking changes in gRPC and HTTP request and response types.
* CLI-breaking changes.
* Cosmetic fixes, such as formatting or linter warning fixes.
## What pull requests will be included in stable point-releases
Pull requests that fix bugs and add features that fall in the following categories do not require a **Stable Release Exception** to be granted to be included in a stable point-release:
* **Severe regressions**.
* Bugs that may cause **client applications** to be **largely unusable**.
* Bugs that may cause **state corruption or data loss**.
* Bugs that may directly or indirectly cause a **security vulnerability**.
* Non-breaking features that are strongly requested by the community.
* Non-breaking CLI improvements that are strongly requested by the community.
## What pull requests will NOT be automatically included in stable point-releases
As rule of thumb, the following changes will **NOT** be automatically accepted into stable point-releases:
* **State machine changes**.
* **Protobug-breaking changes**, as specified in [ADR-044](./docs/architecture/adr-044-protobuf-updates- guidelines.md).
* **Client-breaking changes**, i.e. changes that prevent gRPC, HTTP and RPC clients to continue interacting with the node without any change.
* **API-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code.
* **CLI-breaking changes**, i.e. changes that require usage changes for CLI users.
In some circumstances, PRs that don't meet the aforementioned criteria might be raised and asked to be granted a *Stable Release Exception*.
## Stable Release Exception - Procedure
1. Check that the bug is either fixed or not reproducible in `master`. It is, in general, not appropriate to release bug fixes for stable releases without first testing them in `master`. Please apply the label [v0.43](https://github.com/cosmos/cosmos-sdk/milestone/26) to the issue.
2. Add a comment to the issue and ensure it contains the following information (see the bug template below):
* **[Impact]** An explanation of the bug on users and justification for backporting the fix to the stable release.
* A **[Test Case]** section containing detailed instructions on how to reproduce the bug.
* A **[Regression Potential]** section with a clear assessment on how regressions are most likely to manifest as a result of the pull request that aims to fix the bug in the target stable release.
3. **Stable Release Managers** will review and discuss the PR. Once *consensus* surrounding the rationale has been reached and the technical review has successfully concluded, the pull request will be merged in the respective point-release target branch (e.g. `release/v0.43.x`) and the PR included in the point-release's respective milestone (e.g. `v0.43.5`).
### Stable Release Exception - Bug template
```
#### Impact
Brief xplanation of the effects of the bug on users and a justification for backporting the fix to the stable release.
#### Test Case
Detailed instructions on how to reproduce the bug on Stargate's most recently published point-release.
#### Regression Potential
Explanation on how regressions might manifest - even if it's unlikely.
It is assumed that stable release fixes are well-tested and they come with a low risk of regressions.
It's crucial to make the effort of thinking about what could happen in case a regression emerges.
```
## Stable Release Managers
The **Stable Release Managers** evaluate and approve or reject updates and backports to Cosmos-SDK Stable Release series,
according to the [stable release policy](#stable-release-policy) and [release procedure](#stable-release-exception-procedure).
Decisions are made by consensus.
Their responsibilites include:
* Driving the Stable Release Exception process.
* Approving/rejecting proposed changes to a stable release series.
* Executing the release process of stable point-releases in compliance with the [Point Release Procedure](CONTRIBUTING.md).
The Stable Release Managers are appointed by the Interchain Foundation. Currently residing Stable Release Managers:
* @clevinson - Cory Levinson
* @amaurym - Amaury Martiny
* @robert-zaremba - Robert Zaremba

6
contrib/rosetta/README.md
View File

@ -17,7 +17,11 @@ Contains the required files to set up rosetta cli and make it work against its w
## node
Contains the files for a deterministic network, with fixed keys and some actions on there, to test parsing of msgs and historical balances.
Contains the files for a deterministic network, with fixed keys and some actions on there, to test parsing of msgs and historical balances. This image is used to run a simapp node and to run the rosetta server.
## Rosetta-cli
The docker image for ./rosetta-cli/Dockerfile is on [docker hub](https://hub.docker.com/r/tendermintdev/rosetta-cli). Whenever rosetta-cli releases a new version, rosetta-cli/Dockerfile should be updated to reflect the new version and pushed to docker hub.
## Notes

2
crypto/keys/multisig/amino.go
View File

@ -64,7 +64,7 @@ func tmToProto(tmPk tmMultisig) (*LegacyAminoPubKey, error) {
}
// MarshalAminoJSON overrides amino JSON unmarshaling.
func (m LegacyAminoPubKey) MarshalAminoJSON() (tmMultisig, error) { //nolint:golint
func (m LegacyAminoPubKey) MarshalAminoJSON() (tmMultisig, error) { //nolint:revive
return protoToTm(&m)
}

1
crypto/keys/secp256k1/secp256k1_nocgo.go
View File

@ -1,3 +1,4 @@
//go:build !libsecp256k1
// +build !libsecp256k1
package secp256k1

2
crypto/ledger/ledger_notavail.go
View File

@ -1,4 +1,6 @@
//go:build !cgo || !ledger
// +build !cgo !ledger
// test_ledger_mock
package ledger

47
docs/404.md Normal file
View File

@ -0,0 +1,47 @@
<!--
permalink: /404.html
layout: homepage
title: 404 Lost in Space!
description: You've been lost in space
sections:
- title: Introduction
desc: High-level overview of the Cosmos SDK.
url: /intro/overview.html
icon: introduction
- title: Basics
desc: Anatomy of a blockchain, transaction lifecycle, accounts and more.
icon: basics
url: /basics/app-anatomy.html
- title: Core Concepts
desc: Read about the core concepts like baseapp, the store, or the server.
icon: core
url: /core/baseapp.html
- title: Building Modules
desc: Discover how to build modules for the Cosmos SDK.
icon: modules
url: /building-modules/intro.html
- title: Running a Node
desc: Running and interacting with nodes using the CLI and API.
icon: interfaces
url: /run-node/
- title: Modules
desc: Explore existing modules to build your application with.
icon: specifications
url: /modules/
stack:
- title: Cosmos Hub
desc: The first of thousands of interconnected blockchains on the Cosmos Network.
color: "#BA3FD9"
label: hub
url: http://hub.cosmos.network
- title: Tendermint Core
desc: The leading BFT engine for building blockchains, powering Cosmos SDK.
color: "#00BB00"
label: core
url: http://docs.tendermint.com
footer:
newsletter: false
aside: false
-->
# 404 - Lost in space, this is just an empty void

20
docs/DOCS_README.md
View File

@ -1,13 +1,21 @@
# Updating the docs
If you want to open a PR on the Cosmos SDK to update the documentation, please follow the guidelines in the [`CONTRIBUTING.md`](https://github.com/cosmos/cosmos-sdk/tree/master/CONTRIBUTING.md#updating-documentation)
If you want to open a PR in Cosmos SDK to update the documentation, please follow the guidelines in [`CONTRIBUTING.md`](https://github.com/cosmos/cosmos-sdk/tree/master/CONTRIBUTING.md#updating-documentation).
## Translating
## Internationalization
- Docs translations live in a `docs/country-code/` folder, where `country-code` stands for the country code of the language used (`cn` for Chinese, `kr` for Korea, `fr` for France, ...).
- Always translate content living on `master`.
- Only content under `/docs/intro/`, `/docs/basics/`, `/docs/core/`, `/docs/building-modules/` and `docs/run-node/` needs to be translated, as well as `docs/README.md`. It is also nice (but not mandatory) to translate `/docs/spec/`.
- Specify the release/tag of the translation in the README of your translation folder. Update the release/tag each time you update the translation.
- Translations for documentation live in a `docs/<locale>/` folder, where `<locale>` is the language code for a specific language. For example, `zh` for Chinese, `ko` for Korean, `ru` for Russian, etc.
- Each `docs/<locale>/` folder must follow the same folder structure within `docs/`, but only content in the following folders needs to be translated and included in the respective `docs/<locale>/` folder:
- `docs/basics/`
- `docs/building-modules/`
- `docs/core/`
- `docs/ibc/`
- `docs/intro/`
- `docs/migrations/`
- `docs/run-node/`
- Each `docs/<locale>/` folder must also have a `README.md` that includes a translated version of both the layout and content within the root-level [`README.md`](https://github.com/cosmos/cosmos-sdk/tree/master/docs/README.md). The layout defined in the `README.md` is used to build the homepage.
- Always translate content living on `master` unless you are revising documentation for a specific release. Translated documentation like the root-level documentation is semantically versioned.
- For additional configuration options, please see [VuePress Internationalization](https://vuepress.vuejs.org/guide/i18n.html).
## Docs Build Workflow

4
docs/architecture/adr-010-modular-antehandler.md
View File

@ -273,10 +273,6 @@ Cons:
1. Decorator pattern may have a deeply nested structure that is hard to understand, this is mitigated by having the decorator order explicitly listed in the `ChainAnteDecorators` function.
2. Does not make use of the ModuleManager design. Since this is already being used for BeginBlocker/EndBlocker, this proposal seems unaligned with that design pattern.
## Status
> Accepted Simple Decorators approach
## Consequences
Since pros and cons are written for each approach, it is omitted from this section

4
docs/architecture/adr-022-custom-panic-handling.md
View File

@ -187,10 +187,6 @@ func (app *BaseApp) AddRunTxRecoveryHandler(handlers ...RecoveryHandler) {
This method would prepend handlers to an existing chain.
## Status
Proposed
## Consequences
### Positive

55
docs/migrations/pre-upgrade.md Normal file
View File

@ -0,0 +1,55 @@
# Pre-Upgrade Handling
Cosmovisor supports custom pre-upgrade handling. Use pre-upgrade handling when you need to implement application config changes that are required in the newer version before you perform the upgrade.
Using Cosmovisor pre-upgrade handling is optional. If pre-upgrade handling is not implemented, the upgrade continues.
For example, make the required new-version changes to `app.toml` settings during the pre-upgrade handling. The pre-upgrade handling process means that the file does not have to be manually updated after the upgrade.
Before the application binary is upgraded, Cosmovisor calls a `pre-upgrade` command that can be implemented by the application.
The `pre-upgrade` command does not take in any command-line arguments and is expected to terminate with the following exit codes:
| Exit status code | How it is handled in Cosmosvisor |
|------------------|---------------------------------------------------------------------------------------------------------------------|
| `0` | Assumes `pre-upgrade` command executed successfully and continues the upgrade. |
| `1` | Default exit code when `pre-upgrade` command has not been implemented. |
| `30` | `pre-upgrade` command was executed but failed. This fails the entire upgrade. |
| `31` | `pre-upgrade` command was executed but failed. But the command is retried until exit code `1` or `30` are returned. |
## Sample
Here is a sample structure of the `pre-upgrade` command:
```go
func preUpgradeCommand() *cobra.Command {
cmd := &cobra.Command{
Use: "pre-upgrade",
Short: "Pre-upgrade command",
Long: "Pre-upgrade command to implement custom pre-upgrade handling",
Run: func(cmd *cobra.Command, args []string) {
err := HandlePreUpgrade()
if err != nil {
os.Exit(30)
}
os.Exit(0)
},
}
return cmd
}
```
Ensure that the pre-upgrade command has been registered in the application:
```go
rootCmd.AddCommand(
// ..
preUpgradeCommand(),
// ..
)
```

2
docs/migrations/rest.md
View File

@ -102,4 +102,4 @@ Previously, some modules exposed legacy `POST` endpoints to generate unsigned tr
## Migrating to gRPC
Instead of hitting REST endpoints as described in the previous paragraph, the SDK also exposes a gRPC server. Any client can use gRPC instead of REST to interact with the node. An overview of different ways to communicate with a node can be found [here](../core/grpc_rest.md), and a concrete tutorial for setting up a gRPC client [here](../run-node/txs.md#programmatically-with-go).
Instead of hitting REST endpoints as described above, the Cosmos SDK also exposes a gRPC server. Any client can use gRPC instead of REST to interact with the node. An overview of different ways to communicate with a node can be found [here](../core/grpc_rest.md), and a concrete tutorial for setting up a gRPC client can be found [here](../run-node/txs.md#programmatically-with-go).

3
docs/ru/README.md Executable file
View File

@ -0,0 +1,3 @@
# Cosmos SDK Documentation (Russian)
A Russian translation of the Cosmos SDK documentation is not available for this version. If you would like to help with translating, please see [Internationalization](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md#internationalization). A `v0.39` version of the documentation can be found [here](https://github.com/cosmos/cosmos-sdk/tree/v0.39.3/docs/ru).

53
docs/run-node/rosetta.md
View File

@ -1,6 +1,57 @@
# Rosetta
Package rosetta implements the rosetta API for the current cosmos sdk release series.
The `rosetta` package implements Coinbase's [Rosetta API](https://www.rosetta-api.org). This document provides instructions on how to use the Rosetta API integration. For information about the motivation and design choices, refer to [ADR 035](../architecture/adr-035-rosetta-api-support.md).
## Add Rosetta Command
The Rosetta API server is a stand-alone server that connects to a node of a chain developed with Cosmos SDK.
To enable Rosetta API support, it's required to add the `RosettaCommand` to your application's root command file (e.g. `appd/cmd/root.go`).
Import the `server` package:
```go
"github.com/cosmos/cosmos-sdk/server"
```
Find the following line:
```go
initRootCmd(rootCmd, encodingConfig)
```
After that line, add the following:
```go
rootCmd.AddCommand(
server.RosettaCommand(encodingConfig.InterfaceRegistry, encodingConfig.Marshaler)
)
```
The `RosettaCommand` function builds the `rosetta` root command and is defined in the `server` package within Cosmos SDK.
Since we’ve updated the Cosmos SDK to work with the Rosetta API, updating the application's root command file is all you need to do.
An implementation example can be found in `simapp` package.
## Use Rosetta Command
To run Rosetta in your application CLI, use the following command:
```
appd rosetta --help
```
To test and run Rosetta API endpoints for applications that are running and exposed, use the following command:
```
appd rosetta
--blockchain "your application name (ex: gaia)"
--network "your chain identifier (ex: testnet-1)"
--tendermint "tendermint endpoint (ex: localhost:26657)"
--grpc "gRPC endpoint (ex: localhost:9090)"
--addr "rosetta binding address (ex: :8080)"
```
## Extension

20
docs/run-node/run-node.md
View File

@ -39,6 +39,26 @@ The `~/.simapp` folder has the following structure:
|- priv_validator_key.json # Private key to use as a validator in the consensus protocol.
```
## Updating Some Default Settings
If you want to change any field values in configuration files (for ex: genesis.json) you can use `jq` ([installation](https://stedolan.github.io/jq/download/) & [docs](https://stedolan.github.io/jq/manual/#Assignment)) & `sed` commands to do that. Few examples are listed here.
```bash
# to change the chain-id
jq '.chain_id = "testing"' genesis.json > temp.json && mv temp.json genesis.json
# to enable the api server
sed -i '/\[api\]/,+3 s/enable = false/enable = true/' app.toml
# to change the voting_period
jq '.app_state.gov.voting_params.voting_period = "600s"' genesis.json > temp.json && mv temp.json genesis.json
# to change the inflation
jq '.app_state.mint.minter.inflation = "0.300000000000000000"' genesis.json > temp.json && mv temp.json genesis.json
```
## Adding Genesis Accounts
Before starting the chain, you need to populate the state with at least one account. To do so, first [create a new account in the keyring](./keyring.md#adding-keys-to-the-keyring) named `my_validator` under the `test` keyring backend (feel free to choose another name and another backend).
Now that you have created a local account, go ahead and grant it some `stake` tokens in your chain's genesis file. Doing so will also make sure your chain is aware of this account's existence:

99
docs/run-node/run-testnet.md Normal file
View File

@ -0,0 +1,99 @@
<!--
order: 7
-->
# Running a Testnet
The `simd testnet` subcommand makes it easy to initialize and start a simulated test network for testing purposes. {synopsis}
In addition to the commands for [running a node](./run-node.html), the `simd` binary also includes a `testnet` command that allows you to start a simulated test network in-process or to initialize files for a simulated test network that runs in a separate process.
## Initialize Files
First, let's take a look at the `init-files` subcommand.
This is similar to the `init` command when initializing a single node, but in this case we are initializing multiple nodes, generating the genesis transactions for each node, and then collecting those transactions.
The `init-files` subcommand initializes the necessary files to run a test network in a separate process (i.e. using a Docker container). Running this command is not a prerequisite for the `start` subcommand ([see below](#start-testnet)).
In order to initialize the files for a test network, run the following command:
```bash
simd testnet init-files
```
You should see the following output in your terminal:
```bash
Successfully initialized 4 node directories
```
The default output directory is a relative `.testnets` directory. Let's take a look at the files created within the `.testnets` directory.
### gentxs
The `gentxs` directory includes a genesis transaction for each validator node. Each file includes a JSON encoded genesis transaction used to register a validator node at the time of genesis. The genesis transactions are added to the `genesis.json` file within each node directory during the initilization process.
### nodes
A node directory is created for each validator node. Within each node directory is a `simd` directory. The `simd` directory is the home directory for each node, which includes the configuration and data files for that node (i.e. the same files included in the default `~/.simapp` directory when running a single node).
## Start Testnet
Now, let's take a look at the `start` subcommand.
The `start` subcommand both initializes and starts an in-process test network. This is the fastest way to spin up a local test network for testing purposes.
You can start the local test network by running the following command:
```bash
simd testnet start
```
You should see something similar to the following:
```bash
acquiring test network lock
preparing test network with chain-id "chain-mtoD9v"
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ THIS MNEMONIC IS FOR TESTING PURPOSES ONLY ++
++ DO NOT USE IN PRODUCTION ++
++ ++
++ sustain know debris minute gate hybrid stereo custom ++
++ divorce cross spoon machine latin vibrant term oblige ++
++ moment beauty laundry repeat grab game bronze truly ++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
starting test network...
started test network
press the Enter Key to terminate
```
The first validator node is now running in-process, which means the test network will terminate once you either close the terminal window or you press the Enter key. In the output, the mnemonic phrase for the first validator node is provided for testing purposes. The validator node is using the same default addresses being used when initializing and starting a single node (no need to provide a `--node` flag).
Check the status of the first validator node:
```
simd status
```
Import the key from the provided mnemonic:
```
simd keys add test --recover --keyring-backend test
```
Check the balance of the account address:
```
simd q bank balances [address]
```
Use this test account to manually test against the test network.
## Testnet Options
You can customize the configuration of the test network with flags. In order to see all flag options, append the `--help` flag to each command.

2
go.mod
View File

@ -56,6 +56,8 @@ require (
gopkg.in/yaml.v2 v2.4.0
)
// latest grpc doesn't work with with our modified proto compiler, so we need to enforce
// the following version across all dependencies.
replace google.golang.org/grpc => google.golang.org/grpc v1.33.2
replace github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alpha.regen.1

48
scripts/module-tests.sh Normal file
View File

@ -0,0 +1,48 @@
#!/usr/bin/env bash
# this script is used by Github CI to tranverse all modules an run module tests.
# the script expects a diff to be generated in order to skip some modules.
# Executes go module tests and merges the coverage profile.
# If GIT_DIFF variable is set then it's used to test if a module has any file changes - if
# it doesn't have any file changes then we will ignore the module tests.
execute_mod_tests() {
go_mod=$1;
mod_dir=$(dirname "$go_mod");
mod_dir=${mod_dir:2}; # remove "./" prefix
root_dir=$(pwd);
# TODO: in the future we will need to disable it once we go into multi module setup, because
# we will have cross module dependencies.
if [ -n "$GIT_DIFF" ] && ! grep $mod_dir <<< $GIT_DIFF; then
echo ">>> ignoring module $mod_dir - no changes in the module";
return;
fi;
echo ">>> running $go_mod tests"
cd $mod_dir;
go test -mod=readonly -timeout 30m -coverprofile=${root_dir}/${coverage_file}.tmp -covermode=atomic -tags='norace ledger test_ledger_mock' ./...
local ret=$?
echo "test return: " $ret;
cd -;
# strip mode statement
tail -n +1 ${coverage_file}.tmp >> ${coverage_file}
rm ${coverage_file}.tmp;
return $ret;
}
# GIT_DIFF=`git status --porcelain`
echo "GIT_DIFF: " $GIT_DIFF
coverage_file=coverage-go-submod-profile.out
return_val=0;
for f in $(find -name go.mod -not -path "./go.mod"); do
execute_mod_tests $f;
if [[ $? -ne 0 ]] ; then
return_val=2;
fi;
done
exit $return_val;

2
server/rosetta/client_online.go
View File

@ -507,7 +507,7 @@ func extractInitialHeightFromGenesisChunk(genesisChunk string) (int64, error) {
return 0, err
}
re, err := regexp.Compile("\"initial_height\":\"(\\d+)\"")
re, err := regexp.Compile("\"initial_height\":\"(\\d+)\"") //nolint:gocritic
if err != nil {
return 0, err
}

2
server/rosetta/lib/internal/service/online.go
View File

@ -51,7 +51,7 @@ func (o OnlineNetwork) AccountCoins(_ context.Context, _ *types.AccountCoinsRequ
// networkOptionsFromClient builds network options given the client
func networkOptionsFromClient(client crgtypes.Client, genesisBlock *types.BlockIdentifier) *types.NetworkOptionsResponse {
var tsi *int64 = nil
var tsi *int64
if genesisBlock != nil {
tsi = &(genesisBlock.Index)
}

1
simapp/simd/cmd/genaccounts.go
View File

@ -39,7 +39,6 @@ contain valid denominations. Accounts may optionally be supplied with vesting pa
Args: cobra.ExactArgs(2),
RunE: func(cmd *cobra.Command, args []string) error {
clientCtx := client.GetClientContextFromCmd(cmd)
serverCtx := server.GetServerContextFromCmd(cmd)
config := serverCtx.Config

236
snapshots/README.md Normal file
View File

@ -0,0 +1,236 @@
# State Sync Snapshotting
The `snapshots` package implements automatic support for Tendermint state sync
in Cosmos SDK-based applications. State sync allows a new node joining a network
to simply fetch a recent snapshot of the application state instead of fetching
and applying all historical blocks. This can reduce the time needed to join the
network by several orders of magnitude (e.g. weeks to minutes), but the node
will not contain historical data from previous heights.
This document describes the Cosmos SDK implementation of the ABCI state sync
interface, for more information on Tendermint state sync in general see:
* [Tendermint Core State Sync for Developers](https://medium.com/tendermint/tendermint-core-state-sync-for-developers-70a96ba3ee35)
* [ABCI State Sync Spec](https://docs.tendermint.com/master/spec/abci/apps.html#state-sync)
* [ABCI State Sync Method/Type Reference](https://docs.tendermint.com/master/spec/abci/abci.html#state-sync)
## Overview
For an overview of how Cosmos SDK state sync is set up and configured by
developers and end-users, see the
[Cosmos SDK State Sync Guide](https://blog.cosmos.network/cosmos-sdk-state-sync-guide-99e4cf43be2f).
Briefly, the Cosmos SDK takes state snapshots at regular height intervals given
by `state-sync.snapshot-interval` and stores them as binary files in the
filesystem under `<node_home>/data/snapshots/`, with metadata in a LevelDB database
`<node_home>/data/snapshots/metadata.db`. The number of recent snapshots to keep are given by
`state-sync.snapshot-keep-recent`.
Snapshots are taken asynchronously, i.e. new blocks will be applied concurrently
with snapshots being taken. This is possible because IAVL supports querying
immutable historical heights. However, this requires `state-sync.snapshot-interval`
to be a multiple of `pruning-keep-every`, to prevent a height from being removed
while it is being snapshotted.
When a remote node is state syncing, Tendermint calls the ABCI method
`ListSnapshots` to list available local snapshots and `LoadSnapshotChunk` to
load a binary snapshot chunk. When the local node is being state synced,
Tendermint calls `OfferSnapshot` to offer a discovered remote snapshot to the
local application and `ApplySnapshotChunk` to apply a binary snapshot chunk to
the local application. See the resources linked above for more details on these
methods and how Tendermint performs state sync.
The Cosmos SDK does not currently do any incremental verification of snapshots
during restoration, i.e. only after the entire snapshot has been restored will
Tendermint compare the app hash against the trusted hash from the chain. Cosmos
SDK snapshots and chunks do contain hashes as checksums to guard against IO
corruption and non-determinism, but these are not tied to the chain state and
can be trivially forged by an adversary. This was considered out of scope for
the initial implementation, but can be added later without changes to the
ABCI state sync protocol.
## Snapshot Metadata
The ABCI Protobuf type for a snapshot is listed below (refer to the ABCI spec
for field details):
```protobuf
message Snapshot {
uint64 height = 1; // The height at which the snapshot was taken
uint32 format = 2; // The application-specific snapshot format
uint32 chunks = 3; // Number of chunks in the snapshot
bytes hash = 4; // Arbitrary snapshot hash, equal only if identical
bytes metadata = 5; // Arbitrary application metadata
}
```
Because the `metadata` field is application-specific, the Cosmos SDK uses a
similar type `cosmos.base.snapshots.v1beta1.Snapshot` with its own metadata
representation:
```protobuf
// Snapshot contains Tendermint state sync snapshot info.
message Snapshot {
uint64 height = 1;
uint32 format = 2;
uint32 chunks = 3;
bytes hash = 4;
Metadata metadata = 5 [(gogoproto.nullable) = false];
}
// Metadata contains SDK-specific snapshot metadata.
message Metadata {
repeated bytes chunk_hashes = 1; // SHA-256 chunk hashes
}
```
The `format` is currently `1`, defined in `snapshots.types.CurrentFormat`. This
must be increased whenever the binary snapshot format changes, and it may be
useful to support past formats in newer versions.
The `hash` is a SHA-256 hash of the entire binary snapshot, used to guard
against IO corruption and non-determinism across nodes. Note that this is not
tied to the chain state, and can be trivially forged (but Tendermint will always
compare the final app hash against the chain app hash). Similarly, the
`chunk_hashes` are SHA-256 checksums of each binary chunk.
The `metadata` field is Protobuf-serialized before it is placed into the ABCI
snapshot.
## Snapshot Format
The current version `1` snapshot format is a zlib-compressed, length-prefixed
Protobuf stream of `cosmos.base.store.v1beta1.SnapshotItem` messages, split into
chunks at exact 10 MB byte boundaries.
```protobuf
// SnapshotItem is an item contained in a rootmulti.Store snapshot.
message SnapshotItem {
// item is the specific type of snapshot item.
oneof item {
SnapshotStoreItem store = 1;
SnapshotIAVLItem iavl = 2 [(gogoproto.customname) = "IAVL"];
}
}
// SnapshotStoreItem contains metadata about a snapshotted store.
message SnapshotStoreItem {
string name = 1;
}
// SnapshotIAVLItem is an exported IAVL node.
message SnapshotIAVLItem {
bytes key = 1;
bytes value = 2;
int64 version = 3;
int32 height = 4;
}
```
Snapshots are generated by `rootmulti.Store.Snapshot()` as follows:
1. Set up a `protoio.NewDelimitedWriter` that writes length-prefixed serialized
`SnapshotItem` Protobuf messages.
1. Iterate over each IAVL store in lexicographical order by store name.
2. Emit a `SnapshotStoreItem` containing the store name.
3. Start an IAVL export for the store using
[`iavl.ImmutableTree.Export()`](https://pkg.go.dev/github.com/tendermint/iavl#ImmutableTree.Export).
4. Iterate over each IAVL node.
5. Emit a `SnapshotIAVLItem` for the IAVL node.
2. Pass the serialized Protobuf output stream to a zlib compression writer.
3. Split the zlib output stream into chunks at exactly every 10th megabyte.
Snapshots are restored via `rootmulti.Store.Restore()` as the inverse of the above, using
[`iavl.MutableTree.Import()`](https://pkg.go.dev/github.com/tendermint/iavl#MutableTree.Import)
to reconstruct each IAVL tree.
## Snapshot Storage
Snapshot storage is managed by `snapshots.Store`, with metadata in a `db.DB`
database and binary chunks in the filesystem. Note that this is only used to
store locally taken snapshots that are being offered to other nodes. When the
local node is being state synced, Tendermint will take care of buffering and
storing incoming snapshot chunks before they are applied to the application.
Metadata is generally stored in a LevelDB database at
`<node_home>/data/snapshots/metadata.db`. It contains serialized
`cosmos.base.snapshots.v1beta1.Snapshot` Protobuf messages with a key given by
the concatenation of a key prefix, the big-endian height, and the big-endian
format. Chunk data is stored as regular files under
`<node_home>/data/snapshots/<height>/<format>/<chunk>`.
The `snapshots.Store` API is based on streaming IO, and integrates easily with
the `snapshots.types.Snapshotter` snapshot/restore interface implemented by
`rootmulti.Store`. The `Store.Save()` method stores a snapshot given as a
`<- chan io.ReadCloser` channel of binary chunk streams, and `Store.Load()` loads
the snapshot as a channel of binary chunk streams -- the same stream types used
by `Snapshotter.Snapshot()` and `Snapshotter.Restore()` to take and restore
snapshots using streaming IO.
The store also provides many other methods such as `List()` to list stored
snapshots, `LoadChunk()` to load a single snapshot chunk, and `Prune()` to prune
old snapshots.
## Taking Snapshots
`snapshots.Manager` is a high-level snapshot manager that integrates a
`snapshots.types.Snapshotter` (i.e. the `rootmulti.Store` snapshot
functionality) and a `snapshots.Store`, providing an API that maps easily onto
the ABCI state sync API. The `Manager` will also make sure only one operation
is in progress at a time, e.g. to prevent multiple snapshots being taken
concurrently.
During `BaseApp.Commit`, once a state transition has been committed, the height
is checked against the `state-sync.snapshot-interval` setting. If the committed
height should be snapshotted, a goroutine `BaseApp.snapshot()` is spawned that
calls `snapshots.Manager.Create()` to create the snapshot.
`Manager.Create()` will do some basic pre-flight checks, and then start
generating a snapshot by calling `rootmulti.Store.Snapshot()`. The chunk stream
is passed into `snapshots.Store.Save()`, which stores the chunks in the
filesystem and records the snapshot metadata in the snapshot database.
Once the snapshot has been generated, `BaseApp.snapshot()` then removes any
old snapshots based on the `state-sync.snapshot-keep-recent` setting.
## Serving Snapshots
When a remote node is discovering snapshots for state sync, Tendermint will
call the `ListSnapshots` ABCI method to list the snapshots present on the
local node. This is dispatched to `snapshots.Manager.List()`, which in turn
dispatches to `snapshots.Store.List()`.
When a remote node is fetching snapshot chunks during state sync, Tendermint
will call the `LoadSnapshotChunk` ABCI method to fetch a chunk from the local
node. This dispatches to `snapshots.Manager.LoadChunk()`, which in turn
dispatches to `snapshots.Store.LoadChunk()`.
## Restoring Snapshots
When the operator has configured the local Tendermint node to run state sync
(see the resources listed in the introduction for details on Tendermint state
sync), it will discover snapshots across the P2P network and offer their
metadata in turn to the local application via the `OfferSnapshot` ABCI call.
`BaseApp.OfferSnapshot()` attempts to start a restore operation by calling
`snapshots.Manager.Restore()`. This may fail, e.g. if the snapshot format is
unknown (it may have been generated by a different version of the Cosmos SDK),
in which case Tendermint will offer other discovered snapshots.
If the snapshot is accepted, `Manager.Restore()` will record that a restore
operation is in progress, and spawn a separate goroutine that runs a synchronous
`rootmulti.Store.Restore()` snapshot restoration which will be fed snapshot
chunks until it is complete.
Tendermint will then start fetching and buffering chunks, providing them in
order via ABCI `ApplySnapshotChunk` calls. These dispatch to
`Manager.RestoreChunk()`, which passes the chunks to the ongoing restore
process, checking if errors have been encountered yet (e.g. due to checksum
mismatches or invalid IAVL data). Once the final chunk is passed,
`Manager.RestoreChunk()` will wait for the restore process to complete before
returning.
Once the restore is completed, Tendermint will go on to call the `Info` ABCI
call to fetch the app hash, and compare this against the trusted chain app
hash at the snapshot height to verify the restored state. If it matches,
Tendermint goes on to process blocks.

2
types/denom.go
View File

@ -9,7 +9,7 @@ import (
var denomUnits = map[string]Dec{}
// baseDenom is the denom of smallest unit registered
var baseDenom string = ""
var baseDenom string
// RegisterDenom registers a denomination with a corresponding unit. If the
// denomination is already registered, an error will be returned.

7
x/auth/spec/01_concepts.md
View File

@ -4,6 +4,13 @@ order: 1
# Concepts
**Note:** The auth module is different from the [authz module](../modules/authz/).
The differences are:
* `auth` - authentication of accounts and transactions for Cosmos SDK applications and is responsible for specifying the base transaction and account types.
* `authz` - authorization for accounts to perform actions on behalf of other accounts and enables a granter to grant authorizations to a grantee that allows the grantee to execute messages on behalf of the granter.
## Gas & Fees
Fees serve two purposes for an operator of the network.

2
x/auth/spec/05_vesting.md
View File

@ -614,3 +614,5 @@ linearly over time.
all coins at a given time.
- PeriodicVestingAccount: A vesting account implementation that vests coins
according to a custom vesting schedule.
- PermanentLockedAccount: It does not ever release coins, locking them indefinitely.
Coins in this account can still be used for delegating and for governance votes even while locked.

421
x/auth/spec/07_client.md Normal file
View File

@ -0,0 +1,421 @@
<!--
order: 7
-->
# Client
# Auth
## CLI
A user can query and interact with the `auth` module using the CLI.
### Query
The `query` commands allow users to query `auth` state.
```bash
simd query auth --help
```
#### account
The `account` command allow users to query for an account by it's address.
```bash
simd query auth account [address] [flags]
```
Example:
```bash
simd query auth account cosmos1...
```
Example Output:
```bash
'@type': /cosmos.auth.v1beta1.BaseAccount
account_number: "0"
address: cosmos1zwg6tpl8aw4rawv8sgag9086lpw5hv33u5ctr2
pub_key:
'@type': /cosmos.crypto.secp256k1.PubKey
key: ApDrE38zZdd7wLmFS9YmqO684y5DG6fjZ4rVeihF/AQD
sequence: "1"
```
#### accounts
The `accounts` command allow users to query all the available accounts.
```bash
simd query auth accounts [flags]
```
Example:
```bash
simd query auth accounts
```
Example Output:
```bash
accounts:
- '@type': /cosmos.auth.v1beta1.BaseAccount
account_number: "0"
address: cosmos1zwg6tpl8aw4rawv8sgag9086lpw5hv33u5ctr2
pub_key:
'@type': /cosmos.crypto.secp256k1.PubKey
key: ApDrE38zZdd7wLmFS9YmqO684y5DG6fjZ4rVeihF/AQD
sequence: "1"
- '@type': /cosmos.auth.v1beta1.ModuleAccount
base_account:
account_number: "8"
address: cosmos1yl6hdjhmkf37639730gffanpzndzdpmhwlkfhr
pub_key: null
sequence: "0"
name: transfer
permissions:
- minter
- burner
- '@type': /cosmos.auth.v1beta1.ModuleAccount
base_account:
account_number: "4"
address: cosmos1fl48vsnmsdzcv85q5d2q4z5ajdha8yu34mf0eh
pub_key: null
sequence: "0"
name: bonded_tokens_pool
permissions:
- burner
- staking
- '@type': /cosmos.auth.v1beta1.ModuleAccount
base_account:
account_number: "5"
address: cosmos1tygms3xhhs3yv487phx3dw4a95jn7t7lpm470r
pub_key: null
sequence: "0"
name: not_bonded_tokens_pool
permissions:
- burner
- staking
- '@type': /cosmos.auth.v1beta1.ModuleAccount
base_account:
account_number: "6"
address: cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn
pub_key: null
sequence: "0"
name: gov
permissions:
- burner
- '@type': /cosmos.auth.v1beta1.ModuleAccount
base_account:
account_number: "3"
address: cosmos1jv65s3grqf6v6jl3dp4t6c9t9rk99cd88lyufl
pub_key: null
sequence: "0"
name: distribution
permissions: []
- '@type': /cosmos.auth.v1beta1.BaseAccount
account_number: "1"
address: cosmos147k3r7v2tvwqhcmaxcfql7j8rmkrlsemxshd3j
pub_key: null
sequence: "0"
- '@type': /cosmos.auth.v1beta1.ModuleAccount
base_account:
account_number: "7"
address: cosmos1m3h30wlvsf8llruxtpukdvsy0km2kum8g38c8q
pub_key: null
sequence: "0"
name: mint
permissions:
- minter
- '@type': /cosmos.auth.v1beta1.ModuleAccount
base_account:
account_number: "2"
address: cosmos17xpfvakm2amg962yls6f84z3kell8c5lserqta
pub_key: null
sequence: "0"
name: fee_collector
permissions: []
pagination:
next_key: null
total: "0"
```
#### params
The `params` command allow users to query the current auth parameters.
```bash
simd query auth params [flags]
```
Example:
```bash
simd query auth params
```
Example Output:
```bash
max_memo_characters: "256"
sig_verify_cost_ed25519: "590"
sig_verify_cost_secp256k1: "1000"
tx_sig_limit: "7"
tx_size_cost_per_byte: "10"
```
## gRPC
A user can query the `auth` module using gRPC endpoints.
### Account
The `account` endpoint allow users to query for an account by it's address.
```bash
cosmos.auth.v1beta1.Query/Account
```
Example:
```bash
grpcurl -plaintext \
-d '{"address":"cosmos1.."}' \
localhost:9090 \
cosmos.auth.v1beta1.Query/Account
```
Example Output:
```bash
{
"account":{
"@type":"/cosmos.auth.v1beta1.BaseAccount",
"address":"cosmos1zwg6tpl8aw4rawv8sgag9086lpw5hv33u5ctr2",
"pubKey":{
"@type":"/cosmos.crypto.secp256k1.PubKey",
"key":"ApDrE38zZdd7wLmFS9YmqO684y5DG6fjZ4rVeihF/AQD"
},
"sequence":"1"
}
}
```
### Accounts
The `accounts` endpoint allow users to query all the available accounts.
```bash
cosmos.auth.v1beta1.Query/Accounts
```
Example:
```bash
grpcurl -plaintext \
localhost:9090 \
cosmos.auth.v1beta1.Query/Accounts
```
Example Output:
```bash
{
"accounts":[
{
"@type":"/cosmos.auth.v1beta1.BaseAccount",
"address":"cosmos1zwg6tpl8aw4rawv8sgag9086lpw5hv33u5ctr2",
"pubKey":{
"@type":"/cosmos.crypto.secp256k1.PubKey",
"key":"ApDrE38zZdd7wLmFS9YmqO684y5DG6fjZ4rVeihF/AQD"
},
"sequence":"1"
},
{
"@type":"/cosmos.auth.v1beta1.ModuleAccount",
"baseAccount":{
"address":"cosmos1yl6hdjhmkf37639730gffanpzndzdpmhwlkfhr",
"accountNumber":"8"
},
"name":"transfer",
"permissions":[
"minter",
"burner"
]
},
{
"@type":"/cosmos.auth.v1beta1.ModuleAccount",
"baseAccount":{
"address":"cosmos1fl48vsnmsdzcv85q5d2q4z5ajdha8yu34mf0eh",
"accountNumber":"4"
},
"name":"bonded_tokens_pool",
"permissions":[
"burner",
"staking"
]
},
{
"@type":"/cosmos.auth.v1beta1.ModuleAccount",
"baseAccount":{
"address":"cosmos1tygms3xhhs3yv487phx3dw4a95jn7t7lpm470r",
"accountNumber":"5"
},
"name":"not_bonded_tokens_pool",
"permissions":[
"burner",
"staking"
]
},
{
"@type":"/cosmos.auth.v1beta1.ModuleAccount",
"baseAccount":{
"address":"cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn",
"accountNumber":"6"
},
"name":"gov",
"permissions":[
"burner"
]
},
{
"@type":"/cosmos.auth.v1beta1.ModuleAccount",
"baseAccount":{
"address":"cosmos1jv65s3grqf6v6jl3dp4t6c9t9rk99cd88lyufl",
"accountNumber":"3"
},
"name":"distribution"
},
{
"@type":"/cosmos.auth.v1beta1.BaseAccount",
"accountNumber":"1",
"address":"cosmos147k3r7v2tvwqhcmaxcfql7j8rmkrlsemxshd3j"
},
{
"@type":"/cosmos.auth.v1beta1.ModuleAccount",
"baseAccount":{
"address":"cosmos1m3h30wlvsf8llruxtpukdvsy0km2kum8g38c8q",
"accountNumber":"7"
},
"name":"mint",
"permissions":[
"minter"
]
},
{
"@type":"/cosmos.auth.v1beta1.ModuleAccount",
"baseAccount":{
"address":"cosmos17xpfvakm2amg962yls6f84z3kell8c5lserqta",
"accountNumber":"2"
},
"name":"fee_collector"
}
],
"pagination":{
"total":"9"
}
}
```
### Params
The `params` endpoint allow users to query the current auth parameters.
```bash
cosmos.auth.v1beta1.Query/Params
```
Example:
```bash
grpcurl -plaintext \
localhost:9090 \
cosmos.auth.v1beta1.Query/Params
```
Example Output:
```bash
{
"params": {
"maxMemoCharacters": "256",
"txSigLimit": "7",
"txSizeCostPerByte": "10",
"sigVerifyCostEd25519": "590",
"sigVerifyCostSecp256k1": "1000"
}
}
```
## REST
A user can query the `auth` module using REST endpoints.
### Account
The `account` endpoint allow users to query for an account by it's address.
```bash
/cosmos/auth/v1beta1/account?address={address}
```
### Accounts
The `accounts` endpoint allow users to query all the available accounts.
```bash
/cosmos/auth/v1beta1/accounts
```
### Params
The `params` endpoint allow users to query the current auth parameters.
```bash
/cosmos/auth/v1beta1/params
```
# Vesting
## CLI
A user can query and interact with the `vesting` module using the CLI.
### Transactions
The `tx` commands allow users to interact with the `vesting` module.
```bash
simd tx vesting --help
```
#### create-periodic-vesting-account
The `create-periodic-vesting-account` command creates a new vesting account funded with an allocation of tokens, where a sequence of coins and period length in seconds. Periods are sequential, in that the duration of of a period only starts at the end of the previous period. The duration of the first period starts upon account creation.
```bash
simd tx vesting create-periodic-vesting-account [to_address] [periods_json_file] [flags]
```
Example:
```bash
simd tx vesting create-periodic-vesting-account cosmos1.. periods.json
```
#### create-vesting-account
The `create-vesting-account` command creates a new vesting account funded with an allocation of tokens. The account can either be a delayed or continuous vesting account, which is determined by the '--delayed' flag. All vesting accouts created will have their start time set by the committed block's time. The end_time must be provided as a UNIX epoch timestamp.
```bash
simd tx vesting create-vesting-account [to_address] [amount] [end_time] [flags]
```
Example:
```bash
simd tx vesting create-vesting-account cosmos1.. 100stake 2592000
```

172
x/authz/spec/05_client.md Normal file
View File

@ -0,0 +1,172 @@
<!--
order: 5
-->
# Client
## CLI
A user can query and interact with the `authz` module using the CLI.
### Query
The `query` commands allow users to query `authz` state.
```bash
simd query authz --help
```
#### grants
The `grants` command allows users to query grants for a granter-grantee pair. If the message type URL is set, it selects grants only for that message type.
```bash
simd query authz grants [granter-addr] [grantee-addr] [msg-type-url]? [flags]
```
Example:
```bash
simd query authz grants cosmos1.. cosmos1.. /cosmos.bank.v1beta1.MsgSend
```
Example Output:
```bash
grants:
- authorization:
'@type': /cosmos.bank.v1beta1.SendAuthorization
spend_limit:
- amount: "100"
denom: stake
expiration: "2022-01-01T00:00:00Z"
pagination: null
```
### Transactions
The `tx` commands allow users to interact with the `authz` module.
```bash
simd tx authz --help
```
#### exec
The `exec` command allows a grantee to execute a transaction on behalf of granter.
```bash
simd tx authz exec [tx-json-file] --from [grantee] [flags]
```
Example:
```bash
simd tx authz exec tx.json --from=cosmos1..
```
#### grant
The `grant` command allows a granter to grant an authorization to a grantee.
```bash
simd tx authz grant <grantee> <authorization_type="send"|"generic"|"delegate"|"unbond"|"redelegate"> --from <granter> [flags]
```
Example:
```bash
simd tx authz grant cosmos1.. send --spend-limit=100stake --from=cosmos1..
```
#### revoke
The `revoke` command allows a granter to revoke an authorization from a grantee.
```bash
simd tx authz revoke [grantee] [msg-type-url] --from=[granter] [flags]
```
Example:
```bash
simd tx authz revoke cosmos1.. /cosmos.bank.v1beta1.MsgSend --from=cosmos1..
```
## gRPC
A user can query the `authz` module using gRPC endpoints.
### Grants
The `Grants` endpoint allows users to query grants for a granter-grantee pair. If the message type URL is set, it selects grants only for that message type.
```bash
cosmos.authz.v1beta1.Query/Grants
```
Example:
```bash
grpcurl -plaintext \
-d '{"granter":"cosmos1..","grantee":"cosmos1..","msg_type_url":"/cosmos.bank.v1beta1.MsgSend"}' \
localhost:9090 \
cosmos.authz.v1beta1.Query/Grants
```
Example Output:
```bash
{
"grants": [
{
"authorization": {
"@type": "/cosmos.bank.v1beta1.SendAuthorization",
"spendLimit": [
{
"denom":"stake",
"amount":"100"
}
]
},
"expiration": "2022-01-01T00:00:00Z"
}
]
}
```
## REST
A user can query the `authz` module using REST endpoints.
```bash
/cosmos/authz/v1beta1/grants
```
Example:
```bash
curl "localhost:1317/cosmos/authz/v1beta1/grants?granter=cosmos1..&grantee=cosmos1..&msg_type_url=/cosmos.bank.v1beta1.MsgSend"
```
Example Output:
```bash
{
"grants": [
{
"authorization": {
"@type": "/cosmos.bank.v1beta1.SendAuthorization",
"spend_limit": [
{
"denom": "stake",
"amount": "100"
}
]
},
"expiration": "2022-01-01T00:00:00Z"
}
],
"pagination": null
}
```

31
x/crisis/spec/05_client.md Normal file
View File

@ -0,0 +1,31 @@
<!--
order: 5
-->
# Client
## CLI
A user can query and interact with the `crisis` module using the CLI.
### Transactions
The `tx` commands allow users to interact with the `crisis` module.
```bash
simd tx crisis --help
```
#### invariant-broken
The `invariant-broken` command submits proof when an invariant was broken to halt the chain
```bash
simd tx crisis invariant-broken [module-name] [invariant-route] [flags]
```
Example:
```bash
simd tx crisis invariant-broken bank total-supply --from=[keyname or address]
```

2
x/distribution/legacy/v043/helpers.go
View File

@ -19,7 +19,7 @@ func MigratePrefixAddress(store sdk.KVStore, prefixBz []byte) {
for ; oldStoreIter.Valid(); oldStoreIter.Next() {
addr := oldStoreIter.Key()
var newStoreKey []byte = prefixBz
var newStoreKey = prefixBz
newStoreKey = append(newStoreKey, address.MustLengthPrefix(addr)...)
// Set new key on store. Values don't change.

2
x/distribution/spec/README.md
View File

@ -42,7 +42,7 @@ following rewards between validators and associated delegators:
Fees are pooled within a global pool, as well as validator specific
proposer-reward pools. The mechanisms used allow for validators and delegators
to independently and lazily withdraw their rewards.
to independently and lazily withdraw their rewards.
## Shortcomings

188
x/evidence/spec/07_client.md Normal file
View File

@ -0,0 +1,188 @@
# Client
## CLI
A user can query and interact with the `evidence` module using the CLI.
### Query
The `query` commands allows users to query `evidence` state.
```bash
simd query evidence --help
```
### evidence
The `evidence` command allows users to list all evidence or evidence by hash.
Usage:
```bash
simd query evidence [flags]
```
To query evidence by hash
Example:
```bash
simd query evidence "DF0C23E8634E480F84B9D5674A7CDC9816466DEC28A3358F73260F68D28D7660"
```
Example Output:
```bash
evidence:
consensus_address: cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h
height: 11
power: 100
time: "2021-10-20T16:08:38.194017624Z"
```
To get all evidence
Example:
```bash
simd query evidence
```
Example Output:
```bash
evidence:
consensus_address: cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h
height: 11
power: 100
time: "2021-10-20T16:08:38.194017624Z"
pagination:
next_key: null
total: "1"
```
## REST
A user can query the `evidence` module using REST endpoints.
### Evidence
Get evidence by hash
```bash
/cosmos/evidence/v1beta1/evidence/{evidence_hash}
```
Example:
```bash
curl -X GET "http://localhost:1317/cosmos/evidence/v1beta1/evidence/DF0C23E8634E480F84B9D5674A7CDC9816466DEC28A3358F73260F68D28D7660"
```
Example Output:
```bash
{
"evidence": {
"consensus_address": "cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h",
"height": "11",
"power": "100",
"time": "2021-10-20T16:08:38.194017624Z"
}
}
```
### All evidence
Get all evidence
```bash
/cosmos/evidence/v1beta1/evidence
```
Example:
```bash
curl -X GET "http://localhost:1317/cosmos/evidence/v1beta1/evidence"
```
Example Output:
```bash
{
"evidence": [
{
"consensus_address": "cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h",
"height": "11",
"power": "100",
"time": "2021-10-20T16:08:38.194017624Z"
}
],
"pagination": {
"total": "1"
}
}
```
## gRPC
A user can query the `evidence` module using gRPC endpoints.
### Evidence
Get evidence by hash
```bash
cosmos.evidence.v1beta1.Query/Evidence
```
Example:
```bash
grpcurl -plaintext -d '{"evidence_hash":"DF0C23E8634E480F84B9D5674A7CDC9816466DEC28A3358F73260F68D28D7660"}' localhost:9090 cosmos.evidence.v1beta1.Query/Evidence
```
Example Output:
```bash
{
"evidence": {
"consensus_address": "cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h",
"height": "11",
"power": "100",
"time": "2021-10-20T16:08:38.194017624Z"
}
}
```
### All evidence
Get all evidence
```bash
cosmos.evidence.v1beta1.Query/AllEvidence
```
Example:
```bash
grpcurl -plaintext localhost:9090 cosmos.evidence.v1beta1.Query/AllEvidence
```
Example Output:
```bash
{
"evidence": [
{
"consensus_address": "cosmosvalcons1ntk8eualewuprz0gamh8hnvcem2nrcdsgz563h",
"height": "11",
"power": "100",
"time": "2021-10-20T16:08:38.194017624Z"
}
],
"pagination": {
"total": "1"
}
}
```

1060
x/gov/spec/07_client.md Normal file
View File

File diff suppressed because it is too large Load Diff

224
x/mint/spec/06_client.md Normal file
View File

@ -0,0 +1,224 @@
<!--
order: 6
-->
# Client
## CLI
A user can query and interact with the `mint` module using the CLI.
### Query
The `query` commands allow users to query `mint` state.
```
simd query mint --help
```
#### annual-provisions
The `annual-provisions` command allow users to query the current minting annual provisions value
```
simd query mint annual-provisions [flags]
```
Example:
```
simd query mint annual-provisions
```
Example Output:
```
22268504368893.612100895088410693
```
#### inflation
The `inflation` command allow users to query the current minting inflation value
```
simd query mint inflation [flags]
```
Example:
```
simd query mint inflation
```
Example Output:
```
0.199200302563256955
```
#### params
The `params` command allow users to query the current minting parameters
```
simd query mint params [flags]
```
Example:
```
blocks_per_year: "4360000"
goal_bonded: "0.670000000000000000"
inflation_max: "0.200000000000000000"
inflation_min: "0.070000000000000000"
inflation_rate_change: "0.130000000000000000"
mint_denom: stake
```
## gRPC
A user can query the `mint` module using gRPC endpoints.
### AnnualProvisions
The `AnnualProvisions` endpoint allow users to query the current minting annual provisions value
```
/cosmos.mint.v1beta1.Query/AnnualProvisions
```
Example:
```
grpcurl -plaintext localhost:9090 cosmos.mint.v1beta1.Query/AnnualProvisions
```
Example Output:
```
{
"annualProvisions": "1432452520532626265712995618"
}
```
### Inflation
The `Inflation` endpoint allow users to query the current minting inflation value
```
/cosmos.mint.v1beta1.Query/Inflation
```
Example:
```
grpcurl -plaintext localhost:9090 cosmos.mint.v1beta1.Query/Inflation
```
Example Output:
```
{
"inflation": "130197115720711261"
}
```
### Params
The `Params` endpoint allow users to query the current minting parameters
```
/cosmos.mint.v1beta1.Query/Params
```
Example:
```
grpcurl -plaintext localhost:9090 cosmos.mint.v1beta1.Query/Params
```
Example Output:
```
{
"params": {
"mintDenom": "stake",
"inflationRateChange": "130000000000000000",
"inflationMax": "200000000000000000",
"inflationMin": "70000000000000000",
"goalBonded": "670000000000000000",
"blocksPerYear": "6311520"
}
}
```
## REST
A user can query the `mint` module using REST endpoints.
### annual-provisions
```
/cosmos/mint/v1beta1/annual_provisions
```
Example:
```
curl "localhost:1317/cosmos/mint/v1beta1/annual_provisions"
```
Example Output:
```
{
"annualProvisions": "1432452520532626265712995618"
}
```
### inflation
```
/cosmos/mint/v1beta1/inflation
```
Example:
```
curl "localhost:1317/cosmos/mint/v1beta1/inflation"
```
Example Output:
```
{
"inflation": "130197115720711261"
}
```
### params
```
/cosmos/mint/v1beta1/params
```
Example:
```
curl "localhost:1317/cosmos/mint/v1beta1/params"
```
Example Output:
```
{
"params": {
"mintDenom": "stake",
"inflationRateChange": "130000000000000000",
"inflationMax": "200000000000000000",
"inflationMin": "70000000000000000",
"goalBonded": "670000000000000000",
"blocksPerYear": "6311520"
}
}
```

294
x/slashing/spec/09_client.md Normal file
View File

@ -0,0 +1,294 @@
<!--
order: 9
-->
# CLI
A user can query and interact with the `slashing` module using the CLI.
### Query
The `query` commands allow users to query `slashing` state.
```bash
simd query slashing --help
```
#### params
The `params` command allows users to query genesis parameters for the slashing module.
```bash
simd query slashing params [flags]
```
Example:
```bash
simd query slashing params
```
Example Output:
```bash
downtime_jail_duration: 600s
min_signed_per_window: "0.500000000000000000"
signed_blocks_window: "100"
slash_fraction_double_sign: "0.050000000000000000"
slash_fraction_downtime: "0.010000000000000000"
```
#### signing-info
The `signing-info` command allows users to query signing-info of the validator using consensus public key.
```bash
simd query slashing signing-infos [flags]
```
Example:
```bash
simd query slashing signing-info '{"@type":"/cosmos.crypto.ed25519.PubKey","key":"Auxs3865HpB/EfssYOzfqNhEJjzys6jD5B6tPgC8="}'
```
Example Output:
```bash
address: cosmosvalcons1nrqsld3aw6lh6t082frdqc84uwxn0t958c
index_offset: "2068"
jailed_until: "1970-01-01T00:00:00Z"
missed_blocks_counter: "0"
start_height: "0"
tombstoned: false
```
#### signing-infos
The `signing-infos` command allows users to query signing infos of all validators.
```bash
simd query slashing signing-infos [flags]
```
Example:
```bash
simd query slashing signing-infos
```
Example Output:
```bash
info:
- address: cosmosvalcons1nrqsld3aw6lh6t082frdqc84uwxn0t958c
index_offset: "2075"
jailed_until: "1970-01-01T00:00:00Z"
missed_blocks_counter: "0"
start_height: "0"
tombstoned: false
pagination:
next_key: null
total: "0"
```
### Transactions
The `tx` commands allow users to interact with the `slashing` module.
```bash
simd tx slashing --help
```
#### unjail
The `unjail` command allows users to unjail a validator previously jailed for downtime.
```bash
simd tx slashing unjail --from mykey [flags]
```
Example:
```bash
simd tx slashing unjail --from mykey
```
## gRPC
A user can query the `slashing` module using gRPC endpoints.
### Params
The `Params` endpoint allows users to query the parameters of slashing module.
```bash
cosmos.slashing.v1beta1.Query/Params
```
Example:
```bash
grpcurl -plaintext localhost:9090 cosmos.slashing.v1beta1.Query/Params
```
Example Output:
```bash
{
"params": {
"signedBlocksWindow": "100",
"minSignedPerWindow": "NTAwMDAwMDAwMDAwMDAwMDAw",
"downtimeJailDuration": "600s",
"slashFractionDoubleSign": "NTAwMDAwMDAwMDAwMDAwMDA=",
"slashFractionDowntime": "MTAwMDAwMDAwMDAwMDAwMDA="
}
}
```
### SigningInfo
The SigningInfo queries the signing info of given cons address.
```bash
cosmos.slashing.v1beta1.Query/SigningInfo
```
Example:
```bash
grpcurl -plaintext -d '{"cons_address":"cosmosvalcons1nrqsld3aw6lh6t082frdqc84uwxn0t958c"}' localhost:9090 cosmos.slashing.v1beta1.Query/SigningInfo
```
Example Output:
```bash
{
"valSigningInfo": {
"address": "cosmosvalcons1nrqsld3aw6lh6t082frdqc84uwxn0t958c",
"indexOffset": "3493",
"jailedUntil": "1970-01-01T00:00:00Z"
}
}
```
### SigningInfos
The SigningInfos queries signing info of all validators.
```bash
cosmos.slashing.v1beta1.Query/SigningInfos
```
Example:
```bash
grpcurl -plaintext localhost:9090 cosmos.slashing.v1beta1.Query/SigningInfos
```
Example Output:
```bash
{
"info": [
{
"address": "cosmosvalcons1nrqslkwd3pz096lh6t082frdqc84uwxn0t958c",
"indexOffset": "2467",
"jailedUntil": "1970-01-01T00:00:00Z"
}
],
"pagination": {
"total": "1"
}
}
```
## REST
A user can query the `slashing` module using REST endpoints.
### Params
```bash
/cosmos/slashing/v1beta1/params
```
Example:
```bash
curl "localhost:1317/cosmos/slashing/v1beta1/params"
```
Example Output:
```bash
{
"params": {
"signed_blocks_window": "100",
"min_signed_per_window": "0.500000000000000000",
"downtime_jail_duration": "600s",
"slash_fraction_double_sign": "0.050000000000000000",
"slash_fraction_downtime": "0.010000000000000000"
}
```
### signing_info
```bash
/cosmos/slashing/v1beta1/signing_infos/%s
```
Example:
```bash
curl "localhost:1317/cosmos/slashing/v1beta1/signing_infos/cosmosvalcons1nrqslkwd3pz096lh6t082frdqc84uwxn0t958c"
```
Example Output:
```bash
{
"val_signing_info": {
"address": "cosmosvalcons1nrqslkwd3pz096lh6t082frdqc84uwxn0t958c",
"start_height": "0",
"index_offset": "4184",
"jailed_until": "1970-01-01T00:00:00Z",
"tombstoned": false,
"missed_blocks_counter": "0"
}
}
```
### signing_infos
```bash
/cosmos/slashing/v1beta1/signing_infos
```
Example:
```bash
curl "localhost:1317/cosmos/slashing/v1beta1/signing_infos
```
Example Output:
```bash
{
"info": [
{
"address": "cosmosvalcons1nrqslkwd3pz096lh6t082frdqc84uwxn0t958c",
"start_height": "0",
"index_offset": "4169",
"jailed_until": "1970-01-01T00:00:00Z",
"tombstoned": false,
"missed_blocks_counter": "0"
}
],
"pagination": {
"next_key": null,
"total": "1"
}
}
```

4
x/slashing/spec/README.md
View File

@ -43,3 +43,7 @@ This module will be used by the Cosmos Hub, the first hub in the Cosmos ecosyste
7. **[Staking Tombstone](07_tombstone.md)**
- [Abstract](07_tombstone.md#abstract)
8. **[Parameters](08_params.md)**
9. **[Client](09_client.md)**
- [CLI](09_client.md#cli)
- [gRPC](09_client.md#grpc)
- [REST](09_client.md#rest)

2088
x/staking/spec/09_client.md Normal file
View File

File diff suppressed because it is too large Load Diff

459
x/upgrade/spec/04_client.md Normal file
View File

@ -0,0 +1,459 @@
<!--
order: 4
-->
# Client
## CLI
A user can query and interact with the `upgrade` module using the CLI.
### Query
The `query` commands allow users to query `upgrade` state.
```bash
simd query upgrade --help
```
#### applied
The `applied` command allows users to query the block header for height at which a completed upgrade was applied.
```bash
simd query upgrade applied [upgrade-name] [flags]
```
If upgrade-name was previously executed on the chain, this returns the header for the block at which it was applied.
This helps a client determine which binary was valid over a given range of blocks, as well as more context to understand past migrations.
Example:
```bash
simd query upgrade applied "test-upgrade"
```
Example Output:
```bash
"block_id": {
"hash": "A769136351786B9034A5F196DC53F7E50FCEB53B48FA0786E1BFC45A0BB646B5",
"parts": {
"total": 1,
"hash": "B13CBD23011C7480E6F11BE4594EE316548648E6A666B3575409F8F16EC6939E"
}
},
"block_size": "7213",
"header": {
"version": {
"block": "11"
},
"chain_id": "testnet-2",
"height": "455200",
"time": "2021-04-10T04:37:57.085493838Z",
"last_block_id": {
"hash": "0E8AD9309C2DC411DF98217AF59E044A0E1CCEAE7C0338417A70338DF50F4783",
"parts": {
"total": 1,
"hash": "8FE572A48CD10BC2CBB02653CA04CA247A0F6830FF19DC972F64D339A355E77D"
}
},
"last_commit_hash": "DE890239416A19E6164C2076B837CC1D7F7822FC214F305616725F11D2533140",
"data_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
"validators_hash": "A31047ADE54AE9072EE2A12FF260A8990BA4C39F903EAF5636B50D58DBA72582",
"next_validators_hash": "A31047ADE54AE9072EE2A12FF260A8990BA4C39F903EAF5636B50D58DBA72582",
"consensus_hash": "048091BC7DDC283F77BFBF91D73C44DA58C3DF8A9CBC867405D8B7F3DAADA22F",
"app_hash": "28ECC486AFC332BA6CC976706DBDE87E7D32441375E3F10FD084CD4BAF0DA021",
"last_results_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
"evidence_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
"proposer_address": "2ABC4854B1A1C5AA8403C4EA853A81ACA901CC76"
},
"num_txs": "0"
}
```
#### module versions
The `module_versions` command gets a list of module names and their respective consensus versions.
Following the command with a specific module name will return only
that module's information.
```bash
simd query upgrade module_versions [optional module_name] [flags]
```
Example:
```bash
simd query upgrade module_versions
```
Example Output:
```bash
module_versions:
- name: auth
version: "2"
- name: authz
version: "1"
- name: bank
version: "2"
- name: capability
version: "1"
- name: crisis
version: "1"
- name: distribution
version: "2"
- name: evidence
version: "1"
- name: feegrant
version: "1"
- name: genutil
version: "1"
- name: gov
version: "2"
- name: ibc
version: "2"
- name: mint
version: "1"
- name: params
version: "1"
- name: slashing
version: "2"
- name: staking
version: "2"
- name: transfer
version: "1"
- name: upgrade
version: "1"
- name: vesting
version: "1"
```
Example:
```bash
regen query upgrade module_versions ibc
```
Example Output:
```bash
module_versions:
- name: ibc
version: "2"
```
#### plan
The `plan` command gets the currently scheduled upgrade plan, if one exists.
```bash
regen query upgrade plan [flags]
```
Example:
```bash
simd query upgrade plan
```
Example Output:
```bash
height: "130"
info: ""
name: test-upgrade
time: "0001-01-01T00:00:00Z"
upgraded_client_state: null
```
## REST
A user can query the `upgrade` module using REST endpoints.
### Applied Plan
`AppliedPlan` queries a previously applied upgrade plan by its name.
```bash
/cosmos/upgrade/v1beta1/applied_plan/{name}
```
Example:
```bash
curl -X GET "http://localhost:1317/cosmos/upgrade/v1beta1/applied_plan/v2.0-upgrade" -H "accept: application/json"
```
Example Output:
```bash
{
"height": "30"
}
```
### Current Plan
`CurrentPlan` queries the current upgrade plan.
```bash
/cosmos/upgrade/v1beta1/current_plan
```
Example:
```bash
curl -X GET "http://localhost:1317/cosmos/upgrade/v1beta1/current_plan" -H "accept: application/json"
```
Example Output:
```bash
{
"plan": "v2.1-upgrade"
}
```
### Module versions
`ModuleVersions` queries the list of module versions from state.
```bash
/cosmos/upgrade/v1beta1/module_versions
```
Example:
```bash
curl -X GET "http://localhost:1317/cosmos/upgrade/v1beta1/module_versions" -H "accept: application/json"
```
Example Output:
```bash
{
"module_versions": [
{
"name": "auth",
"version": "2"
},
{
"name": "authz",
"version": "1"
},
{
"name": "bank",
"version": "2"
},
{
"name": "capability",
"version": "1"
},
{
"name": "crisis",
"version": "1"
},
{
"name": "distribution",
"version": "2"
},
{
"name": "evidence",
"version": "1"
},
{
"name": "feegrant",
"version": "1"
},
{
"name": "genutil",
"version": "1"
},
{
"name": "gov",
"version": "2"
},
{
"name": "ibc",
"version": "2"
},
{
"name": "mint",
"version": "1"
},
{
"name": "params",
"version": "1"
},
{
"name": "slashing",
"version": "2"
},
{
"name": "staking",
"version": "2"
},
{
"name": "transfer",
"version": "1"
},
{
"name": "upgrade",
"version": "1"
},
{
"name": "vesting",
"version": "1"
}
]
}
```
## gRPC
A user can query the `upgrade` module using gRPC endpoints.
### Applied Plan
`AppliedPlan` queries a previously applied upgrade plan by its name.
```bash
cosmos.upgrade.v1beta1.Query/AppliedPlan
```
Example:
```bash
grpcurl -plaintext \
-d '{"name":"v2.0-upgrade"}' \
localhost:9090 \
cosmos.upgrade.v1beta1.Query/AppliedPlan
```
Example Output:
```bash
{
"height": "30"
}
```
### Current Plan
`CurrentPlan` queries the current upgrade plan.
```bash
cosmos.upgrade.v1beta1.Query/CurrentPlan
```
Example:
```bash
grpcurl -plaintext localhost:9090 cosmos.slashing.v1beta1.Query/CurrentPlan
```
Example Output:
```bash
{
"plan": "v2.1-upgrade"
}
```
### Module versions
`ModuleVersions` queries the list of module versions from state.
```bash
cosmos.upgrade.v1beta1.Query/ModuleVersions
```
Example:
```bash
grpcurl -plaintext localhost:9090 cosmos.slashing.v1beta1.Query/ModuleVersions
```
Example Output:
```bash
{
"module_versions": [
{
"name": "auth",
"version": "2"
},
{
"name": "authz",
"version": "1"
},
{
"name": "bank",
"version": "2"
},
{
"name": "capability",
"version": "1"
},
{
"name": "crisis",
"version": "1"
},
{
"name": "distribution",
"version": "2"
},
{
"name": "evidence",
"version": "1"
},
{
"name": "feegrant",
"version": "1"
},
{
"name": "genutil",
"version": "1"
},
{
"name": "gov",
"version": "2"
},
{
"name": "ibc",
"version": "2"
},
{
"name": "mint",
"version": "1"
},
{
"name": "params",
"version": "1"
},
{
"name": "slashing",
"version": "2"
},
{
"name": "staking",
"version": "2"
},
{
"name": "transfer",
"version": "1"
},
{
"name": "upgrade",
"version": "1"
},
{
"name": "vesting",
"version": "1"
}
]
}
```