Solution to Offline Sub P-Reps: Rotating Block Producing Slots

We are all aware with the current lack of protocol layer enforcement to get Sub P-Reps to run a node, and we all agree this is an issue that should be solved.

For ICON 2.0, the current plan is to add a rotating slot(s) for Sub P-Reps to produce blocks. Sub P-Reps will be pseudo-randomly selected (based on their bonded delegation) to produce blocks for 1 term. This solution can be seen in action on EOS.

If a Sub P-Rep is offline, they will suffer a validation penalty. If they miss too many blocks, eventually they will get slashed. Specifics on the penalty structure for ICON 2.0 will be discussed on a separate post, but for this discussion just understand that the point of this solution is that we have found a way to penalize inactive Sub P-Rep nodes.

Assuming there is no serious pushback to this solution, this will be the plan for ICON 2.0. It is also relatively easy to develop and implement.

We are also still considering how many rotating slots to have. Currently considering between 1-3, but open to suggestions. More rotating slots would be more decentralized because more entities will be producing blocks more often. The downside of more slots is that, if all the Sub P-Rep nodes happen to be offline and too many Main P-Reps are also offline at the time, it increases the chances of the edge case where we have too many offline nodes to produce a block. Remember that to produce a block, we must have 2/3 + 1 nodes online.

Finally, the last thing to consider is whether or not the rotating sub p-rep slots should have governance power and governance responsibilities. If there is a network proposal vote, will the rotating sub p-reps get to vote? If yes, they will also be susceptible to the governance slashing we agreed to. I am leaning toward “yes”, they should be involved in governance, just to keep things simple.

Disclaimer: Everything said here is subject to change due to development hurdles.

10 Likes

This is a great topic and I’m happy that it’s being considered as part of the upgrades for 2.0. I’m happy to expand where desired, but my short answers are:

I think more rotating slots would be better, so I would vote for 3 to encourage nodes to be online as much as possible. I do think its unlikely that the edge case will be realized at this point.

I also think these rotating slots should be encouraged and susceptible to governance participation and slashing. Ultimately it will mean, as sub p-reps, we will need to pay much closer attention to what happens and when, but thats a good thing IMO.

One concern, though, is that if we are going to be rotated in as block producers, we are going to have to run more robust nodes most likely all the time. I get that its better for the network and prefer that, but im concerned of the financial feasibility or encouragement for sub p-reps to do so if thats true.

4 Likes

Thanks for the feedback Brandon. I meant to address your point in the original post. The cost of running a block producing node on ICON 2.0 is expected to be cheaper, but if it’s still a problem for some Sub P-Reps that have proven to be active members of the community I’m sure we can come up with a way or a program to get them more votes until they can be self-sustaining running a full node.

5 Likes

Awesome I had wondered if 2.0 might make it cheaper overall. Great news, looking forward to it!

3 Likes

Already had a similar idea some time ago: Proposal: Incentivize Sub P-Reps to run a Node by changing how Sub P-Reps become Main P-Reps

I think it definitely makes sense to create such sub prep slots. Maybe start out with only 1 and leave it open to governance to create more (or less).

3 Likes

This is a great idea. As Scott said, ICON 2.0 should be more efficient in terms of resource usage because of the refactoring in Golang. Though even with the current level of network activity, I think many sub P-Rep nodes should be able to handle block production just fine.

Anyway, definitely in support. 3 spots is a good start, and I think they should be able to participate in governance if they are are going to replace a main P-Rep for block production.

3 Likes

We are very supportive of this idea. As ICON moves towards incentivizing further decentralization with the upcoming vote spreading algorithm, a solution to solving the inactive Sub P-Rep free-rider issue becomes a must.

In terms of implementation, I guess we can start with 1 slot and then iterate from there. The threat that slashing exists and is possible might be enough to convert all the motivated Sub P-Reps from inactive to active.

4 Likes

