We are a few weeks into decentralization and we are now starting to see IISS in action. We can see the pros/cons of the design more clearly in practice, and I think it’s time to start bringing P-Rep teams together to think of ways to enhance IISS. While there have been some great contributions so far (and I’m sure more to come) we can all admit the design is not perfect.
I have summarized what I believe to be the current pressing issues and I present a potential short term and long term solution. Looking forward to the discussion and seeing how IISS evolves.
1.) Competition instead of collaboration. Some P-Reps have collaborated, but there is a competitive nature to this rewards design that limits synergies and incentivizes combativeness, smearing, a major focus on PR/politics, etc.
2.) Votes are too concentrated - this is a research intensive decision and many people do not put in the time/effort necessary to comfortably diversify their votes among many P-Reps.
3.) Some P-Reps have reported being extorted by voters trying to push the teams to do what they want.
4.) P-Reps at the top are getting too many rewards.
5.) Self-delegation by ICX whales is highly economical and there is no unbiased/objective/decentralized way to stop this with the current design.
6.) There is a strong economic incentive to buy votes. Although we have stifled this problem for now via political tactics, I would much prefer a solution at the protocol level.
7.) Overlap between responsibilities of a P-Rep and what will be the responsibilities/scope of an EEP.
8.) This is not decentralized enough, thus we lack some key benefits of public blockchain (immutability, security, etc.) since we are essentially 22 non-anonymous entities that could easily be shut down by authorities, collude to alter transactions, freeze accounts, etc. This is especially true considering the concentration of votes.
(I may have missed some problems - anybody feel free to add to the list if you believe I missed something)
In my opinion, the root cause of most of these problems (problems 1-6) is the competition to break into the top 22 P-Reps and, more generally, the concept of more votes = more rewards. Mitigating the benefits of receiving more votes would fix problems 1-6, although I am still considering the potential consequences of such an adjustment.
Short Term Solution
I am considering a proposal that would take the square root (or even cubed root) of the percentage of votes received prior to calculating rewards. This would help close the gap between high ranked teams and low ranked teams, but does not fix the other issues. For example, the calculation for delegation rewards (B2) if you had 9% of the vote would be:
SQRT(9) x (i_rep/2)
Longer Term Solution (When the Contribution Proposal System launches)
Separate the role of EEPs and P-Reps and make ICON more decentralized. Core responsibility of a P-Rep becomes governance and block validation, while core responsibility of EEPs is to contribute to the growth of the network via specific initiatives. Block rewards would be allocated as such at the protocol level, lowering the rewards for individual P-Reps and increasing the reward pool for Contribution Proposals. I would expect many of the current P-Reps to start forming teams that execute EEPs and build DApps on a regular basis. The larger economic incentive would switch from running a P-Rep/campaigning for votes to submitting Contribution Proposals and executing on such proposals. A key benefit here is that each individual EEP has specific goals and KPIs, thus putting the larger portion of block reward funding directly towards specific projects/initiatives rather than to the control of P-Rep teams.
i_rep would create a monthly reward pool that would be evenly divided amongst all nodes that meet the following requirements: a minimum delegation of [1M] ICX and having their node synched to within [43,120] blocks from the current block height. Block producing nodes would earn an additional % for being a block producing node. All numbers here are TBD, but an example of the model with i_rep set to 2M ICX is shown below:
B1 = Reward to each main P-Rep for producing blocks
B2 = Reward pool for running a node and meeting the minimum requirements
Receiving additional votes would earn you more governance power, not more rewards. Governance decisions would be strictly based on stake-weighted vote and all P-Reps (sub P-Reps included) that meet the mandatory requirements (minimum delegation and synched to a proper block height) would be included in governance decisions. This mitigates the impact of single entities launching multiple nodes. If you want a bigger share of rewards, then you can deploy more nodes, but this will not give you more governance power. If the network wants to incentivize more nodes to join, the network can increase i_rep. More nodes = more decentralization and more security.
As you give feedback please also consider the development effort required in your proposed solution. I have tried to propose a solution that is more about adjusting math rather than making significant adjustments to the core code. Looking forward to hearing everybody’s thoughts!