IISS 3.1 Structure

Governance
1

When designing IISS 3.0 we were operating under the constraints associated with what was developed on ICON 1.0. It was a fairly complex design so we didn’t want to make too many changes to the code.

Now that we’ll be migrating to Batang we have much more freedom in terms of design. That is why I’m now proposing a much cleaner and straight-forward economic design for Batang with predictable inflation rates and clearly defined percentage breakdowns of where inflation is allocated. In our current system, it is impossible to say with certainty that “x% of inflation will be going to voters while y% inflation goes to validators” or “the amount of newly minted ICX per month is x”. The percentage breakdown and amount of newly created ICX per day constantly changes as more/less people delegate their ICX, meaning we have very little control of how we would like to allocate network resources and how much new ICX will be minted during any given period.

IISS 3.1 will consist of several inflation pools with specific percentages of inflation allocated to each of them. The percentages assigned to each pool, as well as the size of the total pool, will all be able to be changed via a Network Proposal vote.

Variables:

  • i_global = Monthly inflation pool size in ICX
  • i_prep = percentage of pool going to P-Reps
  • i_voter = percentage of pool going to voters
  • i_relay = percentage of pool going to relayers
  • i_cpf = percentage of pool going to the CPF

Note: As a rule, i_prep + i_voter + i_relay + i_cpf + i_n must always equal 100%.

As for the specific allocations, I think it would make more sense to decide these things closer to launch when we have a better idea of the state of the network at the time. This way we can lock in the lowest inflation rate possible while still ensuring P-Reps are profitable, the CPF is properly funded, and voters still have a high enough incentive to stake + vote.

Additionally, in future iterations, it will become relatively easy to add new inflation targets through Network Proposals. This opens up the door for many interesting opportunities. For example, we could decide to create some sort of network-funded Defi project and direct inflation toward the smart contract as network-funded collateral. Another option could be a pool for people that lock their ICX for a full year to earn extra inflation. These are just examples that came to mind during writing, but we could direct inflation toward anything we want with this simple and clean model.

I’d like to form consensus on 2 things for now:

1.) Direction - that we will have one inflation pool that gets split into the aforementioned buckets

2.) Removing the 3/4 root function for P-Reps above 1% delegation that we previously agreed upon in IISS 3.0. This adds considerable development difficulty and detracts from the simplicity I’m shooting for in IISS 3.1. I would prefer to solve the vote concentration problem a different way using some form of vote decay, which we will discuss in a separate thread.

Overall, I am becoming a bigger believer of “simple is better” and trying to work that into our economic designs. This means less exceptions and conditional rules where possible, as these add a lot of calculation burden to our network and open the door for more issues, bugs and edge cases.

15 Likes
2

I agree, I think it makes complete sense not to implement the ¾
root function. An automatic system that spreads stagnant votes does well to address the root problem.

The voter list being random helps prevent votes centralising.

6 Likes
3

I agree that simpler is better and also that a set amount of inflation that can be split into exact percentage amounts based on needs makes sense. We would probably want to have sufficient stability for those amounts - so that they move as needed, but at low frequencies of change.

4 Likes
4

Not much to add Scott, agree with the above and “simple is better”.

I would be keen to jam on the vote concentration problem/solution at the right time.

3 Likes
5

Absolutely love the approach. Obviously simplifying the rules will be better for many reasons, not the least of which will be to help everyone understand how inflation and rewards work. Having the flexibility to adjust and add to the distributions is fantastic too. It’s a much better model over all.

I also believe a vote decay instead of the 3/4 root function would be better. It’s clear there is a significant amount of vote stagnancy that is contributing to the concentration of votes and addressing that might, very well, fix the issue out right.

Personally I think having a more granular control over inflation is key going forward. There is a lot of misunderstanding and misinformation in the community about how this all works, still, and I’m sure it’s not helping the network grow. My hope is that between these changes (especially the CPF), vote decay and the (presumed) ability and initiative to increase network fees we can reign in inflation a bit and help insure we, as a community, are maximizing the inflation for network benefit overall.

I’m super excited to see these changes materialize.

2 Likes
6

To play devil’s advocate since the top 22 is going to change to top 22 biggest bond holders why would the top 22 not just vote to have a ridiculous i_prep and get tons of money? In ICON 3.1 the voters don’t decide the top 22 anymore right? So what’s the reason they wouldn’t take advantage of the system now that there’s no fear of voters pulling their votes?

7

I’d say you might be a bit confused on Bonded Delegation.

Bonded Delegation = Bond Posted / 5%, with a upper limit = to actual delegation

So yes, teams will be ranked by those with the largest bond, but that is because those with the largest bond also have the largest delegation. Nothing really changes in terms of ICX holders having a voice in who operates the network, there’s just now a required investment in ICX to run a node on our network.

Additionally, it’s extremely easy for ICX holders to post a bond for a node if they so choose. Even in an extreme example, where let’s say 10% of delegated ICX wants to support a P-Rep that holds 0 ICX for whatever reason, those ICX holders can use their ICX to post the bond on behalf of this 0 ICX holding P-Rep very easily to make sure this P-Rep, that they want in power, can actually stay in power despite having 0 ICX of their own.

Having said all that, your concern of P-Reps taking all money from voters is not realistic imo, since that could currently happen right now. P-Reps could raise i_rep to the maximum (this is our current system), max out inflation and max out their rewards. Why don’t we do this? Because it will hurt ICX price, which we all hold a lot of and our cashflow is based entirely in ICX. However, we could also build in a hard-coded minimum for something like i_voter if we think it’s a realistic threat.

4 Likes
8

Additionally, it’s extremely easy for ICX holders to post a bond for a node if they so choose. Even in an extreme example, where let’s say 10% of delegated ICX wants to support a P-Rep that holds 0 ICX for whatever reason, those ICX holders can use their ICX to post the bond on behalf of this 0 ICX holding P-Rep very easily to make sure this P-Rep, that they want in power, can actually stay in power despite having 0 ICX of their own.

Oh, I wasn’t aware of this. So anyone can post a bond on behalf of a node?

1 Like
9

Yeah that is the current plan

4 Likes
10

Sounds good to me. Nothing to add.

4 Likes
11

Block Rewards
IISS 3.0 removed Block rewards ,we believe this is the wrong decision. Block rewards encourage validators liveliness, the 17.5% of total rewards allocated to P-Reps should be split based on vote percentage and round production, maybe 70% vote / 30% reward

Block rewards in themself work as an incentive for a validator to keep their node online, removing them removes this incentive and we introduce a penalty instead. Is a penalty better than a reward? If a validator gets jailed for failing to produce they would lose rewards, the jail time could be the current round and possibly the next 24-72 hours or whatever might be deemed a penalty enough to the validator. No validators want to lose rounds as they lose income as a result, as well as reputation.

Self bond with Slash vs missing rewards, in IOST if you miss 10 blocks in 10 minute round you are jailed for 24 hours, that is incentive enough in our opinion as you missed out in all rounds for the day. The same is true on IoTeX with the addition of voters rewards excluded, if you miss blocks your rewards are nullified for 6 epochs(6 hours) as well as your voters , but you do not lose bond you loose rewards and so do your voters, this encourages liveliness without bond slashing. Slashing of voters tokens we believe is not good under any circumstance. There can be many reasons that validator misses round and they are not necessarily malicious. It also does not play well in Enterprise Blockchain deployment scenario.

  • Re-introduce block rewards for IISS 3.1 (ICON 2.0) , 70% vote / 30% block rewards of the proposed 17.5% overall
  • Limit slashing to producer if its maintained at all

Block Production
Currently we have 22 Main prep in round that last 24 hours, all you need to censor transaction in theory is 1/3 and 2/3 to create invalid, as the vote stagnation means this rarely changes it can cause to much influence. ICON 2.0 introduces the idea of inclusion of sub prep which is good but some improvements

With shorter rounds and higher selection of random the network will have greater security and decentralisation. If you consider the likilness you can get 1/3 or 2/3 of the current round influenced under this it would be nearly impossible to organise.

Please study the IOST SERVI node rotation system where with greater number of validators on network there is very little chance you can even predict who might ever be in the next round

  • Shorter rounds (every hour maximum)
  • Random selection of 7/10 from top 10 , 8/20 from 11-40 , 7/20 from 41-100

Code is Law
The current constitution which prevents teams like Sesameseed or Metanyx creating their own economic design and should be removed, it is not enforceable or managable if it is not enforced by code is law principal. If a validator wishes to share their rewards with their voters they should be allowed to do so without an offchain rule. This is not vote buying it is a reward , the validator is not necessarily receiving additional rewards if are passing it on. It may lead to teams being voted higher and as proposed above may include them in more block rounds and if B1 is re-instated they might be passing those on their voters but is this a bad thing?

  • Constitution should be replaced with Code is Law

Inflation
Inflation should be set to 2-3 percent of total circulating supply with ability for Preps to vote on increase with a maximum of 5% and a minimum of 0.1% . All top 100 elected nodes should have vote with 2/3 required to pass on a 1 vote each scenario. An elected member of parliament (in the UK) has 1 vote, they are not weighted based on how many votes they received and this should be maintained as exists with top 22 but expanded to all elected 100. To much power is given to a handful where as all 100 are considered elected, if they are elected than they should be given a vote.

  • 0.1 to 5% inflation
  • Top 100 1 to 1 vote on change of inflation

Bond Requirement
Bond requirement could be used to define Capacity of total vote , it should not create an unnecessarily high barrier to inclusion. Current Main Preps who earn considerably more already have advantage to others. AION uses a Bond to define capacity but there is no slashing of the bond.

Bond slashing if maintained should be a percentage of the bond vs a given amount.

  • Bond to define capacity
  • Percentage of a bond slashed if slashing must exist
  • Voters should never have their tokens slashed

CPF
We believe that DPoC has generally been proven not to work, we saw this where main preps are unwilling to use there rewards to fund development and instead requested grants on top of what they were already receiving. The general idea of DPoC seems to be more of marketing than reality as proven today by the need to reduce P-rep rewards and create a Grant system.

CPF is a replacement of the grant system, we agree this is a better approach than a grant system.

  • 1 million ICX cap as proposed, must be distributed or burned instead
  • 2/3 of 100 must vote and agree on any funding (not just top 22, why are they considered elected if they do not get a vote)

We also believe in the KISS = Keep it Simple Stupid , ICON Foundation has listened to the community and tried to create an ecosystem that is sustainable around the protocol, we believe however some parts were unnecessarily complex and more simple model should be adopted .

Metanyx Team

5 Likes
12

Thanks for all the effort everyone. ICON is moving forward with a lot of moving parts.

1 Like
13

Thanks for the detailed reply @metanyx!

Self bond with Slash vs missing rewards, in IOST if you miss 10 blocks in 10 minute round you are jailed for 24 hours,

On ICON, we have both. The “Jail” penalty is the Validation Penalty, which is assessed after missing 660 blocks (~20 minutes of downtime). After suffering 5 validation penalties out of your last 30 terms, which translates to only 83% uptime, you will be slashed 20% of your Bond.

We can’t simply have jail because that creates an issue. If enough P-Reps are consistently down and there is no slashing penalty, they will continue to get out of jail and continue to fail to produce blocks. Yes, we could trigger another condition to get out of jail, like sending a transaction as suggested by @Edouard_Stakin, but after further discussion with ICON the “jail + unjail transaction” is an added feature that will slow down ICON 2.0 development and migration. We can add this feature after launch if we find it to be necessary or a strong improvement.

Re-introduce block rewards for IISS 3.1 (ICON 2.0)
70% vote / 30% block rewards of the proposed 17.5% overall

Any reward that is based specifically on running a node (flat reward per node, reward per block-producing node, etc. etc.) incentivizes a Sybil Attack. I don’t want to be in a situation where 10 Main P-Reps are operated by 1 entity and we just don’t know. We don’t need to pay people extra money for executing a Sybil Attack. On top of that, now that we are pursuing 3 rotating Sub P-Rep slots, all nodes will engage in block production anyway. The long term goal is to remove Sub P-Reps and only have Main P-Reps. The Validation Penalty (Jail) incentivizes uptime as well. If you suffer this penalty, you face opportunity cost for the term you are in Jail.

Shorter rounds (every hour maximum)
Random selection of 7/10 from top 10 , 8/20 from 11-40 , 7/20 from 41-100

This is an interesting thought that we will likely pursue / look into after ICON 2.0 launch. Making adjustments like this will take some dev resources to research and develop a different consensus algorithm and I’d rather have ICON focus all resources on migration to ICON 2.0.

Constitution should be replaced with Code is Law

We don’t have a constitution FYI and overall I agree here.

0.1 to 5% inflation
Top 100 1 to 1 vote on change of inflation

ICON is 1 to 1 vote AND stake-weighted vote. I don’t see the purpose of making it less secure by removing one of those thresholds. It will be Main P-Reps only, however, Sub P-Reps will be rotating in (3 per term), and the long term goal is to have only Main P-Reps as mentioned earlier. As for inflation rates, we are shooting for as low as possible. I like the suggestion of capping at around 5%, we can add this cap or something similar.

Bond to define capacity
Percentage of a bond slashed if slashing must exist
Voters should never have their tokens slashed

Everything you said here is already true.

1 million ICX cap as proposed, must be distributed or burned instead
2/3 of 100 must vote and agree on any funding (not just top 22, why are they considered elected if they do not get a vote)

1M ICX cap is already agreed and burning any extra is already agreed.
CPS will be managed by anybody that wants to sign up to manage it as mentioned on this thread.

14

Hi @BennyOptions_LL, Great proposal and thanks for putting it together.
Nothing to add to both point 1 & 2.
Additional recommendation around the inflation pool split categories; would it make sense to hard code a minimum and maximum expectations, this will fix expectation and enable better business and project planning with an aspect of certitude around earning vs cost.

Thank you,
Reda, Team ICONPLUS

1 Like
15

While I agree most of this part and new updates finally sub p-rep votes mean something with managing CPF issue is entry to 100 is near to nothing. Even though I agree to this approach without fixing the heavy vote % on top that would be suicide.

16

Hey Reda - this is a good idea that we had been debating internally. Thank you for sharing your opinion, and when it comes time to decide actual allocations we will also discuss minimums / maximums for each bucket

17

Any reward that is based specifically on running a node (flat reward per node, reward per block-producing node, etc. etc.) incentivizes a Sybil Attack. I don’t want to be in a situation where 10 Main P-Reps are operated by 1 entity and we just don’t know. We don’t need to pay people extra money for executing a Sybil Attack. On top of that, now that we are pursuing 3 rotating Sub P-Rep slots, all nodes will engage in block production anyway. The long term goal is to remove Sub P-Reps and only have Main P-Reps. The Validation Penalty (Jail) incentivizes uptime as well. If you suffer this penalty, you face opportunity cost for the term you are in Jail.

How will the sub-preps pay for adequate server resource on only vote based rewards? consider a random selection of 3 out of 23-100, you will have teams who cant afford to have adequate server on line, in current market anyone >50 probably cant run recommended server spec without loosing money. We are proposing more dynamic vote weighted rotation and to reward block production so people can cover costs of running server. You may never get into rotation if it is 3 slots and sub prep with lower vote wont be able to afford it

We do not think having block rewards incentivizes a Sybil attack if there is no way to predict if you get into a round, it only encourages more active nodes and network liviliness.

This is an interesting thought that we will likely pursue / look into after ICON 2.0 launch. Making adjustments like this will take some dev resources to research and develop a different consensus algorithm and I’d rather have ICON focus all resources on migration to ICON 2.0.

We really hope you do consider it, hard to change later, do you really want only network with top 22 and 3 rotating slots long term. Rotating more frequently with a weighted random selection as proposed in conjunction with block rewards would create more engaged sub-preps. It also distributes rewards more fairly outside of the top 22.

We don’t have a constitution FYI and overall I agree here.

If so can a P-Rep share their own rewards with a voter? if not why not?

Voting rights
Sub-preps should be given a vote if they are considered elected, if you have 100 elected candidates as you do in ICON it should be the same as in parliament(UK), every elected MP in parliament gets to vote not the 22 who have the highest amount of individual voter and the rest have no vote. The 100 seats should equate to 650 seats in parliament, the 650 have equal voting rights within the house of commons for any bill. Maybe its time to not distinguish between the two (P-rep vs sub P-rep), you are elected or you are not with the caveat that a higher vote gives you higher probability of being in block production (taking into account populous vote for block production only)

Metanyx Team

18

@BennyOptions_LL I agree on some of the points @metanyx share and I think there is a way to tackle it. Hard capping vote amount.
About rotating part I agree but it still drop down to most of the vote gathering on top I don’t think it’s going to be possible without server cost while that’s still can change. Same for vote rights case. So if we cap the vote amount to some number. It will force community vote towards to lower preps if some team have that much of their holding they can create a second one self stake and have 2 vote while they can’t gather vote over time because they are at top region. That’s also help a lot with foundations effect over onchain decisions and all. If I count icx station with foundation and didn’t count 2 main prep all other preps need to be together to make decision against foundation and station. For sybil atack issue I remember foundation self stake 24m right now foundation have 49.3m votes considering this vote goes towards other preps again sybil attack become less possibility foundation will still have more votes than any other prep but in the end not going to be that hard to pass something foundation doesn’t agree. For sybil attack instead of making it every sub prep we can do like every sub over 4 million for example can have vote + can join to sub prep rotation. Right now that’s literally 0 sub prep but that was a basic number I come up considering circulation numbers. Considering hard cap 8 million main preps have 238m vote that left 62m vote outside 22 considering all 22 become 8 million hard capped prep
with 4 million cap that still equal to 15 sub joining in to block production cycle and voting. Foundation have 4 votes in this format with 8 fully maxed prep account. It’s something I come up with now but it can be calculated and become something for the future.

White this on mobile let me know if anything about it is not clear :slight_smile:

19

If we put a cap on the number of votes a team can get, then literally every team that reaches that cap will simply launch a second node. The second node can easily climb ranks, as the larger node will delegate all rewards to the smaller node. As the smaller node grows, other community members will vote for it. I don’t see how it solves the issue, all this does is force whales to create more nodes, which we don’t want to happen.

If I were any team in the top 10, I would immediately create a new node if we pass this rule. Then I would delegate all my ICX to the new node until it grows to the cap.

Also, even if we did want to go down this route, I don’t see how it’s possible logistically. We would need to manually remove delegation from the top nodes, which will hurt the voters that support them for no reason. But open to ideas just in case this ends up being the bes

20

Not sure hardcap makes sense without some other method to reduce team wanting to spin up another node, one idea that AION has is that your bond creates a capacity of your node, it can however also be used as Stake , maybe it shouldn’t be for reasons below.

So imagine this, you have Bond, it is 100k ICX, you get capacity at x10 (pick the multiplier) your bond.

100k x 10 = 1 million capacity

For you to spin up multiple nodes you need a bond for each defining your capacity, it also means you have skin in the game and you are not necessarily rewarded for your bond meaning doing so reduces your overall reward. If we had 1 million ICX , it would be better for us to do

250k ICX bond = 2.5 million ICX capacity <— no reward on your 250k bond
750k ICX staked to my validator ← rewards on teams own holdings endorsing your validator

It creates a limit defined by your bond but also does not encourage you to create multiple nodes as it limits your overall ROI on your own holdings. Excluding bond from rewards with a capacity might be the answer

In case of scenario of a slashing penalty (whatever that might be) , the slash should be a percentage of your bond. There should be a minimal bond but not to high for lower Preps, It does however limit the ability for a team without large internal holdings to move up the ranks so there is that caveat.

As stated previously, rotation and block rewards we believe are necessary to pay for nodes to run adequate hardware, currently 50th ranked node generates about $30-40USD a day ($900-1200USD monthly). There is no way >50 can afford a server adequate to pay without block rewards.

Block rewards were removed mainly because they only were applied to top 22 (they already get more in vote rewards to begin with) and to subsidise the CPF (correct us if we are wrong). If we change the parameters to include more rotation than 22 (as proposed and as in IOST design basis) this is no longer the case that only a few get the block rewards as rotation will occur more frequently and more Preps get a proportion of block rewards to pay for there hardware overhead costs.

Metanyx Team