Rendering Protocol Parameter Change Governance Actions

m-i-k-e commented 1 month ago

What?

GovTool should show voters the on-chain details for Protocol Parameter Change Governance Actions
Extra contextual information about what the current value of the parameter is, should be used to give context to proposed change.

Why?

This is important information that will help inform the voters
Protocol parameter changes are available in the bootstrapping phase

How?

@m-i-k-e and team design how this could be rendered
GovTool BE API adjusted to provide this information
GovTool FE adjusted to render this new information

User Story

Title: Render all relevant all on-chain details of protocol parameter changes.

User Story: As a DRep, I want to be able to see all the relevant on-chain information for protocol parameter changes, including what parameters are being changed from what current value to the new proposed value.

Acceptance Criteria:

Given that I am a DRep.
When I view a protocol parameter change proposal in GovTool.
Then I should see all relevant on-chain details, including:
- The specific parameters being modified.
- Their current values.
- The proposed new values.

Ryun1 commented 1 month ago

What is this action all about?

Allows changing of any updatable protocol parameters
Changes to (more details)
- network group are voted on by DReps and CC
- economic group are voted on by DReps and CC
- technical group are voted on by DReps and CC
- governance group are voted on by DReps and CC
- security group are voted on by DReps, CC and SPOs
Available within bootstrapping phase, but only voted on by CC in this phase.
- will be done by core team in bootstrapping
- Really only an emergency measure, incase something has to be changed

What are the on-chain details?

governance action ID of the previous protocol parameter change to be enacted (this isnt super important, but shows users how protocol parameters change/order of changes)
The script hash of the guardrails script applied (this is unlikely to change between actions so may not be 100% required to always be shown)
The value of the parameter(s) being changed
- this can be integers / floats / etc - this makes it much more complex

For example;

Changing the the DRep deposit to 100 ADA

(param being changed) dRepDeposit <= 100 ada
guardrailsScriptHash = edcd84c10e36ae810dc50847477083069db796219b39ccde790484e0
prevGovActID = fc0386f81025d66fc448d4f0aa3ca6c1eeae95fe88e3b10244bacc126bbeb007#0

What is other contextual information that might be nice?

What group these parameters are in
The current values of the parameter(s) being changed (what is the current value of DRep deposits? is this a big change?)
When these parameters were last changed (has the community already voted for similar changes?)

m-i-k-e commented 1 month ago

Maybe a history of parameter changes would be nice, well, almost essential in the long run.

m-i-k-e commented 1 month ago

Questions:

Does the GuardRails Script need to be shown?
What about by default listing somewhere the values of all parameters?
Should we show a link to the (current and previous) transactions?
Is this going to be a votable or just for viewing purposes in the bootstrapping phase?

Ryun1 commented 1 month ago

Changable protocol params

{ "minfee_a": null, "minfee_b": null, "max_block_body_size": null, "max_tx_size": null, "max_block_header_size": null, "key_deposit": "0", "pool_deposit": null, "max_epoch": null, "n_opt": null, "pool_pledge_influence": null, "expansion_rate": null, "treasury_growth_rate": null, "d": null, "extra_entropy": null, "protocol_version": null, "min_pool_cost": null, "ada_per_utxo_byte": null, "cost_models": null, "execution_costs": null, "max_tx_ex_units": null, "max_block_ex_units": null, "max_value_size": null, "collateral_percentage": null, "max_collateral_inputs": null, "pool_voting_thresholds": null, "drep_voting_thresholds": null, "min_committee_size": null, "committee_term_limit": null, "governance_action_validity_period": null, "governance_action_deposit": null, "drep_deposit": null, "drep_inactivity_period": null, "ref_script_coins_per_byte": null }

Ryun1 commented 1 month ago

Example values:

params.json

Ryun1 commented 1 month ago

Next step;

wireframes by Friday (@m-i-k-e)

cc @bosko-m

Ryun1 commented 1 month ago

Example input for protocol parameter changes

https://governance-govtool.cardanoapi.io/

Ryun1 commented 1 month ago

Current values

"maxBlockBodySize": 90112,
"maxBlockExecutionUnits": {
    "memory": 62000000,
    "steps": 20000000000
},

New values

"maxBlockBodySize": 90112,
"maxBlockExecutionUnits": {
    "memory": 500000000,
    "steps": 40000000000
},

m-i-k-e commented 1 month ago

I think this is the best solution. Two tabs to show the code diff.

Will not work very well on mobile, but could be adapted to display vertically. No one uses github diff on a phone, I bet.

parameter change

l-br1 commented 1 month ago

@m-i-k-e how will this work on mobile? Is it worth adding this just to support one type of governance action (and just one type of parameter change?)?

Do we know if users who will want to vote on this type of parameter change will use this?

m-i-k-e commented 1 month ago

@l-br1

Is it worth adding this just to support one type of governance action? Do you mean by 'one type of governance action' parameter actions? We are supporting Info (read/write) Treasury, and parameter actions (read only) in bootstrapping.

(and just one type of parameter change?)? I can't see any subsetting of parameter changes. Maybe I'm wrong here, but they all seem to be a load of JSON. I'll ask @Ryun1

m-i-k-e commented 1 month ago

This has been passed to @kgrzonka to work up in a Figma branch

m-i-k-e commented 3 weeks ago

@MSzalowski This is done in Figma now: https://www.figma.com/design/mJTBiUofLfb74Xc3W2U59o/Voltaire---GOV-TOOL?m=auto&node-id=14774-93035&t=hLlpXMOe0RpGkeDc-1

Note: the side-by-side code concept is a screenshot from GitHub. I realise that you need to use some plug-in or library, so it's OK if it varies. However, what it needs to do is clearly show that there are "Existing" and "Proposed" columns in a classic split view. This does also work on mobile, but it's not as great. Please get in touch with me when you are ready to test the design and I'll work with you to get a good result.

bosko-m commented 2 weeks ago

Verified on Sancho.

bosko-m commented 2 weeks ago

Reopening issue @MSzalowski to clarify after the discussion with @Ryun1 . For this one: https://sanchogov.tools/connected/governance_actions/84fe1da5d14450537db36c28ffe2a1a4878f501fc26c998bba54e396711205bc#0 Quoting @Ryun1 : "the values are wrong, the data on the left has some junk in it"

MSzalowski commented 2 weeks ago

Values are not exactly wrong. This GA updated optimal_pool_count to 1000 which is presented in a diff. However, diff presents also other values like id, nonce and some other that should not be considered as the parameter change proposal.

Is that correct @Ryun1?

Ryun1 commented 2 weeks ago

Values are not exactly wrong.

Agreed

However, diff presents also other values like id, nonce and some other that should not be considered as the parameter change proposal.

Is that correct @Ryun1?

Yup these should not be shown to the user IMO Im not sure where these values came from as they arent protocol parameters

IntersectMBO / govtool