Jul 6, 2023 | Voltaire era: Parameter committee intermediate state

Governance Parameters Committee Updates
1

Hi all,
Here are the notes from the previous meeting, held on July 6th. Sorry for the delay but we have been very busy at the CIP-1694 Workshop in Edinburgh.

The Parameter Committee (interim state) meets on a tri-weekly basis. Its members are a mix of different Cardano community members. The Parameter Committee discusses all parameters relating to the Cardano protocol including network, technical and economic parameter type. They are a technical advisory group and only make recommendations.

Updated list of the Members (interim state):

Chairs:
Chair: Kevin Hammond
Vice- chair: Alex Moser
Vice- chair: Vijay Bhuvangiri

Advisory Group Heads:
Network group: Neil Davies
Economic group: Samuel Leathers
Technical group: Markus Gufler

Advisory Group Members:
Network group: Karl Knutson, Matthias Sieber, Marcin Szamotulski
Technical group: Ruslan Dudin, Michael Peyton Jones
Economic group: Sergio Sanchez, Philip Lazos, Giovanni Gargiulo

Other:
Communications: Tommy Kammerer, Nathaniel Acton, Addie Girouard, Matthew Capps
Domain experts: Martin Lang, Andrew Westberg
Observers: WIP
Secretary: Joaquín López

Agenda and Updates:

Agenda:

  • Committee membership changes: Cristina, Becky are leaving and Joaquin, Matthew are nominated as replacements:
    • Joaquin Lopez is proposed as secretary, introduction to the team
    • Matthew Capps is proposed for communications, introduction to the team
  • Confirm that advisory groups are active
  • To receive reports from each advisory group on k and minPoolCost, to discuss these, and then to make a recommendation if possible
    • Consider whether a recommendation can be made on reducing minPoolCost by 50% (to 170 ada per epoch) now, and to take input on whether this is the best value for minPoolCost
    • To consider whether a recommendation can be made on increasing k (targetNumberOfPools)
    • To confirm that independent decisions can be taken on the two parameters

Updates:

  • All three advisory groups are up and running, having meetings and discussing PCP 001.

    • The Network Advisory Group has been monitoring the network performance and didn’t find any concerns.
    • The Technical Advisory Group has been discussing the need for more feedback about increasing the k parameter and considering decreasing the minPoolCost parameter
    • The Economic Advisory Group has been discussing Mempool saturation and the effects of changing the k parameter.

  • Reports on PCP 001 are still in preparation but all the advisory groups have made significant progress on discussing both k and minPoolCost, including considering the community input from the SPO poll.

  • There is a relationship between the k parameter and the minPoolCost. Changing both parameters drastically and at the same time could have unexpected and potentially negative effects on the economics of stake pool operation. As long as the number of pools doesn’t change dramatically, we see no big effects on the operational performance of the network.

  • The committee recommended decreasing the minPoolCost parameter to 170 Ada per epoch in line with the results of the SPO poll, and monitoring the effects of changing this parameter. Once the effects on the network and stake pools have been analyzed, further changes to either or both parameters can be considered.

  • Votes in favor of decreasing the minPoolCost parameter: all.

    • Votes against decreasing minPoolCost parameter: none.

  • Votes in favor of keeping k at 500 (for the near future): all.

    • Votes against keeping k at 500 (for the near future): none.

Action items

  • Community relations team to be consulted
  • Joaquín to summarize the outcomes of the meeting.
  • Consult with research team
4 Likes
2

Hello, thanks for the write-up Joaqin and welcome aboard.

We were promised by @Kevin_Hammond an update from the IOG research department on the subject of pledge effectiveness. I also see no comments/responses in regards to Jun 8, 2023 | Voltaire era: Parameter committee intermediate state - #9 by Homer_J - again, about information posted by IOG in the past related to research.

I also do not see anything in above summary about analysis of SPO comments and plans to have an improved SPO survey v2. You know, so maybe we can come up with a community plan not involving changing one magic number to a smaller magic number.

Where can we find out more about ‘effects of k parameter changing on Mempool saturation’ discussions?

What exactly was Network Advisory Group monitoring that was related to the proposed parameter changes?

How can changing minPoolCost drastically have negative effect on economics of stake pool operation - please elaborate, is this the ‘everybody will start running their pools at a loss on cheap hardware to try and get higher rankings in wallets’ argument? Something a bit more concrete backed by data would be appreciated - as current inferior ROI by new starting out or smaller pools is not something that’s up for debate, I hope.

10 Likes
3

It would be great if we could capture some of the meat of the discussion in these notes or somewhere else if that is too low level for this venue. It looks like everyone voted in favor of lowering minPoolCost, but there is no analysis of why from the economic standpoint. It seems fair to say the poll is not a sufficient reason by itself, and other reasons were likely discussed before a vote took place, but none of that seems to be revealed here. I think the community will digest the recommendation better if they are brought along for the discussion rather than forced into a take or leave it recommendation at the end

4

Hi Homer

I’ve passed the pledge issue on to the research team to consider. We’d expect them to need to consider the whole incentives scheme, but that is a broader issue. This will then feed into the CPS
process, I expect.

We’re waiting for the full analysis of SPO comments, which I am expecting to be very informative
in terms of community aspirations.

5

which research team? This one =>

" The current structure of the rewards formula does not give us the flexibility to tweak the impact by a simple parameter change; we will need to modify the rewards formula, which is something our research team has been working on for some time.

Several promising candidates have come out of that evaluation process…

Our research team is in the late stages of finalizing an approach. They will soon present their findings, and we will update the community then. However, the team has now concluded that a0 should change."

or did they all move on to other tasks back in 2021 (when the above lines were written) and there are new faces now who’ll be starting afresh?

2 Likes
6

Thanks for the update. When can we expect the changes to be implemented?

2 Likes
7

It seems my comments here Jun 8, 2023 | Voltaire era: Parameter committee intermediate state - #31 by earncoinpool were ignored.

This update just raises more questions. For example it says

Who is all? Every member listed? Are all members listed voting members? If so where are the disclosures? How many members are pool operators? How many are MPOs? How many are single pools? How many voted in the poll? How did they vote?

How can this be said?

Once again, the poll showed by all metrics that the community wanted K to be increased 1,000 and min fee to be reduced to 170.

poll_results_number_SPOs
pool_results_by_pledge
pool_results_by_stake
pool_results_number_delegators
pool_results_number_pools

3 Likes
8

How to foster apathy through disenfranchisement - encourage people to spend considerable time upgrading infrastructure to vote only to ignore the clear result.

How does this encourage voter engagement?

6 Likes
9

Agreed, discussion feels opaque.

Ethereum Protocol and Foundation calls (Consensus, Dev, EIP, Community, Implementer, etc.) are recorded and public for transparency.

We have room for improvement in that regard.

1 Like
10

There actually was one metric that had a slight preference for keeping k at 500:
screenshot-2023-07-21-03:11:43

But really only one and only very slightly, the other metrics show preference for k=1000 even when grouping by parameters:

screenshot-2023-07-21-03:13:35
screenshot-2023-07-21-03:13:351693×645 129 KB

1 Like
11

That’s what I had thought. @earncoinpool calls into question the accuracy of grouping by parameter. Jun 8, 2023 | Voltaire era: Parameter committee intermediate state - #31 by earncoinpool

3 Likes
12

This seems reasonable to me. Changing one parameter at a time seems logical. However, how much time to analyze are we talking? 5 epochs, 10…a ballpark estimate at least.

This is also a very good point. Transparency and openess are always preferred.

It seems at times like open communication is always a little hit or miss which just leaves room for frustration and speculation.

13

Hi @Joaquin,

Thank you for the update. This recommendation from the committee comes rather unexpected given the votes cast by the SPO community.

I agree with the general principle of changing one parameter at a time, although changing k seems to me more in line with the current state of the network.

As others have commented already, including Rich @earncoinpool, it would be auspicabile to get a bit more clarity on the committee’s composition and how it came to be.

This is a rather important first step toward Voltaire, some growing pains are to be expected, but overall it appears that the committee has ignored the SPO vote. This will need to be ironed out going forward IMO.

:facepunch:

3 Likes
14

For those who anticipated that the SPO poll results would be the definitive and sole factor to determine which changes to implement, I want to highlight a few crucial points:

  1. The poll took place before the Voltaire era, and there is no established formula to decide the votes. Therefore, it remains undecided whether we should consider stake-based results, number of SPO votes, number of delegators, amount of pledge, or a combination of these metrics. Any arguments based on using one or a combination of these metrics overlook this fact.

  2. Even if we knew which metrics of the poll results would determine the outcome, there was no quorum to decide if the poll could be used at all.

  3. Additionally, there were no threshold rules in place to determine when a certain outcome would prevail over others, like requiring K=1000 to have x% more votes than K=500.

Overall, it was clear that this poll could not objectively decide the actual changes. Thus, the final decision would need to be made by subjective parties such as the committee and the founding members, relying on the poll as one input among others and incorporating their views and expertise.

Moving forward, I would like to emphasize that the poll results show overwhelming support for lowering minpoolcost, regardless of how one interprets the data. Furthermore, no convincing arguments against reducing these fees have been presented. Therefore, deciding to lower the minpoolcost appears to be a clear choice.

However, the case for increasing K was not as straightforward. The poll results did not show overwhelming support for this change from all aspects. Moreover, there have been multiple compelling arguments against increasing K, which I personally support. I provided an elaborate and quantitative analysis to illustrate why increasing K might not be the obvious choice. You can find the analysis on the forum here:

Despite sharing this analysis, it received no comments. Taking into account all these factors and setting aside political arguments – as I am not politically inclined (i.e., committee members’ personal votes, the criteria for members’ selection, and the lack of transparency in meeting reporting) – I concur with the committee’s recommendations.

3 Likes
15

I tend to agree, but would at least like to point out that not only large and multi pool operators (allegedly to secure against competition) have argued for keeping minPoolCost (or at least not going further to 0, which is not on the table right now), but also some small or medium pool operators.

If you have somehow managed to get in the range of around 1 block per epoch (despite the minPoolCost making much larger pools more attractive) and figure that you will manage that you will stay in that range, reducing minPoolCost will likely put a pressure on you to reduce the actual poolCost. And that will reduce your earnings quite substantially, since in that range you get little out of poolMargin.

So, the argument would be that minPoolCost ensures that pools producing just few blocks can be run sustainably.

I, personally, don’t support that argument, since the level playing field seems much more important to me, but it should at least be recognised that it doesn’t have to be anti-competition by the large players.

16

I think minPoolCost should be decreased in line with the decrease in staking rewards, but it should be done “gradually” considering the impact on the pool’s sustainability.

In the SPO poll., there were only two extreme choices, either maintaining the current level or reducing it by half, but the middle range should have been included as an option.

Changing parameters based on the results of the SPO poll which are determined according to the two extreme choices provided by the Foundation for each parameter, feels like too much intervention by the Foundation.
i think the results of the SPO poll are not worthy of being used as a reference for parameter determination.

I am not sure why The Parameter Committee is also trying to decide on two choices for each parameter.

1 Like
17

You do understand that lowering the minPoolCost parameter doesn’t impact any pool owner’s rewards directly/immediately after the change is rolled out, right? And what exactly is the purpose behind the reduction of minPoolCost parameter being proposed in the first place?

Re ‘in line with decrease in staking rewards’ - compared to mainnet launch, what fraction of original per-block reward is the current per-block reward?

1 Like
18

Let me first say that what I am trying to argue is that there are more abundant options to choose from, not just two choices: maintain the status quo or cut it in half at once.

compared to mainnet launch, what fraction of original per-block reward is the current per-block reward?

https://cexplorer.io/supply
I used the above URL as a reference.
The initial unsupplied ADA is 13.89B₳.
And now the ADA supply has increased by 4,89B₳ from the initial period.
The percentage of ADA supplied is
4,89B₳ / 13.89B₳ =0.352…
The remaining unsupplied ADA today is about 65% and the current amount of reward compared to the initial is a similar percentage.
These are my perceptions.
(Sorry if there are any errors in my understanding)

However, this does not take into account the fact that the network’s transaction fees are added to the reward.
Also, I do not intend to argue for the reward reduction rate and minPoolCost reduction rate should match perfectly.

And what exactly is the purpose behind the reduction of the minPoolCost parameter being proposed in the first place?

Currently, the total reward for a pool generating one block per epoch is about 495 ADA.
Subtracting the minPoolCost of 340 ADA from this, even with a 0% pool, the delegator is left with about 155 ADA.
If this is a pool that generates 50 blocks per epoch, the total reward is about 24,900 ADA.
Subtracting the minPoolCost of 340 ADA from this, the total compensation remaining to the delegator for a 0% pool is 24,560 ADA.

Reward for pool generating 1 block
155ADA / 495ADA = 0.313…
Reward for pool generating 50 blocks
24,560ADA / 24,900ADA = 0.986…

The minPoolCost 340ADA accounts for a larger percentage of the overall reward in the small pool, and the delegator’s reward is less than in the large pool.
delegators knowing this, may avoid delegating to small pools and concentrate their delegations in large pools.
As rewards decrease over time, this percentage increases even more.
If minPoolCost remains high, it may inhibit decentralization and should be lowered.
However, the minPoolCost should be lowered “gradually” because we do not know the impact of reduced SPO rewards,.

1 Like
19

Dear Vahid @ADA4Good thank you for your input,

I hope it will provide a good spark for further discussion here. I must admit I was not aware of your linked visual tool until now. Nice work. I will try to breakdown my thoughts in regards to your contribution:

  1. The poll took place before the Voltaire era, and there is no established formula to decide the votes. Therefore, it remains undecided whether we should consider stake-based results, number of SPO votes, number of delegators, amount of pledge, or a combination of these metrics. Any arguments based on using one or a combination of these metrics overlook this fact.
  2. Even if we knew which metrics of the poll results would determine the outcome, there was no quorum to decide if the poll could be used at all.
  3. Additionally, there were no threshold rules in place to determine when a certain outcome would prevail over others, like requiring K=1000 to have x% more votes than K=500.

I agree wholeheartedly here, the vote worked well technically but very few guidelines (if any) had been provided regarding the interpretation needs after the vote.

I must say I was not expecting the amount of participation that we saw: the number of voting pools amounted to nearly 800. Referendums get passed with as little as 50% of voters voting, so whether this is a quorum or not would have to be determined based on how you count the total number of pools. Do we count the total registered? Do we count the ones which have minted at least one block in their lifetime? Further, as others have pointed out, this good participation might struggle to be maintained if voters feel like their votes were for nought.

However, the case for increasing K was not as straightforward. The poll results did not show overwhelming support for this change from all aspects. Moreover, there have been multiple compelling arguments against increasing K, which I personally support. I provided an elaborate and quantitative analysis to illustrate why increasing K might not be the obvious choice. You can find the analysis on the forum here:

Your visualisation of the effects of k changes is quite something: A visualization of Pools and effects of K=1000 and everyone should be encouraged to take the time and have a look. Nevertheless, like all analyses, it contains an inherent bias once interpreted. This is not a criticism, merely an observation coming from someone who’s livelihood has been scientific research for years. The bias is human, as we often bend data and stats to align with the question we are asking. To your credit you did acknowledge the potential for bias in your write up.

I won’t go into MPO vs SPO at all, but consider k as what it represents and has the potential to do to the network. It’s effects naturally assume redelegation, absence of further pool splitting and many other human behaviours which are hard to predict. However, I think just because affected (only from the perspective of becoming oversaturated) pools are fewer than non-affected ones, this does not mean it would be an change without value. Your tool shows 139 pools would be affected, which is a pretty large number.

Further, as k determines the saturation level of pools, it follows that its value represents the ideal number of saturated pools. Given that currently more than 1000 pools have minted at least one block in their lifetime, IMO k should be set at 1000 in one go, as it is not a parameter that likes to change gradually (every time one changes it, delegates have to do something). This has been illustrated quite well by domain experts:

https://iohk.io/en/blog/posts/2018/10/23/stake-pools-in-cardano/

https://iohk.io/en/blog/posts/2020/11/13/the-general-perspective-on-staking-in-cardano/

https://iohk.io/en/blog/posts/2020/11/05/parameters-and-decentralization-the-way-ahead/

https://iohk.io/en/blog/posts/2022/10/27/staking-parameters-and-network-optimization-where-next-for-k-and-min-fee/

Looking forward to your thoughts, with love and respect :love_you_gesture:

2 Likes
20

You didn’t answer my question about per block rewards.

Using adastat.net, picking a couple of pools that produced same number of blocks in the early Shelley era days vs recent epoch:

epoch 219
A randomly picked pool made 65 blocks - ₳102,231 rewards, ₳3231 pool fee

epoch 421
Pool made 65 blocks - ₳26,218 rewards, ₳2620 pool fee

So overall rewards are about 1/4 of what they were 200 epochs ago when minFixedCost was first rolled out.

You seem to understand why minPoolCost lowering is being proposed, but your ‘do not know the impact of reduced SPO rewards’ makes it sound like you think lowering this parameter means every SPO starts getting less Ada immediately as soon as the change comes into effect.

I can have a quick crystal ball guess as to what will happen when its rolled out: a small subset of pools will adjust their fixed costs setting in pool certificate and see how it affects their wallet rankings/affect delegator movements, majority of the pools (especially behemoths like Binance/Coinbase) will not. It probably would have been nice if IOG lowered this setting to zero in one of the testnet so one could have a play with that experiment using existing wallets today (although obviously effectiveness of such experiment in testnet is also a bit limited given pool quantity/major discrepancies between it and mainnet pool cohort/composition)

1 Like