LaconicNetwork/cosmos-sdk
7
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

docs: improve documentation navigation and redirection (#13455)

Browse Source
This commit is contained in:
Julien Robert
2022-10-06 15:51:10 +02:00
committed by GitHub
parent ff39d243d4
commit 74ce07eb26
43 changed files with 299 additions and 12935 deletions
Download Patch File Download Diff File Expand all files Collapse all files
x/auth/README.md
+3 -15
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
x/authz/README.md
-10
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
x/bank/README.md
-12
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
x/capability/README.md
-4
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
x/crisis/README.md
-8
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
x/distribution/README.md
-16
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
x/epoching/README.md
-2
View File
@@ -36,8 +36,6 @@ func NewKeeper(cdc codec.BinaryMarshaler, key sdk.StoreKey) Keeper {
* [State](#state)
<!-- order: 1 -->
# State
## Messages queue
x/evidence/README.md
-7
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
x/feegrant/README.md
-9
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
x/gov/README.md
-15
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
x/group/README.md
-11
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.
x/mint/README.md
-5
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
x/nft/README.md
-6
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).
x/params/README.md
-4
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
x/slashing/README.md
-16
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.
x/staking/README.md
-18
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
x/upgrade/README.md
-8
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.