Addition of a requirement for all P-Reps to run nodes, and process for removal of P-Reps who do not run nodes

Governance
#1

To secure properly the ICON Network all the P-Reps should run a node (not just Main P-Reps). ICON Network is built in such a way if that all 22 P-Reps are down then the next 22 Sub P-Reps can replace the P-Reps and run and secure the ICON Network properly. Additionally, Sub P-Reps run citizen nodes, which provide a copy of the ledger and enhance the decentralization and availability of the network. As a minimum contribution, all P-Reps should have their node properly configured and running. Since Sub P-Reps receive fewer rewards, we would expect their nodes to be scaled down into configurations that can run on a $50-$100 estimated monthly cost.

Our proposal is to add a node uptime indicator to the tracker for all the P-Reps and Sub P-Reps. All the P-Reps and Sub P-Reps will be expected to maintain an uptime of 85% for their node, with an initial grace period to get their node up and running. If, after the grace period, a P-Rep does not comply with the 85% uptime requirement, then the P-Rep will be automatically removed from ICON Network.

1 Like
#2

From what i’ve understood, the reason for the Sub P-Reps not running their nodes is their rewards not covering the expenses. If however one can run a node for shy of $100 a month, i agree everyone should be able to run a node.
However, we are still very early in this whole process, so a think this proposal is a little premature still. Try and get everyone run a node, absolutely! Think we should wait a while with the whole DQing though. Rather focus on getting more P-Reps in total.

#3

Citizen / sub P-Rep node can be run for low $10’s / mo. Everyone in top 60 makes at least that, so I don’t think that not making enough to cover the cost of the node is the main reason for not running it. It’s more likely receiving not enough to care or total lack of technical skills to run it.

Node uptime and productivity are two completely different metrics and I don’t think the former is something that blockchain could track.
Looking at the tracker now, it appears that inactive nodes are concentrated below rank 50, which is not a problem for the network security as such. These nodes are unlikely to fill in for Main P-Reps and even if they did, at these ranks they’d be presumably heavily scaled down and might not be able to function properly.

I think what needs to be done is:

  • reach out to P-Reps not operating a node and inform them it’s their duty; offer technical help
  • educate ICONists that they should take the node status into account when voting

All in all, I think this problem will be solved over time as inactive P-Reps fall out of top 100.

#4

Oh okey. In that case i definitely agree p-reps should be able to run one. And as you are saying, as the total number eventually grows north of 100 teams, this will probably (hopefully) be less of an issue

#5

Yes, I agree that the method of education and helping lower p-reps should help. This has been offered to all p-reps who engage By ICON and other p-reps, and resulted in an increased number of p-reps running nodes. The issue is with p-reps who do not engage or take advantage of the resources available. I agree that the problem should sort itself out over time as more p-reps join. The question is should we add a rule, give a buffer of time to setup a node (maybe a month), and then enforce. Or do we allow a small portion of p-reps to continue and be inactive, even while offering to help.

#6

I agree that a node should be run but also agree with everyone’s assessment here.

One thing to consider for things like this is, instead of a hard “network proposal”, maybe we leverage ICONalysts “community policies” for this. These function similarly to network proposals, but allow all P-Reps and iconists to weigh in on the policy. If enacted these simply become the networks adopted policies and guidelines (at least that’s the intent), rather then hard rules.

What are your thoughts on this approach?

#7

Overall, I would prefer to solve as many problems as possible at the protocol level rather than relying on off-chain politics and potentially biased decision making.

For this specific problem, I would be interested in researching how we can get the ICON Network itself to recognize whether or not a node is synched. If a node is out of synch by a certain threshold of blocks, then the node does not receive any rewards.

For example, let’s say the threshold is 21,560 blocks (~12 hours). If the current block height is 10,021,560, nodes must be synched to at least block 10,000,000 in order to be eligible for rewards.

#8

That is a great idea, if i may say so! I was pondering over the whole reward-problem myself. This sounds like a good solution!

1 Like