Question. Is this part of the Staking Calculator? When I run simulations I get a different outcome.
for example 1% pool, with 50k pledge vs 600k pledge, everything else is 100% the same. I get a 1 ada difference. If it was the .1 vs .001 it should be more like 98 ada difference not 1 ada.
50k = 98642.38154
600k = 98643.613515
One Idea i pitched like a month back was changing the goal posts for example. Rather than have .03 range be from 0 to saturation (or the highest pledge) have it be form 50k to like 5m , giving a much bigger difference in rewards for someone pledging 50k vs 500k vs 1m , making it better to have 1 pool with say 1m vs 10 pools with 100k , as the 10 100k pools will earn more than the 1 1m pledge pool due to min fixed fee. every time.
I created a feature request on the cardano-node github to get this idea into the
system somewhere.
It probably is more of a Cardano Improvement Proposal but I don’t know if there
is a process for that yet.
@Lars_Brunjes @pparent76 @AllisonFromm
I enjoyed your discussion of Pierre’s alternative rewards equation.
I would love to know what you think about my proposal to modify the current equation to have a curved pledge benefit rather than the current linear factor.
Thanks!
Hi, I was concerned about the linear characteristic of a0 about half year ago and we had some discussion in the guild channel at that time.
But, I gave it a second thought as who will decide where the function of the shape would start having affect on the reward i.e. where the curve starts inclining and in what degree? I.e. as charles would say similar ‘who says who decides?”. There is no good choice at all. So, that is why I left it as it is.
My other concern was the ‘killing pool’ feature of the reward equation when for example a fully saturated private pool can kill and other fully saturated pool by staking its all stakes for short term to a fully saturated target pool that will cause the target pool’s would die in some epochs cos its rewards would drops down significantly and its delegators would leave. Of course the delegators could redelegate later and it cannot be sustained for long term cos the adversarial pool would loose money too but it might worth doing it anyway for some reason. So one possible idea for solving this that came up around the same time the previous one, that the over-saturator would be gradually punished but it would be hard to implement in the current design.
The problem with this is that the a0 reward benefit effect is pretty much linear related to pledge.
Hi, I was concerned about the linear characteristic of a0
With this factor in the official formula it is absolutely not linear.
I would love to know what you think about my proposal to modify the current equation to have a curved
If you upload an actual reward formula I can give you my thoughts about it, currently I’m not sure to see what you propose. But as you might have realized I’m not really in favor of a_0, so it is quite unlikely I will be in favor of it, unless you really found a clever way to make sense out of a_0! 
(Also note that your proposal will have to match the fact that with it only Nash equilibrium are k equal-sized pool, which apparently is of critical importance for Cardano devs, and the slightest modification can destroy this property in a model, (and which I’m currently redacting a proof that my model is compliant)).
My other concern was the ‘killing pool’
One of the flaws of this model, that I called “DDoS on a pool”, in the other thread.
Thanks for the reply @_ilap !
As to who will decide where the curve crosses the line and how much it curves that, like any other parameter in the equation, is subject to the CIP process.
The crossover parameter is set to 5m ADA in my example which seems like a resonable place to start but is certainly debatable and different values can be easily tried and compared to clearly see the effect.
The choice of curve function is also debatable.
I think the cube root function provides stronger incentives to pool operators to pledge and thus increases Sybil attack resistance.
It also reduces the unnecessary over rewarding of private pools.
My twitter poll showed a strong preference for this.
That is obviously not a deciding factor but is indicative of what some people in the community think.
I don’t think the Oversaturate Pool attack is a real concern as it is so expensive and would in the end be self harming.
I also don’t think it is relevant to this propoosal since the change I suggest is only to the pledge benefit factor.
It depends on what you choose for the x coordinate, the R, the a0, the nOpt a.k.a k, the pledge i.e s', the whole stake i.e o', or is it a multivariable calculus i.e. more than one variables are used i.e. graphed as f(stake, pledge)? It depends on what you want to interpret
I think @shawnim was refering to a similar function described here and what I was responded to that:
https://antipalos.github.io/cardano-calculator/docs/pool-reward-demo/#charts
For somebody 5m ADA (i.e. 500K USD) is nothing for others is an unreachable dreams.
Is not really expensive, but you need to understand how reward calculation correlates to the ledger i.e. blockchain, whihc is quite complex, check the Transition diagram I have created to have other SPOs getting their head around that
It is difficult for me to see the image you posted since I am legally blind but I believe it is the same formula as the maxPool function defined in section 11.8 Rewards Distribution Calculation of “A Formal Specification of the Cardano Ledger” and called f(s, σ) in section 5.5.2 of “Design Specification for Delegation and Incentives in Cardano”.
maxPool = (R / (1 + a0)) * (o + (s * a0 * ((o - (s * ((z0 - o) / z0))) / z0)))
where:
R = ((reserve * rho) + fees) * (1 - tau)
z0 = 1 / k
s = pledge / total_stake
Note that “s” seems to be called “p” in the first specification above and “s” in the second.
There are 2 variations of my proposal (Alt2 and Alt3).
In both cases the maxPool function is unchanged but I change the meaning of “s”.
Alt2 substitutes the square root of pledge times the square root of crossover for pledge in the original definition.
s = (sqrt(pledge) * sqrt(crossover)) / total_stake
Alt3 substitutes the cube root of pledge times the square of the cube root of crossover.
s = (pow(pledge, 1/3) * pow(crossover, 2/3)) / total_stake
The new definitions of “s” introduce a new parameter called “crossover” which is the amount of pledge where the pledge benefit is the same for the curve as the original line.
So in Alt2 when
pledge = crossover
then
(sqrt(pledge) * sqrt(crossover)) / total_stake = pledge / total_stake
and similarly for Alt3
(pow(pledge, 1/3) * pow(crossover, 2/3)) / total_stake = pledge / total_stake
I hope that is a clear explanation of my reward equation proposals. I am a developer, not a mathematician, and do not have tools or skills to create fancy math equations with greek letters.
Please let me know if I have misinterpreted the formula or misunderstood the meaning of any of the parameters.
Thanks for taking a look!
The linear relationship that I was refering to in the current equation is that of the added rewards due to pledge versus pledge.
Sorry, was working and yep assumed.
It was clear anyway, I just reflected to him that you was referring to a linear function like that I showed and not any non-linear one.
Also, you only need one and not alt2 alt3, as they just alternate version of your pow function when the exponent is the following: (sqrt(pledge) * sqrt(crossover)) / total_stake = (pow(pledge, exp) * pow(crossover, 1-exp))/ total stake, when pledge=crossover and if the exponent is R={0…1}.
And the alt2 is when the exponent is 0 at the one side.
So, I was referring, who decides the exponent (the shape of the curve and what is he crossover)?
It’s not easy. Though, my solution was different as I wanted to change the curve of the 1/(s+sa0).
I meant, you can generalise it:
sqrt(pledge) * sqrt(crossover)
= pow(pledge, 1/2) * pow(crossover, 1/2)
= pow(pledge, exp) * pow(crossover, 1-exp)
where exp=0.5 int the above example (i.e. Alt2) and exp R={0..1}
or exp=1/3 (Alt3), or any numbers from 0..1.
(sqrt(pledge) * sqrt(crossover)) / total_stake = pledge / total_stake
(pow(pledge, 1/3) * pow(crossover, 2/3)) / total_stake = pledge / total_stake
This does not strongly incentivize pool operators to put some pledge (such as 50k or 200k ADA) when the benefit is so small compared to 0 pledge.
Thank’s for clarifying.
Ok I think I got what you want to do, and in some aspects it is similar to what I wanted to do initially (so you might want to check out what I am currently proposing).
I think you missed something important:
In the model with a0 if you do not have a competitive pledge you will loose your delegates because you have a bad RoS, and then if your pool is not anywhere close to saturation the benefit of having some pledge is virtually null, in the original model and in yours (because of the factor ((o - (s * ((z0 - o) / z0))) / z0 ). So much likely if you only have 10k 50k, 100k or 200k ADA, then your pool will end up being nowhere near saturation, so your pledge will almost not give you any benefit at all in the first place, whether in your scheme or in the official one, and it is useless to calculate what the benefit for the pledge would be if it was saturated which it will never be.
Now how high a competitive pledge is will not change in your model. Because the k pools that have the largest pledge also higher (sqrt(pledge) * sqrt(crossover)) / total_stake , and then higher RoS. So the competitive pledge will still be approximately the minimum on so that their are only k pools who have a pledge that high. They will attract delegates, then the other won’t be able to become close to saturation and will almost not have any positive effect for their pledge. In short this is a competition of who has the largest pledge. Whether this competition is done in linear space or in square root space does not change the winners.
Also how significant the difference in RoS will be between close-to-saturated pools depends a lot more on the chosen value for a_0 than whether or not we replace s like you said.
So my conclusion on this, in that in my mind we should not add complexity to complexity, I don’t think this proposal solves any of the problems of the reward scheme and formula with a_0 that I think is wrong in the first place.
In the scheme I propose the “benefit” of pledging more is obvious whatever the amount is, and equal whatever the size of the pool is (except of course if is already over-saturated, and has stake above 1/k) .
I realized that I was using the active stake (estimated at 22b) rather than the total stake (estimated at 31b) in the rewards calculation.
This stretches out the curve since the saturation level is higher.
You can see this in the less improved benefit in this recalculation of Alt2.
Assumptions
Reserve: 14b
Total stake: 31b
Tx fees: 0
Fully Saturated Pool
Rewards available in epoch: 29.3m
Pool saturation: 206.7m
Curve exponent: 2
Crossover: 5m
Pledge Rewards Benefit Alt Rwd Alt Bnft
0k 150051 0% 150051 0%
10k 150053 0% 150100 0.03%
50k 150062 0.01% 150160 0.07%
100k 150073 0.01% 150205 0.1%
200k 150095 0.03% 150269 0.15%
500k 150160 0.07% 150396 0.23%
1m 150269 0.15% 150538 0.32%
2m 150487 0.29% 150740 0.46%
5m 151140 0.73% 151140 0.73%
10m 152229 1.45% 151591 1.03%
20m 154408 2.9% 152229 1.45%
50m 160942 7.26% 153495 2.3%
100m 171833 14.52% 154922 3.25%
206.7m 195067 30% 157053 4.67%
Because the a0 pledge benefit is spread over the pledge range from 0 to saturation there is a dependence on k and total_stake.
Since k and total_stake will likely change over time it would be better to express crossover in terms of k and total_stake instead of a fixed number.
One possibility would be
crossover = total_stake / (k * crossover_factor)
where crossover_factor is any real number greater than 0.
For example, setting crossover_factor to 20 with k = 150 and total_stake = 31b gives a crossover of approximately 10.3m.
As @_ilap pointed out, we can generalize the alternative approaches to try out different curve exponents.
This gives us
s = pow(pledge, (1 / curve_exp)) * pow(crossover, ((curve_exp - 1) / curve_exp)) / total_stake
The curve_exp could be set to any integer greater than 0 and when set to 1 produces the current rewards equation.
An interesting set of parameters as an example is
Curve exponent: 3
Crossover factor: 10
which produces
Crossover: 20.7m
Pledge Rewards Benefit Alt Rwd Alt Bnft
0k 150051 0% 150051 0%
10k 150053 0% 150405 0.24%
50k 150062 0.01% 150656 0.4%
100k 150073 0.01% 150813 0.51%
200k 150095 0.03% 151011 0.64%
500k 150160 0.07% 151353 0.87%
1m 150269 0.15% 151692 1.09%
2m 150487 0.29% 152118 1.38%
5m 151140 0.73% 152856 1.87%
10m 152229 1.45% 153585 2.36%
20m 154408 2.9% 154504 2.97%
50m 160942 7.26% 156094 4.03%
100m 171833 14.52% 157665 5.07%
206.7m 195067 30% 159750 6.46%
As you can see this gives meaningful pledge benefit rewards to pools pledging less than 1m ADA.
Just saw your reply @pparent76 .
I will have to think about it and reply tomorrow as it is after 2am here.
@pparent76 I think you have brought up some interesting points and had a good discussion in the other thread on your proposal.
I don’t claim that my proposal will address your concerns, only that it is an improvement on the current system.
I will defer to @Lars_Brunjes and others to discuss your general concerns.
@shawnim Thanks very much for tagging me! I wish that my math skills were up to the task of providing feedback on your proposal.
My contributions are at the conceptual level, and I have trying to understand how the current model works, so I can explain it in non-mathematical terms. I am afraid I am not qualified to give feedback on your suggestions. It looks like there is a good discussion going on, and I hope that Lars and others will continue to engage with you.
Someone also made a really good suggestion in Pierre’s thread about creating a monthly forum with IOHK for mathematically focused conversations. I hope that will happen, as that would be an excellent arena to discuss your ideas.
@AllisonFromm Thanks for the reply!
I think that more than the details of the math the important thing about my proposal is the concept that we need to incentivize stake pool operators to pledge even if they only have 10k, 50kor 200k ADA and we don’t need to give massive rewards to whale pools and private pools for pledging millions of ADA.
I hope that @Lars_Brunjes will respond at some point. I know it has been a super busy time for IOHK with the Shelley release but maybe he will have time in August.
I think it would be useful that you publish a numerical comparison within your model and the current one, as you did above in post 21, but in a realistic situation. For example comparing a 200k-ADA-pledge pool saturated at 1% with a 2million-ADA-pledge saturated at 10% and a 20million-ADA-pledge saturated at 100%. Because a 200k-ADA-pledge pool will never ever be fully saturated in the real world, and if it did it would be a very bad sign that we are very weak to Sybill attacks.