CIP: Improved Rewards Scheme Parameters

Developers CIPs
1

Introduction

There’s been a lot of discussion recently regarding minPoolCost and how Cardano’s rewards scheme parameters should be updated. As many of you know, I recently posted a CIP for fair stakepool rewards. And while I still think that CIP is useful, it simply changes too many aspects of the current scheme and includes changes that the community has not discussed. After reviewing the current rewards scheme, I have developed this proposal which includes several changes that the community has specifically voiced. This proposal removes minPoolCost, introduces minPoolRate (minimum variable fee) and increases k. These changes have been the most requested and understood changes I have seen in discussion. This CIP will create a level playing field for all stakepools while ensuring that established community pools earn sufficient revenue via minPoolRate. The CIP is structured into four well-thought-out stages that will move the network to a fairer environment that promotes increasing pledge and decentralization. Furthermore, sybil attack resistance is sufficient in every stage. I hope you enjoy this short-novel-length CIP and look forward to all feedback!

Abstract

The current parameter settings of Cardano’s rewards sharing scheme leave much to be desired in terms of fairness and promoting decentralization. minPoolCost puts small stakepools at a significant disadvantage. Replacing minPoolCost with a minPoolRate will ensure a level playing field for stakepools while providing sufficient sybil attack resistance. Additionally, the current setting of k, the optimal number of stakepools, is too low to provide an adequate pledge benefit. Increasing k will make the pledge benefit more effective and get delegations moving in hopes of helping single pool operators gain delegations.

The parameter changes in this proposal are an optimization of the current settings and are meant to improve the fairness and decentralization of Cardano. Furthermore, all changes suggested in this proposal have been specifically voiced by the Cardano community.

Motivation

Definitions

Stakepool Operator (SPO)

  • The operator of a stakepool, can be a single person or an entity.

Multipool

  • A group or brand of stakepools operated by a single entity or stakepool operator.

ROS

  • Return on staking (often annualized and represented as a percentage of the initial investment).

Stakepool Viability Point

  • The amount of pledge required for a stakepool with zero delegations to distribute nonzero rewards to delegators (assuming minimum stakepool fees and ignoring luck in VRF block production, i.e., rewards are exactly proportional to stake).

Stakepool Competitive Point

  • The amount of pledge required for a stakepool with zero delegations to offer the same ROS as a fully-saturated stakepool with zero pledge (assuming minimum stakepool fees).

Stakepool Saturation Point

  • The maximum amount of total stake in a stakepool before total stakepool rewards are capped and ROS diminishes.

Minimum Attack Vector (MAV)

  • Also known as the Nakamoto Coefficient, the MAV is the minimum number of entities required to capture more than 50% of a network. In the context of Cardano, this refers to the minimum number of SPOs required to capture more than 50% of active stake.

Sybil Attack

  • An attack on an online system where an entity tries to take over the network by creating many identities or nodes.

Cardano’s Declining MAV

Cardano’s declining MAV is a real problem as the network matures and gains more users. Ideally MAV should increase or stay consistent over time. However, this is currently not the case. This trend points to potential problems with the parameters set in the rewards sharing scheme. Now that staking on the network has matured, it is time to re-examine the rewards sharing scheme parameters and seek optimization. This proposal suggests changes that aim to increase the fairness and decentralization of the Cardano network.

minPoolCost

minPoolCost sets a minimum fixed fee that a stakepool must collect from an epoch’s rewards before distributing to delegators. This parameter was added to the rewards sharing scheme to provide additional sybil attack protection. While this parameter has been successful at deterring sybil attacks on the Cardano network, it has been at the expense of fairness and decentralization. minPoolCost imposes a proportionally greater staking fee on small stakepools in contrast to larger pools. This discrepancy results in many small pools being unviable and the network centralizing around established pools. It is not uncommon for small stakepools with higher pledge to offer inferior rewards to that of large stakepools with much lower pledge. In this way, minPoolCost reduces the effectiveness of pledge in the rewards scheme. In order to create a level playing field for stakepools and increase the effectiveness of pledge, minPoolCost must be removed from the protocol.

minPoolRate

The current pledge benefit favors established pools close to saturation as a means of sybil attack protection. Specifically, this property combats high pledge sybil pools (~1 mil ADA pledge) that could be set up by large entities such as centralized exchanges. In contrast to minPoolCost, the pledge benefit’s built-in sybil attack protection is significantly less aggressive and does not affect the viability of stakepools. In this way, it is a useful mechanism to combat sybil pools. However, the pledge benefit on its own has no means to combat zero fee sybil pools. Without minPoolCost, zero fee sybil pools could offer greater rewards than that of established stakepools that must set fees to pay for continued operation. In order to combat zero fee sybil pools without minPoolCost, minPoolRate must be added to the protocol. minPoolRate will set a minimum margin or percentage fee that operators can extract from an epoch’s staking rewards. This new parameter will protect established stakepools by ensuring that they collect sufficient revenue from operation while offering a competitive ROS. Additionally, minPoolRate can be updated to reflect current economic conditions. As minPoolRate enforces a proportional minimum fee, it does not affect the viability of stakepools. Unlike minPoolCost, minPoolRate will be able to provide sufficient sybil attack protection with the pledge benefit while maintaining a level playing field for stakepools. minPoolRate was originally proposed in CIP-0023.

k, the optimal number of stakepools

k represents the optimal number of stakepools that the Cardano network can support. This is achieved through a saturation mechanism where after exceeding a saturation point a stakepool will earn no additional rewards. A stakepool larger than the saturation point will offer lower rewards than a stakepool at the saturation point. The parameter k is used to tune the saturation point. In addition to tuning the saturation point, k also affects the pledge benefit. The maximum pledge benefit exists when a pool is fully saturated. Therefore, increasing k will increase the number of optimal stakepools, decrease the saturation point, and make it easier for stakepools to achieve the maximum pledge benefit. Increasing the effect of the pledge benefit on rewards is imperative, as pledge currently has little effect on rewards allowing low pledge pools to proliferate through marketing alone. Furthermore, increasing k can be used to get stale delegations moving. This is especially useful in the case of saturated multipools, where delegators would have to reconsider their delegation potentially assisting small and medium sized pools. Any delegation flow from multipools to single pool operators will increase the decentralization of Cardano.

Specification

This CIP proposes several parameter changes. In order to give SPOs and delegators enough time to react to the changes, this CIP is divided into 4 stages. The proposed time interval between stages is 3 epochs or 15 days. However, it is up to the implementors to determine the best time interval between stages. Parameters are changed in the following stages:

Stage 1: minPoolCost decreased to 170 ADA

Name of the Parameter New Parameter (Y/N) Deleted Parameter (Y/N) Proposed Value Summary Rationale for Change
minPoolCost N N 170000000 See Rationale Section.

Stage 2: minPoolCost deleted, minPoolRate of 3% implemented (requires hardfork)

Name of the Parameter New Parameter (Y/N) Deleted Parameter (Y/N) Proposed Value Summary Rationale for Change
minPoolCost N Y N/A See Rationale Section.
minPoolRate Y N 0.03 See Rationale Section.

In order to ensure the compatibility of existing stakepool registration certificates with this CIP, the variable poolRateEff must be added to the protocol. This variable will be the effective margin used during stakepool fee calculation. Following the hardfork, poolRate will only be the value set by SPOs. poolRate will be superseded by minPoolRate if its value is lower than minPoolRate. This is demonstrated in the definition of poolRateEff:

$$poolRateEff = max(poolRate, minPoolRate)$$

Stage 3: k increased to 750

Name of the Parameter New Parameter (Y/N) Deleted Parameter (Y/N) Proposed Value Summary Rationale for Change
stakePoolTargetNum N N 750 See Rationale Section.

Stage 4: k increased to 1000

Name of the Parameter New Parameter (Y/N) Deleted Parameter (Y/N) Proposed Value Summary Rationale for Change
stakePoolTargetNum N N 1000 See Rationale Section.

Rationale

Principles

  1. Propose changes voiced by the community.
  2. Make Cardano staking fairer by eliminating aggressive anticompetitive features.
  3. Increase the effect of the pledge benefit on staking rewards.
  4. Get stale delegations moving and allow users to reconsider their delegation.
  5. Maintain sufficient sybil attack protection.

Explanation

Stage 1: minPoolCost is decreased to 170 ADA

Stage 1 reduces minPoolCost from 340 ADA to 170 ADA. 170 ADA is proposed because it is half of the current minPoolCost and is close to what the USD value of minPoolCost was during the launch of Shelley. This value is more than sufficient to allow established community pools to stay profitable while enabling smaller pools to be more competitive. This value also maintains sybil attack resistance.

Stage 2: minPoolCost is deleted, minPoolRate of 3% is implemented (requires hardfork)

Stage 2 introduces the largest change to the network by deleting minPoolCost from the protocol in favor of a minPoolRate of 3%. 3% is proposed, as it allows established community pools to stay profitable when competing against minimum fee pools. This in combination with the pledge benefit provide sufficient sybil attack resistance while leveling the playing field for all stakepools. As pool size is significantly less important following this stage, pledge becomes a more important factor in choice of delegation. In contrast, Lido, Ethereum’s most popular liquid staking DApp, applies a 10% fee on participants’ staking rewards.

Stage 3: k is increased to 750

Stage 3 increases k from 500 to 750. The purpose of stage 3 and stage 4 is two-fold. Firstly, increasing k increases the pledge benefit. The more effective the pledge benefit, the greater Cardano’s sybil attack resistance. Secondly, increasing k may get stale delegations moving again by oversaturating large pools. This will cause many delegators to reconsider their delegation, potentially helping smaller community pools find delegations. Increasing k is split into two stages to give SPOs sufficient time to react to the change. Furthermore, it is imperative that k is increased after stage 2, as small stakepools will only be competitive after minPoolCost has been removed.

Stage 4: k is increased to 1000

Stage 4 increases k from 750 to 1000. Stage 4 will further improve the pledge benefit and get more delegations moving. This is the final stage of this proposal.

Test Cases and Sybil Attack Resistance

Below are test cases for the current rewards scheme and each stage of this proposal. The calculated values assume all pools are operating with minimum fees. Sybil pools are assumed to be small pools with no delegations. Community pools are assumed to be pools with significant delegation. As demonstrated below, this proposal allows community pools to have sufficient revenue (higher than the USD value of minPoolCost at the launch of Shelley) while creating a level playing field for all stakepools. Sybil attack resistance is maintained at every stage, as community pool ROS remains higher than sybil pool ROS. Data used for calculations was approximated from epoch 385.

More test cases:

Current Rewards Scheme

Stakepool Viability Point: ~670,000 ADA
Stakepool Competitive Point: ~20,000,000 ADA

Pool Type Pool Stake Pool Pledge Pool Epoch Revenue Delegator ROS
Sybil 100,000.00 ADA 100,000.00 ADA 340 ADA Below Viability Point
Sybil 1,000,000.00 ADA 1,000,000.00 ADA 340 ADA 1.2339%
Community 10,000,000.00 ADA 100,000.00 ADA 340 ADA 3.5213%
Community Saturated 1,000,000.00 ADA 340 ADA 3.7567%

Proposed - Stage 1

Stakepool Viability Point: ~335,000 ADA
Stakepool Competitive Point: ~16,500,000 ADA

Pool Type Pool Stake Pool Pledge Pool Epoch Revenue Delegator ROS
Sybil 100,000.00 ADA 100,000.00 ADA 170 ADA Below Viability Point
Sybil 1,000,000.00 ADA 1,000,000.00 ADA 170 ADA 2.4977%
Community 10,000,000.00 ADA 100,000.00 ADA 170 ADA 3.6498%
Community Saturated 1,000,000.00 ADA 170 ADA 3.7749%

Proposed - Stage 2

Stakepool Viability Point: 1 ADA
Stakepool Competitive Point: 1 ADA

Pool Type Pool Stake Pool Pledge Pool Epoch Revenue Delegator ROS
Sybil 100,000.00 ADA 100,000.00 ADA 1.52 ADA 3.6615%
Sybil 1,000,000.00 ADA 1,000,000.00 ADA 15.24 ADA 3.6617%
Community 10,000,000.00 ADA 100,000.00 ADA 152.42 ADA 3.6631%
Community Saturated 1,000,000.00 ADA 1081.06 ADA 3.6773%

Proposed - Stage 3

Stakepool Viability Point: 1 ADA
Stakepool Competitive Point: 1 ADA

Pool Type Pool Stake Pool Pledge Pool Epoch Revenue Delegator ROS
Sybil 100,000.00 ADA 100,000.00 ADA 1.52 ADA 3.6615%
Sybil 1,000,000.00 ADA 1,000,000.00 ADA 15.24 ADA 3.6620%
Community 10,000,000.00 ADA 100,000.00 ADA 152.49 ADA 3.6639%
Community Saturated 1,000,000.00 ADA 720.44 ADA 3.6853%

Proposed - Stage 4

Stakepool Viability Point: 1 ADA
Stakepool Competitive Point: 1 ADA

Pool Type Pool Stake Pool Pledge Pool Epoch Revenue Delegator ROS
Sybil 100,000.00 ADA 100,000.00 ADA 1.52 ADA 3.6615%
Sybil 1,000,000.00 ADA 1,000,000.00 ADA 15.24 ADA 3.6624%
Community 10,000,000.00 ADA 100,000.00 ADA 152.52 ADA 3.6646%
Community Saturated 1,000,000.00 ADA 542.82 ADA 3.6932%

Backward Compatibility

This proposal includes several parameter changes and changes to ledger rules. Specifically, stage 2 of this proposal will require a hardfork to introduce a new parameter, delete a parameter, and modify the stakepool fee calculation equation. As mentioned in the specification section, the stakepool fee calculation equation must be modified in order to ensure current stakepool registration certificates are compatible with this CIP.

Path to Active

Acceptance Criteria

For Stages 1, 3, and 4

  1. The raw transaction for the parameter update is built.
  2. Genesis delegates IOG, CF, and Emurgo sign the transaction.
  3. Transaction is submitted.
  4. Parameter update is accepted by majority of the network.
  5. Parameter update is confirmed.

For Stage 2

  1. IOG completes necessary research and develops the changes to the ledger rules.
  2. IOG releases a new version of cardano-node supporting the changes to the ledger rules.
  3. The raw transaction signalling the hardfork is built.
  4. Genesis delegates IOG, CF, and Emurgo sign the transaction.
  5. Transaction is submitted.
  6. Hardfork is accepted by majority of the network.
  7. Hardfork and changes to ledger rules are confirmed.

Implementation Plan

Implementors include IOG, CF, and Emurgo. All three entities must approve the changes to the network. Each stage will be an individual update. Stages 1, 3, and 4 will be parameter updates. Stage 2 will require a hardfork.

Before implementation, IOG’s engineering and research teams must review the feasibility and potential consequences of the proposal. IOG will create the implementation for each update and decide on the time interval between updates.

As previously mentioned, implementation will occur in the following stages:

  1. minPoolCost is decreased to 170 ADA
  2. minPoolCost is deleted, minPoolRate of 3% is implemented (requires hardfork)
  3. k is increased to 750
  4. k is increased to 1000
10 Likes
2

For the record, this has now been presented & is being discussed in the CIP repository:

4 Likes
3

Congrats for the detailled description, with references to previous discussions, rationales ecc.

Just to add - as it was also brought up as an idea in the past - one option would be to keep all existing pool fees, even if they are <minPoolRate, but only change the reward calculation that everything below minPoolRate does not become rewards, but goes back to the treasury.

@Colin_Edwards has discussed this already before the last k-change.
increase k gradually or do one big step?

gradual steps create max possible “pain” for multi-pools and delegators who absolutely want to remain with them.
Or some of these multi-pools already setup their pools at stage3 in expectation for stage4. Worst case they would fill them up even more than they had before.
Ofc this is speculation only, but possible.

2 Likes
4

What are the aims? I would say:

  1. Having around 75% total stakes, for securing the network.
  2. having a k number of almost fully saturated pools (>~97.5%), and does not matter how many tails for the rest. Remember, not the nr. of pools are the Sybil threats, but the gained/existing - money/stake - power.
  3. having max. x nr. of pool per entities, where x is equal with ceil(pledge i.e., owned stake as % * k), same comments for Sybil applies too.

So, I would say these are the aims to achieve, but how to achieve them? Only, by right incentives for:

  1. wallet owners, incentives them to stake.
  2. pool members, incentives them to select the right pools, based on their economic and/or emotional incentives i.e., based on their values, ideology etc. It does not need to be the highest pledged pool, ideal for ideology based SPOs too.
  3. SPOs, incentives them to have only max x nr. of pools per SPO.

IMO, we cannot discuss anything until these incentives are set by some game theoretical solutions, and remember this is very hard, just recall how the very simple “Prisoner’s dilemma” was not that “easy”.

But, the problem is that everybody wants to have their wet dreams (believed by them as the Holy Grail and the only solution) to be implemented without proper research, but by only gut feelings, appeal to authority, fancy science related words/sentences etc.

Why I say ^? Because, I could not read any research paper on it from those who want to make the changes.
Write one and ppl will read it (I definitely would) and then we all as a community can have some discussions, but until then, do not try to make changes without any backed claims.

2 Likes
5

I find your feedback to be interesting for 2 reasons.

“Holy Grail Solution”:
In no part of this CIP did I say that this is the only solution (I even have another alternative CIP). In fact, I have said on Twitter that this proposal isn’t perfect by any means. It’s simply a good first step that can be implemented faster than other alternatives due to it’s simplicity. It also introduces ideas that the community understands and supports.

“Needs more research”:
I find this point to be especially ironic because I believe that this proposal is closer to the original RSS paper incentives than what is currently on mainnet. minPoolCost was not tested in the original RSS paper. It also wasn’t included in the simulations when IOG revisited the rewards sharing scheme some months ago. minPoolCost creates a disparity in rewards between large and small pools. This has an enormous effect on incentives. Due to this disparity, pledge is also not properly implemented because it simply isn’t enough overcome the effect of minPoolCost. The introduction of minPoolRate does not introduce a disparity in rewards, and therefore should not affect incentives to the same degree as minPoolCost. If anything, this proposal has more research backing it than what is on mainnet, imo.

6

MinPoolRate:
Interesting idea to send rewards below minPoolRate to the treasury. However, I feel like this would require greater complexity. If it is the simpler way to implement minPoolRate, then it’s definitely a consideration.

k:
I proposed two steps because k hasn’t changed for so long. So the first step would be a “warning” and the second would be the final setting in this proposal. Would multipools fill up? I don’t think so, especially since they would have to split pledge even further. This proposal isn’t really supposed to solve the problem of multipools. It’s more about incentivizing consolidation of pledge. So high leverage multipools (multipools with low pledge in contrast to stake) would have to consolidate pledge to offer competitive rewards.

7

Even with k increased, with the current pledge formula, the effect of pledge will be negligible, so splitting up pledge won’t effect rewards so much.

8

I thought, it would be interesting for starting some discussion to solve those 3 aims instead somehow.

I wrote my post as a generic respond/reply to all CIP writers and why? Bacause having these kind of firm statemens like the below example (what I saw in many CIPs), which is not backed at all, even just mantraing fancy “Sybil attack” word without any proper definition (for the context etc) is just good enough to fool the ppl who has not reached the required knowledge and understanding of the topic (to realise what they do not know).

9

What I meant on this? The example below can explain it. Imagine two smart ppl. one believe in flat-earth the other believe that’s not flat (who studied hard and not because the other ppl. scientists says it’s sphere). These are not contradict, as smartness is not equal with ignorance, but ignorance driven linking of logical premisses can cause wrong conclusion even for smart ppl.

What’s the difference between them?
Only that, the flat-earther has not reached the required knowledge in Quantum physics (QCD, QFT etc.) and Classical Physics (Universal law of Gravity, Electromagnetism, general relativity etc.) that what he is stating cannot be true based on our current knowledge/understating of the laws of Physics.

So, back to fool ppl, they would believe it without any verification (easy way) because it sounds logical etc. That’s why the verifiable claims are very important.

1 Like
10

I wouldn’t say negligible. For large whales, fractions of percents are a big deal. And if pools pledge millions of ADA like they are supposed to, pledge starts to work fine. There are many small and medium sized pools with millions of ADA as pledge that would get a boost from this CIP.

1 Like
11

I define Sybil attack in the CIP. I provide test cases with assumptions that clearly demonstrate why it ensures a level playing field while providing sufficient sybil attack resistance in the Rationale section. We can argue about semantics all day, but that is not constructive. If you are so interested in research, then perhaps you should ask IOG where minPoolCost is tested in the original RSS paper and recent simulations. Imo, this CIP is closer to the incentives presented in the original RSS paper. If you have any real critique for this CIP, I’ll be happy to hear it. Otherwise, we are done here. No need to start a huge debate over semantics and the CIP process as a whole for something that is literally just a proposal. In the end, it’s not up to you or me. It’s up to the community as a whole.

1 Like
12

No there aren’t, only a handful or so…

13

There are more in 500k to 2 mil ADA pledge range. These pools should be saturated and many aren’t. With this CIP, multipools would have to consolidate pledge (close pools) to compete with these pools and pools with minimum fees.

14

Even when saturated, the current pledge formula won’t give them considerable enough more rewards.

15

Pledge will give community pools in that range a slight ROS boost in contrast to low pledge pools. And of course what I say in regards to what multipools and delegators will do is just speculation. I do think pledge could be improved, but this CIP is just supposed to be a simple improvement to what we have now. Not a perfect solution. Not a final solution. And something that doesn’t need a lot of additional research (incentives nearly identical to the original RSS paper). So perhaps in the future the pledge formula or a0 can be adjusted or k increased further, but that is outside the scope of this CIP.

16

Can we add new parameters? Like min pledge, max pledge, and ROI parameter.
Screen Shot 2022-12-30 at 14.03.58

if K = 2000 the max pool size is 22.5M ada. max ada for the pledge is 225K. if someone adds more the max pool size is not increased. the min pledge for the pool to start minting blocks is 22.5K if it’s below that level the pool did not find any blocks. another parameter is the ROI factor, which counts between min and max in percentage. if the pool has a max pledge it gets a 100% reward.
so if anybody wants an attack he or she needs to pledge 22.5k ADA for just one pool.
in this case, there are no 0 pledge pools so everyone has skin in the game.
there is no min few. so it cost to make a few pools with min pledge.

17

What difference do you see between the plots that has min cost and no cost?
Also, I had to use 3.4m pledge as min because the op ROI will be too high (converge to infinity) if I would use lower pledge, to see its surface at the low ~4%. So, pls try to interpret these graphs (Blue=op reward, Orange= delegators rewards).

Figure_1

Figure_2

Source is there, I just created it for showing these graphs

3 Likes
18

Thank you for providing these plots! They look great. I see the main difference being the lower delegator ROI when a pool has low pledge and low delegations. This is how the incentives are altered with a min cost. What’s your interpretation? Do you support lowering or removing min cost to restore what the original RSS paper proposed?

19

I think we should simplify the complexity and code testing required by leaving Stage 2 hardfork to the end if necessary. Just decrease the minPoolFee to 0 and no hardfork should be needed in stage-2. In general, I like the approach of the 4-stages.

20

Tbh, the whole RSS is much more complicated than it looks, we need to see it as a whole and not just pick up some parts of it and having ideas what to change to fix the whole.
The RSS can be split to four main parts:

  1. Reward allocation (RA), treasury, decay etc. i.e., the epoch reward calculation, based on system params tau, rho etc.
  2. Reward Sharing Scheme (RSS) function i.e., the pool reward calculation based on pledge and system parameters like a0, k it also includes apparent performance etc.
  3. Reward Splitting (RS) i.e., the pool reward splitting between the operator(s) and delegators/members
  4. Ranking (R), i.e., the incentives for delegators where to delegate (based on their values i.e, based on their economic and/or emotional incentives).

These all parts are created for having a Nash equilibrium in the “Staking-Pool” game, i.e., having k nr of nearly-fully saturated pool from individuals/entities based on their initial investments a.k.a pledge (very important). To reach the equilibrium the game also assumes >51% (by stake and not by numbers) of honest nodes.

The prediction and more importantly the expectation - based on the RSS - is having k nr. of nearly fully saturated and some tail block-producer nodes (i.e., BP nodes or pools) and that these all pools are operated by individual entities based on their power (stake).

Note: The RSS is created for that and if we want to have different outcome, then we need to rewrite the whole and not just some part of it as the whole paper was created for this type of game.

How to achieve that we should only have k nr. of almost fully saturated pools?

  1. To incentive the delegators to delegate to some pool that are economically (best profit etc) and/or emotionally (ideology etc) aligned with them. We can argue, that we should teach them etc. but the incentives do not work like this.
  2. To incentive the pools to only operate x nr. of pools where x = ceil(pledge / total * k) or similar. Meaning, do not incentives for having more pools than the allowed nr. based on the initial investment (pledge).

There are two main types of Sybil attacks (accumulate money/stake power over the network) can :

  • Adversaries try to take over the network by creating hundreds, thousands of pools to take over the network. It is mitigated by the 500ADA registration cost and RSS and by that the power means stake i.e. ADA and not nr. of pools. I have not seen any attempt as they’re mitigated properly.
  • Non-adversaries, tries to accumulate power by attracting delegators by false promises, popularity etc. examples 1PCT, BLOOM, DIGI etc.

Keep in mind exchanges ARE NOT Sybil threats as their investment comes out of the - Cardano’s - system. The DIGI and this kind of behaviours are Sybil threats, as they accumulating power slowly from inside the System itself. Also, that I do not want to talk abt other P2P vulnerabilities as it would be too time consuming even only just explaining them.

If we cannot agree on these above (to achieve RSS’ predictions) above, then how the f*ck do we want to solve the game at all?

1. Total Reward allocation/calculation (TR)

The Total Reward calculation for an epoch.

It has some issues too, for example the double-taxation for which @feqifei and @Antonio-CSP created a really good paper to solve it. Posted here abt 3yrs ago. I referred this kind of research paper when anybody want to solve something.

2 Reward Sharing Scheme (RSS) function

This is where the pool reward (PR) for an epoch from the Total Reward is calculated.

3. Reward Splitting (RS)

This is where the allocated pool rewards (PR) are split between the pool operator(s) (SPOs) and the delegators/members.

4. Ranking (R)

Even we can argue that the Hitrate estimate for Ranking is necessary or even effective.
The main aim of the ranking is to incentives the stakeholders to delegate their stakes to any pool.

I would say the most important thing is having changes that are enforce/incentives the outcome assumed by the RSS paper by achieving to have only k nr. of almost fully saturated pools (that is the target Nash equilibrium of the game).

But, how that’s the question. Some examples:

  • by incentivising the pool operator/owners only having fewer pools instead of more.
  • by incentivising the stakeholders to delegate their stake to the pools will be most likely in the k nr. ones.

It’s complicate, but imo we need to set the targets (i.e., having k nr. of almost fully saturated pools)

Anyway, I modified the code to be able to simulate the decay or min pledge etc.
Figure_1

2 Likes