I can assure you that we looked at the comments individually and in groups. That was also what was meant when we responded to questions about whether the comments were being paid attention to at all. Of course, because they are a valuable source of ideas from which perspectives certain opinions arise and how to also look at the situation.
But a demand to evaluate these comments in any form and to construct a kind of parallel result I consider to be decidedly fundamentally wrong and absolutely not desirable.
That can - if one absolutely wants, and has a good basis in philosophy and interpretation - gladly take over someone else. Since the idea to make these comments has come from the SPO community, it would actually also be obvious that a corresponding processing comes from there, no?
The analysis assumesâand to be relatively accurate would requireârational behaviour on the part of delegators. I am not sure that is a safe assumption. For example, many delegators do not seem to understand important details of how staking works. That is a challenge of education, not the protocol.
It would be useful to hear how CF and other entities signing off on such a decision may be planning to identify and take responsibility for any negative unforeseen consequences or externalities as they may arise as a result of such a change (as there also have been as a result of introducing a mPC in the first place, as others have described above).
That was maybe the reason why the poll had a second part in the question - which seems to be ignored for some unknown reason: doubling k to 1000. This would solve the problem of re-distribution - at least to some degree. Funny enough, the polled question had both parts in it: k=1000 together with min fee reduction to 170. And that answer got a serious majority. Donât know why someone changed the context and made it 2 questions, when it was only one. I also donât know why increasing k is blocked that massively. It was already planned to be changed to 750 in 2021.
With having about 3000 pools active, setting k to 1000 should not be such a big issue - given that k represents the optimal number of pools. Do we really want the number of pools going down to 500?
Being an operator of a very small pool keeping delegations is absolutely impossible. When you mint a block once in a while - distributing about 130 ADA (and shrinking) to delegators is pointless.
To be more precise: the current setting is going to kill all smaller pools. That is a fact and already happening. The poll and especially the result, made us believe that there is rescue in sight. And now - a couple of month later - all hopes are gone.
Where did you read that? Or is it your interpretation?
Would you prefer satisfying 1000 out of 3000 pools? If yes can you specify which ones (not) ?
Or would you prefer increasing k to have 3000 pools saturated at 13M ada?
If 3000, would you keep a minPoolCost of 340 or 170 ada to multiple the total operative costs per epoch (= way less staking rewards and APY for delegators)
âŚor set it down to 0 minPoolCost for the reasons you mentioned, where each pool then operates at 0-100 ada per epoch operative budget. (= at a loss or very much lowest possible cost infrastructure and maintenance)
Keep in mind independent to such changes the rewards will continue to degrade by logarithmic curve.
Last but not least 4 more questions:
who should define âenoughâ pools for a sufficient decentralisation? Should it be always oriented on how many operators want to have a saturated pool? 1000, 3000, 6000, âŚ
assuming parameters are changed and you end up with one of 1500 saturated pools. Now 1500 more operators want the same and double k again. Would you vote for?
would you ask (poll) bears if they want more money?
3 years after mainnet launch and bootstrapping: do we need more pools or more dapps, integrations, use-cases and transactions?
Need guidance from the Edinburgh decentralisation index research paper and also see answer to 2. below.
There is definitely going to be a trade-off point. If K value is pushed too high, even if minPC is reduced to 0, single pools will make too few blocks to justify even minimal infrastructure costs.
The simple way for operators to mitigate K being pushed too high is for every pool operator to then become a multi-pool operator in order to share infrastructure costs across multiple pools. This is relatively easy to do by running the pool software in virtual machines.
A more complex way to mitigate K being pushed too high is to modify the software so that multiple pools can be run within one virtual machine in order to keep RAM usage requirements low. This could be achieved through a cardano-node modification whereby the software had the concept of using multiple pool keys within the one pool. Such a change would then undermine the concept of K entirely.
You donât even need to hack the node implementation. You could just script always restarting the block producer with the keys of the pool that is next scheduled to produce a block. Ugly as hell, but totally possible (and still preferable to running X virtual machines for no reason).
A node implementation that just allows to manage multiple pools without restart would be much more elegant, though. And there is nothing in the protocol that prevents it, so it should be done. If only to prevent the naĂŻve narrative that running multiple pools does cause any form of infrastructure costs.
âŚ
That running multiple pools is so easy, done a lot, and there are also a lot of legitimate reasons to do it (and those only grow with any arbitrary lowering of saturation, increase of k), is one of the reasons Iâd much prefer k going to 1, k removed completely, no arbitrary saturation limit.
(Even if some researchers in Edinburgh or elsewhere, paid by IOG or not pluck a number from the air.)
âŚ
Making pledge matter, defining saturation by a maximal leverage (poolâs saturation limit is XĂ its pledge) would be a lot less arbitrary. No need to split pools, all pledge that I can afford can stay in one pool that then just has a much higher saturation limit.
Makes it also easier for delegators who do not have to gamble anymore which of the pools of a multi-pool operation to delegate to (if they want to delegate to that SPO).
I absolutely agree. Pledge represents actual skin in the game. Pledge leverage is something more equitable and unable to be easily worked around.
More importantly, both minPoolCost and K parameters are already being undermined and are essentially ineffective to those that would choose to negate their effect. The pools getting hurt by these parameters at present are the ones choosing to comply with the ârulesâ.
K parameter undermining
Multi-pool operators are already not complying with the K parameter. They quickly figured out that K could be undermined by simply running multiple pools. They run their separate block producers in virtual machines to minimise infrastructure costs. Eventually they can minimise their costs further by modifying the node software so that they can run one block producer with multiple pool keys, in one virtual machine.
minPoolCost undermining
Some pools are already not complying with the minPoolCost parameter. They have arranged separate side agreements with delegators to return a portion of the minPoolCost fees each epoch, but these agreements require trusting the operator. However, now that ISPO Bonds can be issued through Optim.finance, the minPoolCost parameter can be undermined in a trustless manner. Just issue a ISPO Bond paying say 4% and this is guaranteed 4% yield to those that buy it. If the SPO generates more yield than this, including the minPoolCost amounts through his stake pool operation, then he gets the extra as profit margin. The downside of these ISPO Bonds is that users lock up their Ada for the duration of the bond.
A better solution for undermining the minPoolCost parameter might be to design a smart contract system which doesnât ask delegators to lock up any Ada. Instead it asks them to opt-in to a smart contract where they will receive a portion of the minPoolCost amounts each epoch that they remain delegated to the pool. The SPO pays the minPoolCost amount to this smart contract each epoch that he makes at least one block. Delegators can opt-in to receive a commensurate portion of this Ada during their delegation period. Delegators can later opt-out of the smart contract to be paid their extra Ada. If the pool operator doesnât keep paying the minPoolCost amounts into the smart contract each epoch then the delegators can see this on-chain and easily move their stake to another pool. Delegators donât need to lock-up their Ada and so they have no restrictions on using it but they will receive extra rewards if they choose to opt-in to this âminPoolCost proportional distributionâ smart contract.
Surely IOG sees that minPoolCost and K parameters are ineffective against those who really want to undermine them. minPoolCost is so stupid, frustratingly anti-competitive, and it is only hurting the honest small pool operators trying to play by the ârulesâ.
Seriously IOG parameter committee decision makers, where is your head at with all these delays? Do you realise how stupid your insistence on leaving minPoolCost at such a high level is going to look if it becomes common to undermine it by using a smart contract like described above?
I see it this way: there is a demand to push k higher in the hope to move some sticky stake. And no real other reason.
That might would work out for a limited part of what at max could happen, but the by far most significant part will remain convinced and delegated at
custodial wallets (exchanges, wallets, âŚ)
existing multiPool operators
new multiPool operators
If this assumption is true, there would be a few new âestablishedâ pools, happy to be out of the lower risk zones and somewhere between middle up to fully saturated.
Then there will be still thousands of other smallest pool operators, who want something changed in order to allow them too becoming a saturated one.
the infrastructure costs is only part of the whole calculation if done correctly, honestly and especially with full dedication to the whole range of activities, understanding and participation. Just some examples: Smaller pools have less room and so options from their operational budget. so they will look for more ways to safe more costs. This usually comes with some tradeoffs, because if there wouldnât be any tradeoff it would already be standard behaviour and recommendation.
Instead of weighting quality or other benefits, the operator will focus more on low-cost offerings. This will shrink the options from which cloud provider you can order services from ~20 to ~5.
Then - if the SPO does not just operate a pool in his free time as a hobby - and actually calculate in maintenance, quality, security ⌠his time and knowledge, the next way to safe costs is there.
Then a next potential cost and efforts saving step for an SPO is to just do what he already has up and running, but avoid any extra efforts:
testnet
governance
mithril
âŚ
One more step for SPOs is, to consciously run a pool at a loss, with the goal to sum up stake and produce blocks. Then join groups and business models where certain TXs can pay extra fees off-chain to get backed into blocks through the fast lane.
So as you see, shrinking the pool size and potential rewards, has much more than restart or multi-key solutions to offer.
The question is which one of them we want pushed and adopted more and more for the sake of ⌠âmore decentralisationâ (they say)
{IOG CF Emurgo} decided they could use parameters and genesis keys to centrally control decentralization (k, minPoolCost, !maxLeverage, !minMargin) while benefitting incumbents (a0, ICO) in a âpermissionlessâ ecosystem.
Hubris.
This saga has exposed that the genesis organizations had good principles for marketing and attracting a loyal principled community, but not the best principles. All of members of the Cardano community who are here because of the principles, values, and the_mission will gravitate towards the best principles and values eventually.
Well, the only thing I read about changing k, was that the poll was not conclusive. Which is a wrong interpretation of the result and no further discussion.
The result of the poll was a majority pro k = 1000. k, as I mentioned, is the assumed optimal number of pools. Of course we have more than 500 active pools out there. And, it is obvious, that more than 500 pools can operate even with k = 500. However, only increasing k will keep the current number of active pools. Otherwise many (smaller pools) will have to cease operations because it cannot be done in a profitable way.
As I also mentioned: it was already planned to increase k and if increasing k was out of question - then why asking for it in the poll?
Again coming back to the poll: It was asked about the parameter and there is a clear result. Wasnât the idea of self governance to have the audience (owners of ADA delegating it) to decide?
If the results of future polls are ignored the same way as this first one - then Voltaire is just a facade to hide that the chain is still controlled by CF, IOG, and Emurgo.
Well the result of the poll was setting minPoolCost to 170. I am just asking to respect the result of the poll. The problem is not the cost of operations. With the current setup small pools cannot attract delegations and without delegations they cannot afford the cost of infrastructure. Independent of minPoolCost.
A simple example: a pool produces a block once a month. Currently, it pays about 140 ADA to delegators. Compare that to nearly saturated pools and youâll see that there is no way to keep delegations that way.
Now one can say, that CF, etc. donât want to have such small pools. But they are that small because of the current parameter setting. It gives pools with 10s of millions of ADA a huge advantage over small pools.
If the results of the poll are not implemented, then many of those smaller pools will cease operations.
