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

2 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