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

docs: improve documentation navigation and redirection (#13455)

This commit is contained in:
Julien Robert 2022-10-06 15:51:10 +02:00 committed by GitHub
parent ff39d243d4
commit 74ce07eb26
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
43 changed files with 299 additions and 12935 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/ISSUE_TEMPLATE/module-readiness-checklist.md vendored
View File

@ -16,7 +16,7 @@ The module **should not** be included in any Release Candidate tag until it has
- [ ] API audit (at least 1 person) (@assignee)
- [ ] Are Msg and Query methods and types well-named and organized?
- [ ] Is everything well documented (inline godoc as well as [`/spec/` folder](https://github.com/cosmos/cosmos-sdk/blob/main/docs/spec/SPEC-SPEC.md) in module directory)
- [ ] Is everything well documented (inline godoc as well as the spec [README.md](https://github.com/cosmos/cosmos-sdk/blob/main/docs/spec/SPEC-SPEC.md) in module directory)
- [ ] State machine audit (at least 2 people) (@assignee1, @assignee2)
- [ ] Read through MsgServer code and verify correctness upon visual inspection
- [ ] Ensure all state machine code which could be confusing is properly commented

2
CONTRIBUTING.md
View File

@ -159,7 +159,7 @@ If you open a PR on the Cosmos SDK, it is mandatory to update the relevant docum
* 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/`.
* If your changes relate to a module, then be sure to update the module's spec in `x/{moduleName}/README.md`.
When writing documentation, follow the [Documentation Writing Guidelines](./docs/DOC_WRITING_GUIDELINES.md).

1
Makefile
View File

@ -18,7 +18,6 @@ DOCS_DOMAIN=docs.cosmos.network
# RocksDB is a native dependency, so we don't assume the library is installed.
# Instead, it must be explicitly enabled and we warn when it is not.
ENABLE_ROCKSDB ?= false
GOWORK = off # we disable the `go.work` for consistency with our CI
# process build tags
build_tags = netgo

2
README.md
View File

@ -7,7 +7,7 @@ parent:
<h1> Cosmos SDK </h1>
</div>
![banner](docs/cosmos-sdk-image.jpg)
![banner](docs/assets/banner.jpg)
<div align="center">
<a href="https://github.com/cosmos/cosmos-sdk/blob/main/LICENSE">

12
depinject/README.md
View File

@ -52,7 +52,7 @@ Concretely `SimApp` uses the implementation in `x/auth`, but this design allows
Given the following types
```golang
```go
package duck
type Duck interface {
@ -76,7 +76,7 @@ type Pond struct {
This usage
```golang
```go
var pond Pond
depinject.Inject(
@ -91,7 +91,7 @@ depinject.Inject(
results in an *implicit* binding of `Duck` to `Mallard`. This works because there is only one implementation of `Duck`
in the container. However, adding a second provider of `Duck` will result in an error:
```golang
```go
var pond Pond
depinject.Inject(
@ -110,7 +110,7 @@ A specific binding preference for `Duck` is required.
In the above situation registering a binding for a given interface binding may look like
```golang
```go
depinject.Inject(
depinject.Configs(
depinject.BindInterface(
@ -174,7 +174,7 @@ be printed to stderr and a rendering of the dependency graph in Graphviz DOT for
`debug_container.dot`.
Here is an example Graphviz rendering of a successful build of a dependency graph:
![Graphviz Example](./testdata/example.svg)
![Graphviz Example](https://raw.githubusercontent.com/cosmos/cosmos-sdk/ff39d243d421442b400befcd959ec3ccd2525154/depinject/testdata/example.svg)
Rectangles represent functions, ovals represent types, rounded rectangles represent modules and the single hexagon
represents the function which called `Build`. Black-colored shapes mark functions and types that were called/resolved
@ -182,7 +182,7 @@ without an error. Gray-colored nodes mark functions and types that could have be
were left unused.
Here is an example Graphviz rendering of a dependency graph build which failed:
![Graphviz Error Example](./testdata/example_error.svg)
![Graphviz Error Example](https://raw.githubusercontent.com/cosmos/cosmos-sdk/ff39d243d421442b400befcd959ec3ccd2525154/depinject/testdata/example_error.svg)
Graphviz DOT files can be converted into SVG's for viewing in a web browser using the `dot` command-line tool, ex:

171
docs/.vuepress/config.js
View File

@ -3,19 +3,48 @@ module.exports = {
title: "Cosmos SDK",
locales: {
"/": {
lang: "en-US"
lang: "en-US",
},
},
base: process.env.VUEPRESS_BASE || "/",
head: [
['link', { rel: "apple-touch-icon", sizes: "180x180", href: "/apple-touch-icon.png" }],
['link', { rel: "icon", type: "image/png", sizes: "32x32", href: "/favicon-32x32.png" }],
['link', { rel: "icon", type: "image/png", sizes: "16x16", href: "/favicon-16x16.png" }],
['link', { rel: "manifest", href: "/site.webmanifest" }],
['meta', { name: "msapplication-TileColor", content: "#2e3148" }],
['meta', { name: "theme-color", content: "#ffffff" }],
['link', { rel: "icon", type: "image/svg+xml", href: "/favicon-svg.svg" }],
['link', { rel: "apple-touch-icon-precomposed", href: "/apple-touch-icon-precomposed.png" }],
[
"link",
{
rel: "apple-touch-icon",
sizes: "180x180",
href: "/apple-touch-icon.png",
},
],
[
"link",
{
rel: "icon",
type: "image/png",
sizes: "32x32",
href: "/favicon-32x32.png",
},
],
[
"link",
{
rel: "icon",
type: "image/png",
sizes: "16x16",
href: "/favicon-16x16.png",
},
],
["link", { rel: "manifest", href: "/site.webmanifest" }],
["meta", { name: "msapplication-TileColor", content: "#2e3148" }],
["meta", { name: "theme-color", content: "#ffffff" }],
["link", { rel: "icon", type: "image/svg+xml", href: "/favicon-svg.svg" }],
[
"link",
{
rel: "apple-touch-icon-precomposed",
href: "/apple-touch-icon-precomposed.png",
},
],
],
themeConfig: {
repo: "cosmos/cosmos-sdk",
@ -27,28 +56,28 @@ module.exports = {
algolia: {
id: "BH4D9OD16A",
key: "ac317234e6a42074175369b2f42e9754",
index: "cosmos-sdk"
index: "cosmos-sdk",
},
versions: [
{
"label": "v0.44",
"key": "v0.44"
label: "v0.45",
key: "v0.45",
},
{
"label": "v0.45",
"key": "v0.45"
label: "v0.46",
key: "v0.46",
},
{
"label": "v0.46",
"key": "v0.46"
label: "v0.47 - Twilight",
key: "v0.47",
},
{
"label": "main",
"key": "main"
}
label: "main",
key: "main",
},
],
topbar: {
banner: false
banner: false,
},
sidebar: {
auto: true,
@ -59,28 +88,28 @@ module.exports = {
{
title: "Modules",
directory: true,
path: "/modules"
}
]
path: "/modules",
},
],
},
{
title: "Resources",
children: [
{
title: "Tutorials",
path: "https://tutorials.cosmos.network"
path: "https://tutorials.cosmos.network",
},
{
title: "SDK API Reference",
path: "https://pkg.go.dev/github.com/cosmos/cosmos-sdk"
path: "https://pkg.go.dev/github.com/cosmos/cosmos-sdk",
},
{
title: "REST API Spec",
path: "https://cosmos.network/rpc/"
}
]
}
]
path: "https://cosmos.network/rpc/",
},
],
},
],
},
gutter: {
title: "Help & Support",
@ -89,90 +118,92 @@ module.exports = {
title: "Discord",
text: "Chat with Cosmos developers on Discord.",
url: "https://discordapp.com/channels/669268347736686612",
bg: "linear-gradient(225.11deg, #2E3148 0%, #161931 95.68%)"
bg: "linear-gradient(225.11deg, #2E3148 0%, #161931 95.68%)",
},
forum: {
title: "Cosmos SDK Forum",
text: "Join the SDK Developer Forum to learn more.",
url: "https://forum.cosmos.network/",
bg: "linear-gradient(225deg, #46509F -1.08%, #2F3564 95.88%)",
logo: "cosmos"
logo: "cosmos",
},
github: {
title: "Found an Issue?",
text: "Help us improve this page by suggesting edits on GitHub."
}
text: "Help us improve this page by suggesting edits on GitHub.",
},
},
footer: {
question: {
text: "Chat with Cosmos developers in <a href='https://discord.gg/cosmosnetwork' target='_blank'>Discord</a> or reach out on the <a href='https://forum.cosmos.network/c/tendermint' target='_blank'>SDK Developer Forum</a> to learn more."
text:
"Chat with Cosmos developers in <a href='https://discord.gg/cosmosnetwork' target='_blank'>Discord</a> or reach out on the <a href='https://forum.cosmos.network/c/tendermint' target='_blank'>SDK Developer Forum</a> to learn more.",
},
logo: "/logo-bw.svg",
textLink: {
text: "cosmos.network",
url: "https://cosmos.network"
url: "https://cosmos.network",
},
services: [
{
service: "medium",
url: "https://blog.cosmos.network/"
url: "https://blog.cosmos.network/",
},
{
service: "twitter",
url: "https://twitter.com/cosmos"
url: "https://twitter.com/cosmos",
},
{
service: "linkedin",
url: "https://www.linkedin.com/company/tendermint/"
url: "https://www.linkedin.com/company/interchain-gmbh/",
},
{
service: "reddit",
url: "https://reddit.com/r/cosmosnetwork"
url: "https://reddit.com/r/cosmosnetwork",
},
{
service: "telegram",
url: "https://t.me/cosmosproject"
url: "https://t.me/cosmosproject",
},
{
service: "youtube",
url: "https://www.youtube.com/c/CosmosProject"
}
url: "https://www.youtube.com/c/CosmosProject",
},
],
smallprint: "The development of the Cosmos SDK is led primarily by [Interchain Core Teams](https://interchain.io/ecosystem). Funding for this development comes primarily from the Interchain Foundation, a Swiss non-profit.",
smallprint:
"The development of the Cosmos SDK is led primarily by [Interchain Core Teams](https://interchain.io/ecosystem). Funding for this development comes primarily from the Interchain Foundation, a Swiss non-profit.",
links: [
{
title: "Documentation",
children: [
{
title: "Cosmos Hub",
url: "https://hub.cosmos.network"
url: "https://hub.cosmos.network",
},
{
title: "Tendermint Core",
url: "https://docs.tendermint.com"
url: "https://docs.tendermint.com",
},
{
title: "IBC-Go",
url: "https://ibc.cosmos.network"
title: "IBC Go",
url: "https://ibc.cosmos.network",
},
]
],
},
{
title: "Community",
children: [
{
title: "Cosmos blog",
url: "https://blog.cosmos.network"
url: "https://blog.cosmos.network",
},
{
title: "Forum",
url: "https://forum.cosmos.network"
url: "https://forum.cosmos.network",
},
{
title: "Chat",
url: "https://discord.gg/cosmosnetwork"
}
]
url: "https://discord.gg/cosmosnetwork",
},
],
},
{
title: "Contributing",
@ -180,29 +211,35 @@ module.exports = {
{
title: "Contributing to the docs",
url:
"https://github.com/cosmos/cosmos-sdk/blob/main/docs/DOCS_README.md"
"https://github.com/cosmos/cosmos-sdk/blob/main/docs/DOCS_README.md",
},
{
title: "Source code on GitHub",
url: "https://github.com/cosmos/cosmos-sdk/"
}
]
}
]
}
url: "https://github.com/cosmos/cosmos-sdk/",
},
],
},
],
},
},
plugins: [
[
"@vuepress/google-analytics",
{
ga: "UA-51029217-2"
}
ga: "UA-51029217-2",
},
],
[
"@vuepress/html-redirect",
{
countdown: 0,
},
],
[
"sitemap",
{
hostname: "https://docs.cosmos.network"
}
]
]
hostname: "https://docs.cosmos.network",
},
],
],
};

8
docs/.vuepress/enhanceApp.js
View File

@ -1,8 +0,0 @@
export default ({ router }) => {
router.addRoutes([
{ path: "/main/spec/*", redirect: "/modules/" },
{ path: "/main/spec/governance/", redirect: "/modules/gov/" },
{ path: "/v0.43/", redirect: "/v0.44/" }, // TODO to fix: https://github.com/cosmos/cosmos-sdk/issues/11798
{ path: "/master/", redirect: "/" },
]);
};

98
docs/.vuepress/redirects Normal file
View File

@ -0,0 +1,98 @@
/master https://docs.cosmos.network/main/
/main/spec/governance/ https://docs.cosmos.network/main/modules/gov/
/v0.43 https://docs.cosmos.network/main/
/v0.44 https://docs.cosmos.network/main/
/main/modules/auth/01_concepts.html https://docs.cosmos.network/main/modules/auth/
/main/modules/auth/02_state.html https://docs.cosmos.network/main/modules/auth/
/main/modules/auth/03_antehandlers.html https://docs.cosmos.network/main/modules/auth/
/main/modules/auth/04_keepers.html https://docs.cosmos.network/main/modules/auth/
/main/modules/auth/05_vesting.html https://docs.cosmos.network/main/modules/vesting/
/main/modules/auth/06_params.html https://docs.cosmos.network/main/modules/auth/
/main/modules/auth/07_client.html https://docs.cosmos.network/main/modules/auth/
/main/modules/authz/01_concepts.html https://docs.cosmos.network/main/modules/authz/
/main/modules/authz/02_state.html https://docs.cosmos.network/main/modules/authz/
/main/modules/authz/03_messages.html https://docs.cosmos.network/main/modules/authz/
/main/modules/authz/04_events.html https://docs.cosmos.network/main/modules/authz/
/main/modules/authz/05_client.html https://docs.cosmos.network/main/modules/authz/
/main/modules/bank/01_state.html https://docs.cosmos.network/main/modules/bank/
/main/modules/bank/02_keepers.html https://docs.cosmos.network/main/modules/bank/
/main/modules/bank/04_events.html https://docs.cosmos.network/main/modules/bank/
/main/modules/bank/05_params.html https://docs.cosmos.network/main/modules/bank/
/main/modules/bank/06_client.html https://docs.cosmos.network/main/modules/bank/
/main/modules/capability/01_concepts.html https://docs.cosmos.network/main/modules/capability/
/main/modules/capability/02_state.html https://docs.cosmos.network/main/modules/capability/
/main/modules/crisis/01_state.html https://docs.cosmos.network/main/modules/crisis/
/main/modules/crisis/02_messages.html https://docs.cosmos.network/main/modules/crisis/
/main/modules/crisis/03_events.html https://docs.cosmos.network/main/modules/crisis/
/main/modules/crisis/04_params.html https://docs.cosmos.network/main/modules/crisis/
/main/modules/crisis/05_client.html https://docs.cosmos.network/main/modules/crisis/
/main/modules/distribution/01_concepts.html https://docs.cosmos.network/main/modules/distribution/
/main/modules/distribution/02_state.html https://docs.cosmos.network/main/modules/distribution/
/main/modules/distribution/03_begin_block.html https://docs.cosmos.network/main/modules/distribution/
/main/modules/distribution/04_messages.html https://docs.cosmos.network/main/modules/distribution/
/main/modules/distribution/05_hooks.html https://docs.cosmos.network/main/modules/distribution/
/main/modules/distribution/06_events.html https://docs.cosmos.network/main/modules/distribution/
/main/modules/distribution/07_params.html https://docs.cosmos.network/main/modules/distribution/
/main/modules/distribution/08_client.html https://docs.cosmos.network/main/modules/distribution/
/main/modules/epoching/01_state.html https://docs.cosmos.network/main/modules/epoching/
/main/modules/epoching/03_to_improve.html https://docs.cosmos.network/main/modules/epoching/
/main/modules/evidence/01_concepts.html https://docs.cosmos.network/main/modules/evidence/
/main/modules/evidence/02_state.html https://docs.cosmos.network/main/modules/evidence/
/main/modules/evidence/03_messages.html https://docs.cosmos.network/main/modules/evidence/
/main/modules/evidence/04_events.html https://docs.cosmos.network/main/modules/evidence/
/main/modules/evidence/05_params.html https://docs.cosmos.network/main/modules/evidence/
/main/modules/evidence/06_begin_block.html https://docs.cosmos.network/main/modules/evidence/
/main/modules/evidence/07_client.html https://docs.cosmos.network/main/modules/evidence/
/main/modules/feegrant/01_concepts.html https://docs.cosmos.network/main/modules/feegrant/
/main/modules/feegrant/02_state.html https://docs.cosmos.network/main/modules/feegrant/
/main/modules/feegrant/03_messages.html https://docs.cosmos.network/main/modules/feegrant/
/main/modules/feegrant/04_events.html https://docs.cosmos.network/main/modules/feegrant/
/main/modules/feegrant/05_client.html https://docs.cosmos.network/main/modules/feegrant/
/main/modules/gov/01_concepts.html https://docs.cosmos.network/main/modules/gov/
/main/modules/gov/02_state.html https://docs.cosmos.network/main/modules/gov/
/main/modules/gov/03_messages.html https://docs.cosmos.network/main/modules/gov/
/main/modules/gov/04_events.html https://docs.cosmos.network/main/modules/gov/
/main/modules/gov/05_future_improvements.html https://docs.cosmos.network/main/modules/gov/
/main/modules/gov/06_params.html https://docs.cosmos.network/main/modules/gov/
/main/modules/gov/07_client.html https://docs.cosmos.network/main/modules/gov/
/main/modules/gov/08_metadata.html https://docs.cosmos.network/main/modules/gov/
/main/modules/group/01_concepts.html https://docs.cosmos.network/main/modules/group/
/main/modules/group/02_state.html https://docs.cosmos.network/main/modules/group/
/main/modules/group/03_messages.html https://docs.cosmos.network/main/modules/group/
/main/modules/group/04_events.html https://docs.cosmos.network/main/modules/group/
/main/modules/group/05_client.html https://docs.cosmos.network/main/modules/group/
/main/modules/group/06_metadata.html https://docs.cosmos.network/main/modules/group/
/main/modules/mint/01_concepts.html https://docs.cosmos.network/main/modules/mint/
/main/modules/mint/02_state.html https://docs.cosmos.network/main/modules/mint/
/main/modules/mint/03_begin_block.html https://docs.cosmos.network/main/modules/mint/
/main/modules/mint/04_params.html https://docs.cosmos.network/main/modules/mint/
/main/modules/mint/05_events.html https://docs.cosmos.network/main/modules/mint/
/main/modules/mint/06_client.html https://docs.cosmos.network/main/modules/mint/
/main/modules/nft/01_concepts.html https://docs.cosmos.network/main/modules/nft/
/main/modules/nft/02_state.html https://docs.cosmos.network/main/modules/nft/
/main/modules/nft/03_messages.html https://docs.cosmos.network/main/modules/nft/
/main/modules/nft/04_events.html https://docs.cosmos.network/main/modules/nft/
/main/modules/params/01_keeper.html https://docs.cosmos.network/main/modules/params/
/main/modules/params/02_subspace.html https://docs.cosmos.network/main/modules/params/
/main/modules/slashing/01_concepts.html https://docs.cosmos.network/main/modules/slashing/
/main/modules/slashing/02_state.html https://docs.cosmos.network/main/modules/slashing/
/main/modules/slashing/03_messages.html https://docs.cosmos.network/main/modules/slashing/
/main/modules/slashing/04_begin_block.html https://docs.cosmos.network/main/modules/slashing/
/main/modules/slashing/05_hooks.html https://docs.cosmos.network/main/modules/slashing/
/main/modules/slashing/06_events.html https://docs.cosmos.network/main/modules/slashing/
/main/modules/slashing/07_tombstone.html https://docs.cosmos.network/main/modules/slashing/
/main/modules/slashing/08_params.html https://docs.cosmos.network/main/modules/slashing/
/main/modules/slashing/09_client.html https://docs.cosmos.network/main/modules/slashing/
/main/modules/staking/01_state.html https://docs.cosmos.network/main/modules/staking/
/main/modules/staking/02_state_transitions.html https://docs.cosmos.network/main/modules/staking/
/main/modules/staking/03_messages.html https://docs.cosmos.network/main/modules/staking/
/main/modules/staking/04_begin_block.html https://docs.cosmos.network/main/modules/staking/
/main/modules/staking/05_end_block.html https://docs.cosmos.network/main/modules/staking/
/main/modules/staking/06_hooks.html https://docs.cosmos.network/main/modules/staking/
/main/modules/staking/07_events.html https://docs.cosmos.network/main/modules/staking/
/main/modules/staking/08_params.html https://docs.cosmos.network/main/modules/staking/
/main/modules/staking/09_client.html https://docs.cosmos.network/main/modules/staking/
/main/modules/upgrade/01_concepts.html https://docs.cosmos.network/main/modules/upgrade/
/main/modules/upgrade/02_state.html https://docs.cosmos.network/main/modules/upgrade/
/main/modules/upgrade/03_events.html https://docs.cosmos.network/main/modules/upgrade/
/main/modules/upgrade/04_client.html https://docs.cosmos.network/main/modules/upgrade/

30
docs/architecture/adr-003-dynamic-capability-store.md
View File

@ -47,7 +47,7 @@ a name. A `String()` method is provided for debugging.
A `Capability` is simply a struct, the address of which is taken for the actual capability.
```golang
```go
type Capability struct {
index uint64
}
@ -55,7 +55,7 @@ type Capability struct {
A `CapabilityKeeper` contains a persistent store key, memory store key, and mapping of allocated module names.
```golang
```go
type CapabilityKeeper struct {
persistentKey StoreKey
memKey StoreKey
@ -71,7 +71,7 @@ and passed to modules, which can then use them to claim capabilities they receiv
capabilities which they own by name, in addition to creating new capabilities & authenticating capabilities
passed by other modules.
```golang
```go
type ScopedCapabilityKeeper struct {
persistentKey StoreKey
memKey StoreKey
@ -83,7 +83,7 @@ type ScopedCapabilityKeeper struct {
`ScopeToModule` is used to create a scoped sub-keeper with a particular name, which must be unique.
It MUST be called before `InitialiseAndSeal`.
```golang
```go
func (ck CapabilityKeeper) ScopeToModule(moduleName string) ScopedCapabilityKeeper {
if k.sealed {
panic("cannot scope to module via a sealed capability keeper")
@ -110,7 +110,7 @@ necessary `ScopedCapabilityKeeper`s, in order to populate the memory store with
capability keys in accordance with the keys previously claimed by particular modules and prevent the
creation of any new `ScopedCapabilityKeeper`s.
```golang
```go
func (ck CapabilityKeeper) InitialiseAndSeal(ctx Context) {
if ck.sealed {
panic("capability keeper is sealed")
@ -140,7 +140,7 @@ func (ck CapabilityKeeper) InitialiseAndSeal(ctx Context) {
reference. The newly created capability is automatically persisted; the calling module need not
call `ClaimCapability`.
```golang
```go
func (sck ScopedCapabilityKeeper) NewCapability(ctx Context, name string) (Capability, error) {
// check name not taken in memory store
if capStore.Get("rev/" + name) != nil {
@ -178,7 +178,7 @@ func (sck ScopedCapabilityKeeper) NewCapability(ctx Context, name string) (Capab
does in fact correspond to a particular name (the name can be untrusted user input)
with which the calling module previously associated it.
```golang
```go
func (sck ScopedCapabilityKeeper) AuthenticateCapability(name string, capability Capability) bool {
// return whether forward mapping in memory store matches name
return memStore.Get(sck.moduleName + "/fwd/" + capability) === name
@ -192,7 +192,7 @@ so that future `GetCapability` calls will succeed.
in the future. Capabilities are multi-owner, so if multiple modules have a single `Capability` reference,
they will all own it.
```golang
```go
func (sck ScopedCapabilityKeeper) ClaimCapability(ctx Context, capability Capability, name string) error {
persistentStore := ctx.KVStore(sck.persistentKey)
@ -212,7 +212,7 @@ func (sck ScopedCapabilityKeeper) ClaimCapability(ctx Context, capability Capabi
`GetCapability` allows a module to fetch a capability which it has previously claimed by name.
The module is not allowed to retrieve capabilities which it does not own.
```golang
```go
func (sck ScopedCapabilityKeeper) GetCapability(ctx Context, name string) (Capability, error) {
// fetch the index of capability using reverse mapping in memstore
index := memStore.Get(sck.moduleName + "/rev/" + name)
@ -228,7 +228,7 @@ func (sck ScopedCapabilityKeeper) GetCapability(ctx Context, name string) (Capab
`ReleaseCapability` allows a module to release a capability which it had previously claimed. If no
more owners exist, the capability will be deleted globally.
```golang
```go
func (sck ScopedCapabilityKeeper) ReleaseCapability(ctx Context, capability Capability) err {
persistentStore := ctx.KVStore(sck.persistentKey)
@ -263,7 +263,7 @@ func (sck ScopedCapabilityKeeper) ReleaseCapability(ctx Context, capability Capa
Any modules which use dynamic capabilities must be provided a `ScopedCapabilityKeeper` in `app.go`:
```golang
```go
ck := NewCapabilityKeeper(persistentKey, memoryKey)
mod1Keeper := NewMod1Keeper(ck.ScopeToModule("mod1"), ....)
mod2Keeper := NewMod2Keeper(ck.ScopeToModule("mod2"), ....)
@ -281,14 +281,14 @@ Consider the case where `mod1` wants to create a capability, associate it with a
Module 1 would have the following code:
```golang
```go
capability := scopedCapabilityKeeper.NewCapability(ctx, "resourceABC")
mod2Keeper.SomeFunction(ctx, capability, args...)
```
`SomeFunction`, running in module 2, could then claim the capability:
```golang
```go
func (k Mod2Keeper) SomeFunction(ctx Context, capability Capability) {
k.sck.ClaimCapability(ctx, capability, "resourceABC")
// other logic...
@ -297,7 +297,7 @@ func (k Mod2Keeper) SomeFunction(ctx Context, capability Capability) {
Later on, module 2 can retrieve that capability by name and pass it to module 1, which will authenticate it against the resource:
```golang
```go
func (k Mod2Keeper) SomeOtherFunction(ctx Context, name string) {
capability := k.sck.GetCapability(ctx, name)
mod1.UseResource(ctx, capability, "resourceABC")
@ -306,7 +306,7 @@ func (k Mod2Keeper) SomeOtherFunction(ctx Context, name string) {
Module 1 will then check that this capability key is authenticated to use the resource before allowing module 2 to use it:
```golang
```go
func (k Mod1Keeper) UseResource(ctx Context, capability Capability, resource string) {
if !k.sck.AuthenticateCapability(name, capability) {
return errors.New("unauthenticated")

2
docs/architecture/adr-004-split-denomination-keys.md
View File

@ -50,7 +50,7 @@ core functionality or persistence.
Balances will be stored first by the address, then by the denomination (the reverse is also possible,
but retrieval of all balances for a single account is presumed to be more frequent):
```golang
```go
var BalancesPrefix = []byte("balances")
func (k Keeper) SetBalance(ctx Context, addr AccAddress, balance Coin) error {

2
docs/architecture/adr-017-historical-header-module.md
View File

@ -15,7 +15,7 @@ The application MUST store the most recent `n` headers in a persistent store. At
The application MUST store this information by storing new headers immediately when handling `abci.RequestBeginBlock`:
```golang
```go
func BeginBlock(ctx sdk.Context, keeper HistoricalHeaderKeeper, req abci.RequestBeginBlock) abci.ResponseBeginBlock {
info := HistoricalInfo{
Header: ctx.BlockHeader(),

0
docs/cosmos-sdk-image.jpg → docs/assets/banner.jpg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 137 KiB

After

Width:  |  Height:  |  Size: 137 KiB

2
docs/building-chain/README.md → docs/building-apps/README.md
View File

@ -4,7 +4,7 @@ parent:
order: 5
-->
# Building a Chain
# Building Apps
This repository contains documentation on concepts developers need to know in order to build a Cosmos SDK applications.

6
docs/building-chain/app-go.md → docs/building-apps/app-go.md
View File

@ -7,8 +7,6 @@ order: 0
This section is intended to provide an overview of the `app.go` file and is still a work in progress.
For now we invite you to read the [tutorials](https://tutorials.cosmos.network) for a deep dive on how to build a chain.
<!--
## `app.go`
Since `v0.47.0` the Cosmos SDK have made easier wiring an `app.go` thanks to dependency injection:
@ -19,6 +17,4 @@ Since `v0.47.0` the Cosmos SDK have made easier wiring an `app.go` thanks to dep
## `app_legacy.go`
+++ https://github.com/cosmos/cosmos-sdk/blob/main/simapp/app_legacy.go
-->
+++ https://github.com/cosmos/cosmos-sdk/blob/main/simapp/app_legacy.go

17
docs/building-chain/depinject.md
View File

@ -1,17 +0,0 @@
<!--
order: 1
-->
# Dependency Injection
This section is intended to provide an overview of the `depinject` package and is still a work in progress.
The SDK uses a dependency injection framework called `depinject` for helping building a chain faster.
## `AppConfig`
* https://pkg.go.dev/cosmossdk.io/core/appconfig
## `depinject`
* https://pkg.go.dev/cosmossdk.io/depinject

4
docs/building-modules/upgrade.md
View File

@ -27,7 +27,7 @@ Migration registration takes place in the `Configurator` using the `RegisterMigr
You can register one or more migrations. If you register more than one migration script, list the migrations in increasing order and ensure there are enough migrations that lead to the desired consensus version. For example, to migrate to version 3 of a module, register separate migrations for version 1 and version 2 as shown in the following example:
```golang
```go
func (am AppModule) RegisterServices(cfg module.Configurator) {
// --snip--
cfg.RegisterMigration(types.ModuleName, 1, func(ctx sdk.Context) error {
@ -47,7 +47,7 @@ Since these migrations are functions that need access to a Keeper's store, use a
To define the functionality that takes place during an upgrade, write a migration script and place the functions in a `migrations/` directory. For example, to write migration scripts for the bank module, place the functions in `x/bank/migrations/`. Use the recommended naming convention for these functions. For example, `v2bank` is the script that migrates the package `x/bank/migrations/v2`:
```golang
```go
// Migrating bank module from version 1 to 2
func (m Migrator) Migrate1to2(ctx sdk.Context) error {
return v2bank.MigrateStore(ctx, m.keeper.storeKey) // v2bank is package `x/bank/migrations/v2`.

12605
docs/package-lock.json generated
View File

File diff suppressed because it is too large Load Diff

3
docs/package.json
View File

@ -15,5 +15,8 @@
"license": "ISC",
"dependencies": {
"vuepress-theme-cosmos": "^1.0.183"
},
"devDependencies": {
"@vuepress/plugin-html-redirect": "^0.1.4"
}
}

1
docs/post.sh
View File

@ -2,3 +2,4 @@
rm -rf modules
rm -rf run-node/cosmovisor.md
rm -rf building-apps/depinject.md

17
docs/pre.sh
View File

@ -7,15 +7,6 @@ for D in ../x/*; do
MODDOC=modules/$(echo $D | awk -F/ '{print $NF}')
rm -rf $MODDOC
mkdir -p $MODDOC && cp -r $D/README.md "$_"
if [ -f "$MODDOC/README.md" ]; then
cd $MODDOC
# This ensures that we have multiples pages for the modules documantation
# This is easier to read for the user
# In order to split pages, we need to add a <!-- order: X --> in the module README.md, for each pages that we want.
csplit -k -q README.md '/<!-- order:/' '{*}' --prefix='section_' --suffix-format='%02d.md'
mv section_00.md README.md
cd ../..
fi
fi
done
@ -23,11 +14,11 @@ done
## TODO to be removed in https://github.com/cosmos/cosmos-sdk/issues/9958
mkdir -p modules/vesting
cp -r ../x/auth/vesting/README.md modules/vesting
cd modules/vesting
csplit -k -q README.md '/<!-- order:/' '{*}' --prefix='section_' --suffix-format='%02d.md'
mv section_00.md README.md
cd ../..
cat ../x/README.md | sed 's/\.\/x/\/modules/g' | sed 's/\.\.\/docs\/building-modules\/README\.md/\/building-modules\/intro\.html/g' > ./modules/README.md
## Add Cosmovisor documentation
cp ../cosmovisor/README.md ./run-node/cosmovisor.md
## Add depinject documentation
cp ../depinject/README.md ./building-apps/depinject.md

35
docs/spec/SPEC-SPEC.md
View File

@ -19,26 +19,23 @@ element as a part of a larger description.
## Common Layout
The following generalized file structure should be used to breakdown
specifications for modules. With the exception of README.md, `XX` at the
beginning of the file name should be replaced with a number to indicate
document flow (ex. read `01_state.md` before `02_state_transitions.md`). The
following list is nonbinding and all files are optional.
The following generalized `README` structure should be used to breakdown
specifications for modules. The following list is nonbinding and all sections are optional.
* `README.md` - overview of the module
* `XX_concepts.md` - describe specialized concepts and definitions used throughout the spec
* `XX_state.md` - specify and describe structures expected to marshalled into the store, and their keys
* `XX_state_transitions.md` - standard state transition operations triggered by hooks, messages, etc.
* `XX_messages.md` - specify message structure(s) and expected state machine behaviour(s)
* `XX_begin_block.md` - specify any begin-block operations
* `XX_end_block.md` - specify any end-block operations
* `XX_hooks.md` - describe available hooks to be called by/from this module
* `XX_events.md` - list and describe event tags used
* `XX_client.md` - list and describe CLI commands and gRPC and REST endpoints
* `XX_params.md` - list all module parameters, their types (in JSON) and examples
* `XX_future_improvements.md` - describe future improvements of this module
* `XX_tests.md` - acceptance tests
* `XX_appendix.md` - supplementary details referenced elsewhere within the spec
* `# {Module Name}` - overview of the module
* `## Concepts` - describe specialized concepts and definitions used throughout the spec
* `## State` - specify and describe structures expected to marshalled into the store, and their keys
* `## State Transitions` - standard state transition operations triggered by hooks, messages, etc.
* `## Messages` - specify message structure(s) and expected state machine behaviour(s)
* `## Begin Block` - specify any begin-block operations
* `## End Block` - specify any end-block operations
* `## Hooks` - describe available hooks to be called by/from this module
* `## Events` - list and describe event tags used
* `## Client` - list and describe CLI commands and gRPC and REST endpoints
* `## Params` - list all module parameters, their types (in JSON) and examples
* `## Future Improvements` - describe future improvements of this module
* `## Tests` - acceptance tests
* `## Appendix` - supplementary details referenced elsewhere within the spec
### Notation for key-value mapping

4
docs/spec/store/README.md
View File

@ -168,7 +168,7 @@ removed from each `KVStore`. Note, it is up to the underlying `KVStore`
implementation to determine how pruning is actually performed. The `PruningOptions`
are defined as follows:
```golang
```go
type PruningOptions struct {
// KeepRecent defines how many recent heights to keep on disk.
KeepRecent uint64
@ -198,7 +198,7 @@ to it's respective `KVStore` instance.
Example:
```golang
```go
func NewApp(...) Application {
// ...

9
docs/versions
View File

@ -1,5 +1,4 @@
release/v0.44.x v0.44
release/v0.45.x v0.45
main master
main main
release/v0.46.x v0.46
release/v0.45.x v0.45
release/v0.46.x v0.46
main v0.47
main main

8
proto/README.md
View File

@ -7,3 +7,11 @@ a maintainer by running `buf push` in this folder.
User facing documentation should not be placed here but instead goes in
`buf.md` and in each protobuf package following the guidelines in
https://docs.buf.build/bsr/documentation.
## SDK x Buf
| Cosmos SDK Version | Buf Commit Version |
| ------------------ | ---------------------------------------------------------- |
| Prior v0.46.0 | [Unavailable](https://github.com/bufbuild/buf/issues/1415) |
| v0.46.x | 8cb30a2c4de74dc9bd8d260b1e75e176 |
| v0.47.x | - |

13
pruning/README.md
View File

@ -10,18 +10,19 @@ the states and prune nothing. On the other hand, a regular validator node may wa
The strategies are configured in `app.toml`, with the format `pruning = "<strategy>"` where the options are:
- `default`: only the last 362,880 states(approximately 3.5 weeks worth of state) are kept; pruning at 10 block intervals
- `nothing`: all historic states will be saved, nothing will be deleted (i.e. archiving node)
- `everything`: 2 latest states will be kept; pruning at 10 block intervals.
- `custom`: allow pruning options to be manually specified through 'pruning-keep-recent', and 'pruning-interval'
* `default`: only the last 362,880 states(approximately 3.5 weeks worth of state) are kept; pruning at 10 block intervals
* `nothing`: all historic states will be saved, nothing will be deleted (i.e. archiving node)
* `everything`: 2 latest states will be kept; pruning at 10 block intervals.
* `custom`: allow pruning options to be manually specified through 'pruning-keep-recent', and 'pruning-interval'
If no strategy is given to the BaseApp, `nothing` is selected. However, we perform validation on the CLI layer to require these to be always set in the config file.
## Custom Pruning
These are applied if and only if the pruning strategy is custom:
- `pruning-keep-recent`: N means to keep all of the last N states
- `pruning-interval`: N means to delete old states from disk every Nth block.
* `pruning-keep-recent`: N means to keep all of the last N states
* `pruning-interval`: N means to delete old states from disk every Nth block.
## Relationship to State Sync Snapshots

11
third_party/proto/README.md vendored
View File

@ -2,14 +2,9 @@
To generate the protos that were present in this folder run:
## v0.47.x+
```bash
buf export buf.build/cosmos/cosmos-sdk --output .
buf export buf.build/cosmos/cosmos-sdk:${commit} --output .
```
## v0.46.x
```bash
buf export buf.build/cosmos/cosmos-sdk:8cb30a2c4de74dc9bd8d260b1e75e176 --output .
```
where `${commit}` is the commit of the buf commit of version of the Cosmos SDK you are using.
That commit can be found [here](https://github.com/cosmos/cosmos-sdk/blob/main/proto/README.md).

18
x/auth/README.md
View File

@ -29,11 +29,9 @@ This module is used in the Cosmos Hub.
* [Account Keeper](#account-keeper)
* [Parameters](#parameters)
* [Client](#client)
* [CLI](#cli)
* [gRPC](#grpc)
* [REST](#rest)
<!-- order: 1 -->
* [CLI](#cli)
* [gRPC](#grpc)
* [REST](#rest)
# Concepts
@ -75,8 +73,6 @@ Because the market value for tokens will fluctuate, validators are expected to
dynamically adjust their minimum gas prices to a level that would encourage the
use of the network.
<!-- order: 2 -->
# State
## Accounts
@ -147,8 +143,6 @@ message BaseAccount {
See [Vesting](https://docs.cosmos.network/main/modules/vesting/).
<!-- order: 3 -->
# AnteHandlers
The `x/auth` module presently has no transaction handlers of its own, but does expose the special `AnteHandler`, used for performing basic validity checks on a transaction, such that it could be thrown out of the mempool.
@ -186,8 +180,6 @@ The auth module provides `AnteDecorator`s that are recursively chained together
* `IncrementSequenceDecorator`: Increments the account sequence for each signer to prevent replay attacks.
<!-- order: 4 -->
# Keepers
The auth module only exposes one keeper, the account keeper, which can be used to read and write accounts.
@ -232,8 +224,6 @@ type AccountKeeperI interface {
}
```
<!-- order: 5 -->
# Parameters
The auth module contains the following parameters:
@ -246,8 +236,6 @@ The auth module contains the following parameters:
| SigVerifyCostED25519 | uint64 | 590 |
| SigVerifyCostSecp256k1 | uint64 | 1000 |
<!-- order: 6 -->
# Client
## CLI

10
x/authz/README.md
View File

@ -31,8 +31,6 @@ granting arbitrary privileges from one account (the granter) to another account
* [gRPC](#grpc)
* [REST](#rest)
<!-- order: 1 -->
# Concepts
## Authorization and Grant
@ -85,8 +83,6 @@ In order to prevent DoS attacks, granting `StakeAuthorization`s with `x/authz` i
Since the state maintaining a list for granter, grantee pair with same expiration, we are iterating over the list to remove the grant (incase of any revoke of paritcular `msgType`) from the list and we are charging 20 gas per iteration.
<!-- order: 2 -->
# State
## Grant
@ -111,8 +107,6 @@ The `expiration_bytes` are the expiration date in UTC with the format `"2006-01-
The `GrantQueueItem` object contains the list of type urls between granter and grantee that expire at the time indicated in the key.
<!-- order: 3 -->
# Messages
In this section we describe the processing of messages for the authz module.
@ -156,14 +150,10 @@ The message handling should fail if:
* grantee doesn't have permission to run the transaction.
* if granted authorization is expired.
<!-- order: 4 -->
# Events
The authz module emits proto events defined in [the Protobuf reference](https://buf.build/cosmos/cosmos-sdk/docs/main/cosmos.authz.v1beta1#cosmos.authz.v1beta1.EventGrant).
<!-- order: 5 -->
# Client
## CLI

12
x/bank/README.md
View File

@ -109,8 +109,6 @@ The available permissions are:
* `Burner`: allows for a module to burn a specific amount of coins.
* `Staking`: allows for a module to delegate and undelegate a specific amount of coins.
<!-- order: 1 -->
## State
The `x/bank` module keeps state of the following primary objects:
@ -137,8 +135,6 @@ it can be updated with governance or the address with authority.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc3/proto/cosmos/bank/v1beta1/bank.proto#L11-L16
<!-- order: 2 -->
## Keepers
The bank module provides these exported keeper interfaces that can be
@ -284,8 +280,6 @@ type ViewKeeper interface {
}
```
<!-- order: 3 -->
## Messages
### MsgSend
@ -333,8 +327,6 @@ The message will fail under the following conditions:
* There are multiple SendEnabled entries with the same Denom.
* One or more SendEnabled entries has an invalid Denom.
<!-- order: 4 -->
## Events
The bank module emits the following events:
@ -481,8 +473,6 @@ In addition to message events, the bank keeper will produce events when the foll
}
```
<!-- order: 5 -->
## Parameters
The bank module contains the following parameters
@ -499,8 +489,6 @@ The default send enabled value controls send transfer capability for all
coin denominations unless specifically included in the array of `SendEnabled`
parameters.
<!-- order: 6 -->
## Client
### CLI

4
x/capability/README.md
View File

@ -80,8 +80,6 @@ func NewApp(...) *App {
* [In persisted KV store](#in-persisted-kv-store)
* [In-memory KV store](#in-memory-kv-store)
<!-- order: 1 -->
# Concepts
## Capabilities
@ -114,8 +112,6 @@ not own.
* MemStore
* KeyStore
<!-- order: 2 -->
# State
## In persisted KV store

8
x/crisis/README.md
View File

@ -22,8 +22,6 @@ application initialization process.
* [Client](#client)
* [CLI](#cli)
<!-- order: 1 -->
# State
## ConstantFee
@ -39,8 +37,6 @@ it can be updated with governance or the address with authority.
* Params: `mint/params -> legacy_amino(sdk.Coin)`
<!-- order: 2 -->
# Messages
In this section we describe the processing of the crisis messages and the
@ -63,8 +59,6 @@ never deducted as the transaction is never committed to a block (equivalent to
being refunded). However, if the invariant is not broken, the constant fee will
not be refunded.
<!-- order: 3 -->
# Events
The crisis module emits the following events:
@ -88,8 +82,6 @@ The crisis module contains the following parameters:
|-------------|---------------|-----------------------------------|
| ConstantFee | object (coin) | {"denom":"uatom","amount":"1000"} |
<!-- order: 4 -->
# Client
## CLI

16
x/distribution/README.md
View File

@ -97,8 +97,6 @@ to set up a script to periodically withdraw and rebond rewards.
* [CLI](#cli)
* [gRPC](#grpc)
<!-- order: 1 -->
# Concepts
In Proof of Stake (PoS) blockchains, rewards gained from transaction fees are paid to validators. The fee distribution module fairly distributes the rewards to the validators' constituent delegators.
@ -130,8 +128,6 @@ is created which might need to reference the historical record, the reference co
Each time one object which previously needed to reference the historical record is deleted, the reference
count is decremented. If the reference count hits zero, the historical record is deleted.
<!-- order: 2 -->
# State
## FeePool
@ -202,8 +198,6 @@ it can be updated with governance or the address with authority.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/distribution/v1beta1/distribution.proto#L11-L30
<!-- order: 3 -->
# Begin Block
At each `BeginBlock`, all fees received in the previous block are transferred to
@ -276,8 +270,6 @@ the total rewards. Consequently, the reward for a single delegator is:
community tax rate) * (1 - validator commission rate)
```
<!-- order: 4 -->
# Messages
## MsgSetWithdrawAddress
@ -407,8 +399,6 @@ The message handling can fail if:
* signer is not the gov module account address.
<!-- order: 5 -->
# Hooks
Available hooks that can be called by and from this module.
@ -465,8 +455,6 @@ Any remaining rewards are dust amounts.
* The slash event is stored for later use.
The slash event will be referenced when calculating delegator rewards.
<!-- order: 6 -->
# Events
The distribution module emits the following events:
@ -512,8 +500,6 @@ The distribution module emits the following events:
| message | action | withdraw_validator_commission |
| message | sender | {senderAddress} |
<!-- order: 7 -->
# Parameters
The distribution module contains the following parameters:
@ -528,8 +514,6 @@ The distribution module contains the following parameters:
* [0] `communitytax`, `baseproposerreward` and `bonusproposerreward` must be
positive and their sum cannot exceed 1.00.
<!-- order: 8 -->
# Client
## CLI

2
x/epoching/README.md
View File

@ -36,8 +36,6 @@ func NewKeeper(cdc codec.BinaryMarshaler, key sdk.StoreKey) Keeper {
* [State](#state)
<!-- order: 1 -->
# State
## Messages queue

7
x/evidence/README.md
View File

@ -39,8 +39,6 @@ Each corresponding handler must also fulfill the `Handler` interface contract. T
`Handler` for a given `Evidence` type can perform any arbitrary state transitions
such as slashing, jailing, and tombstoning.
<!-- order: 1 -->
# Concepts
## Evidence
@ -116,7 +114,6 @@ by the `Handler` should be persisted.
type Handler func(sdk.Context, Evidence) error
```
<!-- order: 2 -->
# State
@ -134,7 +131,6 @@ message GenesisState {
All `Evidence` is retrieved and stored via a prefix `KVStore` using prefix `0x00` (`KeyPrefixEvidence`).
<!-- order: 3 -->
# Messages
@ -188,7 +184,6 @@ First, there must not already exist valid submitted `Evidence` of the exact same
type. Secondly, the `Evidence` is routed to the `Handler` and executed. Finally,
if there is no error in handling the `Evidence`, an event is emitted and it is persisted to state.
<!-- order: 4 -->
# Events
@ -205,13 +200,11 @@ The `x/evidence` module emits the following events:
| message | sender | {senderAddress} |
| message | action | submit_evidence |
<!-- order: 5 -->
# Parameters
The evidence module does not contain any parameters.
<!-- order: 6 -->
# BeginBlock

9
x/feegrant/README.md
View File

@ -31,8 +31,6 @@ This module allows accounts to grant fee allowances and to use fees from their a
* [CLI](#cli)
* [gRPC](#grpc)
<!-- order: 1 -->
# Concepts
## Grant
@ -123,7 +121,6 @@ In order to prevent DoS attacks, using a filtered `x/feegrant` incurs gas. The S
A queue in the state maintained with the prefix of expiration of the grants and checks them on EndBlock with the current block time for every block to prune.
<!-- order: 2 -->
# State
@ -145,8 +142,6 @@ Fee allowance queue keys are stored in the state as follows:
* Grant: `0x01 | expiration_bytes | grantee_addr_len (1 byte) | grantee_addr_bytes | granter_addr_len (1 byte) | granter_addr_bytes -> EmptyBytes`
<!-- order: 3 -->
# Messages
## Msg/GrantAllowance
@ -161,8 +156,6 @@ An allowed grant fee allowance can be removed with the `MsgRevokeAllowance` mess
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/feegrant/v1beta1/tx.proto#L41-L50
<!-- order: 4 -->
# Events
The feegrant module emits the following events:
@ -193,8 +186,6 @@ The feegrant module emits the following events:
| message | granter | {granterAddress} |
| message | grantee | {granteeAddress} |
<!-- order: 6 -->
# Client
## CLI

15
x/gov/README.md
View File

@ -125,8 +125,6 @@ staking token of the chain.
* [Proposal](#proposal-3)
* [Vote](#vote-5)
<!-- order: 1 -->
# Concepts
*Disclaimer: This is work in progress. Mechanisms are susceptible to change.*
@ -327,8 +325,6 @@ new version of the software.
Validators and full nodes can use an automation tool, such as [Cosmovisor](https://github.com/cosmos/cosmos-sdk/blob/main/cosmovisor/README.md), for automatically switching version of the chain.
<!-- order: 2 -->
# State
## Proposals
@ -545,8 +541,6 @@ While proposals should use the new implementation of the governance proposal, we
More information on how to submit proposals in the [client section](07_client.md).
<!-- order: 3 -->
# Messages
## Proposal Submission
@ -727,8 +721,6 @@ handled:
store(Governance, <txGovVote.ProposalID|'addresses'|sender>, txGovVote.Vote) // Voters can vote multiple times. Re-voting overrides previous vote. This is ok because tallying is done once at the end.
```
<!-- order: 4 -->
# Events
The governance module emits the following events:
@ -791,8 +783,6 @@ The governance module emits the following events:
* [0] Event only emitted if the voting period starts during the submission.
<!-- order: 5 -->
# Future Improvements
The current documentation only describes the minimum viable product for the
@ -820,8 +810,6 @@ governance module. Future improvements may include:
`proposal.Deposit`, one for anti-spam (same as in MVP) and an other one to
reward third party auditors.
<!-- order: 6 -->
# Parameters
The governance module contains the following parameters:
@ -847,8 +835,6 @@ The governance module contains the following parameters:
modules. If only a subset of parameters are desired to be changed, only they need
to be included and not the entire parameter object structure.
<!-- order: 7 -->
# Client
## CLI
@ -2650,7 +2636,6 @@ Example Output:
}
```
<!-- order: 8 -->
# Metadata

11
x/group/README.md
View File

@ -58,8 +58,6 @@ This module allows the creation and management of on-chain multisig accounts and
* [REST](#rest)
* [Metadata](#metadata)
<!-- order: 1 -->
# Concepts
## Group
@ -214,8 +212,6 @@ Proposals are pruned:
whichever happens first.
<!-- order: 2 -->
# State
The `group` module uses the `orm` package which provides table storage with support for
@ -318,8 +314,6 @@ The `voteTable` is a primary key table and its `PrimaryKey` is given by
`voteByVoterIndex` allows to retrieve votes by voter address:
`0x42 | len([]byte(voter.Address)) | []byte(voter.Address) | PrimaryKey -> []byte()`.
<!-- order: 3 -->
# Msg Service
## Msg/CreateGroup
@ -476,8 +470,6 @@ It's expected to fail if:
* the group member is not part of the group.
* for any one of the associated group policies, if its decision policy's `Validate()` method fails against the updated group.
<!-- order: 4 -->
# Events
The group module emits the following events:
@ -547,7 +539,6 @@ The group module emits the following events:
| cosmos.group.v1.EventLeaveGroup | proposal_id | {proposalId} |
| cosmos.group.v1.EventLeaveGroup | address | {address} |
<!-- order: 5 -->
# Client
@ -2057,8 +2048,6 @@ Example Output:
}
```
<!-- order: 6 -->
# Metadata
The group module has four locations for metadata where users can provide further context about the on-chain actions they are taking. By default all metadata fields have a 255 character length field where metadata can be stored in json format, either on-chain or off-chain depending on the amount of data required. Here we provide a recommendation for the json structure and where the data should be stored. There are two important factors in making these recommendations. First, that the group and gov modules are consistent with one another, note the number of proposals made by all groups may be quite large. Second, that client applications such as block explorers and governance interfaces have confidence in the consistency of metadata structure accross chains.

5
x/mint/README.md
View File

@ -49,7 +49,6 @@ It can be broken down in the following way:
* If the inflation rate is above the goal %-bonded the inflation rate will
decrease until a minimum value is reached
<!-- order: 1 -->
# State
@ -70,7 +69,6 @@ it can be updated with governance or the address with authority.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/mint/v1beta1/mint.proto#L25-L57
<!-- order: 2 -->
# Begin-Block
@ -135,7 +133,6 @@ BlockProvision(params Params) sdk.Coin {
return sdk.NewCoin(params.MintDenom, provisionAmt.Truncate())
```
<!-- order: 3 -->
# Parameters
@ -150,7 +147,6 @@ The minting module contains the following parameters:
| GoalBonded | string (dec) | "0.670000000000000000" |
| BlocksPerYear | string (uint64) | "6311520" |
<!-- order: 4 -->
# Events
@ -165,7 +161,6 @@ The minting module emits the following events:
| mint | annual_provisions | {annualProvisions} |
| mint | amount | {amount} |
<!-- order: 5 -->
# Client

6
x/nft/README.md
View File

@ -31,8 +31,6 @@ parent:
The full name of NFT is Non-Fungible Tokens. Because of the irreplaceable nature of NFT, it means that it can be used to represent unique things. The nft implemented by this module is fully compatible with Ethereum ERC721 standard.
<!-- order: 1 -->
# State
## Class
@ -65,8 +63,6 @@ TotalSupply is responsible for tracking the number of all nfts under a certain c
* OwnerKey: `0x05 | classID |-> totalSupply`
<!-- order: 2 -->
# Messages
In this section we describe the processing of messages for the nft module.
@ -81,8 +77,6 @@ The message handling should fail if:
* provided `Id` is not exist.
* provided `Sender` is not the owner of nft.
<!-- order: 3 -->
# Events
The nft module emits proto events defined in [the Protobuf reference](https://buf.build/cosmos/cosmos-sdk/docs/main:cosmos.nft.v1beta1).

4
x/params/README.md
View File

@ -30,8 +30,6 @@ The following contents explains how to use params module for master and user mod
* [KeyTable](#keytable)
* [ParamSet](#paramset)
<!-- order: 1 -->
# Keeper
In the app initialization stage, [subspaces](#subspace) can be allocated for other modules' keeper using `Keeper.Subspace` and are stored in `Keeper.spaces`. Then, those modules can have a reference to their specific parameter store through `Keeper.GetSubspace`.
@ -48,8 +46,6 @@ func (k ExampleKeeper) SetParams(ctx sdk.Context, params types.Params) {
}
```
<!-- order: 2 -->
# Subspace
`Subspace` is a prefixed subspace of the parameter store. Each module which uses the

16
x/slashing/README.md
View File

@ -45,8 +45,6 @@ This module will be used by the Cosmos Hub, the first hub in the Cosmos ecosyste
* [gRPC](#grpc)
* [REST](#rest)
<!-- order: 1 -->
# Concepts
## States
@ -101,8 +99,6 @@ Multiple infractions are committed and then later discovered, at which point the
validator is jailed and slashed for only one infraction. Because the validator
is also tombstoned, they can not rejoin the validator set.
<!-- order: 2 -->
# State
## Signing Info (Liveness)
@ -160,8 +156,6 @@ it can be updated with governance or the address with authority.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc3/proto/cosmos/slashing/v1beta1/slashing.proto#L35-L45
<!-- order: 3 -->
# Messages
In this section we describe the processing of messages for the `slashing` module.
@ -210,8 +204,6 @@ If the validator has enough stake to be in the top `n = MaximumBondedValidators`
and all delegators still delegated to the validator will be rebonded and begin to again collect
provisions and rewards.
<!-- order: 4 -->
# BeginBlock
## Liveness Tracking
@ -306,7 +298,6 @@ for vote in block.LastCommitInfo.Votes {
SetValidatorSigningInfo(vote.Validator.Address, signInfo)
}
```
<!-- order: 5 -->
# Hooks
@ -349,7 +340,6 @@ onValidatorBonded(address sdk.ValAddress)
return
```
<!-- order: 6 -->
# Events
@ -394,8 +384,6 @@ The slashing module emits the following events:
| ----- | ------------- | ------------------ |
| slash | jailed | {validatorAddress} |
<!-- order: 7 -->
# Staking Tombstone
## Abstract
@ -520,8 +508,6 @@ want to slash them equally, and thus we can enact the above change.
> not for a different consensus algorithm or future versions of Tendermint that
> may want to punish at different levels (for example, partial slashing).
<!-- order: 8 -->
# Parameters
The slashing module contains the following parameters:
@ -534,8 +520,6 @@ The slashing module contains the following parameters:
| SlashFractionDoubleSign | string (dec) | "0.050000000000000000" |
| SlashFractionDowntime | string (dec) | "0.010000000000000000" |
<!-- order: 9 -->
# CLI
A user can query and interact with the `slashing` module using the CLI.

18
x/staking/README.md
View File

@ -60,8 +60,6 @@ network.
* [gRPC](#grpc)
* [REST](#rest)
<!-- order: 1 -->
# State
## Pool
@ -276,8 +274,6 @@ they are in a deterministic order.
The oldest HistoricalEntries will be pruned to ensure that there only exist the parameter-defined number of
historical entries.
<!-- order: 2 -->
# State Transitions
This document describes the state transition operations pertaining to:
@ -457,8 +453,6 @@ A special case is the initial delegation, when `T = 0` and `S = 0`, so `T_j / T`
For the initial delegation, delegator `j` who delegates `T_j` tokens receive `S_j = T_j` shares.
So a validator that hasn't received any rewards and has not been slashed will have `T = S`.
<!-- order: 3 -->
# Messages
In this section we describe the processing of the staking messages and the corresponding updates to the state. All created/modified state objects specified by each message are defined within the [state](./02_state_transitions.md) section.
@ -643,8 +637,6 @@ The message handling can fail if:
* signer is not the authority defined in the staking keeper (usually the gov module account).
<!-- order: 4 -->
# Begin-Block
Each abci begin block call, the historical info will get stored and pruned
@ -658,8 +650,6 @@ Otherwise, the latest historical info is stored under the key `historicalInfoKey
In most cases, this results in a single entry being pruned per block.
However, if the parameter `HistoricalEntries` has changed to a lower value there will be multiple entries in the store that must be pruned.
<!-- order: 5 -->
# End-Block
Each abci end block call, the operations to update queues and validator set
@ -734,8 +724,6 @@ Complete the unbonding of all mature `Redelegation.Entries` within the
* remove the `Redelegation` object from the store if there are no
remaining entries.
<!-- order: 6 -->
# Hooks
Other modules may register operations to execute when a certain event has
@ -762,8 +750,6 @@ following hooks can registered with staking:
* `BeforeDelegationRemoved(Context, AccAddress, ValAddress) error`
* called when a delegation is removed
<!-- order: 7 -->
# Events
The staking module emits the following events:
@ -851,8 +837,6 @@ The staking module emits the following events:
* [0] Time is formatted in the RFC3339 standard
<!-- order: 8 -->
# Parameters
The staking module contains the following parameters:
@ -866,8 +850,6 @@ The staking module contains the following parameters:
| BondDenom | string | "stake" |
| MinCommissionRate | string | "0.000000000000000000" |
<!-- order: 9 -->
# Client
## CLI

8
x/upgrade/README.md
View File

@ -126,8 +126,6 @@ A `MsgCancelUpgrade` proposal can also be made while the original
`MsgSoftwareUpgrade` proposal is still being voted upon, as long as the `VotingPeriod`
ends after the `MsgSoftwareUpgrade` proposal.
<!-- order: 1 -->
# State
The internal state of the `x/upgrade` module is relatively minimal and simple. The
@ -145,15 +143,11 @@ by the corresponding module name of type `string`. The state maintains a
The `x/upgrade` module contains no genesis state.
<!-- order: 2 -->
# Events
The `x/upgrade` does not emit any events by itself. Any and all proposal related
events are emitted through the `x/gov` module.
<!-- order: 3 -->
# Client
## CLI
@ -610,8 +604,6 @@ Example Output:
}
```
<!-- order: 4 -->
# Resources
A list of (external) resources to learn more about the `x/upgrade` module.