Great news and a good idea!
We support this step; I would support more rotations near three as everything will be more decentralized, but even 1 will be enough to understand who works and who does not.

In EOS, it was a decisive move to decentralization, they also had skin in the game, it’s very important.

If you need any help with testing or ideas, we will be happy to help.

3 Likes

Really supportive of the ideas, thanks for sharing them.

I too lately have been thinking a lot about this subject. In searching for the best solution I was able to come up with what follows. I like this approach as it seeks to incentivise positive behaviour rather than focusing on punishing the negative.

  • Source funding - via DApp/CPS/Grants,
  • Track Node uptime,
  • Pay an uptime/node operating bonus for qualifying teams after,
  • Qualifying teams need to do more than just run a node, they’d have to be ‘public representitves’ for a few hours a week,
  • This doesn’t mean shilling, it means being exciting about the technology and wanting to share it/promote adoption,
  • Compulsory video meeting attendance quarterly/monthly with the Icon Foundation/network.

Obviously not a long term solution, but perhaps a fun short/mid term initiative to boost node numbers and uptime?

I am also very supportive of this solution since there are many dormant nodes at high places. Only issue I see is where do we draw the line since we can’t expect every sub prep to run full performance node and these low performance nodes also effect networks performance.when they got in to consensus group

Hi everyone! We are happy to see this being soon implemented as we also suggested a similar solution in one of the Governance calls back in March. Our proposal was the following:

  • Identities that don’t run a node shouldn’t earn rewards. The solution we suggested: set identities that don’t run a node as inactive if the node isn’t up for a certain period of time (x days). These identities can be set again as active with a certain transaction. If one identity goes inactive multiple times, after a certain number of cases (y times) they should get a slash. Monitoring of the P-Reps can be made by using the latest block height of every node.
1 Like

A few days ago, we had a meeting with the team and discussed ICON and Rotating Block Producing Slots solution, similar decisions were in the EOS as mentioned above, but everything was much easier.

Maybe someone doesn’t know but our team is a block producer in the EOS ecosystem - https://bloks.io/account/atticlabeosb almost from the beginning we have been involved in creating many solutions both for the network and for validation, development, etc. - https://medium.com/eosatticlab/attic-lab-contribution-to-the-eos-blockchain-193212fe6e16

so, we can help with the development of Rotating Block Producing Slots solution, but make a similar decision as it was in EOS

J-son file that randomly checks whether the subnode is online and whether it will be able to sign the block or no, etc, if it may be interesting - I can share more information

3 Likes

Hi Scott,

Do we know how many subs will be willing to pay for and run a full node? What is the cost?

We don’t know the cost yet

Scott, I like your ideas but feel we need to research which teams would actually participate. I do like your ideas:) Below are my thoughts…

If subs are required to pay for and run a node that costs around $500 a month with the risk of a burn penalty it would be good to get feedback from each Sub P-Rep team to see if they would play by those rules.

*You only have 2 or 3 subs that have responded to your question on this forum, there are 78 teams that will be affected.

IMO-
*If your goal is to limit future rewards going to about 40 teams that will run a full node, then the plan is good.

IMO-
*If your plan is to try to motivate P-Reps to run a form of a node you need to increase to 30 main P-Reps and require the other 70 Sub P-Reps to run a less powerful node so profit margins seem attractive.

Maybe you should use ICON VOTE and actually get details on who would support this. We need feedback from more teams on major decisions.

Personally, I don’t mind which direction this goes but thought I would share my thoughts.

@Icon4Education let me clarify the situation.

Sub P-Reps are and always have been expected to run a node on the ICON Network. Currently, there is no way to enforce that on the network level. This is not a matter of gathering interest of sub p-reps. This is a matter of creating a secure network with proper fallback mechanisms (sub p-reps). That is their purpose -> to be a fallback mechanism if main p-reps go down, and with this new model, they will also be acting as Main P-Reps whenever they are selected by the algorithm to produce blocks further decentralizing the block production process.

