Improve the Gov Module Mechanism by BLV Labs #529

TuSoict · 2024-10-28T07:47:45Z

Spec or proposal link: https://commonwealth.im/terra-luna-classic-lunc/discussion/24630-proposal-to-improve-the-gov-module-mechanism-by-blv-labs

sidebar_position: 1

`x/gov`

Custom Governace Module Updates

Concepts

Disclaimer: This is work in progress. Mechanisms are susceptible to change.

The governance process is divided in a few steps that are outlined below:

Proposal submission: Proposal is submitted to the blockchain with a
deposit.
Vote: When the deposit for a proposal reaches a minimum threshold equivalent to
500 USD (MinUusdDeposit), proposal is confirmed and vote opens.
Execution After a period of time, the votes are tallied and depending
on the result, the messages in the proposal will be executed.

Proposal submission

Right to submit a proposal

Every account can submit proposals by sending a MsgSubmitProposal transaction.
Once a proposal is submitted, it is identified by its unique proposalID.

Proposal Messages

A proposal includes an array of sdk.Msgs which are executed automatically if the
proposal passes. The messages are executed by the governance ModuleAccount itself. Modules
such as x/upgrade, that want to allow certain messages to be executed by governance
only should add a whitelist within the respective msg server, granting the governance
module the right to execute the message once a quorum has been reached. The governance
module uses the MsgServiceRouter to check that these messages are correctly constructed
and have a respective path to execute on but do not perform a full validity check.

Deposit

To prevent spam, proposals must be submitted with a deposit in the coins defined by the equation luncMinDepositAmountBasedOnUusd = MinUusdDeposit / real-time price of LUNC at the time of proposal submission.

github.com/classic-terra/core/v3/custom/gov/keeper/proposal.go#L136-L149

The value of luncMinDepositAmountBasedOnUusd will be stored in KVStores, using a key defined as UUSDMinKeyPrefix|proposalID, where the proposal ID is appended to the prefix, represented as a single byte.

github.com/classic-terra/core/v3/custom/gov/types/keys.go#L20-L22

When a proposal is submitted, it has to be accompanied with a deposit that must be
strictly positive, but can be inferior to luncMinDepositAmountBasedOnUusd. The submitter doesn't need
to pay for the entire deposit on their own. The newly created proposal is stored in
an inactive proposal queue and stays there until its deposit passes the luncMinDepositAmountBasedOnUusd.
Other token holders can increase the proposal's deposit by sending a Deposit
transaction. If a proposal doesn't pass the luncMinDepositAmountBasedOnUusd before the deposit end time
(the time when deposits are no longer accepted), the proposal will be destroyed: the
proposal will be removed from state and the deposit will be burned (see x/gov EndBlocker).
When a proposal deposit passes the luncMinDepositAmountBasedOnUusd threshold (even during the proposal
submission) before the deposit end time, the proposal will be moved into the
active proposal queue and the voting period will begin.

The deposit is kept in escrow and held by the governance ModuleAccount until the
proposal is finalized (passed or rejected).

Deposit refund and burn

When a proposal is finalized, the coins from the deposit are either refunded or burned
according to the final tally of the proposal:

If the proposal is approved or rejected but not vetoed, each deposit will be
automatically refunded to its respective depositor (transferred from the governance
ModuleAccount).
When the proposal is vetoed with greater than 1/3, deposits will be burned from the
governance ModuleAccount and the proposal information along with its deposit
information will be removed from state.
All refunded or burned deposits are removed from the state. Events are issued when
burning or refunding a deposit.

Vote

Voting period

Once a proposal reaches luncMinDepositAmountBasedOnUusd, it immediately enters Voting period. We
define Voting period as the interval between the moment the vote opens and
the moment the vote closes. Voting period should always be shorter than
Unbonding period to prevent double voting. The initial value of
Voting period is 2 weeks.

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 five mappings:

A mapping from proposalID|'proposal' to Proposal.
A mapping from proposalID|'addresses'|address to Vote. This mapping allows
us to query all addresses that voted on the proposal along with their vote by
doing a range query on proposalID:addresses.
A mapping from ParamsKey|'Params' to Params. This map allows to query all
x/gov params.
A mapping from VotingPeriodProposalKeyPrefix|proposalID to a single byte. This allows
us to know if a proposal is in the voting period or not with very low gas cost.
A mapping from UUSDMinKeyPrefix|proposalID to a single byte. This allows us to determine the minimum amount of LUNC that a specific proposal must deposit to pass the deposit phase.

