This is an interesting and well-made point. However, I’m not sure it’s an argument to NOT go ahead with the proposal, but rather to be more strict about the measures we’re taking. Which seems to conflict with your next argument about not taking any economic measures.
Apps care about reliability above all else. I would think that our DAO being thoughtful about the reliability of the network sends a positive rather than negative signal.
Not every node operator will keep updated with the news, but they’ll surely be monitoring the profitability of their node? There might be a lag for some of them but when they realize their service node rewards are dropping, they’ll take notice and enough should spin down nodes in response to keep our node count at a reliable level.
We have a solution at the Pocket Core level. PIP-4: Consensus Rule Change: 0.6.0 introduces a change that means any nodes beyond the 5k limit will become just service nodes. However, and this answers @shane’s question too, service nodes are still likely to face the scalability problems that Tendermint P2P is known for, so we still need to go ahead with this proposal to help prevent possible degradation of service.
The limit is “unknown” but we should generally be conservative where the reliability of service is concerned, especially since we already have more than enough nodes to service the apps that we’ll be servicing in the mid-term.
@bulutcambazi A general rule of thumb would be to assume that the developer’s have already thought about optimizations like you describe and that they’re working to the best of their ability to optimize our network to balance scalability and reliability without breaking anything along the way. The separation of validators/servicers in 0.6 is a monumental achievement that is coming a lot sooner than we anticipated and the core devs are working on many other improvements that will help realize the full-scale vision that you describe.