thanks for posting this and opening up the conversation, just finished reading it and wanted to make a quick comment about the “sybil attack” sorry if someone already mentioned this, I havent read all the replies yet.
If this is approved the “sybil attack” scenario could be avoided if we expand the block producers to more than 22 top nodes (maybe top 50?) but if my understanding of PBFT is correct if we increase the amount of block producing nodes this will make consensus slower and the block generation will be slower, maybe this is not the case for us since we use LFT2 but I dont know enough about the details of how consensus is achieved to be completely sure
the other important point is that if we increase the amount of block producing nodes it will have an economical impact on the operators that will need to be analyzed and/or discussed too
I agree with Geo on this, the best action right now is to wait for the bond to be activated and see how many nodes are able to successfully post their entire bond, after a couple of month we can evaluate and act accordingly.
is highly likely that the bond will improve this situation
Nym’s proposal seems like the most efficient solution to asymmetric vote distribution, which I do think is a problem. It’s important to spread resources and increase number of main p-reps in order to maintain a meritocracy and increase decentralization.
The multiple node issue seems like an inevitability that can only be stopped by expanding the number of main p-reps.
I’m still new to all this but is it possible to just redistribute the voting rewards of those over the proposed 2.5% equally to the rest of the nodes? If not and the solution is voters being prompted to vote for an alternative P-Rep then I think it is important to have vote guide functionality built into the wallets. These should display the P-Rep’s action plans, bios and milestone updates.
I also think we should consider have voting refreshment period where every six months or so you should be prompted to review your vote distribution. This encourages more thoughtful voting than the default which for many is just set it and forget it.
There’s changes already pending to be made to the governance contract and we are discussing more changes? This is what I’m talking about. Give the current changes time to take effect before we can even consider more changes. How can you even know what will need to be changed after 3.1 if 3.1 isn’t even live yet?
I agree with Geo. Let’s start by implementing bond requirements as discussed earlier. Perhaps that alone will be enough to fix the issue? Give it some time. If we start throwing the whole kitchen sink at once, we’ll have no idea what’s actually working.
Furthermore, I’m still not seeing a satisfactory solution against large entities spinning up multiple nodes and potentially taking over the ICON network. So as it currently stands Mineable would vote to reject this proposal.
First, I think we need to consider “Decentralization”! I don’t really understand how ICON came up with only 22 Main P-Reps who can produce blocks?!? I don’t think 22 can be considered a decentralised network at all! If ICON is worried that more Main P-Reps producing blocks can bring security risk or some other form of threat to the network, then the ICON Dev team needs to work on this aspect until they find the solution.
My main point is that ICON Network needs only Main P-Reps and everyone who wants to be the Main P-Rep to apply for that, follow the rules, and be penalised if their nodes aren’t working as required.
The other important thing is to standardize the rewards for all main P-Reps to get the same amount of rewards operating the nodes only.
Then, the rewards from voters to the Main P-Reps can be separated and fixed for some reasonable maximum (for example 2.5% as you proposed already) in which if some Main P-Reps want to run multiple nodes and spread the votes on these nodes, so be it. ( this will bring a more stable network and additional cost for those who want to run multiple nodes anyway the % will be the same).
I think this will fix most of the issues and problems we are having now.
has good model too. Since it is the same identical job for all BPs (P-Reps), so, Telos pays exactly the same for all top 21 BPs and then 50% less from 22 to Nr 45. No pay from 46+… Votes have no impact on rewards (Votes only decide rankings and Governance)…
All non-BP activities have Worker Proposal System (like CPS) model… In this model, no one is worried about the cost to manage P-Rep nodes…
In ICON case P-Reps ranked no 1 and ranked nr 22 have to do the same jobs (& same costs for running/managing a node), then it does not make sense to have different rewards…
There can be a limit be on how many P-Reps should be paid e.g. we have today 100 P-Reps. But 2 or 3 ranks can be defined in terms of Payment.
Rank A: Top 22 can have “same” pay, Rank B: 23 to 50 can have 50% less than rank A P-Reps. Rank C: the remaining 51-100 may have no rewards or can be very low e.g. 15% of what Ranks A gets. and the rest has no pay…
NOTE 1: The payment for Rank A should be auto calculated/adjusted monthly, considering the average USD value of ICX in the last 30 days… Whatever is the appropriate USD cost to manage a node can be agreed.
NOTE 2: If P-Reps do other jobs/tasks for growth/development of ICON ecosystem , then, it should be funded by CPS or ICON Foundation.
NOTE 3: ICON Foundation needs to be more involved and should have maybe monthly meetings with P-Reps? We have no idea how ICON Foundation members are selected and what they do? On the other hand Telos choose Foundation members by annual elections on the blockchain (that lead Marketing, Business Development, Growth, Strategy, Legal, etc.) and they have several monthly meetings and live Video Public sessions for the general public.
NOTE 4: Also no BP (P-Rep) can have multiple nodes or stake/investment in multiple P-Reps. P-Reps identities should be known to at least ICON Foundation to ensure that no one runs multipole P-Rep nodes or has an investment in multiple P-Reps. Also in the case of Telos, Foundation can not run a BP Node as the foundation has to be independent…
