I’m hoping to get the technical content and details correct first. I may have some things wrong or have overlooked details.
Then I would like to gather a large list of community supporters indicating community buy-in, including the largest groups like Binance, Coinbase, Kraken, ADALite, ect. After that has been achieved direct engagement with IOG on a plan of action would be appropriate. IOG has been waiting and can continue to wait for the right amount of community support.
A pledge leverage factor of 1000x was way too high . I changed the initial value from 1000x to 100x in the descriptions and updated the graph. I’m still not sure what an ideal initial value for the leverage should be.
Enhanced some of the descriptions and argument cases.
Open Question:
I have found the original paper and reference for the current reward equation, but I haven’t been able to find any information on alternative reward equations tested or the logic/rationale behind why R/(1+a0)*( … a0…) was selected in the context of Sybil protection.
I just included charts for all of the variations the fee and a0 for the current reward equation and the new reward equation. Descriptions will be added soon. I’m still working on creating histograms of the current stake distribution as a function of pledge to support the question from @KryptoKing . I also made the k-effective formula and relationship easier to understand.
Do I understand your proposal correctly that the pledge determines, when the pool is saturated?
So, with less pledge the plummeting yields because of saturation start earlier?
As a champion for trying to make things fairer for smaller pools, whilst appreciating the need for large and stable pools, I love it! This has my complete support
I really like that you have gone back to first principles and tried to express the original intentions of the parameters in your proposed formula.
I agree with your argument that whales would be incentivised to increase decentralisation through splitting their wallets and staking to other pools. They would furthermore be incentivised to do this in order to spread their reward risk across multiple operators.
I can see across a few channels that this proposal is really starting to gather support from the community. So even if you feel it still could be improved upon, it could well be time to submit it as a PR into the official repository. Three of the people you’ve chosen as reviewers seem to respond to new PRs and it would be helpful to have some more committed dialogue.
Also it would assure that your further edits will be compatible with existing CIPs after forcing a conversion of your document to Markdown. You probably know more than I would about phrasing equations in Markdown (if that’s what you want to do) but I can see this plugin has good reviews and could convert the bulk of your document:
I don’t have an opinion about whether this proposal is desirable, but it appears scientifically well justified. What I can tell you from the CIP editors meeting is that protocol changes have to be well into the pipeline in order to be considered for a hard fork and often when such changes are agreed before a hard fork, they’re planned for implementation in the next hard fork: so time may be of the essence as protocol parameter changes are currently under active review.
You have some interesting ideas on here, and I hope it will blossom into a more robust CIP. Assuming I am interpreting your graph and equation correctly, one potential flaw I am seeing here is the lack of consideration of the pool saturation limit in the reward calculation. I can tell that this may be the case because your equation is missing the beta-parameter (β) which is the saturation limit (see reference 5 of your original document). The factor (1 - σ/β) in the original equation should be maintained as this guarantees the penalty in the reward when the pool stake (σ) exceeds saturation limit (β). The absence of the penalty (1 - σ/β) can be potentially exploited by MPOs, and I can give you a scenario:
Binance currently has 62 pools and about 2.9B ADA which translates to a stake fraction of roughly 12%. Since your CIP does not consider any penalty for exceeding the saturation limit, Binance can even decrease its number of pools to let’s say 2 pools and still keep all 2.8B ADA. This strategy will keep Binance’s 2 pools oversaturated. However, since its stake fraction remains the same, Binance and its delegators will get the same reward. Why 2 pools and not 1? To avoid being segregated with the SPOs.
Consequences:
a) Binance expenditure decreases since it will now be able to decrease the number of pools from 62 to just 2.
b) Since its expenditure can get decreased, Binance can offer even more lucrative rewards which can attract even more delegation. This leads to centralization and weakening against Sybil attack.
3) According to your graph, Binance or any pool can achieve as high as 100% stake fraction (i.e., can acquire all stake) and still retain the >5% reward without any penalty.
I do have a CIP that tackles the same problem as yours, but it utilizes a different approach. I am not sure if the idea I laid down in that CIP will be helpful to you as you try to improve your CIP. Best of luck!
β = z0 = 1/k
It’s in there as the 3rd term, I just purposefully left it written as 1/k to provide clarity.
F( stake, pledge ) = R * min{ stake, a0 * pledge, 1/k * total_stake }
The term (1 - σ/β) is not a penalty, it is part of the incentive pledge yield boosting half of the current equation: λ’ ·α·( σ’-λ’ ·(1−σ’ /β)/β ) . Setting a0=α=0.0 makes that whole term go to 0. I include a case for a0=0.0. The term R * σ’ in the original equation provides the saturation limit based on k. 1/(1+a0) decreases the yields for everybody who isn’t boosted by pledge back to a maximum reward of R.
I’m going to review your CIP and ensure I reference it and all relevant contributions.
Interesting! Do you mind providing the expression for min{stake, a0pledge, 1/ktotal_stake} that you used for your plots? I’m kind of curious because just by basing on the graph you provided, any pool can potentially acquire 100% stake fraction (all stake) and still get >5% reward. What does the plot of reward versus stake saturation looks like using your equation? I think this is a very important plot. Thanks!
Also, if you don’t mind providing a short definition of each term found in the original equation and in your equation - TLDR in a way because the IOG paper is quite lengthy and it’s been a while since I’ve browsed it. Thanks again!
So here are my thoughts about this proposal. Before that I would like to talk about the current scheme
Current rewards scheme uses k as a soft nudge to control saturation.
However it also tries to ensure that the ecosystem has max k pools. Delegators will be at disadvantage if they are in k+1 pool
RSS paper clearly states that single entity running multiple pools is a sybil behavior. To control that a0 would have to be used.
a0 can lead to centralization at best and sybil attack at worst. Now the problem with directly changing this will hurt a budding pool more
What I like about this scheme is the equitable RSS to all delegators.
This scheme effectively makes k as a min value instead of max. So we can have k saturated pools or we can have n*k pools such that k+1 pool delegator is not affected disproportionately.
The clever use of a0 also ensures that there is no benefit for sybil behavior.
This proposal also ensures that the current ecosystem where there are many entities can all be cohesive. Concretely the exchanges don’t get away with 0 pledge and budding pools don’t get affected with their growing pledge
So this proposal effectively uses a0 and k as it was originally intended aka use k for saturation and a0 for sybil and is inclined to the current scheme of things in ecosystem.
I see following challenges with this proposal
Since this changes the assumptions in game theory of the current RSS, this scheme has to be analyzed under modified behavior. In current scheme the rewards are aligned to push delegators towards k pools and the assumption that there will be only k saturated pools
Min fee has to change. This min has be to very low so that pool operators don’t split their pledge and pools. for example if I have 10M delegation and 1M pledge, then I could split into 10pools of 1M delegation each and have 100k pledge in each. So I would get 10*minfee. if min fee is low (or rather just adjusted to cost of maintaining a pool) then I would be discouraged from splitting
Because of game theory changes, I think this proposal will undergo a lot more review by the protocol designers and chances of its implementation is slim until voltaire. So need to start soon
I (PGWAD pool) support this proposal and I think this should be converted to a formal CIP and put up for CIP discussion asap.
