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

chore: add markdownlint to lint commands (#9353)

Browse Source 
* add markdownlint config

* update make lint commands

* update markdownlint config

* run make lint-fix

* fix empty link

* resuse docker container

* run lint-fix

* do not echo commands

Co-authored-by: ryanchrypto <12519942+ryanchrypto@users.noreply.github.com>
This commit is contained in:
Ryan Christoffersen
2021-05-27 15:31:04 +00:00
committed by GitHub
co-authored by ryanchrypto
parent b56e1a164b
commit cb66c99eab
147 changed files with 806 additions and 771 deletions
Download Patch File Download Diff File Expand all files Collapse all files
x/README.md
+1 -1
View File
@@ -25,4 +25,4 @@ To learn more about the process of building modules, visit the [building modules
## IBC
The IBC module for the SDK has moved to its [own repository](https://github.com/cosmos/ibc-go).
The IBC module for the SDK has moved to its [own repository](https://github.com/cosmos/ibc-go).
x/auth/atlas/atlas-v0.39.1.md
+4 -4
View File
@@ -86,7 +86,7 @@ module.
func NewApp(...) *App {
app.SetAnteHandler(ante.NewAnteHandler(
app.AccountKeeper,
app.SupplyKeeper,
app.SupplyKeeper,
auth.DefaultSigVerificationGasConsumer,
))
}
@@ -166,19 +166,19 @@ the module itself are defined below:
1. Query an account.
```shell
$ app q auth account [address] [...flags]
app q auth account [address] [...flags]
```
2. Sign an unsigned transaction using a single signature.
```shell
$ app tx auth sign [file]
app tx auth sign [file]
```
3. Sign an unsigned transaction using a multisig.
```shell
$ app tx auth multisign [file] [name] [[signature]...]
app tx auth multisign [file] [name] [[signature]...]
```
### REST
x/auth/spec/05_vesting.md
+27 -21
View File
@@ -5,27 +5,27 @@ order: 6
# Vesting
- [Vesting](#vesting)
- [Intro and Requirements](#intro-and-requirements)
- [Note](#note)
- [Vesting Account Types](#vesting-account-types)
- [Vesting Account Specification](#vesting-account-specification)
- [Determining Vesting & Vested Amounts](#determining-vesting--vested-amounts)
- [Continuously Vesting Accounts](#continuously-vesting-accounts)
- [Periodic Vesting Accounts](#periodic-vesting-accounts)
- [Delayed/Discrete Vesting Accounts](#delayeddiscrete-vesting-accounts)
- [Transferring/Sending](#transferringsending)
- [Keepers/Handlers](#keepershandlers)
- [Delegating](#delegating)
- [Keepers/Handlers](#keepershandlers-1)
- [Undelegating](#undelegating)
- [Keepers/Handlers](#keepershandlers-2)
- [Keepers & Handlers](#keepers--handlers)
- [Genesis Initialization](#genesis-initialization)
- [Examples](#examples)
- [Simple](#simple)
- [Slashing](#slashing)
- [Periodic Vesting](#periodic-vesting)
- [Glossary](#glossary)
- [Intro and Requirements](#intro-and-requirements)
- [Note](#note)
- [Vesting Account Types](#vesting-account-types)
- [Vesting Account Specification](#vesting-account-specification)
- [Determining Vesting & Vested Amounts](#determining-vesting--vested-amounts)
- [Continuously Vesting Accounts](#continuously-vesting-accounts)
- [Periodic Vesting Accounts](#periodic-vesting-accounts)
- [Delayed/Discrete Vesting Accounts](#delayeddiscrete-vesting-accounts)
- [Transferring/Sending](#transferringsending)
- [Keepers/Handlers](#keepershandlers)
- [Delegating](#delegating)
- [Keepers/Handlers](#keepershandlers-1)
- [Undelegating](#undelegating)
- [Keepers/Handlers](#keepershandlers-2)
- [Keepers & Handlers](#keepers--handlers)
- [Genesis Initialization](#genesis-initialization)
- [Examples](#examples)
- [Simple](#simple)
- [Slashing](#slashing)
- [Periodic Vesting](#periodic-vesting)
- [Glossary](#glossary)
## Intro and Requirements
@@ -89,16 +89,21 @@ type VestingAccount interface {
GetEndTime() int64
}
```
### BaseVestingAccount
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/vesting/v1beta1/vesting.proto#L10-L33
### ContinuousVestingAccount
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/vesting/v1beta1/vesting.proto#L35-L43
### DelayedVestingAccount
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/vesting/v1beta1/vesting.proto#L45-L53
### Period
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/vesting/v1beta1/vesting.proto#L56-L62
```go
@@ -108,6 +113,7 @@ type Periods []Period
```
### PeriodicVestingAccount
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/vesting/v1beta1/vesting.proto#L64-L73
In order to facilitate less ad-hoc type checking and assertions and to support
x/authz/spec/01_concepts.md
+1 -2
View File
@@ -5,6 +5,7 @@ order: 1
# Concepts
## Authorization and Grant
`x/authz` module defines interfaces and messages grant authorizations to perform actions
on behalf of one account to other accounts. The design is defined in the [ADR 030](../../../architecture/adr-030-authz-module.md).
@@ -13,7 +14,6 @@ Authorization is an interface which must be implemented by a concrete authorizat
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/authz/authorizations.go#L11-L25
## Built-in Authorizations
Cosmos-SDK `x/authz` module comes with following authorization types
@@ -28,7 +28,6 @@ Cosmos-SDK `x/authz` module comes with following authorization types
- `spent_limit` keeps track of how many coins are left in the authorization.
### GenericAuthorization
`GenericAuthorization` implements the `Authorization` interface, that gives unrestricted permission to execute the provided Msg on behalf of granter's account.
x/authz/spec/03_messages.md
-1
View File
@@ -20,7 +20,6 @@ The message handling should fail if:
- provided `Grant.Authorization` is not implemented.
- `Authorization.MsgTypeURL()` is not defined in the router (there is no defined handler in the app router to handle that Msg types).
## MsgRevoke
A grant can be removed with the `MsgRevoke` message.
x/authz/spec/README.md
+1
View File
@@ -10,6 +10,7 @@ parent:
## Contents
## Abstract
`x/authz` is an implementation of a Cosmos SDK module, per [ADR 30](../../../architecture/adr-030-authz-module.md), that allows
granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations must be granted for a particular Msg service method one by one using an implementation of the `Authorization` interface.
x/bank/atlas/atlas-v0.39.1.md
+1 -1
View File
@@ -141,7 +141,7 @@ The `x/bank` supports the following transactional commands.
1. Send tokens via a `MsgSend` message.
```shell
$ app tx send [from_key_or_address] [to_address] [amount] [...flags]
app tx send [from_key_or_address] [to_address] [amount] [...flags]
```
Note, the `x/bank` module does not natively support constructing a `MsgMultiSend`
x/bank/spec/02_keepers.md
+11 -11
View File
@@ -59,17 +59,17 @@ The base keeper provides full-permission access: the ability to arbitrary modify
// between accounts.
type Keeper interface {
SendKeeper
InitGenesis(sdk.Context, *types.GenesisState)
ExportGenesis(sdk.Context) *types.GenesisState
GetSupply(ctx sdk.Context, denom string) sdk.Coin
GetPaginatedTotalSupply(ctx sdk.Context, pagination *query.PageRequest) (sdk.Coins, *query.PageResponse, error)
IterateTotalSupply(ctx sdk.Context, cb func(sdk.Coin) bool)
GetDenomMetaData(ctx sdk.Context, denom string) (types.Metadata, bool)
SetDenomMetaData(ctx sdk.Context, denomMetaData types.Metadata)
IterateAllDenomMetaData(ctx sdk.Context, cb func(types.Metadata) bool)
SendCoinsFromModuleToAccount(ctx sdk.Context, senderModule string, recipientAddr sdk.AccAddress, amt sdk.Coins) error
SendCoinsFromModuleToModule(ctx sdk.Context, senderModule, recipientModule string, amt sdk.Coins) error
SendCoinsFromAccountToModule(ctx sdk.Context, senderAddr sdk.AccAddress, recipientModule string, amt sdk.Coins) error
@@ -77,10 +77,10 @@ type Keeper interface {
UndelegateCoinsFromModuleToAccount(ctx sdk.Context, senderModule string, recipientAddr sdk.AccAddress, amt sdk.Coins) error
MintCoins(ctx sdk.Context, moduleName string, amt sdk.Coins) error
BurnCoins(ctx sdk.Context, moduleName string, amt sdk.Coins) error
DelegateCoins(ctx sdk.Context, delegatorAddr, moduleAccAddr sdk.AccAddress, amt sdk.Coins) error
UndelegateCoins(ctx sdk.Context, moduleAccAddr, delegatorAddr sdk.AccAddress, amt sdk.Coins) error
types.QueryServer
}
```
@@ -95,16 +95,16 @@ accounts. The send keeper does not alter the total supply (mint or burn coins).
// between accounts without the possibility of creating coins.
type SendKeeper interface {
ViewKeeper
InputOutputCoins(ctx sdk.Context, inputs []types.Input, outputs []types.Output) error
SendCoins(ctx sdk.Context, fromAddr sdk.AccAddress, toAddr sdk.AccAddress, amt sdk.Coins) error
GetParams(ctx sdk.Context) types.Params
SetParams(ctx sdk.Context, params types.Params)
IsSendEnabledCoin(ctx sdk.Context, coin sdk.Coin) bool
IsSendEnabledCoins(ctx sdk.Context, coins ...sdk.Coin) error
BlockedAddr(addr sdk.AccAddress) bool
}
```
@@ -119,13 +119,13 @@ The view keeper provides read-only access to account balances. The view keeper d
type ViewKeeper interface {
ValidateBalance(ctx sdk.Context, addr sdk.AccAddress) error
HasBalance(ctx sdk.Context, addr sdk.AccAddress, amt sdk.Coin) bool
GetAllBalances(ctx sdk.Context, addr sdk.AccAddress) sdk.Coins
GetAccountsBalances(ctx sdk.Context) []types.Balance
GetBalance(ctx sdk.Context, addr sdk.AccAddress, denom string) sdk.Coin
LockedCoins(ctx sdk.Context, addr sdk.AccAddress) sdk.Coins
SpendableCoins(ctx sdk.Context, addr sdk.AccAddress) sdk.Coins
IterateAccountBalances(ctx sdk.Context, addr sdk.AccAddress, cb func(coin sdk.Coin) (stop bool))
IterateAllBalances(ctx sdk.Context, cb func(address sdk.AccAddress, coin sdk.Coin) (stop bool))
}
x/bank/spec/03_messages.md
+2 -1
View File
@@ -10,6 +10,7 @@ Send coins from one address to another.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/bank/v1beta1/tx.proto#L19-L28
The message will fail under the following conditions:
- The coins do not have sending enabled
- The `to` address is restricted
@@ -19,8 +20,8 @@ Send coins from and to a series of different address. If any of the receiving ad
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/bank/v1beta1/tx.proto#L33-L39
The message will fail under the following conditions:
- Any of the coins do not have sending enabled
- Any of the `to` addresses are restricted
- Any of the coins are locked
- The inputs and outputs do not correctly correspond to one another
x/bank/spec/04_events.md
+1 -1
View File
@@ -146,4 +146,4 @@ In addition to handlers events, the bank keeper will produce events when the fol
}
]
}
```
```
x/crisis/spec/01_state.md
+3 -4
View File
@@ -10,9 +10,8 @@ Due to the anticipated large gas cost requirement to verify an invariant (and
potential to exceed the maximum allowable block gas limit) a constant fee is
used instead of the standard gas consumption method. The constant fee is
intended to be larger than the anticipated gas cost of running the invariant
with the standard gas consumption method.
with the standard gas consumption method.
The ConstantFee param is held in the global params store.
- Params: `mint/params -> legacy_amino(sdk.Coin)`
The ConstantFee param is held in the global params store.
- Params: `mint/params -> legacy_amino(sdk.Coin)`
x/crisis/spec/02_messages.md
+6 -5
View File
@@ -5,17 +5,18 @@ order: 2
# Messages
In this section we describe the processing of the crisis messages and the
corresponding updates to the state.
corresponding updates to the state.
## MsgVerifyInvariant
Blockchain invariants can be checked using the `MsgVerifyInvariant` message.
Blockchain invariants can be checked using the `MsgVerifyInvariant` message.
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc7/proto/cosmos/crisis/v1beta1/tx.proto#L14-L22
This message is expected to fail if:
- the sender does not have enough coins for the constant fee
- the invariant route is not registered
This message is expected to fail if:
- the sender does not have enough coins for the constant fee
- the invariant route is not registered
This message checks the invariant provided, and if the invariant is broken it
panics, halting the blockchain. If the invariant is broken, the constant fee is
x/crisis/spec/README.md
+2 -2
View File
@@ -9,9 +9,9 @@ parent:
## Overview
The crisis module halts the blockchain under the circumstance that a blockchain
The crisis module halts the blockchain under the circumstance that a blockchain
invariant is broken. Invariants can be registered with the application during the
application initialization process.
application initialization process.
## Contents
x/distribution/spec/01_concepts.md
+3 -2
View File
@@ -3,7 +3,8 @@ 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.
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.
Rewards are calculated per period. The period is updated each time a validator's delegation changes, for example, when the validator receives a new delegation.
The rewards for a single validator can then be calculated by taking the total rewards for the period before the delegation started, minus the current total rewards.
@@ -12,7 +13,7 @@ To learn more, see the [F1 Fee Distribution paper](/docs/spec/fee_distribution/f
The commission to the validator is paid when the validator is removed or when the validator requests a withdrawal.
The commission is calculated and incremented at every `BeginBlock` operation to update accumulated fee amounts.
The rewards to a delegator are distributed when the delegation is changed or removed, or a withdrawal is requested.
The rewards to a delegator are distributed when the delegation is changed or removed, or a withdrawal is requested.
Before rewards are distributed, all slashes to the validator that occurred during the current delegation are applied.
## Reference Counting in F1 Fee Distribution
x/distribution/spec/03_begin_block.md
+1 -1
View File
@@ -72,7 +72,7 @@ withdraw or update their delegation, and is thus not handled in `BeginBlock`.
### Example Distribution
For this example distribution, the underlying consensus engine selects block proposers in
proportion to their power relative to the entire bonded power.
proportion to their power relative to the entire bonded power.
All validators are equally performant at including pre-commits in their proposed
blocks. Then hold `(precommits included) / (total bonded validator power)`
x/distribution/spec/04_messages.md
+1 -1
View File
@@ -16,7 +16,7 @@ Response:
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.4/proto/cosmos/distribution/v1beta1/tx.proto#L29-L37
```go
func (k Keeper) SetWithdrawAddr(ctx sdk.Context, delegatorAddr sdk.AccAddress, withdrawAddr sdk.AccAddress) error
func (k Keeper) SetWithdrawAddr(ctx sdk.Context, delegatorAddr sdk.AccAddress, withdrawAddr sdk.AccAddress) error
if k.blockedAddrs[withdrawAddr.String()] {
fail with "`{withdrawAddr}` is not allowed to receive external funds"
}
x/distribution/spec/05_hooks.md
+3 -1
View File
@@ -3,10 +3,12 @@ order: 5
-->
# Hooks
Available hooks that can be called by and from this module.
## Create or modify delegation distribution
- triggered-by: `staking.MsgDelegate`, `staking.MsgBeginRedelegate`, `staking.MsgUndelegate`
- triggered-by: `staking.MsgDelegate`, `staking.MsgBeginRedelegate`, `staking.MsgUndelegate`
### Before
x/distribution/spec/README.md
+1 -1
View File
@@ -92,7 +92,7 @@ to set up a script to periodically withdraw and rebond rewards.
- [MsgSetWithdrawAddress](04_messages.md#msgsetwithdrawaddress)
- [MsgWithdrawDelegatorReward](04_messages.md#msgwithdrawdelegatorreward)
- [Withdraw Validator Rewards All](04_messages.md#withdraw-validator-rewards-all)
- [Common calculations ](04_messages.md#common-calculations-)
- [Common calculations](04_messages.md#common-calculations-)
5. **[Hooks](05_hooks.md)**
- [Create or modify delegation distribution](05_hooks.md#create-or-modify-delegation-distribution)
- [Commission rate change](05_hooks.md#commission-rate-change)
x/evidence/atlas/atlas-v0.41.x.md
+2 -2
View File
@@ -43,7 +43,7 @@ with particular kinds of accounts.
func NewApp(...) *App {
// ...
keys := sdk.NewKVStoreKeys(
evidencetypes.StoreKey,
evidencetypes.StoreKey,
)
// ...
}
@@ -81,7 +81,7 @@ with particular kinds of accounts.
// ...
app.mm.SetOrderBeginBlockers(
// ...
evidencetypes.ModuleName,
evidencetypes.ModuleName,
// ...
)
}
x/evidence/spec/01_concepts.md
+1 -1
View File
@@ -66,7 +66,7 @@ The `Handler` (defined below) is responsible for executing the entirety of the
business logic for handling `Evidence`. This typically includes validating the
evidence, both stateless checks via `ValidateBasic` and stateful checks via any
keepers provided to the `Handler`. In addition, the `Handler` may also perform
capabilities such as slashing and jailing a validator. All `Evidence` handled
capabilities such as slashing and jailing a validator. All `Evidence` handled
by the `Handler` should be persisted.
```go
x/evidence/spec/06_begin_block.md
+3 -3
View File
@@ -34,11 +34,11 @@ For some `Equivocation` submitted in `block` to be valid, it must satisfy:
Where:
- `Evidence.Timestamp` is the timestamp in the block at height `Evidence.Height`
- `Evidence.Timestamp` is the timestamp in the block at height `Evidence.Height`
- `block.Timestamp` is the current block timestamp.
If valid `Equivocation` evidence is included in a block, the validator's stake is
reduced (slashed) by `SlashFractionDoubleSign` as defined by the `x/slashing` module
reduced (slashed) by `SlashFractionDoubleSign` as defined by the `x/slashing` module
of what their stake was when the infraction occurred, rather than when the evidence was discovered.
We want to "follow the stake", i.e., the stake that contributed to the infraction
should be slashed, even if it has since been redelegated or started unbonding.
@@ -150,5 +150,5 @@ func (k Keeper) HandleEquivocationEvidence(ctx sdk.Context, evidence *types.Equi
```
Note, the slashing, jailing, and tombstoning calls are delegated through the `x/slashing` module
that emits informative events and finally delegates calls to the `x/staking` module. See documentation
that emits informative events and finally delegates calls to the `x/staking` module. See documentation
on slashing and jailing in [x/staking spec](/.././cosmos-sdk/x/staking/spec/02_state_transitions.md).
x/feegrant/spec/01_concepts.md
+8 -4
View File
@@ -10,19 +10,20 @@ order: 1
+++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/proto/cosmos/feegrant/v1beta1/feegrant.proto#L75-L81
`FeeAllowanceI` looks like:
`FeeAllowanceI` looks like:
+++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/x/feegrant/fees.go#L9-L32
## Fee Allowance types
There are two types of fee allowances present at the moment:
- `BasicAllowance`
- `PeriodicAllowance`
## BasicAllowance
`BasicAllowance` is permission for `grantee` to use fee from a `granter`'s account. If any of the `spend_limit` or `expiration` reaches its limit, the grant will be removed from the state.
+++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/proto/cosmos/feegrant/v1beta1/feegrant.proto#L13-L26
@@ -40,7 +41,7 @@ There are two types of fee allowances present at the moment:
- `basic` is the instance of `BasicAllowance` which is optional for periodic fee allowance. If empty, the grant will have no `expiration` and no `spend_limit`.
- `period` is the specific period of time, after each period passes, `period_spend_limit` will be reset.
- `period` is the specific period of time, after each period passes, `period_spend_limit` will be reset.
- `period_spend_limit` specifies the maximum number of coins that can be spent in the period.
@@ -61,14 +62,17 @@ There are two types of fee allowances present at the moment:
+++ https://github.com/cosmos/cosmos-sdk/blob/d97e7907f176777ed8a464006d360bb3e1a223e4/proto/cosmos/tx/v1beta1/tx.proto#L160-L181
Example cmd:
```go
./simd tx gov submit-proposal --title="Test Proposal" --description="My awesome proposal" --type="Text" --from validator-key --fee-account=cosmos1xh44hxt7spr67hqaa7nyx5gnutrz5fraw6grxn --chain-id=testnet --fees="10stake"
```
## Granted Fee Deductions
Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](../../auth/spec/03_antehandlers.md).
## Gas
In order to prevent DoS attacks, using a filtered `x/feegrant` incurs gas. The SDK must assure that the `grantee`'s transactions all conform to the filter set by the `granter`. The SDK does this by iterating over the allowed messages in the filter and charging 10 gas per filtered message. The SDK will then iterate over the messages being sent by the `grantee` to ensure the messages adhere to the filter, also charging 10 gas per message. The SDK will stop iterating and fail the transaction if it finds a message that does not conform to the filter.
**WARNING**: The gas is charged against the granted allowance. Ensure your messages conform to the filter, if any, before sending transactions using your allowance.
**WARNING**: The gas is charged against the granted allowance. Ensure your messages conform to the filter, if any, before sending transactions using your allowance.
x/feegrant/spec/README.md
+1 -2
View File
@@ -19,7 +19,7 @@ This module allows accounts to grant fee allowances and to use fees from their a
- [BasicAllowance](01_concepts.md#basicallowance)
- [PeriodicAllowance](01_concepts.md#periodicallowance)
- [FeeAccount flag](01_concepts.md#feeaccount-flag)
- [Granted Fee Deductions](01_concepts.md#granted-fee-deductions)
- [Granted Fee Deductions](01_concepts.md#granted-fee-deductions)
- [Gas](01_concepts.md#gas)
2. **[State](02_state.md)**
- [FeeAllowance](02_state.md#feeallowance)
@@ -30,4 +30,3 @@ This module allows accounts to grant fee allowances and to use fees from their a
- [MsgGrantAllowance](04_events.md#msggrantallowance)
- [MsgRevokeAllowance](04_events.md#msgrevokeallowance)
- [Exec fee allowance](04_events.md#exec-fee-allowance)
x/gov/spec/01_concepts.md
+2 -2
View File
@@ -14,9 +14,9 @@ The governance process is divided in a few steps that are outlined below:
confirmed and vote opens. Bonded Atom holders can then send `TxGovVote`
transactions to vote on the proposal.
- If the proposal involves a software upgrade:
- **Signal:** Validators start signaling that they are ready to switch to the
- **Signal:** Validators start signaling that they are ready to switch to the
new version.
- **Switch:** Once more than 75% of validators have signaled that they are
- **Switch:** Once more than 75% of validators have signaled that they are
ready to switch, their software automatically flips to the new version.
## Proposal submission
x/gov/spec/02_state.md
+3
View File
@@ -12,12 +12,15 @@ parameter set, either to modify a value or add/remove a parameter field, a new
parameter set has to be created and the previous one rendered inactive.
### DepositParams
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L127-L145
### VotingParams
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L147-L156
### TallyParams
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L158-L183
Parameters are stored in a global `GlobalParams` KVStore.
x/gov/spec/03_messages.md
+2 -2
View File
@@ -21,7 +21,7 @@ set in the governance module.
- Initialise `Proposals` attributes
- Decrease balance of sender by `InitialDeposit`
- If `MinDeposit` is reached:
- Push `proposalID` in `ProposalProcessingQueue`
- Push `proposalID` in `ProposalProcessingQueue`
- Transfer `InitialDeposit` from the `Proposer` to the governance `ModuleAccount`
A `MsgSubmitProposal` transaction can be handled according to the following
@@ -83,7 +83,7 @@ Once a proposal is submitted, if
- Add `deposit` of sender in `proposal.Deposits`
- Increase `proposal.TotalDeposit` by sender's `deposit`
- If `MinDeposit` is reached:
- Push `proposalID` in `ProposalProcessingQueueEnd`
- Push `proposalID` in `ProposalProcessingQueueEnd`
- Transfer `Deposit` from the `proposer` to the governance `ModuleAccount`
A `MsgDeposit` transaction has to go through a number of checks to be valid.
x/gov/spec/05_future_improvements.md
+17 -17
View File
@@ -4,27 +4,27 @@ order: 5
# Future Improvements
The current documentation only describes the minimum viable product for the
The current documentation only describes the minimum viable product for the
governance module. Future improvements may include:
* **`BountyProposals`:** If accepted, a `BountyProposal` creates an open
* **`BountyProposals`:** If accepted, a `BountyProposal` creates an open
bounty. The `BountyProposal` specifies how many Atoms will be given upon
completion. These Atoms will be taken from the `reserve pool`. After a
`BountyProposal` is accepted by governance, anybody can submit a
`SoftwareUpgradeProposal` with the code to claim the bounty. Note that once a
`BountyProposal` is accepted, the corresponding funds in the `reserve pool`
are locked so that payment can always be honored. In order to link a
`SoftwareUpgradeProposal` to an open bounty, the submitter of the
`SoftwareUpgradeProposal` will use the `Proposal.LinkedProposal` attribute.
If a `SoftwareUpgradeProposal` linked to an open bounty is accepted by
completion. These Atoms will be taken from the `reserve pool`. After a
`BountyProposal` is accepted by governance, anybody can submit a
`SoftwareUpgradeProposal` with the code to claim the bounty. Note that once a
`BountyProposal` is accepted, the corresponding funds in the `reserve pool`
are locked so that payment can always be honored. In order to link a
`SoftwareUpgradeProposal` to an open bounty, the submitter of the
`SoftwareUpgradeProposal` will use the `Proposal.LinkedProposal` attribute.
If a `SoftwareUpgradeProposal` linked to an open bounty is accepted by
governance, the funds that were reserved are automatically transferred to the
submitter.
* **Complex delegation:** Delegators could choose other representatives than
their validators. Ultimately, the chain of representatives would always end
up to a validator, but delegators could inherit the vote of their chosen
representative before they inherit the vote of their validator. In other
words, they would only inherit the vote of their validator if their other
* **Complex delegation:** Delegators could choose other representatives than
their validators. Ultimately, the chain of representatives would always end
up to a validator, but delegators could inherit the vote of their chosen
representative before they inherit the vote of their validator. In other
words, they would only inherit the vote of their validator if their other
appointed representative did not vote.
* **Better process for proposal review:** There would be two parts to
`proposal.Deposit`, one for anti-spam (same as in MVP) and an other one to
* **Better process for proposal review:** There would be two parts to
`proposal.Deposit`, one for anti-spam (same as in MVP) and an other one to
reward third party auditors.
x/gov/spec/06_params.md
+1 -1
View File
@@ -25,4 +25,4 @@ The governance module contains the following parameters:
__NOTE__: The governance module contains parameters that are objects unlike other
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.
to be included and not the entire parameter object structure.
x/mint/spec/01_concepts.md
+9 -7
View File
@@ -7,8 +7,9 @@ order: 0
## The Minting Mechanism
The minting mechanism was designed to:
- allow for a flexible inflation rate determined by market demand targeting a particular bonded-stake ratio
- effect a balance between market liquidity and staked supply
- allow for a flexible inflation rate determined by market demand targeting a particular bonded-stake ratio
- effect a balance between market liquidity and staked supply
In order to best determine the appropriate market rate for inflation rewards, a
moving change rate is used. The moving change rate mechanism ensures that if
@@ -17,10 +18,11 @@ adjust to further incentivize or disincentivize being bonded, respectively. Sett
%-bonded at less than 100% encourages the network to maintain some non-staked tokens
which should help provide some liquidity.
It can be broken down in the following way:
- If the inflation rate is below the goal %-bonded the inflation rate will
It can be broken down in the following way:
- If the inflation rate is below the goal %-bonded the inflation rate will
increase until a maximum value is reached
- If the goal % bonded (67% in Cosmos-Hub) is maintained, then the inflation
rate will stay constant
- If the inflation rate is above the goal %-bonded the inflation rate will
- If the goal % bonded (67% in Cosmos-Hub) is maintained, then the inflation
rate will stay constant
- If the inflation rate is above the goal %-bonded the inflation rate will
decrease until a minimum value is reached
x/mint/spec/02_state.md
+4 -4
View File
@@ -8,14 +8,14 @@ order: 2
The minter is a space for holding current inflation information.
- Minter: `0x00 -> ProtocolBuffer(minter)`
- Minter: `0x00 -> ProtocolBuffer(minter)`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc7/proto/cosmos/mint/v1beta1/mint.proto#L8-L19
## Params
Minting params are held in the global params store.
Minting params are held in the global params store.
- Params: `mint/params -> legacy_amino(params)`
- Params: `mint/params -> legacy_amino(params)`
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc7/proto/cosmos/mint/v1beta1/mint.proto#L21-L53
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc7/proto/cosmos/mint/v1beta1/mint.proto#L21-L53
x/mint/spec/03_begin_block.md
+1 -1
View File
@@ -36,7 +36,7 @@ NextInflationRate(params Params, bondedRatio sdk.Dec) (inflation sdk.Dec) {
## NextAnnualProvisions
Calculate the annual provisions based on current total supply and inflation
rate. This parameter is calculated once per block.
rate. This parameter is calculated once per block.
```
NextAnnualProvisions(params Params, totalSupply sdk.Dec) (provisions sdk.Dec) {
x/mint/spec/README.md
-1
View File
@@ -20,4 +20,3 @@ parent:
4. **[Parameters](04_params.md)**
5. **[Events](05_events.md)**
- [BeginBlocker](05_events.md#beginblocker)
x/params/spec/02_subspace.md
+6 -6
View File
@@ -4,13 +4,13 @@ order: 2
# Subspace
`Subspace` is a prefixed subspace of the parameter store. Each module which uses the
`Subspace` is a prefixed subspace of the parameter store. Each module which uses the
parameter store will take a `Subspace` to isolate permission to access.
## Key
Parameter keys are human readable alphanumeric strings. A parameter for the key
`"ExampleParameter"` is stored under `[]byte("SubspaceName" + "/" + "ExampleParameter")`,
Parameter keys are human readable alphanumeric strings. A parameter for the key
`"ExampleParameter"` is stored under `[]byte("SubspaceName" + "/" + "ExampleParameter")`,
where `"SubspaceName"` is the name of the subspace.
Subkeys are secondary parameter keys those are used along with a primary parameter key.
@@ -18,13 +18,13 @@ Subkeys can be used for grouping or dynamic parameter key generation during runt
## KeyTable
All of the parameter keys that will be used should be registered at the compile
All of the parameter keys that will be used should be registered at the compile
time. `KeyTable` is essentially a `map[string]attribute`, where the `string` is a parameter key.
Currently, `attribute` consists of a `reflect.Type`, which indicates the parameter
Currently, `attribute` consists of a `reflect.Type`, which indicates the parameter
type to check that provided key and value are compatible and registered, as well as a function `ValueValidatorFn` to validate values.
Only primary keys have to be registered on the `KeyTable`. Subkeys inherit the
Only primary keys have to be registered on the `KeyTable`. Subkeys inherit the
attribute of the primary key.
## ParamSet
x/slashing/spec/02_state.md
+2 -2
View File
@@ -27,8 +27,8 @@ number of blocks by being automatically jailed, potentially slashed, and unbonde
Information about validator's liveness activity is tracked through `ValidatorSigningInfo`.
It is indexed in the store as follows:
- ValidatorSigningInfo: ` 0x01 | ConsAddrLen (1 byte) | ConsAddress -> ProtocolBuffer(ValSigningInfo)`
- MissedBlocksBitArray: ` 0x02 | ConsAddrLen (1 byte) | ConsAddress | LittleEndianUint64(signArrayIndex) -> VarInt(didMiss)` (varint is a number encoding format)
- ValidatorSigningInfo: `0x01 | ConsAddrLen (1 byte) | ConsAddress -> ProtocolBuffer(ValSigningInfo)`
- MissedBlocksBitArray: `0x02 | ConsAddrLen (1 byte) | ConsAddress | LittleEndianUint64(signArrayIndex) -> VarInt(didMiss)` (varint is a number encoding format)
The first mapping allows us to easily lookup the recent signing info for a
validator based on the validator's consensus address.
x/slashing/spec/05_hooks.md
-1
View File
@@ -16,7 +16,6 @@ The following hooks impact the slashing state:
+ `AfterValidatorCreated` stores a validator's consensus key.
+ `AfterValidatorRemoved` removes a validator's consensus key.
## Validator Bonded
Upon successful first-time bonding of a new validator, we create a new `ValidatorSigningInfo` structure for the
x/slashing/spec/06_events.md
-3
View File
@@ -15,7 +15,6 @@ The slashing module emits the following events/tags:
| message | module | slashing |
| message | sender | {validatorAddress} |
## Keeper
## BeginBlocker: HandleValidatorSignature
@@ -35,14 +34,12 @@ The slashing module emits the following events/tags:
| liveness | missed_blocks | {missedBlocksCounter} |
| liveness | height | {blockHeight} |
### Slash
+ same as `"slash"` event from `HandleValidatorSignature`, but without the `jailed` attribute.
### Jail
| Type | Attribute Key | Attribute Value |
| ----- | ------------- | ------------------ |
| slash | jailed | {validatorAddress} |
x/staking/spec/02_state_transitions.md
+1
View File
@@ -60,6 +60,7 @@ this process may be also be reversed. the following operations occur:
- if unjailed add record to `ValidatorByPowerIndex`
Jailed validators are not present in any of the following stores:
- the power store (from consensus power to address)
## Delegations
x/staking/spec/03_messages.md
+11 -11
View File
@@ -21,9 +21,9 @@ This message is expected to fail if:
- another validator with this pubkey is already registered
- the initial self-delegation tokens are of a denom not specified as the bonding denom
- the commission parameters are faulty, namely:
- `MaxRate` is either > 1 or < 0
- the initial `Rate` is either negative or > `MaxRate`
- the initial `MaxChangeRate` is either negative or > `MaxRate`
- `MaxRate` is either > 1 or < 0
- the initial `Rate` is either negative or > `MaxRate`
- the initial `MaxChangeRate` is either negative or > `MaxRate`
- the description fields are too large
This message creates and stores the `Validator` object at appropriate indexes.
@@ -108,11 +108,11 @@ When this message is processed the following actions occur:
- validator's `DelegatorShares` and the delegation's `Shares` are both reduced by the message `SharesAmount`
- calculate the token worth of the shares remove that amount tokens held within the validator
- with those removed tokens, if the validator is:
- `Bonded` - add them to an entry in `UnbondingDelegation` (create `UnbondingDelegation` if it doesn't exist) with a completion time a full unbonding period from the current time. Update pool shares to reduce BondedTokens and increase NotBondedTokens by token worth of the shares.
- `Unbonding` - add them to an entry in `UnbondingDelegation` (create `UnbondingDelegation` if it doesn't exist) with the same completion time as the validator (`UnbondingMinTime`).
- `Unbonded` - then send the coins the message `DelegatorAddr`
- `Bonded` - add them to an entry in `UnbondingDelegation` (create `UnbondingDelegation` if it doesn't exist) with a completion time a full unbonding period from the current time. Update pool shares to reduce BondedTokens and increase NotBondedTokens by token worth of the shares.
- `Unbonding` - add them to an entry in `UnbondingDelegation` (create `UnbondingDelegation` if it doesn't exist) with the same completion time as the validator (`UnbondingMinTime`).
- `Unbonded` - then send the coins the message `DelegatorAddr`
- if there are no more `Shares` in the delegation, then the delegation object is removed from the store
- under this situation if the delegation is the validator's self-delegation then also jail the validator.
- under this situation if the delegation is the validator's self-delegation then also jail the validator.
![Unbond sequence](../../../docs/uml/svg/unbond_sequence.svg)
@@ -144,11 +144,11 @@ When this message is processed the following actions occur:
- the source validator's `DelegatorShares` and the delegations `Shares` are both reduced by the message `SharesAmount`
- calculate the token worth of the shares remove that amount tokens held within the source validator.
- if the source validator is:
- `Bonded` - add an entry to the `Redelegation` (create `Redelegation` if it doesn't exist) with a completion time a full unbonding period from the current time. Update pool shares to reduce BondedTokens and increase NotBondedTokens by token worth of the shares (this may be effectively reversed in the next step however).
- `Unbonding` - add an entry to the `Redelegation` (create `Redelegation` if it doesn't exist) with the same completion time as the validator (`UnbondingMinTime`).
- `Unbonded` - no action required in this step
- `Bonded` - add an entry to the `Redelegation` (create `Redelegation` if it doesn't exist) with a completion time a full unbonding period from the current time. Update pool shares to reduce BondedTokens and increase NotBondedTokens by token worth of the shares (this may be effectively reversed in the next step however).
- `Unbonding` - add an entry to the `Redelegation` (create `Redelegation` if it doesn't exist) with the same completion time as the validator (`UnbondingMinTime`).
- `Unbonded` - no action required in this step
- Delegate the token worth to the destination validator, possibly moving tokens back to the bonded state.
- if there are no more `Shares` in the source delegation, then the source delegation object is removed from the store
- under this situation if the delegation is the validator's self-delegation then also jail the validator.
- under this situation if the delegation is the validator's self-delegation then also jail the validator.
![Begin redelegation sequence](../../../docs/uml/svg/begin_redelegation_sequence.svg)
x/staking/spec/05_end_block.md
+2 -2
View File
@@ -18,9 +18,9 @@ consensus layer. Operations are as following:
- the new validator set is taken as the top `params.MaxValidators` number of
validators retrieved from the `ValidatorsByPower` index
- the previous validator set is compared with the new validator set:
- missing validators begin unbonding and their `Tokens` are transferred from the
- missing validators begin unbonding and their `Tokens` are transferred from the
`BondedPool` to the `NotBondedPool` `ModuleAccount`
- new validators are instantly bonded and their `Tokens` are transferred from the
- new validators are instantly bonded and their `Tokens` are transferred from the
`NotBondedPool` to the `BondedPool` `ModuleAccount`
In all cases, any validators leaving or entering the bonded validator set or
x/staking/spec/06_hooks.md
+17 -17
View File
@@ -7,21 +7,21 @@ order: 5
Other modules may register operations to execute when a certain event has
occurred within staking. These events can be registered to execute either
right `Before` or `After` the staking event (as per the hook name). The
following hooks can registered with staking:
following hooks can registered with staking:
- `AfterValidatorCreated(Context, ValAddress)`
- called when a validator is created
- `BeforeValidatorModified(Context, ValAddress)`
- called when a validator's state is changed
- `AfterValidatorRemoved(Context, ConsAddress, ValAddress)`
- called when a validator is deleted
- `AfterValidatorBonded(Context, ConsAddress, ValAddress)`
- called when a validator is bonded
- `AfterValidatorBeginUnbonding(Context, ConsAddress, ValAddress)`
- called when a validator begins unbonding
- `BeforeDelegationCreated(Context, AccAddress, ValAddress)`
- called when a delegation is created
- `BeforeDelegationSharesModified(Context, AccAddress, ValAddress)`
- called when a delegation's shares are modified
- `BeforeDelegationRemoved(Context, AccAddress, ValAddress)`
- called when a delegation is removed
- `AfterValidatorCreated(Context, ValAddress)`
- called when a validator is created
- `BeforeValidatorModified(Context, ValAddress)`
- called when a validator's state is changed
- `AfterValidatorRemoved(Context, ConsAddress, ValAddress)`
- called when a validator is deleted
- `AfterValidatorBonded(Context, ConsAddress, ValAddress)`
- called when a validator is bonded
- `AfterValidatorBeginUnbonding(Context, ConsAddress, ValAddress)`
- called when a validator begins unbonding
- `BeforeDelegationCreated(Context, AccAddress, ValAddress)`
- called when a delegation is created
- `BeforeDelegationSharesModified(Context, AccAddress, ValAddress)`
- called when a delegation's shares are modified
- `BeforeDelegationRemoved(Context, AccAddress, ValAddress)`
- called when a delegation is removed
x/staking/spec/README.md
+3 -3
View File
@@ -11,7 +11,7 @@ parent:
This paper specifies the Staking module of the Cosmos-SDK, which was first
described in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper)
in June 2016.
in June 2016.
The module enables Cosmos-SDK based blockchain to support an advanced
Proof-of-Stake system. In this system, holders of the native staking token of
@@ -45,9 +45,9 @@ network.
- [MsgBeginRedelegate](03_messages.md#msgbeginredelegate)
4. **[Begin-Block](04_begin_block.md)**
- [Historical Info Tracking](04_begin_block.md#historical-info-tracking)
5. **[End-Block ](05_end_block.md)**
5. **[End-Block](05_end_block.md)**
- [Validator Set Changes](05_end_block.md#validator-set-changes)
- [Queues ](05_end_block.md#queues-)
- [Queues](05_end_block.md#queues-)
6. **[Hooks](06_hooks.md)**
7. **[Events](07_events.md)**
- [EndBlocker](07_events.md#endblocker)
x/upgrade/spec/01_concepts.md
+2 -3
View File
@@ -57,10 +57,9 @@ or if the binary was upgraded too early, the node will gracefully panic and exit
## StoreLoader
The `x/upgrade` module also facilitates store migrations as part of the upgrade. The
`StoreLoader` sets the migrations that need to occur before the new binary can
successfully run the chain. This `StoreLoader` is also application specific and
`StoreLoader` sets the migrations that need to occur before the new binary can
successfully run the chain. This `StoreLoader` is also application specific and
not defined on a per-module basis. Registering this `StoreLoader` is done via
`app#SetStoreLoader` in the application.
x/upgrade/spec/02_state.md
+3 -3
View File
@@ -7,9 +7,9 @@ order: 2
The internal state of the `x/upgrade` module is relatively minimal and simple. The
state contains the currently active upgrade `Plan` (if one exists) by key
`0x0` and if a `Plan` is marked as "done" by key `0x1`. The state
contains the consensus versions of all app modules in the application. The versions
are stored as big endian `uint64`, and can be accessed with prefix `0x2` appended
by the corresponding module name of type `string`. The state maintains a
contains the consensus versions of all app modules in the application. The versions
are stored as big endian `uint64`, and can be accessed with prefix `0x2` appended
by the corresponding module name of type `string`. The state maintains a
`Protocol Version` which can be accessed by key `0x3`.
- Plan: `0x0 -> Plan`