Rewards distribution formula proposal

English General Discussions
, ,
21

I don’t like it because the rewards will be based solely on pledge (absolute pledge, not leverage)

As you write it, I’m really not sure you undestood the formula I proposed.

What it does is set a maximum leverage (as you call it), that I noted b0, that when surpased prevents to get any more rewards, the same that that if your pool is too big in comparaison to k, you don’t get any more rewards.

Exemple: If I have 50K pledge and b0=20, I can get at most rewards for 1M total stake (delegated + pledge ). Any pledge above 1M is not taken into account for rewards. b0 really is a leverage factor.

22

I think our proposals are very similar (Pmin aside). The main difference between our proposals, is that I propose to set a solid leverage “requirement”, that acts as a limit. Pretty much the same way as k does. Where your propose to have a maybe more progressive impact on RoS when leverage becomes too big.

I really think it would be interesting to investigate what the differences are. I have the feeling that if Pmin=1 and Levexp=1 and Levmax=b0 our formulas might be identical or almost identical.

1 Like
24

I replied on the other thread.

25

I can confirm you that if Pmin=1 and Levexp=1 and Levmax=b0 our formulas are identical!

(The one that I proposed was writen f( σ,s ) = R*min(1/k,σ,b0*s) )

I’ll show it under, I’m happy to see that you came to a formula almost idendical that I did, at least in its simplest version.

If Pmin=1 your formula becomes:

f( σ,s ) = R*Levf*σ'= R* b0/max( σ/s,b0)* min( 1/k, σ)

Now let’s consider only a pool where σ<1/k for now. We have for these pools

f( σ,s ) = R*Levf*σ'= R* b0/max( σ/s,b0)* σ

Two cases:

1- If σ<=b0*s, then f( σ,s )= R*σ=R*min(1/k,σ,b0*s) (because 1/k>b0*s>σ)
2- if σ>b0*s, then f( σ,s )= R*(b0*s/σ)*σ = R*b0*s=R*min(1/k,σ,b0*s) (because 1/k>σ>b0*s)

In both cases your formula equals to min(1/k,σ,b0*s) if Pmin=1 and Levexp=1 and Levmax=b0

26

As I wrote in the other thread, I think that the exponential part should be present to avoid steep changes in behavior along the curve. But the concept is the same.

27

As I wrote in the other thread, I think that the exponential part should be present to avoid steep changes in behavior along the curve. But the concept is the same.

Ok I don’t say that the exponential factor should not be there. I should think about that. But I think that’s good to know that before we introduce it, we start from the same basis.

Thank’s.

1 Like
28

Here’s a simplified version without the mininum pledge factor:
image
and some simulations along with it:

image
image1285×620 73.1 KB

image
image1270×610 75.5 KB

image
image1282×612 76.3 KB

image
image1283×626 77.8 KB

image
image1283×631 80.5 KB

image
image1286×627 78 KB

29

Here’s the shape of the leverage factor:
image

30

I want to start a pool and have been thinking why doesn’t system incentivize decentralization better? The other problem is the need for pools to be marketers for delegators. That should be not highly incentivized because that also goes against decentralization. How about we lower the Treasury percentage to provide a reward to a pool in case they don’t mint a block equal to 10% of a block mint reward. If I knew I was guaranteed to get a minimal return of 50ADA for example each epoch for maintaining a good pool, I think that is fair. It could be in addition to your proposal. Would incentivize more SPOs.

1 Like
31

I really like the formula and the thought given into this, I really hope it gains more traction and maybe for IOHK to seriously consider.

I think that Cardano has a thriving community with new people wanting to get into the space everyday. I can see how small pool operators slowly get pushed out due to the difficulty to attract delegators to the pool. Without finding blocks, it’s incrementing costs and the 17% (net cost) to delegate to pool scares away an average investor.

At the end of the day, the average investor wants to make money (not always, but most of the time). The average investing who delegates might not understand all the factors that come into play behind the scenes of staking. In the end, I believe that all of these factors combined makes it extremely difficult for small pools to operate, attract new delegators, or survive.

2 Likes
32

A big chunk of these 17% net costs will be removed when the fixed fees of 340ada is lowered.

1 Like
33

The 340ADA fixed fee is already taken into consideration in the charts reported here. If a small pool has optimal leverage the gross APY will be over 7% and even considering the fixed fee at the current value (340), the effective APY remains good (about 5%, compared to 3% with the current formula).
Of course reducing the fixed fee would further improve the net APY for small pools. I would not go below 250ADA anyway.
We must consider that the effect of fixed costs on APY for small pools have become bigger with the decrease of the d parameter (now 0), since more blocks are produced by community pools and the unit rewards for each block has lowered as a consequence. Now it’s easier to mint a block (about 1M ADA on average), but the weight of the 340ADA has a bigger impact for the pools that mind only a few blocks.

2 Likes
34

@IPIB_Pool

I’ve thought about your proposal to include an exponential factor in the formula you propose in this thread. I think I should first mention the following thing.

I would like to draw your attention towards a problem that concerns your proposal (as well as mine), if applied with no other change than the reward formula itself. It also concerns in a lesser extend, the current formula.

This problem that I would call “DDos on a pool”, allows someone who wants to mostly get rid of a staking pool, to delegate very temporarily a quite large amounts of ADA (in comparison to the pool size) to this pool a provoke a dramatic loss in RoS, so that it eventually looses all its real delegates. Once its done, the attacker undelegates its stake to the targeted pool, and then the pool is left with no delegates and no stake. This attack is of course much easier to perform on small or medium size pools.

I’ve proposed a solution to this problem, by changing the way rewards are distributed within a pool. Everything is described here:

Also it is to be noted that applying such a solution makes it less relevant to worry about how the RoS varies when Lev>Levmax (or σ>b0*s in my notation). In the context where we would apply the workaround for the “DDos on a pool” problem, for now I don’t really see any significant relevance to adding an exponential factor, i.e to choose levexp different than 1. But maybe you can show me otherwise.

I would be very interested in knowing your thoughts about this “Ddos on a pool” problem.

Thank’s a lot for your work!

Cheers!

35

The attack described is possible but I think the proposed solution that takes into account the order of the delegation to exclude the attacker from the rewards seems overly complicated to me, compared to the elegance of the proposed rewards formula.
I think that the DDoS to a pool attack cannot harm the network significantly, because it cannot work on big pools, because the attacker would need a lot of resources. If the attack succeeds on small pools it’s something the system would have to live with, since most of the pools will not be touched.
The priority would need to be the robustness of the network.

1 Like
36

Thank’s for your thoughts,

seems overly complicated to me compared to the elegance of the proposed rewards formula.

Well of course I would not agree with that, tell me explain why.

First I do not find it very complex, both programatically and to understand for the users, especially in comparaison to the current formula with a0. Also it is to be noted that the detailed rules on how are distributed rewards, largly exceeds the simple elegent formula. We could dig into it together if you want. In that context adding this rule seems to me as not increasing very significantly the complexity of the complete set of rules concerning distributing rewards.

Second I do not find it satisfying at all, to leave a real flaw in the system just for sake of simplicity. I don’t think that it has been the philosophy in Cardano devellopement. Complex but flawless solution seem to have always been prefered to simple but problematic ones. Of Course when simplicity is possible it should be prefered, and I adore simplicity, but not at the expense of the proper functioning of the system. Also of course I would be more than happy if we can find a simpler solution that tackle the problem.

I think that the DDoS to a pool attack cannot harm the network significantly

Well it depends on what you call harm. Is a lesser decentralisation, and a system less open to new actors a harm to the network? In the long run I think so.

because it cannot work on big pools

I would not be so confident about that. Several actors have the ressources to perform such an attack on big pools close to saturation. You know for example that exchanges have way more than the resources needed to perform such an attack on big pools. But they are not the only ones. In the scenario Cardano became really big and important and strategic, I would not be surprised if such an attack could be performed by big contries, Knowing the level of cyber-war that happens today on various grounds.

If the attack succeeds on small pools it’s something the system would have to live with

I think we both made our proposal so that small pools may live, where the current formula disadvantage and kill them. I think the small pools are very important to avoid a situation of cartel, where established pools virtualy own the network, in the sense that noone can replace them. So I think it is very important to leave the possibility open for new pools to emerge, and for that purpose that they may start small and grow over time. So I would not agree to say that if small pools get killed " it’s something the system would have to live with". Espcially when there is a possibility to avoid it.

The priority would need to be the robustness of the network.

For that concern, I think the proposed solution only increases robustness of the system, maybe at the expense of a little bit of simplicity. Do you see a way in which it could decrease robustness?

37

Anyway, if we agree to disagree on this “Ddos on a pool” question. :wink:

I would find it very interesting, to help us have a better view about that, that you explain what value or range of value you would consider best for levexp and explain why. On the basis of which indicators should its value be revised (increased or lowered)? Especially what advantage would bring it to have levexp<1 in comparison to using levexp=1?

Thank’s a lot in advance.

38

Wauu… it looks great. Great formula which support the fundamentals of Cardano ecosystem, especially the decentralization which make Cardano network more robust. And also provide more fair rewards distribution. Bravo IPIB good job!

39

@IPIB_Pool, some of the small pools were discussing this subject today in our extra small spo telegram.

I don’t fully grasp your proposed formula but let’s say we set max leverage to 20 do the rewards decrease exponentially when leverage is exceeded?

And second question, why would one want to cap pledge minimum? Imagine a pool has a pledge of 1k. What would be wrong with getting 5% returns as long the total stake is lower than 20k? (Max leverage)? What would be the negative side effects of this.

Lastly, this still seems a great idea. Has it moved into a broader audience or added as a CIP?

40

If the leverage is exceeded the rewards will degrade depending on the exponent. If the exponent is one, the decrease is linear.
Minimum pledge can safely be removed, because the leverage would take that into account automatically, I agree with you.

I did not add the proposal as a CIP, yet.

41

Great, I would say that a hard exponential decrease makes more sense. Pushing large pools with low leverage to act fast and not be able to still profit for a long time as stake increases and pledge doesnt. Dont you think?

Perfect!

I really like this proposal @IPIB_Pool. I think you will get a lot of support if you move it to CIP.