**Original post by Kian:** https://hackmd.io/sP9KlLUBRpukfhL6GyPa2w

**The Problem**

On Polkadot, there is a fixed block time of 6 seconds. Only a relatively small portion of that time can be used for computation: 2 seconds (we need the extra 4 seconds to account for delay in propagation, time it takes for another node to import a block, among other things): even if every machine running a node was a super computer, we would have some upper limit to the amount of computation we can do in 2 seconds. **It is a must to try and keep our validator specs relatively within consumer hardware limits**. We cannot make crazy requirements on the network for running nodes.

We have reached the block in which the NPoS solution had to do the on-chain fallback. The block took about a minute on a local node to be imported, but all in all, the network was shaken for a solid ~ 30minutes until all nodes managed to recover and catch up. The core cause of this is that the staking pallet weights were re-measured again, and the weight for `submit_election_solution` increased almost two-fold. Regardless, **sooner or later NPoS size will be so big that the weight will become too much.**

**The Possible Solutions**

**First temporary solution:** https://github.com/paritytech/substrate/pull/7215 - This is a move toward **DNPoS**, since we are effectively limiting the number of active nominators. **The issue stands in limiting participation to small token holders.**

The immediate patch with PR 7215 (to be deployed soon) will partially remove a number of least staked nominators in favour of fitting the solution on chain. 

1. Some council members seem to favour the idea of **setting a minimum threshold to nominate**: combining this with ways in which small stakeholders can delegate nomination votes. 

- For some, it might be a good idea to set a minimum nominate amount in DOT: above 100 DOT. Like this, very small amounts will not nominate or must increase holding.
- Another idea involves allowing something like a central contract to hold many small nomination holdings and do one nomination for all of them, maybe incentivising 3rd party service to develop around this.
- A third idea is to incentivise the development of offchain nomination pools. 
- As a mid-term/long-term solution, it was also suggested to switch to a more lazy model for nominator slashing and reward.

2. Some of the council members **opposed the idea of setting a minimum amount to participate in staking**, while others stated that a low barrier to entry for governance and operation is a good principle but lack practicality and does not scale well: "...in terms of making usable governance/staking systems with the tools we have available today, that implementing certain thresholds for participation would be a positive thing (...) Our staking system would not be able to handle 1 billion 1 dot stakers as it is written today."

All in all, the idea that seems to be **the most supported** is implementing some participation threshold (based on the first points above) combined with a like-DAO-mechanism for users with smaller amounts of DOTS to collect and act as a single strong voice on Polkadot, i.e: having a hard limit of 100 DOTs to be a nominator, and a DAO so that any number of users can collect 100 dots together and use their own internal governance to choose validators could solve any scaling issues. Someone with less stake would get less flexibility choosing which validators to back than someone with more stake: if you have 1 DOT today you can select 16 validators of your choice to back. In this future scenario, you would simply need to find a DAO (or any other design) who would want to select those same 16 validators. Maybe you can't find that perfect group, but if a DAO supports 14/16 of the people you wanted, you would join them.

Thus the DAOs would convert a potential 7 billion human users into 10,000 groups which the pallet can handle. **Complementing the DAO proposal**, it was suggested to also charge some (optional) percentage fee for delegated participation in order for nominators to make better decisions: this already exists to some extent in a very ad hoc way, as some Validators offer a "controller as a service" for nominations.

A middle point between both POVs was suggested: implement vote delegation with the ability **to immediately withdraw** as the best tradeoff between technical scalability and giving everyone a voice.

**Coming soon?**

A design establishing a min threshold for nomination + DAO design to aggregate small token holders with an option percentage fee for delegated participation seems to be the most popular approach.

In the long-run, It was suggested to take advantage of dedicated system parachains which will offload computation of staking, democracy, etc onto dedicated parachains. We may even have those parachains have longer block times, which would extend the amount of computation that can be done in one block.


- Polkadot has a fixed block time of 6 seconds, but only 2 seconds can be used for computation.
- The NPoS solution is causing problems because it takes a long time for blocks to be imported and the weight for a certain function is increasing.
- One temporary solution is to limit the number of active nominators, but this may exclude small token holders.
- Some council members suggest setting a minimum amount of tokens to nominate or using a central contract or offchain nomination pools.
- Others oppose setting a minimum amount, but suggest implementing a participation threshold and a DAO for small token holders to have a voice.

#114 Polkadot discussion summary: NPoS solution size limit