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:
- Reward allocation (RA), treasury, decay etc. i.e., the epoch reward calculation, based on system params tau, rho etc.
- 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.
- Reward Splitting (RS) i.e., the pool reward splitting between the operator(s) and delegators/members
- 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?
- 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.
- 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
knr. 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.