This type of mechanism is necessary regardless of whether or not the current sub p-reps want to run a node. Economics will work out in such a way that only those that make enough money will run nodes. The number of nodes we actually end up with depends on what we decide for IISS 3.1 in terms of:

  • Amount of total inflation
  • percentage of inflation going to P-Reps
  • ICX price

Depending on the above variables, it may or may not be profitable to run a sub p-rep at slot 100 vs slot 75 vs slot 50 etc. This essentially creates a minimum amount of ICX that you must purchase (and self-delegate) in order to run a profitable sub p-rep. This is somewhat comparable to the minimum amount you must pay for electricity to run a profitable miner on Bitcoin. It’s a function of the price of BTC and the total difficulty on the network, while for us, it’s a function of the price of ICX and the amount of total ICX delegated.

The network can support 100 slots, if not all 100 slots are full of nodes, then there’s no issue. The slots will get filled as ICX price goes up, total delegation goes down, or if more network inflation is allocated to this.

1 Like

Scott,

I like where you are heading with this, I just wanted to make sure the Foundation realizes many will not participate, but I like the way this is heading, rewarding full nodes that are meaningful to the network.

I am also glad to hear the Foundation realizes 100 full active nodes will probably not happen when this initially releases, but could as our blockchain improves over time.

The thought process makes sense, thanks Scott!

1 Like

Great Initiative. We will support it.

As we proposed in IISS 3.1 discussion thread

Block Production Rotation
This was done in IOST since day one with the rotation design where there is an accumulating Servie token(internal token for round entry) balance based on your current vote, the top 22 would be selected in first round, there current committee balance is slashed, in IOST this is now by 1/10th average of all elected candidates average value. The next round the ones sitting on sideline accumulate again as well as the current 22, most likely some of the ones on sideline now have higher than some of the 22, maybe a couple, maybe more, depends on vote distribution on network. The top nodes might have enough balance even after the slash of the balance to get back in to next round.

What we proposed to ICON is

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

This way its weighted in favour of your vote, so you are pretty sure you will have (7 from top 10 and 8 from 11-40) 15(needed for consensus) selected from the top 40. So long as you have 15 out 22 online the chain will continue without interruption.

Block Rewards
Without rotation block rewards are just paying top 22 (who already receive more by vote) even more. In IISS 3.0 the proposal is to remove them, but this is does not apply if you rotate your block producers more fairly as by definition more nodes will now share in these block rewards.

This is important because the top 22 will always receive more rewards with or without block rewards as they are already higher ranked and therefor get more rewards. By rotating block producers in you are now expecting lower ranked nodes to run adequate hardware without paying them any more to do so (Not good).

We believe it is in the interest of the network to review design of competing Blockchains , we propose the following

  • Rotate more producers 7/10 from 1-10, 8/20 from 11-40 and 7/20 from 41-100
  • Do not remove block rewards, they will pay for the lower ranked nodes if rotation occurs more frequently

If implemented correctly based on Metanyx design you will

  • Spread rewards more fairly (block rewards will offset vote rewards)
  • Increase security of the network (as more random rotation occurs)
  • Ensure validators have enough rewards to pay for adequate hardware
  • Increasing network liviliness (validators will not want to miss blocks, suffering loss of rewards, loss of reputation and possible slashing penalties)

Metanyx have worked with both IOST and IoTeX to help improve their network as a technical partner proposing many of the same things in early development of the respective chains. With ICON 2.0 you have the opportunity to improve the base layer, it is not easily done once the chain is live, rushing to get 2.0 out without considering the longer term benefits of a better fairer system is shortsighted. We hope to see the reversal of IISS 3.0 in regards to the block rewards (which are not being removed until 2.0 anyway) and increase the rotation beyond a couple slots. Time to think out of the box and do something truly novel.

Metanyx Team