Increase over time the number of P-Reps

Increase over time the number of Preps
Now we have 22 Preps. Increase over time the number of P-Reps with x%.
The main argument to increase the number of P-Reps is the security and stability of the network.

1 Like

So there is 100 full p reps. 22 block producers and 78 sub p reps help vote. I could see this growing and would like it to when ready, but not too soon of course

I agree number should increase but without significant consensus algorithm improvement that change only hurt scalability i think we need to preserve 2 sec block time

This is a good and valid point. All trade offs should be considered carefully. As I said, not too soon - part of being ready will be proper research into the effects of additional p rep block producers. The 2 second block time is a huge plus for usefulness of the icon network.

As our network grows I would like to see more too. I think 100 is enough to start with though. I really like the idea that there are 22 and then 78 sub P-Reps ready to go too.

Upon further consideration I think bumping P-Rep numbers up very early could be smart. We have a number of quality teams outside the 22 atm. Maybe 25-30 could be a short term goal?

I think just by increasing the number of active P-Reps do not help if the vote difference is so huge as P-Reps in lower ranks (e.g. below 15) will not have the financial strength to implement comparable infrastructure to top P-Reps…

Especially for lower ranked P-Reps, the block reward makes a whole lot of difference. 25k ICX / mo.

I think infrastructure costs should never be eating up a large percentage of any of the P-Reps budget above 1M votes. Node operation costs are variable but rewards should be for expanding ecosystem more than anything. Not just running a node.

This is good point. Actually ICON team has also been discussing about the number of Representative set and we are working on how to implement on current IISS and loopchain logic. In order to implement this, we should consider the reward system, consensus performance, BTP technology and so on. We will approach this carefully and share the initial idea with ICON community. Any discussions and comments are welcome.

2 Likes

Great we should do a lot of stress test to see the effects of change.

The current structure of the ICON Network relies on 22 P-Reps to validate transactions and produce blocks. While this is a good starting point, we believe a higher number of block producers enhances the resiliency and decentralization of the network. Our proposal is to increase this number over time in order to increase the security and stability of the network.

The current structure appoints P-Reps outside the top 22 as “Sub P-Reps.” There are many good teams outside of the top 22 who we believe can and should contribute to block production. Block producers receive a higher amount of ICX rewards and many of the Sub P-Rep teams are contributing to the development of ICON Network and are not receiving enough rewards for their future development. If we can expand the number of Main P-Reps, we can enhance the security and stability of the network, as well as provide rewards across a greater number of P-Rep teams.

1 Like

Do you have any news about this? IISS 3.0 don’t specify anything about this.

As Bong mentioned, yes we should gradually increase. However, for example, I’d like to see CPS work with 22 teams first.

it would be interesting to see how increasing the number of Main P-Rep will affect the overall TPS of the network, or if it does, I haven’t checked out the code or have researched in-depth about this subject yet but basically what I understand is that by applying BFT forks are avoided in a POS or DPoS blockchain, the problem is that as the nodes (in our case Main P-Reps) increases in the blockchain, more communication or messages are necessary to achieve the consensus thus decreasing the speed of block production.

LFT2 decreases the amount of messages between the nodes from 3 to 2 without having a considerable decrease in security and stability in the network, but it would be interesting to see how the TPS of the network changes as we add more Main P-Reps.

if Im way off on this analysis a correction of my mistakes would certainly be appreciated :sweat_smile: