unfortunately, I have no IT-educational background (socioscientific/ philosophical). This is my first post in lisk-research. I’m not very familiar with the guidelines, so take it easy on me.
Since Lisk will have a working product pretty soon, interest and load in/ on the lisk network will grow. Projects will launch on Lisk, which will grow the ecosystem/ network. As we know, the more validators a blockchain system has, the more decentralized, robust and resilient it will be. Furthermore, a large number of delegates (validators) give incentive to become a delegate to comminity members, who have thought about becoming a delegate, but have discarded that thought due to contemporary hurdles.
It might seem a good idea to implement an increase of valodators not only once. As in opposition to the block reward reduction system, the no. of delegates could be increased, multiplied by a factor x after y blocks.
Example:
currently 101 delegates forging; after 1.000.000 blocks increase by factor 2
block 10.000.000 -> 101 delegates
block 10.000.001 - 11.000.000 -> 202 delegates
block 11.000.001 - 12.000.000 -> 404 delegates
and so on
Max amount of delegates can be hardcapped or left open.
I would like to add, that the period after which the no. of delegate increases (every 1.000.000 block) is not well reconsidered. A more convenient period would be every 5.000.000 or 10.000.000 blocks.
Thank you for your interest in Lisk and for sharing your ideas.
Increasing the number of active delegates is one of the approaches we have considered in the past in order to increase the decentralization in Lisk and lower the entry level to become a block generator (delegate) and contribute to secure the network. However we saw a fundamental drawback of this approach and that is why we have discarded it:
Increasing (significantly) the number of active delegates will increase the length of the rounds and consequently decrease the performance of the network. In fact, with the BFT consensus for Lisk, the length of the round becomes a critical factor for the expected time for finality.
Nevertheless, if you check the Lisk Roadmap you will see the objective Incentivise standby delegates under the Delegate Proof of Stake milestone. This objective is meant to solve the exact issue you mentioned in your original post. By giving standby delegates the possibility to forge a block in the next round, they are encouraged to run a Lisk node and improve network decentralization and stability. This proposal is in the last steps of internal review and hopefully its complete version will be open for public in this forum soon.