Leader VRF value no longer settling ties

[JaredCorduan]

I do not know whether or not we've found a bug or just discovered the consequences of an intentional decision.

---

The final tie breaker for "slot battles" is the leader VRF value:

https://github.com/input-output-hk/ouroboros-network/blob/9249a70ed9e2365f3963e47cb31b4b1589bca8f6/ouroboros-consensus-protocol/src/Ouroboros/Consensus/Protocol/Praos/Common.hs#L62-L68

In the TPraos protocol (used prior to the Vasil HF), csvLeaderVRF was the leader VRF value. In the Praos protocol, however, csvLeaderVRF is being set to the single VRF value in the block header (prior to the range extension).

This removes a small advantage that small pools previously enjoyed. Small pools are more likely to win this tie breaker, since by being a small pool they need a smaller leader VRF value in order to win the leader check. Using the the VRF value before the range extension is applied removes this small advantage.

---

The Evidence:

The view, PraosChainSelectView, is populated by the BlockSupportsProtocol class method selectView, which uses the ProtocolHeaderSupportsProtocol class method pHeaderVRFValue to set csvLeaderVRF in the view.

• In TPraos, pHeaderVRFValue uses the leader VRF value: https://github.com/input-output-hk/ouroboros-network/blob/9249a70ed9e2365f3963e47cb31b4b1589bca8f6/ouroboros-consensus-shelley/src/Ouroboros/Consensus/Shelley/Protocol/TPraos.hs#L111
• In Praos, pHeaderVRFValue uses the raw header VRF value: https://github.com/input-output-hk/ouroboros-network/blob/9249a70ed9e2365f3963e47cb31b4b1589bca8f6/ouroboros-consensus-shelley/src/Ouroboros/Consensus/Shelley/Protocol/Praos.hs#L141

---

This was discover here: https://github.com/cardano-community/cncli/issues/19

[TerminadaPool]

In case it was an intentional decision (to randomise slot battle outcomes) the following is worth noting:

• Leader VRF value is something independent of block contents.
• Whereas (I assume) block VRF depends on block contents.

Therefore the way things are currently enables stake pools to game the system by running custom software to re-order, or select transactions, in order to generate a low block VRF result to maximise their chances of winning a potential slot battle.

It is probably not good to have an extra incentive for block producers to manipulate transactions.

[JaredCorduan]

It is probably not good to have an extra incentive for block producers to manipulate transactions.

you are absolutely correct @TerminadaPool , and we've made sure not to incentivize this kind of behavior.

Whereas (I assume) block VRF depends on block contents.

it does not! (to your point above). the value of the VRF in the block header depends on:

• the epoch nonce
• the slot
• the private VRF key

[HT-Moh]

Hi, I appreciate it if you can elaborate on why in these 2 cases CCYT lost 2 blocks to a pool with low VRF after the VHF, is it completely random now?

https://pooltool.io/realtime/7825147 https://pooltool.io/realtime/7700005

[AndrewWestberg]

@HT-Moh Yes, it is currently completely random without any slight advantage to smaller pools as was the case in Alonzo. This issue was opened to see if the change was intentional or unintentional. If unintentional, it can be filed as a bug and corrected in the node.

[HT-Moh]

@AndrewWestberg thanks

[reqlez]

My 2 cents: this was known for a while by the community and nobody ever said it was a bug. I always assumed that it was a design decision since for a small pool losing a slot battle is very noticeable versus a bigger pool.

Here is some documentation about it near bottom of page ( that website is down right now, so linking wayback machine URL ) https://web.archive.org/web/20220822194606/https://cardanofaq.com/books/general-operations/page/what-are-slot-battles

[TerminadaPool]

I think you might be missing the point @reqlez. Slot battles used to be determined in favour of the lowest VRF score (which would favour smaller pools), but now the determination is random. Small pools no longer have the slot battle advantage your link refers to.

[reqlez]

I think you might be missing the point @reqlez. Slot battles used to be determined in favour of the lowest VRF score (which would favour smaller pools), but now the determination is random. Small pools no longer have the slot battle advantage your link refers to.

i'm fully aware. i'm just saying, that i believe the lowest VRF score preference ( how it was before ) was a design decision versus a bug. But I do not have any information from IOG that would suggest that, of course. The reason i believe that, is because i feel it makes sense to give smaller pools a preference, because a lost block is not very noticeable to a big pool, but would hurt a smaller pool quite a bit. What I do not know, is what are the potential security issues with this. I mean... it worked like this for 2 years, and seemed fine. Has anybody found a way to abuse this reliably?

[TerminadaPool]

It was a deliberate design feature to determine slot battles in preference of the lower VRF score.

But the changes in the most recent version 1.35.3, resulted in the removal of this feature. This was why I was surprised to notice the change and the rest of the community was also surprised. The truth hasn't come out yet about whether the removal of this feature was intentional or not.

[JaredCorduan]

Here is some more context that everyone may not be aware of.

At the Vasil hard fork, we switched from using the TPraos ledger protocol ("transitional Praos") to Praos. The TPraos block headers contained two VRF values: one for the leader check and one for the contribution to the next epoch nonce. The VRF check is a bit costly, and so our cryptographers came up with an optimization, namely the range extension. We made use of this optimization in Praos, and hence the Praos block headers only include one VRF value, and we use the range extension on this single value to produce the two values that we need (leader nonce and entropy nonce).

TPraos was settling "slot battles" with the leader nonce in the block header. Praos is settling ties with the single nonce in the block header. The question that I've raised in this issue is: would there be any negative consequences to instead settling these ties in Praos by range extending the single VRF value in the block header to the leader value.

[cardanoinvest]

Do we have any ETA for this fix? This should have higher priority. As it already affecting the ratings and ROI % of smaller pools. In my personal experience I already lost 5 substantial delegators to large pools. Thank you.

[TerminadaPool]

@cardanoinvest I assume that a fix for this will be unlikely to be rolled out separately. This is because the larger stake pools will have no incentive to upgrade since it will slightly disadvantage them. If only part of the network upgrades then slot battles will become non-deterministic (since upgraded nodes nodes will award a different winner half of the time) resulting in more chain forks needing to be settled by longest chain rule.

Yes, it is a blow for small pools especially when the mandatory 340 Ada min fee is also working against them recruiting delegation.

[cardanoinvest]

@TerminadaPool if they fix and release it as 1.35.4 with high recommendation to update and send note to exchanges to update, I believe it will become main version. Because 1.35.5 , 1.35.6 will come anyway with that fix implemented. Not like we have any other major alternative Cardano node development team.

[TerminadaPool]

@cardanoinvest If you update your node and the majority doesn't then your node might produce a block on the non-consensus fork causing your block to become orphaned.

[AndrewWestberg]

This only affects slot battles. Whether someone is running a 1.35.4 with the patch or 1.35.3 without won't make much difference as only 5% of blocks are battles. What matters is whether the node making the block AFTER yours is upgraded. You cannot reduce or improve your chances by being on the same or different version of the node coming after your block. All you can do is upgrade yourself to try and be nice to any smaller pool making a block before yours. Whether your block gets adopted or not is out of your hands.

[kiriakos]

Agreed. But wouldn't this sort of fix better fit a CUE event anyway? In that case the upgrade discussion would be moot no?

[daehan-koreapool]

This is indeed hurting small pool operator's pool performance. Since this directly affects decentralization of Cardano network, we should definitely address this issue. In my opinion, this should have higher priority than the minpool fee debate.

[kaskjabhdlf]

There is a misconception that small pools decentralize. Making slot battle random instead of favoring small pools is an incentive in the right direction, to consolidate pools. A single pool with 30MM stake is better than 10 pools with 3MM stake.

We need to stop incentivizing thousands of pools with low stake and begin incentivizing K desirable pools.

[gusosborne]

There is a misconception that small pools decentralize. Making slot battle random instead of favoring small pools is an incentive in the right direction, to consolidate pools. A single pool with 30MM stake is better than 10 pools with 3MM stake.

We need to stop incentivizing thousands of pools with low stake and begin incentivizing K desirable pools.

Could you please explain this misconception? You are saying a concentration of resources in fewer places helps with decentralization??

[kaskjabhdlf]

You know the pools in the above photo are part of a large group because they are marketed that way. If each of those pools had different metadata, website, etc. they would still be part of a group. Not all groups are so blatant. Assuming that any pool with low pledge is independent because it's marketed that way is naive. Many people (especially ITN OGs) are running tons of pools with low pledge and low stake to farm minPoolCost. Slot battle preference paired with giant minPoolCost are two incentives for SPO to run many small pools instead of one large pool.

By making slot battles random you incentives delegators and operators to consolidate their stake into one large pool instead of dozens of small pools.

[cardanoinvest]

Well if they splitting into multiple small pools they still have to pay for the resources, CPU/RAM etc, so those 340 should cover it. They still make it decentralized

[JaredCorduan]

I've now had a chance to talk to the researchers, the cryptographers, and the folks that did the implementation work.

It was always intended that ties be settled uniformly random. The behavior in Praos is expected, the behavior in TPraos is not.

The Praos paper does not make assumptions about how tie-breaking is done, and is assumed to be controlled by the adversary. The problem is that this is an unintended incentive mechanism. This incentive was not intentionally added To TPraos, nor was it intentionally removed from Praos. The assumption was always that ties were being resolved fairly.

@kaskjabhdlf is right to remind us that we cannot equivocate "good for small pools" with "better for decentralization". Though @cardanoinvest is almost certainly correct that the small pool advantage is dwarfed by other advantages, the fact is that the incentive mechanism that was designed by our research already takes into account the fact that we want decentralized block production.

I'm going to close this issue now, not because I want to end the discussion, but because my original question has been answered. Please feel free to keep the discussion going here, elsewhere on GitHub, or Discord, etc.

[AndrewWestberg]

@JaredCorduan Regardless of intentions, "uniformly random" does not have uniform consequences. The impact of slot battles already negatively impacts a small pool much more than a large pool. It's a huge hit to ROI numbers for a small pool to lose even a single block. For a pool near saturation, it's insignificant.

I believe we will see decentralization decrease and fewer new pools being able to compete with established pools. I would ask you to re-consider the decision to not fix it, otherwise we will likely see a our first community-supported fork of the IOG code.

[cardanoinvest]

@AndrewWestberg I guess we all can manage to gather large enough community to make that fork, even @CharlesHoskinson "RATS" pools is small enough to be negatively affected by this. I would like to hear his comments on that issue.

[rdlrt]

It was always intended that ties be settled uniformly random.

@JaredCorduan - wouldn't that incentivise those operators to create more adversarial forks (as in run multiple BP nodes - was evident in ITN as chain selection was primary reason for those being run) to try and get an advantage? It's not gonna be uniformly random if there are ways to tilt (even if not guarantee) results into a favour by creating forks.

[JaredCorduan]

I believe we will see decentralization decrease and fewer new pools being able to compete with established pools. I would ask you to re-consider the decision to not fix it,

I will re-open this issue if y'all like (just let me know), but my intention with opening it to begin with was to get to the bottom of why the change happened. According to the folks who are responsible for settling ties with the leader nonce, there is nothing to fix anymore. If the community likes the accidental behavior better, that's worth discussing too.

wouldn't that incentivise those operators to create more adversarial forks (as in run multiple BP nodes - was evident in ITN as chain selection was primary reason for those being run) to try and get an advantage? It's not gonna be uniformly random if there are ways to tilt (even if not guarantee) results into a favour by creating forks.

multiple BP nodes with the same keys? that won't help, that doesn't change how consensus chooses between forks. or maybe you mean splitting up your pool into multiple pools? it's not clear that would give you enough of an advantage to be worth it.

---

Let me just say that I'm not the person that anyone needs to convince one way or the other, I'm not a subject expert here.

[cardanoinvest]

@JaredCorduan Thank you for raising that issue. I feel like there is a very little information about it in the community, we have small confused SPOs wondering where their only block went. And developers changed that parameters without any vote from the community, without any prior notification. And that parameter drastically changes the play field.

I don't have any good contacts in Cardano community, so I ask you and others, please make it more loud. And can we also get to Charles to comment on that thing.

[gusosborne]

You know the pools in the above photo are part of a large group because they are marketed that way. If each of those pools had different metadata, website, etc. they would still be part of a group. Not all groups are so blatant. Assuming that any pool with low pledge is independent because it's marketed that way is naive. Many people (especially ITN OGs) are running tons of pools with low pledge and low stake to farm minPoolCost. Slot battle preference paired with giant minPoolCost are two incentives for SPO to run many small pools instead of one large pool.

By making slot battles random you incentives delegators and operators to consolidate their stake into one large pool instead of dozens of small pools.

I was just asking for an explanation of the “misconception” you declared above.

Incentives aside, I still see no valid explanation for how making things more centralized could make the network more decentralized. Please explain that to me.

You seem to assume that the majority of small pools are owned by only a few operators. Even if that was true (which I do not believe at all), it would still provide a larger network with more decentralization- no?

[rdlrt]

multiple BP nodes with the same keys? that won't help, that doesn't change how consensus chooses between forks.

When results for chain election are random, if 2 BPs from same pool are running (for instance with different tx set due to upstream peers) , for their own block - that would mean the battle of A vs B block now becomes A vs B vs C (where A and C are for same slot from same pool, but different block hashes - this was common in ITN and the incentives to do so were curbed in mainnet due to the rule of preferring smaller pools.

The researchers (seems blackbox) did approve of the same back when change was made, see here

[AndrewWestberg]

@rdlrt This is not the case. It's now using the single vrf value from the block. I've been calling it the block_vrf, but it really has nothing to do with the contents of the block. It's just using a random value from an earlier step of the slot leader selection instead of the final step which is the leader_vrf. As long as you're using the same pool keys, two pools (dual leaders) will produce the same vrf value. It's this vrf value that is then hashed again to get the leader_vrf.

[AndrewWestberg]

I just want to leave one final opinion on here and then I'll leave it to others. My opinion is that IOG should modify it so that it works the same way in Babbage as it did in Alonzo. Then IOG should create a CIP to make the change if that's what the researchers desire.

Otherwise, this isn't a step in the right direction toward decentralized governance. It's IOG researchers that wanted the change, let them argue their case through the CIP process. It shouldn't be on the community to push back against changes made without their consent.

[JaredCorduan]

It's IOG researchers that wanted the change

To be clear, neither the researchers, nor the cryptographers, nor the implementors were aware that Praos was doing anything differently than TPraos with respect to settling ties. It was this issue itself (and me talking to folks) that made them aware of the small advantage to small pools.

[kaskjabhdlf]

Until community governance is ready and active, it's the genesis keys holder's responsibility and fully within their power to make changes to the network that they see fit. This includes any and ALL parameter adjustments and removals.

Just because governance is on the roadmap doesn't mean we're there yet. Waiting years for tweaks and changes that research proves beneficial isn't a good direction. Outside input in early development stagnates progress.

Even if that was true (which I do not believe at all), it would still provide a larger network with more decentralization- no?

No. Many/most multi-pools are run on shared hardware and are sharing relays between all BPs in the group. Spreading out stake into many pools owned by 1 operator does not provide a larger network footprint than if the operator consolidated into 1 pool.

[TrevorBenson]

To be clear, neither the researchers, nor the cryptographers, nor the implementors were aware that Praos was doing anything differently than TPraos with respect to settling ties. It was this issue itself (and me talking to folks) that made them aware of the small advantage to small pools.

I am very much for peer review and is part of why I am in the community and a SPO. However I find it quite unsettling that code differences changed the consensus algorithm. To have the above response that nobody realized consensus would change makes me feel that peer or at least code review is quite lacking.

The fact that nobody in IOG even realized this was going to change seems like a good enough reason to me to leave this ticket open and continue the discussion. Anything else at this point seems highly premature.

[TerminadaPool]

my intention with opening it to begin with was to get to the bottom of why the change happened.

@JaredCorduan I don't agree with the explanation you received from the software architects:

According to the folks who are responsible for settling ties with the leader nonce, there is nothing to fix anymore. If the community likes the accidental behavior better, that's worth discussing too.

I don't agree that the previous behaviour, of setting ties based on lower leader VRF score, was "accidental". According to my reading it was a deliberate design feature. See Duncan Coutts' comments here where there was discussion about limiting its effect to 5 seconds only: https://github.com/input-output-hk/ouroboros-network/issues/2913#issuecomment-816953407

In other words, it was a deliberately implemented design feature that leader VRF value was used to decide slot battles. This method was working well up until version 1.35.x and the community expected this behaviour to continue.

The incentive model has now been changed without any community consultation.

[JaredCorduan]

However I find it quite unsettling that code differences changed the consensus algorithm. To have the above response that nobody realized consensus would change makes me feel that peer or at least code review is quite lacking.

@TrevorBenson , maybe I should have made this more clear: we did not find mistakes in the research papers, this was an "integration" mistake (in TPraos). As I said above, the theorems in Praos are true under the assumption that the adversary settles ties. This ended up being an incentives problem, and we did not think to ask them for their opinion (their papers do not deals with tie breaking, but I suspect that they would have noticed the problem were we to present it to them).

The fact that nobody in IOG even realized this was going to change seems like a good enough reason to me to leave this ticket open and continue the discussion. Anything else at this point seems highly premature.

I'm happy to re-open the issue if this is where folks want to have the discussion. (my original question was answered, but I was not intending to stop the discussion about whether or not the community prefers the un-intented behavior).

I don't agree that the previous behaviour, of setting ties based on lower leader VRF score, was "accidental". According to my reading it was a deliberate design feature. See Duncan Coutts' comments here where there was discussion about limiting its effect to 5 seconds only: https://github.com/input-output-hk/ouroboros-network/issues/2913#issuecomment-816953407

@TerminadaPool , Nowhere in that comment does @dcoutts indicate that he is aware of a small advantage for small pools. Yes, the leader nonce was chosen on purpose, but without knowledge of this small pool advantage. There were two nonces in the block header to chose from, and the leader one seem more on topic.

[TerminadaPool]

Nowhere in that comment does @dcoutts indicate that he is aware of a small advantage for small pools.

Oh come on. Duncan Coutts was well aware of the advantage for small pools. As was everyone else commenting in that thread.

[dcoutts]

Since my name is being invoked here, I would like to hereby publicly confess that I did not know! :disappointed:

Here's the story from my perspective.

The intention when we included VRF-based tie breaking was to make the tie-breaking uniformly random. It was not our intention to make it biased. We included this relatively late in the Shelley design, in response to feedback from the ITN where we observed the "everyone moves to Frankfurt" phenomenon. The ITN problem was that there was a strong incentive to be faster to win height battles, and faster really means physically closer, hence the coalescing towards the "centre of gravity" of the network (Frankfurt as it happened). I should also confess that we didn't get a detailed design review from the researchers on this VRF-based tie-breaking. That was partly because it was a late design addition (you'll all remember how much of a rush we were all in to get Shelley out), but also partly because the Praos security argument says that after longest chain wins, any remaining choice can be arbitrary, so we thought we didn't need a security review for it. So we used the leader VRF for the tie-breaking (rather than the nonce VRF). What I (and indeed others) missed is the subtlety of the conditional probability: the leader VRF is indeed uniformly random, but in the situation where we condition on already having won the election, then it's no longer uniformly random. So this was unintentional, and I was not aware of it having been discussed between SPOs.

In the change from TPraos (transitional Praos with the d param) to simply Praos, we made some changes to the VRFs. To improve performance we changed from using 2 VRFs per block header to just 1. This involved using a "range extension" scheme, designed by the crypto researchers, to be able to extract multiple independent VRF outputs from a single underlying VRF (essentially it amounts to hashing the VRF output plus some extra salt). As part of doing that, we separated the output for the leadership check from the output used for tie breaking. This means the tie-breaking is now independent of the leader VRF value, and so there are no biases due to the conditional probability. So this should now be uniformly random, which is exactly what the original intention was. This is why we say that the new Praos code is doing what we want.

Personally I don't think we should re-introduce any bias. The right way to tweak the incentives between big and small pools is by tweaking the primary incentive scheme (rewards etc).

As for the discussion in https://github.com/input-output-hk/ouroboros-network/issues/2913#issuecomment-816953407, I certainly was not aware of the advantage to small pools at the time, and I do still think the proposal I made there is a good idea. I would have preferred to do that for the TPraos -> Praos change, but there wasn't time to do a good analysis of it.

[cardanoinvest]

@dcoutts Thank you for that explanation. So while we have no other "tweaking of primary incentive scheme" (changes to min fee, k, etc..) we should roll back to the non random VRF. Otherwise there is bias towards big pools, they can afford random VRF, small / starting / growing pools can't, its an uphill battle against bigger already fortified army. And I don't see how any delegators will stay with pool with 1% ROI vs 4% in a long run. I like @AndrewWestberg proposition.

I just want to leave one final opinion on here and then I'll leave it to others. My opinion is that IOG should modify it so that it works the same way in Babbage as it did in Alonzo. Then IOG should create a CIP to make the change if that's what the researchers desire.

Otherwise, this isn't a step in the right direction toward decentralized governance. It's IOG researchers that wanted the change, let them argue their case through the CIP process. It shouldn't be on the community to push back against changes made without their consent.

[dcoutts]

Remember that changing protocol parameters (k, min fee etc) is substantially easier technically than changing the code for the protocol. The TPraos -> Praos protocol change was a hard fork, and "rolling back" would also be a hard fork. So changing updatable protocol params "just" requires social consensus, whereas changing the protocol requires social consensus and a hard fork.

[TrevorBenson]

Remember that changing protocol parameters (k, min fee etc) is substantially easier technically than changing the code for the protocol. The TPraos -> Praos protocol change was a hard fork, and "rolling back" would also be a hard fork. So changing updatable protocol params "just" requires social consensus, whereas changing the protocol requires social consensus and a hard fork.

I'm open for discussion with everyone on alternatives. While an increase in k clearly would not alleviate greater loss of slot battles for smaller pools I believe it would essentially double the odds to produce blocks, or blocks per epoch. Please correct me if my generalization is incorrect.

That said while I recall maybe one mention of the delay for increase to k since then I've never found any good discussion thread which provided accurate detail about what looks today like it became an indefinite delay to increase k. From what I recall this should have happened well over 1 year ago, before Babbage era. I had no luck attempting to get answers during AMA events. Since protocol params are being offered as an alternative k is the first that comes to mind which could have an actual effect to counter the loss of leader_vrf usage to settle slot battles.

Am I oversimplifying or overlooking other parameters which could also have an impact to improve decentralization and reduce the chances of many small pools shuttering their doors?

[gitmachtl]

I'm open for discussion with everyone on alternatives. While an increase in k clearly would not alleviate greater loss of slot battles for smaller pools I believe it would essentially double the odds to produce blocks, or blocks per epoch. Please correct me if my generalization is incorrect.

Changing k is only changing the saturation point of a pool. The amount of blocks depends only on the active stake compared to the overall amount of staked Ada. Increasing k is not a magical parameter so delegators redelegating to small pools imo, bigger ones will just split and loyal delegators will redelegate to the new pools of the same SPO. Thats my oppinion. But i think thats not the right thread to discuss about those parameters.

[gitmachtl]

@dcoutts if its required a chain-upgrade (hardfork) to get it back to the old tie breaker, than so it is. its not the first one... 😄

[kiriakos]

What I am seeing across Cardano related social media and on this thread is a very focused opinion across the active SPO community to revert this change to the more welcoming selection logic of TPraos. Be it a Hard-Fork (CUE) or not might affect the timeframe of issuing a change but it does not seem to dilute the opinion formed by the community.

I think the question at hand here is: @JaredCorduan & @dcoutts is this enough for you guys to go on? Are there other things that would block the affected teams from acting on this? Is there something we as the SPO community can do (CIP maybe?)?

[dcoutts]

The point really is this, if as a community we want to adjust the incentives and rewards between big and small pools, we would not want to do it by adjusting this (comparatively rare) corner case (which has never been analysed). We'd want to do it systematically by doing a proper analysis and adjusting the primary incentive mechanisms: the reward curves and the various parameters.

Remember that with K still being 500, we're still playing musical chairs with 3000 people, and only 500 chairs. And remember that the current incentive scheme is designed to achieve an outcome with K pools of similar sizes: it's brutal to the pools outside of that. Now it is also true that K is not magic, and just changing K may not have the full effect some people want. Pledge also needs to be effective so that big pools don't just split into lots of small ones. And I think what some people want is that even outside of the top K pools (even if K were 3000 or something) for the incentives to be less severe in the drop off after K. That's exactly the kind of thing that needs proper analysis, not tinkering with corner cases.

It's also true that pools on the boundary of 1 vs 0 blocks are always going to have a hard time. The lottery is very granular for them. There's not much we can do about that until Leios, when the number of (input) blocks can become substantially higher, which smooths out the probabilities. For example, a pool that is currently expected to get 0.5 blocks per epoch might instead be expected to get 10 input blocks per epoch, and so their variance would be a lot less. Instead of 0 or 1, they'd be expecting to get something like 8,9,10,11,12 each epoch. It's the same total expected rewards, just smoothed out over more blocks.

[TrevorBenson]

Changing k is only changing the saturation point of a pool.

Agreed. I was definitely over generalizing, not actually looking at the algorithm, and acting as if this meant larger pools would reduce to 32M and that difference would be spread around the remaining pools. While I expect some delegation to redistribute, I fully agree changing k doesn't just mean an SPO will find in a week or two double their active stake.

Increasing k is not a magical parameter so delegators redelegating to small pools imo, bigger ones will just split and loyal delegators will redelegate to the new pools of the same SPO.

Also agreed, clearly eToro, Binance and exchange based pools I do not expect to do anything except create more pools and spread their funds out, since enterprise addresses and other concepts never seemed to come to fruition to prevent exchanges from taking a lions share of active nodes.

[TerminadaPool]

Sorry @dcoutts for my accusation about knowing that small pools were slightly biased by the leader VRF slot battle tie breaker.

In your previous comment:

Remember that with K still being 500, we're still playing musical chairs with 3000 people, and only 500 chairs. And remember that the current incentive scheme is designed to achieve an outcome with K pools of similar sizes: it's brutal to the pools outside of that.

If I understand your wording correctly, the protocol seeks to target an absolute number of block producers rather than a minimum number. Is this to keep the network of block producers from becoming too large? In other words, if we take this view of more decentralisation is better to the extreme, then eventually the network gets too big causing reduced performance?

I was thinking that P2P mode might make network size less relevant for performance, since nodes will work out the quickest pathways to receiving blocks themselves. There is a natural limit anyway to the number of block producers since there are only so many blocks per epoch (or ranking blocks with input endorsers). And pool operators will turn off their block producers if they never get to make blocks. So maybe more decentralisation won't impact performance?

It is obvious that the community wants to start taking ownership. Therefore, it is important to understand the philosophy behind the original incentive design if the community is to think about re-designing for improved decentralisation.

[dcoutts]

@TerminadaPool don't worry :-) I wasn't taking it as an accusation. Indeed I'm flattered that you thought I was so clever that I knew about and introduced this bias in the design (but never wrote it down in the specs).

[dcoutts]

Therefore, it is important to understand the philosophy behind the original incentive design if the community is to think about re-designing for improved decentralisation.

I'd recommend reading the incentives paper and the incentives section of the Shelley design, and there were a load of presentations on the topic by Lars (which no doubt can be found on youtube).

Within the existing design, the main lever to pull to control the level of decentralisation is the K param, but one does need to deal with the issue of pool splitting.

[TerminadaPool]

but one does need to deal with the issue of pool splitting.

Yes, pool splitting essentially negates the effect of increasing K. It seems that the main lever to pull to control the pool splitting problem is by properly incentivising pledge.