Closed m-i-k-e closed 2 weeks ago
network group
are voted on by DReps and CCeconomic group
are voted on by DReps and CCtechnical group
are voted on by DReps and CCgovernance group
are voted on by DReps and CCsecurity group
are voted on by DReps, CC and SPOsFor example;
Changing the the DRep deposit to 100 ADA
dRepDeposit
<= 100
adaedcd84c10e36ae810dc50847477083069db796219b39ccde790484e0
fc0386f81025d66fc448d4f0aa3ca6c1eeae95fe88e3b10244bacc126bbeb007#0
Maybe a history of parameter changes would be nice, well, almost essential in the long run.
Questions:
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 }
Example values:
Next step;
cc @bosko-m
Example input for protocol parameter changes
Current values
"maxBlockBodySize": 90112,
"maxBlockExecutionUnits": {
"memory": 62000000,
"steps": 20000000000
},
New values
"maxBlockBodySize": 90112,
"maxBlockExecutionUnits": {
"memory": 500000000,
"steps": 40000000000
},
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.
@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?
@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
This has been passed to @kgrzonka to work up in a Figma branch
@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.
Verified on Sancho.
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"
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?
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
What?
Why?
How?
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: