Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CIP-0037? | Dynamic Saturation based on Pledge #163

Merged
merged 5 commits into from
Sep 6, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 88 additions & 0 deletions cip-caseygibson-dynamicsaturation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
---
CIP: TODO
Title: Dynamic Saturation
Authors: Casey Gibson <caseygibson@protonmail.ch>
Status: Draft
Type: Standards Track
Created: 2021-12-03
License: CC-BY-4.0
---

## Simple Summary

Currently Cardano has been plagued with an ever increasing amount of single entity Stake Pool Operators (SPO) creating multiple pools. The pools that are known to be operated by single entity SPOs account for just 18.72% of the total stake and 50% of the total stake can be attributed to at least 23 single entities (as of 3rd Dec 2021).

The vision of Cardano is that it everyone should be able to have the opportunity to be able to run a stake pool regardless of their financial capabilities and this is even more important for developing countries.

## Abstract

The issue we're currently facing is that many SPOs have been able to exploit a loophole that has allowed them to use their influence to create many sub-pools without any restrictions. As the size of their pools grow, instead of honouring the saturation limits already in place, they are bypassing them by creating more sub-pools. From a technical point, it is theoretically possible for a single entity to run enough stake pools to control more then 50% of the total stake.

While unlikely, the system does not take into account external influences (eg. political) that could harm the system. Shelly has been active for less then 2 years and we are already seeing the risks on a small scale. As real world adoption continues, there could be situations in the next decade that could jeopardise the decentralisation of Cardano. One example could be that a political party could run a ISPO (Initial Stake Pool Offering) on a mass scale. Seeing as Cardano has the potential to be used for voting (even at a political level), the integrity of Cardano could be questioned if political parties controlled stake pools with large shares of total stake.

## Motivation

The pledge used in a pool was meant to show how serious a SPO is and how much "skin in the game" they had. The idea was that if they have more pledge, they have more to lose if something goes wrong. This seems to have lost it's meaning as SPOs that already have a dominating position have created many sub-pools. Some have split up their pledge evenly, some have next to no pledge and have gained high amounts of stake through influential means. This has not only reduced the security of Cardano, but has also lost the meaning of having pledge in the pool.

For example, a SPO might have a pledge of 30,000 ADA across 10 pools, while another SPO might have 1,000,000 pledge but only has 1 pool with a small amount of active stake. Seeing as the SPO with 1M pledge has more overall, they have more to lose and should be trusted more. Since there is no technical advantage to having a high pledge, the meaning and purpose of a pledge is redundant.

To make the pledge a meaningful metric that is fair to all SPOs and aligns with the core values of Cardano, the pledge should be used to calculate the saturation point of a pool. This will mean that SPOs, no matter how many pools they operate, will have a maximum saturation based on their total pledge. For example, if a pool operates a single pool and wanted to open up another pool with the same amount of stake, they will have to assign the equal amount of pledge against that new pool. If a pool wishes to up their saturation point, they will need to assign a higher amount of pledge.

## Specification

For this to be able to work, there firstly needs to be an upper limit and a lower limit. The K parameter can still be used as the upper saturation limit of a single pool. As in, if a SPO has enough pledge assigned to a single pool, that pool will be able to run at the maximum saturation point of K. The lower limit is in place to safe guard small SPOs and allow them to grow.

An example of how Dynamic Saturation would be calculated:

500,000 ADA Pledged = Saturation point at 100% of K
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will need a mechanism to determine these pledge thresholds. For example, why does 500,000 ADA pledge, instead of 600,000 ADA, deserve 100% saturation point.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not smart in general to limit saturation, dynamic impact of pledge, relative to total delegated stake would be much more beneficial, and provide a level playing field...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will need a mechanism to determine these pledge thresholds. For example, why does 500,000 ADA pledge, instead of 600,000 ADA, deserve 100% saturation point.

The example I gave was based on the fact that the values would be adjustable in the same way all the other params were chosen and could be changed based on network consensus.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not smart in general to limit saturation, dynamic impact of pledge, relative to total delegated stake would be much more beneficial, and provide a level playing field...

For the purpose of the discussion, can you please explain why "it's not good to limit saturation"? Technically the k param already limits saturation, so I'm not sure what your point is.

The idea is to shift the saturation to the pledge instead of on the pool.

Copy link

@cffls cffls Dec 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is my idea of formulating the thresholds as a function of k and two additional parameters, e (entry threshold) and l (leverage):

orig_sat = total_supply / k
new_sat = orig_sat * max(e, min(1 / k, pledge / orig_sat * l))

We can use function new_sat to calculate the saturation point for a pool given its pledge, so we don't need to define these thresholds manually in the protocol. The parameter e is to, like Casey mentioned, safe guard small SPOs so they can at least have a reasonable chance to generate a block in a certain period of time. A value of 0.01 could be a starting point. The parameter l (leverage) could be a value the community define, e.g. 20, which means the saturation point will be 20x the amount of pledge.

@mark-stopka Not limiting the saturation point means we will discard k completely, which will be a much bigger change than the scope of this proposal I think.

Copy link

@santonode santonode Jan 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as a small pool, reaching saturation at 13m stake vs 64m seems more reasonable to me and targeting 50k pledge also seems like a realistic target this would encourage me to increase my pledge sooner to avoid declining rewards for my delegates - do I understand this correctly?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These numbers are just used for discussion purpose and nothing is finalized. In this context, increasing the pledge means increasing the saturation threshold for your pool. If your pool's pledge is at 50k, then the pool will be saturated at 13.49M ADA, meaning that any more delegation to the pool will result in decreasing reward. In this case, you are correct in a sense that you would need to increase the pledge above 50k in order to receive more delegations beyond 13.49M ADA without hurting the ROI of your pool.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CyberCyclone Casey, if this formula looks good to you, would you mind including it in your proposal? I can also create a pull request to your clone, and then you can merge it from your clone and resubmit this pull request. I am fine with either way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the reminder @cffls Jerry. I'll try and look into adding it in the next few days. I'm working on another CIP so once that's ready I'll come back to this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cffls I've finally gotten around to updating the CIP. I've attached the code to the bottom of the CIP.


250,000 ADA Pledged = Saturation point at 50% of K

125,000 ADA Pledged = Saturation point at 25% of K

62,500 ADA Pledged = Saturation point at 12.5% of K

To not penalise small pools, there should be a lower limit saturation point, such as 10% of K. Based on this, a pool with a pledge of 50,000 has the same saturation point as a pool with 25,000 pledge, both being 10% of K. This will allow smaller pools to still have some growth potential.

The only way a pool can receive more stake across all their pools without impacting their rewards is to increase their total pledge.

Example with SPO of 1,000,000 Pledge with current k implementation:

| Pools | Pledge | Saturation Per Pool | Total Stake | Fees |
|-------|-----------|---------------------|-------------|----------------------|
| 1 | 1,000,000 | 100% of K | ~65M | 340 fee + margin |
| 2 | 500,000 | 100% of K | ~130M | 340 fee + margin x2 |
| 4 | 250,000 | 100% of K | ~260M | 340 fee + margin x4 |
| 8 | 125,000 | 100% of K | ~520M | 340 fee + margin x8 |
| 16 | 62,500 | 100% of K | ~1040M | 340 fee + margin x16 |

Example with SPO of 1,000,000 Pledge with Dynamic Saturation:

| Pools | Pledge | Saturation Per Pool | Total Stake | Fees |
|-------|-----------|---------------------|-------------|----------------------|
| 1 | 1,000,000 | 100% of K | ~65M | 340 fee + margin |
| 2 | 500,000 | 100% of K | ~130M | 340 fee + margin x2 |
| 4 | 250,000 | 50% of K | ~130M | 340 fee + margin x4 |
| 8 | 125,000 | 25% of K | ~130M | 340 fee + margin x8 |
| 16 | 62,500 | 12.5% of K | ~130M | 340 fee + margin x16 |

As we can see above with the **current** implementation of K, a pool owner can split the pool and double their delegators active stake (or however many times they split).

The Dynamic Saturation method caps the pools so that the amount of total stake across all pools is the same no matter how much they split up their pledge and the only benefit will be the extra fee collected (340 ADA) per pool.

This will mean that the saturation metric will have a direct corelation to an SPOs total pledge.

## Rationale

Since a single entity SPO only has a certain amount of ADA they can pledge, they will eventually hit their saturation point no matter how many pools they create. The only way they can add more delegators is to increase their pledge. Once they run out of pledge and reach their saturation point, the delegators will have no choice but to move to another SPO and increase decentralisation.

In the above example, the base pledge of 500,000 ADA should be set as a parameter that can be adjusted in the future. E.g, if it is found that it is too low or too high to gain 100% saturation, it can be adjusted in the same way k can be adjusted.

One of the questions raised by the community was, will the lower limit stop the growth of small pools if it is set at a level where they can't reach the expected annual 5% return on ADA. This case could be handled a few ways, but the main aim would be to keep it at a sustainable amount for small pools.

1. The value is a percentage of k, such as 10%. This percentage could increase as needed, such as to 15% of k.
2. The value could be calculated based on the average of active stake compared to active pools. E.g, active stake = 23837 M / 3000 = saturation point of 7.94 M ADA

## Copyright

This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)