da36c46f3a
## Description Closes: #11092 ## TODOs I'm thinking to do the 2 todos in a separate PR, or else this PR is too big. WDYT? - [ ] #11246 This involves adding a new index ProposalsByVotingPeriodEnd, so might be better to do in another PR - [ ] #11245 Also should be done in a separate PR (as it needs the above index) ### Main change 1: Group policy proto defs have `voting_period` and `min_execution_period` For group policies: ```diff - // Within this times votes and exec messages can be submitted. - // timeout is the duration from submission of a proposal to the end of voting period - google.protobuf.Duration timeout = 2 [(gogoproto.stdduration) = true, (gogoproto.nullable) = false]; + // voting_period is the duration from submission of a proposal to the end of voting period + // Within this times votes can be submitted with MsgVote. + google.protobuf.Duration voting_period = 2 [(gogoproto.stdduration) = true, (gogoproto.nullable) = false]; + // min_execution_period is the minimum duration after the proposal submission + // where members can start sending MsgExec. This means that the window for + // sending a MsgExec transaction is: + // `[ submission + min_execution_period ; submission + voting_period + max_execution_period]` + // where max_execution_period is a app-specific config, defined in the keeper. + // If not set, min_execution_period will default to 0. + google.protobuf.Duration min_execution_period = 3 [(gogoproto.stdduration) = true, (gogoproto.nullable) = false]; ``` ### Main Change 2: We don't update proposal's FinalTallyResult result on MsgVote/MsgSubmitProposal Unless the msg has TryExec set to true, in which case the FinalTallyResult is updated ONLY if the tally is final. ### Main Change 3: Add a keeper-level `MaxExecutionPeriod` MsgExecs will be rejected if they are sent after `voting_period_end + MaxExecutionPeriod` --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [ ] reviewed "Files changed" and left comments if necessary - [ ] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable) |
||
|---|---|---|
| .. | ||
| auth | ||
| authz | ||
| bank | ||
| capability | ||
| crisis | ||
| distribution | ||
| epoching | ||
| evidence | ||
| feegrant | ||
| genutil | ||
| gov | ||
| group | ||
| mint | ||
| nft | ||
| params | ||
| simulation | ||
| slashing | ||
| staking | ||
| upgrade | ||
| README.md | ||
README.md
List of Modules
Here are some production-grade modules that can be used in Cosmos SDK applications, along with their respective documentation:
- Auth - Authentication of accounts and transactions for Cosmos SDK applications.
- Authz - Authorization for accounts to perform actions on behalf of other accounts.
- Bank - Token transfer functionalities.
- Capability - Object capability implementation.
- Crisis - Halting the blockchain under certain circumstances (e.g. if an invariant is broken).
- Distribution - Fee distribution, and staking token provision distribution.
- Epoching - Allows modules to queue messages for execution at a certain block height.
- Evidence - Evidence handling for double signing, misbehaviour, etc.
- Feegrant - Grant fee allowances for executing transactions.
- Governance - On-chain proposals and voting.
- Mint - Creation of new units of staking token.
- Params - Globally available parameter store.
- Slashing - Validator punishment mechanisms.
- Staking - Proof-of-Stake layer for public blockchains.
- Upgrade - Software upgrades handling and coordination.
To learn more about the process of building modules, visit the building modules reference documentation.
IBC
The IBC module for the SDK has moved to its own repository.