Revert tie breaker change for small pools #1548
Conversation
…or-small-pools Restore leader VRF tiebreaker
Cerkoryn
requested review from
nfrisby,
jasagredo,
amesgen,
fraser-iohk,
dnadales and
geo2a
as code owners
There was a problem hiding this comment.
Thanks for opening this, fully agreeing with
Community feedback is needed, but there isn’t a clear venue for it. Even if this alteration is ultimately not accepted, the PR can help spark the discussion about where protocol-level tie‑breaker rules should be governed.
One natural place would be the Consensus Working Group call (next iteration on the 19th of June, see the Intersect Discord). There also is overlap with the Ledger Working Group (eg as the reward scheme falls into their territory).
Some high-level thoughts:
The problem that this change intends to address is to improve the situation of small SPOs, most directly by increasing their expected rewards.
I think the core points to consider are therefore:
-
Is there agreement that this actually is a problem?
To a certain degree, we want to discourage small pools, in order to avoid Sybil attacks.
-
How exactly does this change achieve that goal?
This requires a quantification of eg how much the expected rewards of a small pool would increase due to this change. Eg calculating how often slot battles happen is straightforward; estimating the frequency height battles requires additional assumptions; a first step could be to take empirical data from eg https://pooltool.io/networkhealth.
-
Are there alternatives achieving the same goal?
Concretely, an alternative is to adjust the reward system to favor smaller pools, cf IntersectMBO/ouroboros-network#4051 (comment). This could either involve changes to related protocol parameters (simple case), or require more fundamental changes to the reward system (involved case).
Another (only half-serious) idea that has been flying around is that we could have an even more drastic tiebreaker: The smaller pool simply always wins the battle. However, this might have undesirable side effects.
One then needs to judge the tradeoffs of all solutions against each other.
| pTieBreakVRFValue = | ||
| mkTestOutputVRF | ||
| . bvValue | ||
| . vrfLeaderValue (Proxy @c) | ||
| . hbVrfRes | ||
| . headerBody |
There was a problem hiding this comment.
For a proof-of-concept implementation, this seems fine; however, for an actual implementation, it makes sense to avoid mkTestOutputVRF and going through Natural.
Also, one needs to add
{-# LANGUAGE ScopedTypeVariables #-}at the top to get this to compile.
There was a problem hiding this comment.
Thanks for your response @amesgen.
One natural place would be the Consensus Working Group call (next iteration on the 19th of June, see the Intersect Discord)
I was not aware of the existence of this working group, but if we are able to get this issue added as a discussion item I'm sure one of us from the SPO Incentives Working Group would be willing to show up and make the case for reverting back to using the L hash for slot battles.
To a certain degree, we want to discourage small pools, in order to avoid Sybil attacks.
I think regarding this and the explanation in @dcoutts comment that pledge was designed to be the limiting factor for both pool splitting and Sybil attacks.
If we can address that separately then we can empower small pools to our hearts' content without having to worry about exploitation by bad actors. Consequently, we have just re-submitted a CIP with simulation research and a built tool to model it that aims to solve exactly this issue.
The PR to merge it into the CIP-repository is here: cardano-foundation/CIPs#1042. CIP Editors will be reviewing it at their next meeting on 10 June.
There was a problem hiding this comment.
One natural place would be the Consensus Working Group call (next iteration on the 19th of June, see the Intersect Discord)
I was not aware of the existence of this working group, but if we are able to get this issue added as a discussion item I'm sure one of us from the SPO Incentives Working Group would be willing to show up and make the case for reverting back to using the L hash for slot battles.
Sounds great, added to the agenda (also pinged you(?) on the Intersect Discord), thanks 👍
To a certain degree, we want to discourage small pools, in order to avoid Sybil attacks.
I think regarding this and the explanation in @dcoutts comment that pledge was designed to be the limiting factor for both pool splitting and Sybil attacks.
If we can address that separately then we can empower small pools to our hearts' content without having to worry about exploitation by bad actors. Consequently, we have just re-submitted a CIP with simulation research and a built tool to model it that aims to solve exactly this issue.
The PR to merge it into the CIP-repository is here: cardano-foundation/CIPs#1042. CIP Editors will be reviewing it at their next meeting on 10 June.
Yeah, these general efforts on changing the reward system are definitely closely related and should be studied together. It seems to me that pool splitting is inherently related to Sybil attacks, but it indeed sounds cool if they could be somehow (at least partially) separated.
Also cc @CarlosLopezDeLara
There was a problem hiding this comment.
FYI some notes on how much non-orphaned blocks/rewards would change for small/large pools with this change compared to the status quo: https://hackmd.io/hX7q5s8JSKSP-j3525J0bA
|
Quoting @amesgen:
Could you please elaborate on this concept? |
In this context, a "sybil attack" is referring to an attacker creating a huge number of tiny pools, in order to gain some kind of advantage (depending on the context, this could for example be a reduction of networking performance or unbounded ledger state growth). There is broad agreement that such sybil attacks should be disincentivized in some way. Concretely, the current reward system uses pledging via the Of course, there is no binary decision between "small pools are encouraged" and "small pools are discouraged"; just a degree of how incentivized or disincentivized small pools are. In particular, new pools are usually small, so a pool being small shouldn't be too disincentivized. These tradeoffs are subject to community discussion:
|
A bad actor preparing a Sybil attack needs more than a bunch of pools, they need a large supply of ada/delegation to make any such attack effective. |
|
Quoting @amesgen:
I agree, this is a design feature of Ouroboros rather than a bug. Ouroboros does seek to somewhat discourage small pools to avoid Sybil attacks. As the operator of a small pool, and the one who first identified the change in 2022 from using "leader VRF" to "block VRF", I can say that I was upset, because prior to that change, my pool was benefiting by winning a high proportion of fork "battles". But, the Ouroboros design doesn't seek to prefer small pools through advantaging them when settling fork ties. Instead Ouroboros tries to achieve a network of "K" fully saturated pools by incentivising stake to coalesce towards nearly saturated pools competing over fees. Changing back to using leader VRF to settle ties would create an incentive for pool splitting in order to game that advantage, especially when it is easy to run multiple pools using virtual machines on the same infrastructure. We want to do the opposite of this. We want to encourage pool operators to coalesce their pools. On the other hand, it is a fairness principle that new entrants should be able to compete against large incumbents. However, there are some factors which were not intended in the Ouroboros design that are currently advantaging large incumbents:
I think it would be better to work on fixing these things which can be viewed as "loop-holes" within the Ouroboros protocol. I don't like the idea of perverting an aspect of Ouroboros design which was intended to be fair by making it unfair, to the advantage of small pools, as a kind of way to make up for the loop-holes. |
|
Hi TERM, some of the points you make below are being evaluated by a Community lead initiative called the Cardano Incentives Working Group, of which OP (@Cerkoryn) is part of. Specifically:
https://incentives.solutions/lower-minpoolcost-to-0/
https://incentives.solutions/cps-lost-stake-2/
https://incentives.solutions/cip-50-rebirth/
https://hackmd.io/hX7q5s8JSKSP-j3525J0bA None of these proposed ideas work in a vacuum, but in concert they would, in our opinion, mitigate some of the concerns you raised above. Respectfully, Stef |
|
Thanks Stef. I am aware of the ongoing work to correct some of the loop-holes within the current protocol operation. IE:
So, I definitely would like to see the playing field levelled. However, I would like to see this happen by fixing loop-holes rather than creating new ones. This proposal seeks to introduce what I believe is a design flaw, as a way to somehow re-balance the advantages large multi-pool operators are obtaining through exploiting loop-holes. Respectfully, in my opinion, doing so would be a mistake. General principle argument:As a general principle it is a bad idea to create a protocol advantage towards new small pools. Large old pools have invested time to build brand reputation and collect stakers. Even if these old pools don't have as much pledge as some others they still have their reputation and their following of loyal stakers to lose if they behave maliciously. Many have spent years paying network and hardware costs as well as communicating with the community via youtube, Cardano Forum, X/Twitter, etc. to build these pools. They don't want to see this business value destroyed. This is expensive and real "skin in the game". On the other hand, it is cheap and quick to spin up 10 new small pools with pledge split across them. Hell, I can even rent staking rights for a period of time using "Liquidity bonds". But, this principled argument is not enough since people won't see past their own pocket books, so here are some examples: Example unwanted outcomes:
|
|
Thoughts so far:
From (unpublished) analysis that I have done about slot battles, I think the problem is actually tiny and that the solution does little to address the problem. That is, the number of slot or height battles is already very small, and thus the number that small pools experience and loose is also very small. And the bias introduced by the "solution" is also slight. Thus I would expect the "solution" to have little effect on the problem. |
FTR I have written up how much the expected rewards would change due to this (only taking a look at slot battles; but height battles are much more rare empirically, so it shouldn't change the picture too much): #1548 (comment) TL;DR the impact is rather small:
There might be some more statistical things to compare, like by how much less the rewards/performance of small pools fluctuate due to this change (which might actually be more relevant for small SPOs), but it is not clear to me how to best do that (eg the coefficient of variation doesn't decrease much). Also linking the slides and the recording from the Consensus Working Group channel on Discord as well as the e-mail to the TSC here as well, which talk about this and other things: |
|
@amesgen that's great! So do you think it's a fair headline to say that best case, there's a 2.6% financial benefit to some of the smaller pools? |
|
Summary from today's TSC meeting:
|
Yes, while emphasizing that this is about mean rewards (so measured over a sufficiently long period of time), and with the caveat that the benefit would increase if height battles became much more frequent. (Not the most elegant headline then 😿) Also (see https://hackmd.io/hX7q5s8JSKSP-j3525J0bA), there are simple generic bounds (for slot battles) for how much the mean rewards can change simply by changing the bias of tiebreaking, namely by assuming the extreme case that a pool previously lost every single slot battle, but it is now winning every single slot battle (or vice versa). In that case, when So even assuming we introduce maximum bias (in either direction) to the tiebreaker, as long as height battles don't become much more frequent, the mean rewards can't improve by more than |
@dcoutts I think the problem itself could be summarized by saying that a small pool that makes less than one block per epoch is disproportionally affected by losing the dice roll of a slot/height battle compared to a large pool who makes many blocks. From a broad point of view, the slot/height battles are not frequent enough to be a big deal (see @amesgen's HackMD post), but from a the small SPO's perspective they are very much a big deal. Perhaps a more meta-problem I've heard from SPOs is that the ledger previously used the L hash and they became accustomed to it, and then it was changed to the B hash seemingly without warning (i.e., no CPS for social consensus, no CIP, no governance, etc.). I think a CIP that introduces a new protocol parameter to control the degree of bias sounds interesting, but coming up with such a design is probably beyond the technical ability and time commitment of our all-volunteer Incentives Working Group. Our intent is to see if we could simply switch back to the way things were done before. |
Background
Issue ouroboros-network#4051 raised concerns that the original Praos implementation used the raw VRF value from the block header instead of the range‑extended leader VRF value. The issue notes:
The change to use the raw VRF value took away the small‑pool advantage that existed when ties were settled with the leader VRF value.
What this PR does
This PR modifies the Praos implementation to once again use the range‑extended leader VRF value for tie‑breaking:
Additional imports for
vrfLeaderValue,mkTestOutputVRF, and helpers were added at the top of the file:This restores the small‑pool advantage in slot battles by using the leader VRF value, matching the behavior before the change referenced in the original discussion.
Why this matters
This modification appears in conjunction with a new cardano-node release and is not exposed as a parameter. Consequently, it is not straightforward to place the change into a standard Parameter Change Governance Action. Community feedback is needed, but there isn’t a clear venue for it. Even if this alteration is ultimately not accepted, the PR can help spark the discussion about where protocol-level tie‑breaker rules should be governed.
Additional notes
The PR was produced using the latest Codex AI tooling with oversight from @Cerkoryn
Due to CI limitations in the provided environment, cabal test all could not fetch dependencies. Anyone reviewing these changes should run the full test suite locally.
Please have knowledgeable developers audit and validate the change before merging.
This PR aims to reopen community dialogue and ensure that the implications of using the leader VRF value (and the small-pool advantage it provides) are properly debated. This issue was additionally raised on X by EarnCoinPool in this post: https://x.com/earncoinpool/status/1925976197520929235.
Parties that may be relevant to this discussion:
@AndrewWestberg @disassembler @kevinhammond