For pseudocode purposes, here are the two function we will use to read or write in stores:

load(StoreKey, Key): Retrieve item stored at key Key in store found at key StoreKey in the multistore
store(StoreKey, Key, value): Write value Value at key Key in store found at key StoreKey in the multistore

Parameters

The governance module contains the following parameters:

Key	Type	Example
min_deposit	array (coins)	[{"denom":"uatom","amount":"10000000"}]
max_deposit_period	string (time ns)	"172800000000000" (17280s)
voting_period	string (time ns)	"172800000000000" (17280s)
quorum	string (dec)	"0.334000000000000000"
threshold	string (dec)	"0.500000000000000000"
veto	string (dec)	"0.334000000000000000"
burn_proposal_deposit_prevote	bool	false
burn_vote_quorum	bool	false
burn_vote_veto	bool	true
min_uusd_deposit	coins	{"denom":"uusd","amount":"500000"}
Currently, the default value of `min_uusd_deposit` is set to `500` usd, but this value can be
updated by the community in the future.

Client

CLI

A user can query and interact with the gov module using the CLI.
We have added two new commands

MinimalDeposit

The MinimalDeposit command enables users to query the minimum LUNC deposit required for a specific proposal, calculated based on the UUSD value.

terrad q gov min-deposit [proposal-id]

Example:

terrad q gov min-deposit 1 cosmos1..

CustomParams

The CustomParams command allows users to query the custom parameters of the module.

terrad q gov custom-params

Example:

terrad q gov custom-params

Future Improvements

We have successfully upgraded the chain by increasing the consensus version to 5. Moving forward,
should the community require updates related to these matters, the BLV Team will be available to
assist with the implementation process.

…lvlabs/dev

in the SubmitProposal function: - Get LUNC price based on UUSD - Calculate the amount of LUNC to send for the proposal during that time - Store the LUNC amount

…odule

…/gov-improve # Conflicts: # custom/gov/keeper/params.go # custom/gov/keeper/proposal.go # custom/gov/types/v2lunc1/query.pb.go

…/gov-improve # Conflicts: # custom/gov/keeper/params.go # custom/gov/types/v2lunc1/query.pb.go

- use empty gas prices for sim tests

TuSoict · 2024-11-07T00:50:24Z

No, this is not what I am referring to. I know what you did by scrolling through the code at least. What I am referring to is the initial deposit necessary to create a proposal at all. This is a percentage of the full deposit amount, currently 20%. So users need to deposit 1M currently or 100$ with your method. But the creation transaction will fail if you provide below that amount, so if the price of LUNC lowers a tiny bit from submitting until confirming the tx … the tx will fail.

in addtion, as per current logic, even 20% or 100% if LUNC price dumps to near 0 then the value of the proposal is very very small around 0.1-0.2$, it can no longer hold 100$. So what do you think?
So do you think it can ensure spam proposal or not?

==> We have read this logic and continue to improve it by:
When creating a proposal, users need to deposit a small amount of 20% first but based on the value of 500$ regardless of LUNC price going up or down.

That means it always ensures the value of the proposal when created is 100$
This is more optimal.

I hope you have a clear view

TuSoict · 2024-11-07T00:52:32Z

No, this is not what I am referring to. I know what you did by scrolling through the code at least. What I am referring to is the initial deposit necessary to create a proposal at all. This is a percentage of the full deposit amount, currently 20%. So users need to deposit 1M currently or 100$ with your method. But the creation transaction will fail if you provide below that amount, so if the price of LUNC lowers a tiny bit from submitting until confirming the tx … the tx will fail.

in addtion, as per current logic, even 20% or 100% if LUNC price dumps to near 0 then the value of the proposal is very very small around 0.1-0.2$, it can no longer hold 100$. So what do you think? So do you think it can ensure spam proposal or not?

==> We have read this logic and continue to improve it by: When creating a proposal, users need to deposit a small amount of 20% first but based on the value of 500$ regardless of LUNC price going up or down.

That means it always ensures the value of the proposal when created is 100$ This is more optimal.

I hope you have a clear view

in this case, if needed we suggest that we provide a CLI that helps users query the required deposit amount when initial deposit
Of course it will be an inaccurate number when the LUNC price fluctuates

- improve fee check handling

…-v8.4

mergify · 2024-11-25T14:35:02Z