State
Proposals
Proposal objects are used to tally votes and generally track the proposal's state. They contain an array of arbitrary sdk.Msg's which the governance module will attempt to resolve and then execute if the proposal passes. Proposal's are identified by a unique id and contains a series of timestamps: submit_time, deposit_end_time, voting_start_time, voting_end_time which track the lifecycle of a proposal
// Proposal defines the core field members of a governance proposal.
message Proposal {
uint64 id = 1;
repeated google.protobuf.Any messages = 2;
ProposalStatus status = 3;
// final_tally_result is the final tally result of the proposal. When
// querying a proposal via gRPC, this field is not populated until the
// proposal's voting period has ended.
TallyResult final_tally_result = 4;
google.protobuf.Timestamp submit_time = 5 [(gogoproto.stdtime) = true];
google.protobuf.Timestamp deposit_end_time = 6 [(gogoproto.stdtime) = true];
repeated cosmos.base.v1beta1.Coin total_deposit = 7 [(gogoproto.nullable) = false];
google.protobuf.Timestamp voting_start_time = 8 [(gogoproto.stdtime) = true];
google.protobuf.Timestamp voting_end_time = 9 [(gogoproto.stdtime) = true];
// metadata is any arbitrary metadata attached to the proposal.
string metadata = 10;
}A proposal will generally require more than just a set of messages to explain its purpose but need some greater justification and allow a means for interested participants to discuss and debate the proposal. In most cases, it is encouraged to have an off-chain system that supports the on-chain governance process.
To accommodate for this, a proposal contains a special metadata field, a string, which can be used to add context to the proposal. The metadata field allows custom use for networks, however, it is expected that the field contains a URL or some form of CID using a system such as IPFS. To support the case of interoperability across networks, the SDK recommends that the metadata represents the following JSON template:
This makes it far easier for clients to support multiple networks.
The metadata has a maximum length that is chosen by the app developer, and passed into the gov keeper as a config. The default maximum length in the SDK is 255 characters.
Writing a module that uses governance
There are many aspects of a chain, or of the individual modules that you may want to use governance to perform such as changing various parameters. This is very simple to do. First, write out your message types and MsgServer implementation.
Add an authority field to the keeper which will be populated in the constructor with the governance module account: govKeeper.GetGovernanceAccount().GetAddress(). Then for the methods in the msg_server.go, perform a check on the message that the signer matches authority. This will prevent any user from executing that message.
Parameters and base types
Parameters define the rules according to which votes are run. There can only be one active parameter set at any given time. If governance wants to change a 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
VotingParams
TallyParams
Parameters are stored in a global GlobalParams KVStore.
Additionally, we introduce some basic types:
Deposit
ValidatorGovInfo
This type is used in a temp map when tallying
Stores
Note: Stores are KVStores in the multi-store. The key to find the store is the first parameter in the list
We will use one KVStore Governance to store two mappings:
A mapping from
proposalID|'proposal'toProposal.A mapping from
proposalID|'addresses'|addresstoVote. This mapping allows us to query all addresses that voted on the proposal along with their vote by doing a range query onproposalID:addresses.A mapping from
ParamsKey|'Params'toParams. This map allows to query all x/gov params.
For pseudocode purposes, here are the two function we will use to read or write in stores:
load(StoreKey, Key): Retrieve item stored at keyKeyin store found at keyStoreKeyin the multistorestore(StoreKey, Key, value): Write valueValueat keyKeyin store found at keyStoreKeyin the multistore
Proposal Processing Queue
Store:
ProposalProcessingQueue: A queuequeue[proposalID]containing all theProposalIDsof proposals that reachedMinDeposit. During eachEndBlock, all the proposals that have reached the end of their voting period are processed. To process a finished proposal, the application tallies the votes, computes the votes of each validator and checks if every validator in the validator set has voted. If the proposal is accepted, deposits are refunded. Finally, the proposal contentHandleris executed.
And the pseudocode for the ProposalProcessingQueue:
Legacy Proposal
A legacy proposal is the old implementation of governance proposal. Contrary to proposal that can contain any messages, a legacy proposal allows to submit a set of pre-defined proposals. These proposal are defined by their types.
While proposals should use the new implementation of the governance proposal, we need still to use legacy proposal in order to submit a software-upgrade and a cancel-software-upgrade proposal.
More information on how to submit proposals in the client section.