Final updates for new docs website (#5388)
* consolidate intro * start anatomy of sdk app * wokring * working * querier * working * workiiiing * finish * add dep and makefile * Apply suggestions from code review Co-Authored-By: Alessio Treglia <quadrispro@ubuntu.com> * typo * typo * Apply suggestions from code review Co-Authored-By: Alexander Bezobchuk <alexanderbez@users.noreply.github.com> Co-Authored-By: Federico Kunze <31522760+fedekunze@users.noreply.github.com> Co-Authored-By: Alessio Treglia <quadrispro@ubuntu.com> Co-Authored-By: frog power 4000 <rigel.rozanski@gmail.com> * refactor for new module interface * karoly review * Apply suggestions from code review Co-Authored-By: Karoly Albert Szabo <szabo.karoly.a@gmail.com> Co-Authored-By: Federico Kunze <31522760+fedekunze@users.noreply.github.com> * encoding * working on baseapp doc * baseapp work * reorg * almost there * finish first draft * remove old files * module doc start * finish intro * working * workinnn * add transactions into core * hans comments * add transactions into core * working * gautier comments * clean * working * consolidate intro * querier * workiiiing * refactor for new module interface * karoly review * working on baseapp doc * baseapp work * reorg * almost there * finish first draft * remove old files * finish intro * workinnn * initial commit after rebase * query-lifecycle and started modules-interfaces * query-lifecycle first draft done * module interfaces first draft * rest and intro skeletons * rest and intro done * small edits and links * comments * revisions * cli.md comments * comments * minor edits * better flow for query lifecycle * add transactions into core * hans comments * add transactions into core * checkout master-docs files * deleted some * remove modules readme * cli.md comments * comments * module-interfaces comments * Merge PR #4857: Add Context concept doc * working * working * finish messages and queries * handler * querier * last comments! * punctuation * querier2 * consolidate intro * querier * workiiiing * refactor for new module interface * karoly review * working on baseapp doc * baseapp work * reorg * almost there * finish first draft * remove old files * finish intro * workinnn * initial commit after rebase * query-lifecycle and started modules-interfaces * query-lifecycle first draft done * module interfaces first draft * rest and intro skeletons * rest and intro done * small edits and links * comments * revisions * cli.md comments * comments * minor edits * better flow for query lifecycle * checkout master-docs files * deleted some * remove modules readme * cli.md comments * comments * module-interfaces comments * keeper * genesis * finish * Apply suggestions from code review Co-Authored-By: Hans Schoenburg <hschoenburg@users.noreply.github.com> * hans review * Update docs/core/baseapp.md Co-Authored-By: Hans Schoenburg <hschoenburg@users.noreply.github.com> * working * last comment * workin * Apply suggestions from code review * encoding and node * almost finish store * finish docs * fixes * fede comments + permalinks * hans review * add more permalinks * update docs theme version (#5239) * R4R: Docs Cleanup (#5246) * start * work * work * work * remove table of content * links intro * fix links * remove junk * cleanup * cleanup * work * finish cleanup * addback readmes * remove nft * fix links * remove dup * remove dup * remove dup * remove dup * remove dup * fix links * add subscribe events * refine rest * index page * sidebar * theme version * theme version * testing netlify * theme version * tooltip example * version * testing code embedding * reverting back * theme version * version * version * version * readme and version * cleanup * redo app anatomy * modules readme, theme version * theme version * fix modules list * theme version * new snippets * modules readme * update docs readme * modify synopsis * version * fix yaml * version * version * version * version * version * version * version * version * version * version * add hide banner * version * version * version * small fixes * modules readme, version * remove hotkeys dep, version * version * version * version * version * version * version * version * slight notice * fix links and hide * permalinks * small clean * version * resolve conflicts, add google analytics * fix merge remants * version * changelog 1/2 * Changelog: docs UI * version * remove merge conflicts * Code: Update link for Contributing to the docs to docs_readme * HTML/CSS: Update layout of homepage footer to match new layout in Figma * version * final modifs * modules, version * modules readme * link to module list from homepage * version * building modules link * version * version * fonts * version * Update post.sh
This commit is contained in:
gamarin2
Federico Kunze
parent
394860068d
commit
7c9164cdc8
|
|
@ -6,18 +6,31 @@ module.exports = {
|
|||
permalinkSymbol: ""
|
||||
}
|
||||
},
|
||||
head: [
|
||||
[
|
||||
"link",
|
||||
{
|
||||
rel: "stylesheet",
|
||||
type: "text/css",
|
||||
href: "https://cloud.typography.com/6138116/7255612/css/fonts.css"
|
||||
}
|
||||
],
|
||||
],
|
||||
locales: {
|
||||
'/': {
|
||||
lang: 'en-US'
|
||||
"/": {
|
||||
lang: "en-US"
|
||||
},
|
||||
'kr': {
|
||||
kr: {
|
||||
lang: "kr"
|
||||
},
|
||||
'cn': {
|
||||
lang: 'cn'
|
||||
kr: {
|
||||
lang: "kr"
|
||||
},
|
||||
'ru': {
|
||||
lang: 'ru'
|
||||
cn: {
|
||||
lang: "cn"
|
||||
},
|
||||
ru: {
|
||||
lang: "ru"
|
||||
}
|
||||
},
|
||||
base: process.env.VUEPRESS_BASE || "/",
|
||||
|
|
@ -35,7 +48,7 @@ module.exports = {
|
|||
title: "Modules",
|
||||
directory: true,
|
||||
path: "/modules"
|
||||
},
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
|
|
@ -81,7 +94,7 @@ module.exports = {
|
|||
logo: "/logo-bw.svg",
|
||||
textLink: {
|
||||
text: "cosmos.network",
|
||||
url: "https://cosmos.network"
|
||||
url: "/"
|
||||
},
|
||||
services: [
|
||||
{
|
||||
|
|
@ -147,7 +160,8 @@ module.exports = {
|
|||
children: [
|
||||
{
|
||||
title: "Contributing to the docs",
|
||||
url: "https://github.com/cosmos/cosmos-sdk/tree/master/docs"
|
||||
url:
|
||||
"https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md"
|
||||
},
|
||||
{
|
||||
title: "Source code on GitHub",
|
||||
|
|
@ -164,6 +178,12 @@ module.exports = {
|
|||
{
|
||||
ga: "UA-51029217-12"
|
||||
}
|
||||
],
|
||||
[
|
||||
"sitemap",
|
||||
{
|
||||
hostname: "https://docs.cosmos.network"
|
||||
}
|
||||
]
|
||||
],
|
||||
]
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: index
|
||||
title: Documentation
|
||||
description: The Cosmos-SDK is a framework for building blockchain applications in Golang. It is being used to build Gaia, the first implementation of the Cosmos Hub.
|
||||
title: Cosmos SDK Documentation
|
||||
description: Cosmos SDK is the world’s most popular framework for building application-specific blockchains.
|
||||
features:
|
||||
- cta: Read
|
||||
title: Introduction to Cosmos SDK
|
||||
|
|
@ -27,7 +27,7 @@ sections:
|
|||
icon: basics
|
||||
url: /basics
|
||||
- title: SDK Core
|
||||
desc: Read about the core concepts like `baseapp`, the store, or the server.
|
||||
desc: Read about the core concepts like `baseapp`, the store, or the server.
|
||||
icon: core
|
||||
url: /core
|
||||
- title: Building Modules
|
||||
|
|
@ -41,15 +41,15 @@ sections:
|
|||
- title: Modules
|
||||
desc: Explore existing modules to build your application with.
|
||||
icon: specifications
|
||||
url: /modules
|
||||
url: /modules/
|
||||
stack:
|
||||
- title: Cosmos Hub
|
||||
desc: Short description about Cosmos Hub, no longer than a few of lines.
|
||||
desc: The first of thousands of interconnected blockchains on the Cosmos Network.
|
||||
color: "#BA3FD9"
|
||||
label: hub
|
||||
url: http://hub.cosmos.network
|
||||
- title: Tendermint
|
||||
desc: Short description about Tendermint, no longer than a few of lines.
|
||||
desc: The leading BFT engine for building blockchains, powering Cosmos SDK.
|
||||
color: "#00BB00"
|
||||
label: core
|
||||
url: http://docs.tendermint.com
|
||||
|
|
@ -66,14 +66,14 @@ footer:
|
|||
|
||||
## Reference
|
||||
|
||||
- **[Basics](./basics/)**: Documentation on the basic concepts of the Cosmos SDK, like the standard anatomy of an application, the transaction lifecycle and accounts management.
|
||||
- **[Core](./core/)**: Documentation on the core concepts of the Cosmos SDK, like `baseapp`, the `store` or the `server`.
|
||||
- **[Building Modules](./building-modules/)**: Important concepts for module developers like `message`s, `keeper`s, `handler`s and `querier`s.
|
||||
- **[Interfaces](./interfaces/)**: Documentation on building interfaces for Cosmos SDK applications.
|
||||
- **[Basics](./basics/)**: Documentation on the basic concepts of the Cosmos SDK, like the standard anatomy of an application, the transaction lifecycle and accounts management.
|
||||
- **[Core](./core/)**: Documentation on the core concepts of the Cosmos SDK, like `baseapp`, the `store` or the `server`.
|
||||
- **[Building Modules](./building-modules/)**: Important concepts for module developers like `message`s, `keeper`s, `handler`s and `querier`s.
|
||||
- **[Interfaces](./interfaces/)**: Documentation on building interfaces for Cosmos SDK applications.
|
||||
|
||||
## Other Resources
|
||||
|
||||
- **[Module Directory](../x/)**: Module implementations and their respective documentation.
|
||||
- **[Module Directory](../x/)**: Module implementations and their respective documentation.
|
||||
- **[Specifications](./spec/)**: Specifications of modules and other parts of the Cosmos SDK.
|
||||
- **[SDK API Reference](https://godoc.org/github.com/cosmos/cosmos-sdk)**: Godocs of the Cosmos SDK.
|
||||
- **[REST API spec](https://cosmos.network/rpc/)**: List of endpoints to interact with a `gaia` full-node through REST.
|
||||
|
|
@ -92,5 +92,3 @@ Contact us for information about funding an implementation in another language.
|
|||
|
||||
See [this file](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md) for details of the build process and
|
||||
considerations when making changes.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ parent:
|
|||
|
||||
# Building Modules
|
||||
|
||||
This repository contains documentation on concepts developers need to know in order to build modules for Cosmos SDK applications.
|
||||
This repository contains documentation on concepts developers need to know in order to build modules for Cosmos SDK applications.
|
||||
|
||||
1. [Introduction to Cosmos SDK Modules](./intro.md)
|
||||
2. [`AppModule` Interface and Module Manager](./module-manager.md)
|
||||
|
|
@ -19,4 +19,3 @@ This repository contains documentation on concepts developers need to know in or
|
|||
9. [Genesis](./genesis.md)
|
||||
10. [Module Interfaces](./module-interfaces.md)
|
||||
11. [Standard Module Structure](./structure.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@ order: 4
|
|||
|
||||
# Main Components of the Cosmos SDK
|
||||
|
||||
The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the SDK is a boilerplate implementation of the [ABCI](./sdk-app-architecture.md#abci) in Golang. It comes with a [`multistore`](../core/store.md#multistore) to persist data and a [`router`](../core/baseapp.md#routing) to handle transactions.
|
||||
The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the SDK is a boilerplate implementation of the [ABCI](./sdk-app-architecture.md#abci) in Golang. It comes with a [`multistore`](../core/store.md#multistore) to persist data and a [`router`](../core/baseapp.md#routing) to handle transactions.
|
||||
|
||||
Here is a simplified view of how transactions are handled by an application built on top of the Cosmos SDK when transferred from Tendermint via `DeliverTx`:
|
||||
|
||||
1. Decode `transactions` received from the Tendermint consensus engine (remember that Tendermint only deals with `[]bytes`).
|
||||
1. Decode `transactions` received from the Tendermint consensus engine (remember that Tendermint only deals with `[]bytes`).
|
||||
2. Extract `messages` from `transactions` and do basic sanity checks.
|
||||
3. Route each message to the appropriate module so that it can be processed.
|
||||
3. Route each message to the appropriate module so that it can be processed.
|
||||
4. Commit state changes.
|
||||
|
||||
## `baseapp`
|
||||
|
|
@ -25,7 +25,7 @@ For more on `baseapp`, please click [here](../core/baseapp.md).
|
|||
|
||||
## Multistore
|
||||
|
||||
The Cosmos SDK provides a [`multistore`](../core/store.md#multisotre) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../core/store.md#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](../core/encoding.md) before being stored.
|
||||
The Cosmos SDK provides a [`multistore`](../core/store.md#multisotre) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../core/store.md#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](../core/encoding.md) before being stored.
|
||||
|
||||
The multistore abstraction is used to divide the state in distinct compartments, each managed by its own module. For more on the multistore, click [here](../core/store.md#multistore)
|
||||
|
||||
|
|
@ -38,9 +38,9 @@ Here is a simplified view of how a transaction is processed by the application o
|
|||
```
|
||||
+
|
||||
|
|
||||
| Transaction relayed from the full-node's Tendermint engine
|
||||
| Transaction relayed from the full-node's Tendermint engine
|
||||
| to the node's application via DeliverTx
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
+---------------------v--------------------------+
|
||||
|
|
@ -88,9 +88,8 @@ SDK modules are defined in the `x/` folder of the SDK. Some core modules include
|
|||
- `x/bank`: Used to enable tokens and token transfers.
|
||||
- `x/staking` + `x/slashing`: Used to build Proof-Of-Stake blockchains.
|
||||
|
||||
In addition to the already existing modules in `x/`, that anyone can use in their app, the SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://cosmos.network/docs/tutorial/keeper.html).
|
||||
In addition to the already existing modules in `x/`, that anyone can use in their app, the SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://cosmos.network/docs/tutorial/keeper.html).
|
||||
|
||||
## Next {hide}
|
||||
|
||||
Learn more about the [anatomy of an SDK application](../basics/app-anatomy.md) {hide}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,10 @@
|
|||
---
|
||||
order: 2
|
||||
synopsis: This document explains what application-specific blockchains are, and why developers would want to build one as opposed to writing Smart Contracts.
|
||||
---
|
||||
|
||||
# Application-Specific Blockchains
|
||||
|
||||
This document explains what application-specific blockchains are, and why developers would want to build one as opposed to writing Smart Contracts.
|
||||
|
||||
## What are application-specific blockchains?
|
||||
|
||||
Application-specific blockchains are blockchains customized to operate a single application. Instead of building a decentralised application on top of an underlying blockchain like Ethereum, developers build their own blockchain from the ground up. This means building a full-node client, a light-client, and all the necessary interfaces (CLI, REST, ...) to interract with the nodes.
|
||||
|
|
|
|||
|
|
@ -877,9 +877,9 @@
|
|||
"integrity": "sha512-tHq6qdbT9U1IRSGf14CL0pUlULksvY9OZ+5eEgl1N7t+OA3tGvNpxJCzuKQlsNgCVwbAs670L1vcVQi8j9HjnA=="
|
||||
},
|
||||
"@types/node": {
|
||||
"version": "12.12.15",
|
||||
"resolved": "https://registry.npmjs.org/@types/node/-/node-12.12.15.tgz",
|
||||
"integrity": "sha512-Pv+vWicyFd07Hw/SmNnTUguqrHgDfMtjabvD9sQyxeqbpCEg8CmViLBaVPHtNsoBgZECrRf5/pgV6FJIBrGSjw=="
|
||||
"version": "12.12.17",
|
||||
"resolved": "https://registry.npmjs.org/@types/node/-/node-12.12.17.tgz",
|
||||
"integrity": "sha512-Is+l3mcHvs47sKy+afn2O1rV4ldZFU7W8101cNlOd+MRbjM4Onida8jSZnJdTe/0Pcf25g9BNIUsuugmE6puHA=="
|
||||
},
|
||||
"@types/q": {
|
||||
"version": "1.5.2",
|
||||
|
|
@ -1135,8 +1135,7 @@
|
|||
"@vuepress/plugin-google-analytics": {
|
||||
"version": "1.2.0",
|
||||
"resolved": "https://registry.npmjs.org/@vuepress/plugin-google-analytics/-/plugin-google-analytics-1.2.0.tgz",
|
||||
"integrity": "sha512-0zol5D4Efb5GKel7ADO/s65MLtKSLnOEGkeWzuipkWomSQPzP7TJ3+/RcYBnGdyBFHd1BSpTUHGK0b/IGwM3UA==",
|
||||
"dev": true
|
||||
"integrity": "sha512-0zol5D4Efb5GKel7ADO/s65MLtKSLnOEGkeWzuipkWomSQPzP7TJ3+/RcYBnGdyBFHd1BSpTUHGK0b/IGwM3UA=="
|
||||
},
|
||||
"@vuepress/plugin-last-updated": {
|
||||
"version": "1.2.0",
|
||||
|
|
@ -2593,9 +2592,9 @@
|
|||
"integrity": "sha1-Z29us8OZl8LuGsOpJP1hJHSPV40="
|
||||
},
|
||||
"copy-webpack-plugin": {
|
||||
"version": "5.0.5",
|
||||
"resolved": "https://registry.npmjs.org/copy-webpack-plugin/-/copy-webpack-plugin-5.0.5.tgz",
|
||||
"integrity": "sha512-7N68eIoQTyudAuxkfPT7HzGoQ+TsmArN/I3HFwG+lVE3FNzqvZKIiaxtYh4o3BIznioxUvx9j26+Rtsc9htQUQ==",
|
||||
"version": "5.1.0",
|
||||
"resolved": "https://registry.npmjs.org/copy-webpack-plugin/-/copy-webpack-plugin-5.1.0.tgz",
|
||||
"integrity": "sha512-0sNrj/Sx7/cWA0k7CVQa0sdA/dzCybqSb0+GbhKuQdOlAvnAwgC2osmbAFOAfha7ZXnreoQmCq5oDjG3gP4VHw==",
|
||||
"requires": {
|
||||
"cacache": "^12.0.3",
|
||||
"find-cache-dir": "^2.1.0",
|
||||
|
|
@ -2607,7 +2606,7 @@
|
|||
"normalize-path": "^3.0.0",
|
||||
"p-limit": "^2.2.1",
|
||||
"schema-utils": "^1.0.0",
|
||||
"serialize-javascript": "^2.1.0",
|
||||
"serialize-javascript": "^2.1.2",
|
||||
"webpack-log": "^2.0.0"
|
||||
},
|
||||
"dependencies": {
|
||||
|
|
@ -8490,15 +8489,15 @@
|
|||
}
|
||||
},
|
||||
"terser-webpack-plugin": {
|
||||
"version": "1.4.2",
|
||||
"resolved": "https://registry.npmjs.org/terser-webpack-plugin/-/terser-webpack-plugin-1.4.2.tgz",
|
||||
"integrity": "sha512-fdEb91kR2l+BVgES77N/NTXWZlpX6vX+pYPjnX5grcDYBF2CMnzJiXX4NNlna4l04lvCW39lZ+O/jSvUhHH/ew==",
|
||||
"version": "1.4.3",
|
||||
"resolved": "https://registry.npmjs.org/terser-webpack-plugin/-/terser-webpack-plugin-1.4.3.tgz",
|
||||
"integrity": "sha512-QMxecFz/gHQwteWwSo5nTc6UaICqN1bMedC5sMtUc7y3Ha3Q8y6ZO0iCR8pq4RJC8Hjf0FEPEHZqcMB/+DFCrA==",
|
||||
"requires": {
|
||||
"cacache": "^12.0.2",
|
||||
"find-cache-dir": "^2.1.0",
|
||||
"is-wsl": "^1.1.0",
|
||||
"schema-utils": "^1.0.0",
|
||||
"serialize-javascript": "^2.1.1",
|
||||
"serialize-javascript": "^2.1.2",
|
||||
"source-map": "^0.6.1",
|
||||
"terser": "^4.1.2",
|
||||
"webpack-sources": "^1.4.0",
|
||||
|
|
@ -9164,9 +9163,9 @@
|
|||
}
|
||||
},
|
||||
"vuepress-theme-cosmos": {
|
||||
"version": "1.0.93",
|
||||
"resolved": "https://registry.npmjs.org/vuepress-theme-cosmos/-/vuepress-theme-cosmos-1.0.93.tgz",
|
||||
"integrity": "sha512-P8I8RSydfW/cetx0ruYegeDPuX3PkD/M9I8F7LX54rnA9wPrTM4fLo3fl2MYJmY9jh9uStVLGx95IlHqxtwsOA==",
|
||||
"version": "1.0.103",
|
||||
"resolved": "https://registry.npmjs.org/vuepress-theme-cosmos/-/vuepress-theme-cosmos-1.0.103.tgz",
|
||||
"integrity": "sha512-vp/5gTySDgjIaO9xLFeTrj241slW1aNG8GhUHtWPOir07SYQ6iOVSncMvHgUlNs4uSha+/EMIpn8Pg4FF8VSLQ==",
|
||||
"requires": {
|
||||
"@cosmos-ui/vue": "^0.5.16",
|
||||
"@vuepress/plugin-last-updated": "^1.2.0",
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@
|
|||
"author": "",
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"vuepress-theme-cosmos": "^1.0.93"
|
||||
"@vuepress/plugin-google-analytics": "^1.2.0",
|
||||
"vuepress-theme-cosmos": "^1.0.103"
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
#!/usr/bin/env bash
|
||||
|
||||
rm -rf modules
|
||||
rm -rf modules
|
||||
|
|
|
|||
|
|
@ -9,4 +9,4 @@ for D in ../x/*; do
|
|||
fi
|
||||
done
|
||||
|
||||
cp ../x/README.md modules/
|
||||
cat ../x/README.md | sed 's/\.\/x/\/modules/g' | sed 's/spec\/README.md//g' | sed 's/\.\.\/docs\/building-modules\/README\.md/\/building-modules\/intro\.html/g' > ./modules/README.md
|
||||
|
|
@ -11,12 +11,11 @@ Here are some production-grade modules that can be used in Cosmos SDK applicatio
|
|||
- [Bank](./x/bank/spec/README.md) - Token transfer functionalities.
|
||||
- [Governance](./x/gov/spec/README.md) - On-chain proposals and voting.
|
||||
- [Staking](./x/staking/spec/README.md) - Proof-of-stake layer for public blockchains.
|
||||
- [Slashing](.x/slashing/spec/README.md) - Validator punishment mechanisms.
|
||||
- [Distribution](.x/distribution/spec/README.md) - Fee distribution, and staking token provision distribution.
|
||||
- [Slashing](./x/slashing/spec/README.md) - Validator punishment mechanisms.
|
||||
- [Distribution](./x/distribution/spec/README.md) - Fee distribution, and staking token provision distribution.
|
||||
- [Crisis](./x/crisis/spec/README.md) - Halting the blockchain under certain circumstances (e.g. if an invariant is broken).
|
||||
- [Mint](./x/mint/spec/README.md) - Creation of new units of staking token.
|
||||
- [Params](./x/params/spec/README.md) - Globally available parameter store.
|
||||
- [Supply](./x/supply/spec/README.md) - Total token supply of the chain.
|
||||
|
||||
To learn more about the process of building modules, visit the [building modules reference documentation](../docs/building-modules/README.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
## Gas & Fees
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
## Accounts
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Messages
|
||||
|
||||
TODO make this file conform to typical messages spec
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Types
|
||||
|
||||
Besides accounts (specified in [State](state.md)), the types exposed by the auth module
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 5
|
||||
---
|
||||
|
||||
# Keepers
|
||||
|
||||
The auth module only exposes one keeper, the account keeper, which can be used to read and write accounts.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 6
|
||||
---
|
||||
|
||||
# Vesting
|
||||
|
||||
- [Vesting](#vesting)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 7
|
||||
---
|
||||
|
||||
# Parameters
|
||||
|
||||
The auth module contains the following parameters:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 0
|
||||
title: "Auth Overview"
|
||||
parent:
|
||||
title: "auth"
|
||||
---
|
||||
|
||||
# `auth`
|
||||
|
||||
## Abstract
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
Presently, the bank module has no inherent state — it simply reads and writes accounts using the `AccountKeeper` from the `auth` module.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# Keepers
|
||||
|
||||
The bank module provides three different exported keeper interfaces which can be passed to other modules which need to read or update account balances. Modules should use the least-permissive interface which provides the functionality they require.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Messages
|
||||
|
||||
## MsgSend
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Events
|
||||
|
||||
The bank module emits the following events:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 5
|
||||
---
|
||||
|
||||
# Parameters
|
||||
|
||||
The bank module contains the following parameters:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 0
|
||||
title: Bank Overview
|
||||
parent:
|
||||
title: "bank"
|
||||
---
|
||||
|
||||
# `bank`
|
||||
|
||||
## Abstract
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
## ConstantFee
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# Messages
|
||||
|
||||
In this section we describe the processing of the crisis messages and the
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Events
|
||||
|
||||
The crisis module emits the following events:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Parameters
|
||||
|
||||
The crisis module contains the following parameters:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 0
|
||||
title: Crisis Overview
|
||||
parent:
|
||||
title: "crisis"
|
||||
---
|
||||
|
||||
# `crisis`
|
||||
|
||||
## Overview
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
## Reference Counting in F1 Fee Distribution
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
## FeePool
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# End Block
|
||||
|
||||
At each `EndBlock`, the fees received are transferred to the distribution `ModuleAccount`, as it's the account the one who keeps track of the flow of coins in (as in this case) and out the module. The fees are also allocated to the proposer, community fund and global pool. When the validator is the proposer of the round, that validator (and their delegators) receives between 1% and 5% of fee rewards, the reserve community tax is then charged, then the remainder is distributed proportionally by voting power to all bonded validators independent of whether they voted (social distribution). Note the social distribution is applied to proposer validator in addition to the proposer reward.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Messages
|
||||
|
||||
## MsgWithdrawDelegationRewardsAll
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 5
|
||||
---
|
||||
|
||||
# Hooks
|
||||
|
||||
## Create or modify delegation distribution
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 6
|
||||
---
|
||||
|
||||
# Events
|
||||
|
||||
The distribution module emits the following events:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 7
|
||||
---
|
||||
|
||||
# Parameters
|
||||
|
||||
The distribution module contains the following parameters:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 0
|
||||
title: Distribution Overview
|
||||
parent:
|
||||
title: "distribution"
|
||||
---
|
||||
|
||||
# `distribution`
|
||||
|
||||
## Overview
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
## Evidence
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
Currently the `x/evidence` module only stores valid submitted `Evidence` in state.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Messages
|
||||
|
||||
## MsgSubmitEvidence
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Events
|
||||
|
||||
The `x/evidence` module emits the following events:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 5
|
||||
---
|
||||
|
||||
# Parameters
|
||||
|
||||
The evidence module contains the following parameters:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 6
|
||||
---
|
||||
|
||||
# BeginBlock
|
||||
|
||||
## Evidence Handling
|
||||
|
|
|
|||
|
|
@ -1,4 +1,11 @@
|
|||
# Evidence Module Specification
|
||||
---
|
||||
order: 0
|
||||
title: Evidence Overview
|
||||
parent:
|
||||
title: "evidence"
|
||||
---
|
||||
|
||||
# `evidence`
|
||||
|
||||
## Table of Contents
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
*Disclaimer: This is work in progress. Mechanisms are susceptible to change.*
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
## Parameters and base types
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Messages
|
||||
|
||||
## Proposal Submission
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Events
|
||||
|
||||
The governance module emits the following events:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 5
|
||||
---
|
||||
|
||||
# Future Improvements
|
||||
|
||||
The current documentation only describes the minimum viable product for the
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 6
|
||||
---
|
||||
|
||||
# Parameters
|
||||
|
||||
The governance module contains the following parameters:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 0
|
||||
title: Gov Overview
|
||||
parent:
|
||||
title: "gov"
|
||||
---
|
||||
|
||||
# `gov`
|
||||
|
||||
## Abstract
|
||||
|
|
|
|||
|
|
@ -1,3 +1,8 @@
|
|||
---
|
||||
order: 0
|
||||
title: Overview
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
## The Minting Mechanism
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
## Minter
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Begin-Block
|
||||
|
||||
Minting parameters are recalculated and inflation
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Parameters
|
||||
|
||||
The minting module contains the following parameters:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 5
|
||||
---
|
||||
|
||||
# Events
|
||||
|
||||
The minting module emits the following events:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 0
|
||||
title: Mint Overview
|
||||
parent:
|
||||
title: "mint"
|
||||
---
|
||||
|
||||
# `mint`
|
||||
|
||||
## Contents
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Keeper
|
||||
|
||||
In the app initialization stage, `Keeper.Subspace(Paramspace)` is passed to the user modules, and the subspaces are stored in `Keeper.spaces`. Later it can be retrieved with `Keeper.GetSubspace`, so the keepers holding `Keeper` can access to any subspace. For example, Gov module can take `Keeper` as its argument and modify parameter of any subspace when a `ParameterChangeProposal` is accepted.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# Subspace
|
||||
|
||||
`Subspace` is a prefixed subspace of the parameter store. Each module who use the parameter store will take a `Subspace`, not the `Keeper`, to isolate permission to access.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 0
|
||||
title: Params Overview
|
||||
parent:
|
||||
title: "params"
|
||||
---
|
||||
|
||||
# `params`
|
||||
|
||||
## Abstract
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
## States
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
## Signing Info (Liveness)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Messages
|
||||
|
||||
In this section we describe the processing of messages for the `slashing` module.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# BeginBlock
|
||||
|
||||
## Liveness Tracking
|
||||
|
|
|
|||
|
|
@ -1,8 +1,12 @@
|
|||
## Hooks
|
||||
---
|
||||
order: 5
|
||||
---
|
||||
|
||||
# Hooks
|
||||
|
||||
In this section we describe the "hooks" - slashing module code that runs when other events happen.
|
||||
|
||||
### Validator Bonded
|
||||
## Validator Bonded
|
||||
|
||||
Upon successful first-time bonding of a new validator, we create a new `ValidatorSigningInfo` structure for the
|
||||
now-bonded validator, which `StartHeight` of the current block.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 6
|
||||
---
|
||||
|
||||
# Tags
|
||||
|
||||
The slashing module emits the following events/tags:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 7
|
||||
---
|
||||
|
||||
# Staking Tombstone
|
||||
|
||||
## Abstract
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 8
|
||||
---
|
||||
|
||||
# Parameters
|
||||
|
||||
The slashing module contains the following parameters:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 20
|
||||
title: Slashing Overview
|
||||
parent:
|
||||
title: "slashing"
|
||||
---
|
||||
|
||||
# `slashing`
|
||||
|
||||
## Abstract
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
## LastTotalPower
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# State Transitions
|
||||
|
||||
This document describes the state transition operations pertaining to:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
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.md) section.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 4
|
||||
---
|
||||
|
||||
# End-Block
|
||||
|
||||
Each abci end block call, the operations to update queues and validator set
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 5
|
||||
---
|
||||
|
||||
# Hooks
|
||||
|
||||
Other modules may register operations to execute when a certain event has
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 6
|
||||
---
|
||||
|
||||
# Events
|
||||
|
||||
The staking module emits the following events:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 7
|
||||
---
|
||||
|
||||
# Parameters
|
||||
|
||||
The staking module contains the following parameters:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 0
|
||||
title: Staking Overview
|
||||
parent:
|
||||
title: "staking"
|
||||
---
|
||||
|
||||
# `staking`
|
||||
|
||||
## Abstract
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
## Supply
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
## Supply
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Future improvements
|
||||
|
||||
The current supply module only keeps track of the total supply of coins held in the network.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
order: 0
|
||||
title: Supply Overview
|
||||
parent:
|
||||
title: "supply"
|
||||
---
|
||||
|
||||
# `supply`
|
||||
|
||||
## Contents
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Concepts
|
||||
|
||||
## Plan
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 2
|
||||
---
|
||||
|
||||
# State
|
||||
|
||||
The internal state of the `x/upgrade` module is relatively minimal and simple. The
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Events
|
||||
|
||||
The `x/upgrade` does not emit any events by itself. Any and all proposal related
|
||||
|
|
|
|||
|
|
@ -1,4 +1,11 @@
|
|||
# Upgrade Module Specification
|
||||
---
|
||||
order: 0
|
||||
title: Upgrade Overview
|
||||
parent:
|
||||
title: "upgrade"
|
||||
---
|
||||
|
||||
# `upgrade`
|
||||
|
||||
## Abstract
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue