CIP-ShawnMcMurdo-CurvePledgeBenefit

[shawnim]

Here is my initial CIP for modifying the reward equation to use a curved pledge benefit factor.
Let me know if I did anything wrong oryou have any feedback on the CIP itself or it's contents.
Thanks!

[mark-stopka]

There is one more thing to consider, there is little to no justification why private pools with <pledged amount>/<total delegated stake> = 1 should be loosing on rewards, special consolidation for such case should be made to incentivize decentralization in general, if unlimited freedom to decentralize is desired property.

Overall strong case to cosnider relative pledge over absolute pledge could be made, I am little disapointed to see how little discussion is being given to te reward sharing scheme proposal you've made.

[shawnim]

Thanks for the reply Mark!I don't understand what you mean about 100% pledge pools losing rewards.Can you explain or give example? I am also a little disappointed that there has been no response at all from Lars or anyone at IOG.Even to say, "We are too busy to consider this right now" or "That's a terrible idea because ...".I appreciate you taking the time to consider this as I think it is important to the long term health of the network and the short term viability of smaller pools. On Saturday, August 22, 2020, 11:38:00 AM PDT, Mark Stopka <[email protected]> wrote: There is one more thing to consider, there is little to no justification why private pools with <pledged amount>/<total delegated stake> = 1 should be loosing on rewards, special consolidation for such case should be made to incentivize decentralization in general, if unlimited freedom to decentralize is desired property. Overall strong case to cosnider relative pledge over absolute pledge could be made, I am little disapointed to see how little discussion is being given to te reward sharing scheme proposal you've made. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mark-stopka]

Both your proposal and current model rewards pools based on the absolute amount of pledge regardless of their pledge to delegated stake ratio, in reality if decentralization of consensus would trully be the goal, you would make it as rewarding as possible for any single participant to participate in consenus decentralization.

There will of course always be non-zero cost to entry due to pure fact that running a pool requires some infrastructure and knowhow, however there is simply no reason to (additionaly) punish people who have both the infrastructure and the resources to operate their own pool which is fully pledged by their own stake.

If one has 1M ADA and decides to operate own pool with 1M ADA pledge, thus resulting in a scenario where pledge = total delegated stake, any such pool should be always elligible for full rewards.

[cffls]

This sounds like a good idea that definitely worth more attention. However, I am a bit lost at the point when crossover point is introduced. Maybe some sort of graph visualization will really help more readers to understand. Although it could be done later, I also think a formal mathematical proof that the new curved pledge mechanism will reach a Nash equilibrium is going to make the case more compelling.

[mark-stopka]

Although it could be done later, I also think a formal mathematical proof that the new curved pledge mechanism will reach a Nash equilibrium is going to make the case more compelling.

A) Making a formal proof is pointless if the gatekeepers don't even bother to react.

B) The proof is already pretty much present in Reward Sharing Schemes for Stake Pools, as long as pledge benefit function is growing up to the k for actors who want to gain the most influence over the system and achieve olygopol stake of control, the only thing this changes is the pace, as long as motives are the same as assumed in the beforemention paper, outcome is also the same.

[shawnim]

Thanks for the reply cffls!
I will try to come up with a visualization of the pledge benefit vs pledge graph showing crossover but it may take me a little while to figure out how to do that.
Also, thanks Mark for explaining about the proof! That was my intuitive understanding but mathematical proofs are beyond my capability.

[Danmcg86]

Hello

I am not a programmer or mathematician, but I am a pool operator for Cardano (MOST) and several other projects. What I wonder most about the way Cardano approaches this is not so much what is being paid as incentives for staking and prevention of Sybil attacks, which seems solid. What I believe is missing is incentives/penalty mechanisms for operating poor performing relays and BP Nodes.
Currently, if you have a large following, you can set up a pool (or Multiple pools) at a very low margin, set up a relay to feed those block producers and be able to produce blocks. You attract a large following based on your low margin and you are rewarded. With the emphasis on producing blocks you attract many more stakes. You can do this with a single relay or 2 and keep operating costs low. Under the current scheme, a 10,000 stake will be rewarded at a set ROI. Number of blocks produced is not a concern as long as the pool produced what was expected. With multiple pools, you can make a good profit for the 340 minimum epoch charge.
For a small pool operator, you can set up a pool and even if you have a 50k to a 400k pledge, you are unlikely to produce a block. So a 10,000 staker to my pool will not be rewarded. In my case, I set up a block producer and 2 relays all at 4 Processor/ 8GB RAM. I have a 50k pledge and another 30k staked from my wallet (Over 10k investment) My relays and block producer are functioning at the same level as any pool, yet none of my stakers would have a chance of getting that reward.
With the emphasis on decentralization, it would seem to me that if that hypothetical 10k stake would be rewarded the same in any of the top 25 pools, why should it not be rewarded in a smaller pool. Currently there is no measurement on how a pool performs relative to connections. If we wind up with only 25-50 viable pools, the network can be susceptible to several different types of attacks.
My point is if we treat a 10k stake the same as long as it is in a large pool, why not put emphasis on utilizing the infrastructure of the small pools and build a bigger network. In the Loki project, block creation is done in listed order. You produce a block and then go to the bottom of the list. They measure uptime performance and penalize the node for missing uptime proofs. The penalty can be severe, 30 days locked out of being able to stake for the operator thus no rewards. You gain credits as you go along, so a certain amount of downtime can be allowed, but over 2 hours, you get decommissioned and then banned after you exhaust your credits. With Cardano, there are many more blocks in an epoch, so you could have multiple lists, putting the largest pools on a smaller list, and small pools on a large list, and then selecting the top pool on a list in a rotating manner.
Setting metrics around network performance and going to a listed approach may be a possible solution for Cardano. You can still keep the same reward formula’s and treat every stake the same, reward good performance and set a requirement for two relays. Eliminate the minimum epoch charge, while setting a minimum margin charge. This way, if you want to set up a charity pool or a small pool based on limited resources your entry point won’t be blocked by the fact you need to attract several million ada, you get more pools participating and you utilize everyone in the community who wants to participate.

Thanks for reading, I only want to make Cardano a better place!

[mark-stopka]

@Danmcg86 while change in reward-sharing scheme would be relatively simple change with simple evaluation of impact, what you're proposing is a major change in consensus algorithm rules, it is also less secure (as the schedule or as you call it ordered list is known ahead of time to all participants), Cardano works with Ouroboros family of consensus protocol, specificaly Ouroboros Praos used on Cardano mainet, there are also further itterations of Ouroboros consensus such as Ouroboros Chronos and Ouroboros Crypsinous.

If the leadership schedule is not known to the network ahead of time, punishing anything like a missing a block production slot is obviously not easy and would require extensive research, what you are proposing is similar to the initial design of Ourobors which utilized Multi-Party Computation in previous epoch (n-1 or n-2, I don't remember anymore) to determine a leadership schedule for epoch n, while it had certain upsides over the Verifiable Random Functions utilized in the current algorithm, reverting back to that would be technological a step back.

This discussion is focussed on the incentives (reward sharing scheme) and sybil protection which you can refer to in the preivously linked paper.

[Danmcg86]

Thanks for your response. I appreciate it. I was trying to state that I see some issues with the way the current implementation is unfolding and I believe that some incentives need to be looked at. As I stated I am not a programmer and would not propose any algorithm change. I wanted to give feedback from what I am seeing as a new SPO. I really believe in the project and wanted to give some perspective in a formal setting as opposed to a chat forum. I am confident that the team will find a way to make the proper changes. It is very early in the Shelley era and I think many of these issues will be resolved. I do appreciate your feedback and appreciate all of the work put into the project by all the teams.

[angelstakepool]

I hold the opinion, even before implementation of shelley mainnet, that linearity is a flawed approach

• agree that private pools do not make the network much more secured and are rewarded unfairly vs all the SPO who are really the backbone of the network. These unfair reward schemes do not help Cardano as a projects, not only for the obvious objective reasons, but also because this could be used by competitors to put Cardano under a bad light.

• it does not take into account sweet spot of pledge for SPO; a heavily non-linear max rewards vs pledge in the interval 0 pledge to 300-500k pledge could be the solution. After that, and up to max pledge , a very easy slope could be used.

• Linearity is too simplistic, and does not discentivize opportunistic behaviors of some SPO who have a large following and thus take advantage to run a large number of pools using a low pledge in each. This goes against centralization: 100 operators each running 10 pools vs 1000 each running 1 pool.

• It promotes a race to the bottom, because the potential reward of a pool with 0 pledge and another with 500k pledge is only an insignificant 0.2-0.25% (it should be at least 1% of difference, which will incentive SPO in concentrating efforts, marketing and financial resources in a single pool, instead of running several at much lower fees)

• I agree that IOHK mathematicians & programmers should pay more attention to these types of proposal, not to take them verbatim ofc, but at least to consider the underlaying ideas in a serious manner. Dismissing an idea as inferior has no place in the world of open source and decentralized blockchains

[mark-stopka]

agree that private pools do not make the network more secured and are rewarded unfairly

You are the only one arguing that (I am arguing the exact opposite), I believe it is a false statement, private pools do make the network more secure as the high network value (and thus network security) is in their selfish interest. Which is actually why I argue that the pledge influence should not be calculated as absolute value regardles of ratio between pledged amount and total delegated stake.

I agree that IOHK mathematicians & programmers should pay more attention to these types of proposal, not to take them verbatim ofc, but at least to consider the underlaying ideas in a serious manner. Dismissing an idea as inferior has no place in the world of open source and decentralized blockchains

I don't believe anyone would imagine this will be how CIP process will look like, as per CIP1 we should be in a phase Wait for approval and/or feedback from the CIP editors, how long does that suppose to take? Proposal is here for 2 weeks yet, nobody from the edditor community bothered to provide feedback.

@crptmppt, @KtoZ, @SebastienGllmt, @dcoutts, as per beforementioned CIP1

CIP editors should strive to keep up to date with general technical conversations and Cardano proposals

How is up-to-date defined in the context of CIP1? It has been mentioned in one of the AMAs by CH that the rewards sharing scheme has been looked at during a Chief Scientist Meeting, has this proposal been considered (he was not specific as to what proposal has been a subject of that meeting)? Are meeting minutes available? What are there any concerns to be addressed?

[shawnim]

Here are 2 graphs that show the pledge benefit vs the pledge amount.
Both of these are for the example parameters of curve_root = 3 and crossover factor = 8.
The first shows the full range of pledge amounts.
The second shows only pledge amounts up to 1m ADA.

[crptmppt]

Hi @shawnim - quick note to say the CIP is being noticed and we hope to loop back in one of the upcoming meetings to review.. Meanwhile grateful that the conversation is occurring naturally! The CIP process is for now a very asynchronous and careful process - and priority was originally given to internal efforts needed for collaboration and publication - Expecting further thorough review/feedback here soon!

[shawnim]

@crptmppt Thanks for the status update!
I look forward to any feedback and discussion.

[mark-stopka]

@shawnim BTW my proposal can be elegantly combined with your proposal if you'd like, we can discuss that off-line and make a joint proposal.

[cardanpool]

I am not mathematician too, but everything that helps cardano descentralisation and more opportunity of rewards to small pools should be consider seriously. Currently there are many pools that are struggling. I've heard already bad comments or dissapontments and that is not health for the entire ecosystem. Imagine that this is just the begining and there are already bad vibes between small pools (the majority, and the core of the network). So in order to prevent more dissapontments between in the ecosystem these proposals need to be analized as soon as possible. Hope CIP can be analized and taked in count.

[cffls]

Thank you Shawn for coming up with graphs! It shows that the pledge amount has higher influence on rewards in lower range, while the influence decreases as the pledge increases.

I think an another important aspect of the issue, other than defining the reward function, is that we need a more transparent process to determine the value of these parameters (e.g. curve root, cross over factor).

Here are some topics I would like to see being discussed:

1. How do the chosen values impact either positively or negatively on small and big pools? What is the definition of small and big pool?
2. What group of pools benefits most from the decision?
3. Does the most benefited group represent the majority of pool operators?
4. What defines majority ? e.g. the number of pools v.s. the stake controlled by pools.

There are definitely better questions that are not in the list, please help add to the thread.

[mark-stopka]

I think an another important aspect of the issue, other than defining the reward function, is that we need a more transparent process to determine the value of these parameters (e.g. curve root, cross over factor).

I haven't done a formal analysis of this but intuitively I would say that if the initial proposal from @shawnim is adopted alone, these numbers need to be a moving target (they should've been from even for the current scheme when minimal fixed costs per epoch were introduced), just like there is a race to the top in PoW mining power, there must be a race to the top with pledge (for pools that accept public delegations), which is why I made my first comment.

I would not consider the proposal to be a solution but rather a temporary bandate, the initial model (linear pledge influence) was relatively good until it got skewed by minimal fixed epoch costs.

Pledge to stake ratio is more fair and at least as secure as absolute pledge if not more in reasonably competitive environment, most importantly it does not punish those who choose to take network security into their own hands when they see negative patterns emerging, PoW chains also self-regulate e.q. BTC miners moved in 2014 when GHash.IO gained 51% of hash power, with current model you punish under certain conditions those who decide to act agains negative consolidation trends.

There is a reason why PoW employs dynamic difficulty adjustment.

[stakepoolplace]

Hello guys, is it possible to change the formula 1 day per week in order to have a complete random distribution of rewards (a lottery) because with the formula only pool with high pledge or stake are rewarded ?

[stakepoolplace]

There is many pools at 0 block minted today ! They will quit i think.

[shawnim]

@mark-stopka I think your idea is definitely worth considering but I think it is better to do it as a separate CIP. It may make it more complicated and contentious to join them.

@stakepoolplace That is an interesting idea! I think it would be a big change from a design goals perspective that would need discussion and research. Perhaps it could be a percentage of blocks that are lottery blocks between all pools that have at least a small minimum pledge.
You should create a separate CIP for this.

@crptmppt It has been 11 days since you said "we hope to loop back in one of the upcoming meetings to review." and 24 days since I submitted this CIP. Considering that the first step is to simply review that the CIP is properly submitted and change the status to "Draft" and has nothing to do with the content, I don't understand why
this is taking so long. It would be helpful if there was a defined timeframe for this initial step and some sort of regular schedule of review or status update after that.
@KtoZ @SebastienGllmt

It has been more than 2 months since I proposed this idea but there has been no response from anyone at IOG.
I would love to see any kind of feedback on the idea and/or implementation alternatives even if it was as simple as "It is an interesting idea but we are too busy to consider it until after ...fill in milestone or date..."
@brunjlar @romainPellerin @solegga

[crptmppt]

@shawnim
The CIP process is intently slow - meetings happen every two weeks and we're still tweaking the process (please see meeting notes for visibility). We're improving the comms as we go, I know this particular proposal has had visibility all the way up and have personally brought it up.

[shawnim]

@crptmppt Thanks for the update!
Just want to know that things are moving forward and not ignored.
Appreciate the response.

[feqifei]

Hi, here a possible formula to calculate rewards, before applying the apparent performance factor, basis on a relative pledge concept introduced by @mark-stopka in his first comment.

This formula still takes into account the "k" parameter (in the variable sigma' in case pool stake/total stake exceed 1/k) as a threshold to avoid centralization. In case of low or null fixed costs "k" parameter could be unnecessary.
Through this formula the pool owner receives full reward (before applying apparent performance factor) in case his pool stake corresponds to the owner pledge and the pool is able to produce at least one block.
As attachment an excel file to test some simulations.

CIP12 relative pledge simulation.xlsx

[gufmar]

I like the general idea because it has "desired" orientation points

From my understanding when we talk about reward benefits this is related to increasing/lowering a0. Not anymore in a linear way. But as a sum of all pools it might change significantly because pools are incentivised to choose pledge amounts with higher reward benefits.

But this does not only affect pools with a currently low pledge. We also need to think about the effects of very large players.

The proposed curve looks logarithmic. It might worth think about a 3-degree curve to deal with participants who can fully pledge their pool. This should motivate them to run fewer pools at full pledge instead of splitting them up to xx high pledged (desirable) pools able to attract a lot of delegations. This would actively kick out numerous other pools from the k-area and significantly work against decentralisation.

^ this is just a quick sketch but generally said the benefit for this big whales should be slightly larger then what they can achieve with competitive margins by collecting huge amounts of delegations. They inevitably will earn more rewards then, but not at the cost of binding too much delegator stake

For sure there is no perfect way to design this curve. A whale holding 30-80% of saturation point still is motivated to split his pools up. But significantly increasing reward benefits to early (eg from 50% of saturation) increases the risk whales able to fully pledge multiple pools will split this up with all the undesired effects.

[shawnim]

Thanks for the thoughtful response @gufmar !
It is worth exploring with some various scenarios to understand whether this is necessary.
The superwhale who can fully saturate their own pool would be taking a risk to accept lower pledge benefit rewards from multiple smaller pledge pools in exchange for the fees they could make from potential delegators.

FYI, the rich list shows the following high value addresses:

# ADA
4 250m+ (1.39b, 1.38b, 1.09b, 604m)
7 211m+ (k = 150 sat)
9 159m+ (k = 200 sat)
14 127m+ (k = 250 sat)
39 100m+ (15 108.66m)
58 50m+ (9 64.11m)

Many of these high value wallets belong to IOG, Emurgo, CF, Charles, etc.
Even with k set to 250 there are only 14 wallets that could fully saturate their own pool.

My intuition is that the curve up at the high end is not needed but it's certainly worth evaluating different scenarios of pledge and delegation to confirm.

[NiekSj]

Pools need to be registered somewhere. Is there no way to limit the number of pools by checking any given data, given the fact that around the globe governments are thinking of ways to legalize the use of Crypto currencies but still get all tax paid on profits on Cryptos. I am aware that super whales could start multiple companies but the costs of having multiple companies, just to be able to run multiple stakepools to get higher rewards looks not logical to me.

[Colin-Edwards-IOHK]

K should be viewed as a minimum number, not a target number of pools We do not want to be using K in a way that forces convergence (beyond what is already implied.) This is particularly important at low levels of K, aka 150: killing off 850+ stake-pools would be an extremely short sighted thing to do Right now, pools are incentivized to split into smaller pools with high leverage You return on investment (ROI) is of the form ( A*(1-x) + B*x ) / x, where x=proportion of the pool pledged i.e., You get a return from proportion of the pool you don't (the variable fee) plus plus a pledge benefit from the part you do own, then divide this through by how much money you had to invest Things to consider, no particular order: 1. We don't want funds running "private pools" that are fully pledged, and distributing rewards like tezos "bakers", to become the de-facto standard There is a limit to where we can push A0 too. 2. Changing K has a fairly large impact; the pledge reward is for a "fully saturated" pool, so increasing K (reducing maximum pool size) is a linear increase to value of pledge 3. "High leverage" pools (i.e., lots of delegation to pledge) are fairly problematic - we want pool operators to have some skin in the game. 4. Higher amounts of pledge unlock more rewards for everyone, so also beneficial for everyone 5. Once a pool gets beyond about 10% pledge, the benefit becomes fairly linear. The rewards for adding more pledge outweigh the loss from less delegation. 6. We probably are not THAT concerned about a 30% pledge pool splitting into two 15% pledge pools; while we might prefer a pool stay pledged to share delegation around, this is not really "sybil" behavior either 7. The really problematic area is the low pledge pools... scaling like (1-x)/x ... as pledge goes very small the ROI increases massively, incentivizing you to create more low pledge pools rather than adding more pledge

…

On Sat, Sep 26, 2020 at 8:08 PM Robert Stanfield ***@***.***> wrote: This may make sense, maybe not, just thinking out loud. Maybe the statistical mode could help us figure out how the curve should be set. We could sort the pledge amounts currently on the block chain each start of an epoch and then remove the lowest pledged pools till it matches k. At this point we could then find the mode of the left over pledges and determine at which point the curve should transition from an aggressive slope a more subtle one. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQEOU7ZEYQQKWSNLCP4ZNMLSHY32JANCNFSM4P4NXLQA> .

[crptmppt]

Approving as discussed - with the note that Shawn agreed to merge without Copyright pending Legal feedback. (could be remove post-merge)
Moving to merge as 'Draft' to bring conversation in the open.

[Colin-Edwards-IOHK]

@shawnim I finished initial modeling on the economics of the proposal, forwarded the results to our formal methods team at IOG for review. I will reach out to you next week to discuss (it's getting late on a Friday, just wanted to let you know this was in fact moving.)

@mark-stopka your suggestions were also evaluated as part of my analysis, your feedback here was very helpful.

[shawnim]

@Colin-Edwards-IOHK Thanks for your work on this! Really appreciate it.

[Colin-Edwards-IOHK]

@shawnim Given we are still establishing a process for CIPs; your feedback would be really appreciated, specifically on how to handle this kind of thing better in the future. I'd personally like to see a bit of a round-table discussion on "the Cardano Show" or something. As we shift to more community engagement I want to make sure we get the lessons out in front of people!

[mark-stopka]

Have you formalized my proposal as well? My scheme is almost the same as I intend for tehelemtry sidechain, it would save me time and money if I could reuse your model or use it as a starting point. Please [see dCloud on Project Catalyst IdeaScale page](https://cardano.ideascale.com/a/dtd/Decentralized-Cloud-Platfom/322909-48088)...

…

-- Sent from mobile Best regards / S pozdravem, BSc. Mark Stopka, BBA Managing Partner @ PERLUR Group mobile: +420 704 373 561 website: www.perlur.cloud

On Fri, Oct 9, 2020, 18:24 Colin ***@***.***> wrote: @shawnim <https://github.com/shawnim> I finished initial modeling on the economics of the proposal, forwarded the results to our formal methods team at IOG for review. I will reach out to you next week to discuss (it's getting late on a Friday, just wanted to let you know this was in fact moving.) @mark-stopka <https://github.com/mark-stopka> your suggestions were also evaluated as part of my analysis, your feedback here was very helpful. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKMP3F2KUGR4ZRSJ7OXSPLSJ42L5ANCNFSM4P4NXLQA> .

[mark-stopka]

I would love to participate in such discussion, I believe my involvement not only in this CIP gives me enough insight 9nto the CIP process to be able to use my knowledge of Lean and 6Sigma methodology to improve upon the current CIP process.

…

-- Sent from mobile Best regards / S pozdravem, BSc. Mark Stopka, BBA Managing Partner @ PERLUR Group mobile: +420 704 373 561 website: www.perlur.cloud

On Fri, Oct 9, 2020, 18:38 Colin ***@***.***> wrote: @shawnim <https://github.com/shawnim> Given we are still establishing a process for CIPs; your feedback would be really appreciated, specifically on how to handle this kind of thing better in the future. I'd personally like to see a bit of a round-table discussion on "the Cardano Show" or something. As we shift to more community engagement I want to make sure we get the lessons out in front of people! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKMP3HOPVOOOEHJOMHLTYTSJ44ABANCNFSM4P4NXLQA> .

[Colin-Edwards-IOHK]

@mark-stopka yes, your feedback was included in my analysis, hopefully fairly ;-)

Speaking of round-tables, it might also be useful to get you, me, Shawn, some of our research team (Akaterini? Lars?) together to talk through the implications of the a0 change as well (maybe separately to improvements the CIP process, although maybe at the same time.)

I'll freely admit having a agenda here; we need to practice giving up some control over the system. As we are starting out the CIP journey, I hope we can use this as starting off point on doing that well: having a real dialogue about the changes being proposed, giving key influencers a forum to talk about their ideas. Getting a decentralized frame work to work, where decisions can still get made promptly, is a work in progress. I am hoping not to just get this change done, but also done in a way that helps future changes go more smoothly.

[mark-stopka]

@mark-stopka yes, your feedback was included in my analysis, hopefully fairly ;-)

Speaking of round-tables, it might also be useful to get you, me, Shawn, some of our research team (Akaterini? Lars?) together to talk through the implications of the a0 change as well (maybe separately to improvements the CIP process, although maybe at the same time.)

I'll freely admit having a agenda here; we need to practice giving up some control over the system. As we are starting out the CIP journey, I hope we can use this as starting off point on doing that well: having a real dialogue about the changes being proposed, giving key influencers a forum to talk about their ideas. Getting a decentralized frame work to work, where decisions can still get made promptly, is a work in progress. I am hoping not to just get this change done, but also done in a way that helps future changes go more smoothly.

Hi @Colin-Edwards-IOHK, I am happy to participate in any round-table, I would also like to see (even privately under NDA) your assessment of my proposal comments / ideas as it is a foundation of the dCloud side-chain...

I was told you spoke highly about my input, so I appreciate that!

[shawnim]

@Colin-Edwards-IOHK I would be happy to participate in any discussion of the CIP process or of particular CIPs.
It would be great to have some dialog with the IOG researchers since they have been publicly silent on this and the Non-Centralizing Rankings CIP.

[Colin-Edwards-IOHK]

As an update to this, my analysis is being reviewed by Elias, Lars and Katerini from the IOG research team. They will be focusing on the game-theory analysis; depending on their feedback we might have a couple more iterations. The research paper from 20 June, 2020 came to different conclusions than I did, so it's still a conversation not a finished decision, but it is an active conversation.

(Off-Topic: I have asked Tim/Ben to get wider engagement from the community regarding the rankings CIP. I personally see no reason why a requested measure should not be incorporated in Daedulus if it was popular enough. There is a development pipeline to work around but I hope to at least get some clarity as to when/how a decision will be made for that soon. It feels more like a "daedulus the wallet" issue, not a "cardano the blockchain" issue, so I have not been personally very involved.)

[Colin-Edwards-IOHK]

Once again an update to say we are still actively working on this. The internal discussions between myself and our research team are progressing, think we have identified a strategy that everyone seems comfortable with. I am working on writing that up, once that gets reviewed, will bring it to the wider community for review/discussion as it has some changes to the original CIP above.

[shawnim]

Thanks @Colin-Edwards-IOHK for the updates!
Really appreciate your open communication.

[Colin-Edwards-IOHK]

I am still working on a more formal response to all this; so apologies for the lack of polish. (Our game-theory researchers are also working through it still as well.) I mostly just wanted to give you a bit of color on what we were thinking about and why things are taking a long time.

In the initial statement you had two items: [1] increase incentives for pool operators to pledge thus increasing Sybil attack resistance while [2] reducing exorbitant rewards for private and whale pools to a more reasonable amount. I strongly agree with the first, it's very consistent with the philosophy and modeling work that has been done. I don't agree with the 2nd point, I'll briefly go over that, but it's a bit of a rabbit hole of a discussion, so it'll be a bit of hand-waving to move things along.

In the chart below there are the additional rewards that pledge attracts in an otherwise unsaturated pool at K=500. It's really small; so small that it is totally overwhelmed by things like block creation which has a large component of random noise. I strongly agree with the idea that this pledge benefit needs to be significantly increased to affect "human decision making". I've also sort of taken the approach of focusing on this one aspect of your CIP - it seems like the most important thing to resolve.

In terms of the "Return on Investment" for bigger pools; we don't have a lot of room to do stuff there. There is a huge trade-off between whether exchanges, funds, whales, etc. lock up their funds in private pools or use the pledge to dominate the SPO business. The main thing to get out of the chart below is that on the right hand side it needs to be either flat or upward curving or else exchanges will all actively start competing for delegation.

So to recap:

Because of that, I have been looking into alternate forms of the rewards.

There are a couple flavors of things I have tried; the most promising is just added a flat pledge benefit by changing the a0 formula to have an intercept and a slope. That intercept can be zero, which keeps the existing behavior, and goes all the way to totally flat for a something more along the lines of Mark's comments. It converges to the existing behavior for saturated pools (which makes it consistent with all the research on stable Nash equilibriums.)

A couple pictures to show how this changes for different types of pools

Fully Saturated

Only-Pledge

A flat benefit of between 5% and 25% tend to behave very well in my simulations, which base behavior off things like "present value of cash flows". In terms of running a staking business, this makes having additional pledge immediately more meaningful, has higher earnings for all small pools and much better earnings for high-pledge small pools, causes real differentiation on the pool dashboards other than by dropping the variable margin to 1% or less.

I have looked at the long-term impact on the reserves, but since the main beneficiaries are small pools with relatively low levels of pledge on a "percent of a saturated pool" basis, it's pretty minimal, different milestones a couple months earlier over a decade.

I know it's gone a bit far afield from the initial CIP!

[shawnim]

Thanks @Colin-Edwards-IOHK for all of your work on this!
I really appreciate the updates.
What you have described all makes sense to me.
I'm not tied to my original proposed solution for making pledge meaninfful. Only that something is done to make it meaninfful in a fair way.
As for reducing the top end rewards I understand the point about encouraging exchanges to fully pledge pools rather than create many pools and try to attract delegation. So on that I defer to your (and the research team's) expertise on finding the right balance of top end rewards.
Happy to see progress on this!

[prometheus-pool]

@Colin-Edwards-IOHK Very cool post, sorry if this is tangential but I was wondering about your comment about exchanges using their funds to dominate the SPO business. It does make sense to me that we'd rather see exchanges self-saturate via pledge, but is there also concern that rewarding exchanges for doing so will allow them to offer higher rewards for people to put their ada on an exchange and hold it there instead of in daedalus and staking to others?

[feqifei]

@Colin-Edwards-IOHK , thanks for your work on this
I understand your point about exchanges too and it's a very good one.
What is not so clear to me is about the left side of the graph. I was thinking that one of the purposes of @shawnim 's proposal was to find a way to amplify the effect of a0 also on the lower range of pledges between 0 and 2M, where most of operators are lied on in order to push the increase of pledges and, as consequences, give operators more rooms to increase fees while remaining competitive to zero-pledge/zero-fee pools.
If I read correctly graphs of your proposal, and I doubt it, it seems to me that the a0 effect is even more mitigated for the lower pledge range of 0-2M. Am I wrong?

[hashedbits]

@Colin-Edwards-IOHK

I would like to thank you for looking into this important matter.

I understand that we might have a problem with incentives if larger pledges in the network earn less rewards than smaller ones (where the majority of SPOs would feel comfortable operating). So I share your view above...

I also see that the propose reward function above, starts off all pools at 15% ROS. The differentiated returns don't kick in until the pool has a pledge=40% of saturation.

This is a problem because:

1. It does not solve the problem of low pledge pools, as it does not introduce differentiated returns till the pool is 40% pledged.
2. At k=1000, which is a target state, a pledge = 40% of saturation equals 13M, which only one SPO may be able to afford out of 1k+. Even then the motivation to pledge that much remains questionable due to the steepness of the curve (or rather lack thereof).

So I have been testing different scenarios with the original function proposed by @shawnim and may have come with something that would allay your earlier concerns with it, while providing the necessary difference in returns in the lower range of pledge distribution.

Here is the sensitivity table with graphs comparing the results of the function with the status quo.

Note: this CIP scenario seems to create negative returns for pools with pledges at 500K unless the pool size equal 6M... so maybe the curve should be modified a bit to eliminate those scenarios. This may be it's shortfall for pools that are just starting... but it does solve some of the above problems. Game theoretically I it can encourage the stake to join pools with higher pledge as they maximize profit. It can lead to higher levels of pledge in the system, which ultimately improves security.

Alternatively we could look into just changing the rho+a0 parameters together in the current curve to arrive at an acceptable solution.

I have also attached the excel file for your convenience.

shelley_rewards_wdv.xlsx

PS: updated the file and the table after finding some inaccuracies.

Thank you again,

Umed Saidov, CFA [SKY]

[fastism]

@Colin-Edwards-IOHK Very cool post, sorry if this is tangential but I was wondering about your comment about exchanges using their funds to dominate the SPO business. It does make sense to me that we'd rather see exchanges self-saturate via pledge, but is there also concern that rewarding exchanges for doing so will allow them to offer higher rewards for people to put their ada on an exchange and hold it there instead of in daedalus and staking to others?

@prometheus-pool @mark-stopka Remind me about Mark's idea that a0 should affect ratio of pledge and total delegated stake so big pools need to pledge more.

[mark-stopka]

Exchanges can achieve largest rewards either way if they sufficiently restrict customer widhrawal policies + they have strong motivation to have people to encouraged to keep funds on exchanges, because they are then more liklely to trade which generates fees for the exchange which is the primaqry source of revenue for the exchange.

[jbax]

K should be viewed as a minimum number, not a target number of pools We do not want to be using K in a way that forces convergence (beyond what is already implied.) This is particularly important at low levels of K, aka 150: killing off 850+ stake-pools would be an extremely short sighted thing to do Right now, pools are incentivized to split into smaller pools with high leverage You return on investment (ROI) is of the form ( A*(1-x) + Bx ) / x, where x=proportion of the pool pledged i.e., You get a return from proportion of the pool you don't (the variable fee) plus plus a pledge benefit from the part you do own, then divide this through by how much money you had to invest Things to consider, no particular order: 1. We don't want funds running "private pools" that are fully pledged, and distributing rewards like tezos "bakers", to become the de-facto standard There is a limit to where we can push A0 too. 2. Changing K has a fairly large impact; the pledge reward is for a "fully saturated" pool, so increasing K (reducing maximum pool size) is a linear increase to value of pledge 3. "High leverage" pools (i.e., lots of delegation to pledge) are fairly problematic - we want pool operators to have some skin in the game. 4. Higher amounts of pledge unlock more rewards for everyone, so also beneficial for everyone 5. Once a pool gets beyond about 10% pledge, the benefit becomes fairly linear. The rewards for adding more pledge outweigh the loss from less delegation. 6. We probably are not THAT concerned about a 30% pledge pool splitting into two 15% pledge pools; while we might prefer a pool stay pledged to share delegation around, this is not really "sybil" behavior either 7. The really problematic area is the low pledge pools... scaling like (1-x)/x ... as pledge goes very small the ROI increases massively, incentivizing you to create more low pledge pools rather than adding more pledge
…
On Sat, Sep 26, 2020 at 8:08 PM Robert Stanfield @.**> wrote: This may make sense, maybe not, just thinking out loud. Maybe the statistical mode could help us figure out how the curve should be set. We could sort the pledge amounts currently on the block chain each start of an epoch and then remove the lowest pledged pools till it matches k. At this point we could then find the mode of the left over pledges and determine at which point the curve should transition from an aggressive slope a more subtle one. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQEOU7ZEYQQKWSNLCP4ZNMLSHY32JANCNFSM4P4NXLQA .

Could we use token locking to give extra rewards to delegators (and pool operators) who freeze their funds delegated into any given pool for a given amount of time? That intuitively would drive delegators to lock their funds for a while to increase network security. It would also allow us to get rid of pledge altogether as any pledge formula rewards exchanges/funds no matter how the formula looks like. Finally, getting rid of pledge would not expose pool operators and their families to criminals who can physically try to harm them either (coming from a 3rd world country, this hits me the hardest)

[chbfiv]

Great comments. Thanks for sharing this in the blog post also.

@Colin-Edwards-IOHK can you try to explain in simple terms what this would mean for smaller stake pools and how it may or may not impact how larger pools split?

My attempt to understand so far is more or less the following:

If the distribution of rewards (not sure is that is the same as benefit here) for smaller pledges is increased (still targeting 30% at full saturation / pledge), then the total rewards isn't changing. Just that the more successful pools will subsidize the smaller pools to allow them to bootstrap and compete? Then when K = 1000 at some point, more blocks will be created by smaller pools and provided that additional opportunity to sustain themselves until they can work towards more pledge their their community efforts/contributions?

[shawnim]

Here's the link to the IOG blog post by Colin that talks about the IOG response to this proposal and related issues:
https://iohk.io/en/blog/posts/2021/03/04/not-long-till-d-0-day/
Looking forward to IOG publishing the details on the new rewards function.

[danhosg]

A large part of solving this puzzle will be at Daedalus and Yoroi wallets functionality to provide a more comprehensive multi-pool delegation capability that is more intuitive for the end-user. I wrote a blog post about this with some thoughts on possible alternative solves to support decentralization. Taking the general population the way banks would treat mass market consumers, the UI/UX and options on Daedalus/Yoroi would be a crucial piece to solving this puzzle, as alluded to by the iohk blog post by Colin as well.

https://www.cardano-official.sg/blog/why-the-k-parameter-is-not-enough

[rphair]

@danhosg if interested in that vein, please pressure your facilitators at IOG Marketing to help get the "multi stake pool links" part of this CIP implemented: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/CIP-0013.md#specification

... along with @KtorZ 's equivalent for more articulated multi-pool delegation with JSON files: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0017/CIP-0017.md

... and provide your +1 for this already existing request to provide the now-standardised multi pool links in Daedalus: input-output-hk/daedalus#2548

I don't know if there's a request for JSON based multi pool delegation in Daedalus, but @disassembler himself suggested it here, almost a year ago now: https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594/2

My impression is that any implementation of these standards in the Cardano officially supported wallets will only be provided through relentless pressure by SPOs through their representatives at IOG Marketing.

BTW your comment doesn't directly relate to the "Curve Pledge Benefit" so I'm simply responding to your suggestion to "facilitate distribution of delegation."