# NPoS solution size limits 😱.

This is the first block in which the NPoS solution had to do the on-chain fallback. The block took about a minute on my 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.

https://polkascan.io/polkadot/block/1733750#events

We expect to see the same behaviour until this is addressed. Grab a 🍿 and 🥤 every day around 1:30pm to witness this with me.

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. I don’t want to investigate more if this is correct, because the weight is just a matter of time. Regardless, sooner or later NPoS size will be so big that the weight will become too much. Anyways,

before the upgrade, based on my estimates, the solution size was around 50% of the block weight. Now it must be around the full block weight.

> Kusama doesn't have this issue yet, but it will get there rather soon.

There are no perfect ways to solve this, at least until we have multi-block-processing.

While we are bound to **one** block, there is quite a tight limit to

1. If we *compute* a solution on chain, how big it can be,
2. If we *check* a solution on chain, how big it can be.

My first solution to this, as a temporary measure is this: https://github.com/paritytech/substrate/pull/7215

This will make the OCW *weight-aware*, and they start stripping the final compact edge weights until we fit into the block. We always reduce the least valuable nominators first, those that have the least amount locked.

This is, in some sense, a move toward DNPoS, because we are effectively limiting the number of active nominators. Well, we're limiting the number that can be processed by the offchain submission, but unless if we are fine with on-chain solutions, this is the only way for now.

So the continuation of this effort is to formalise this, and make it easier for small token holders to still participate in staking by the means of delegating their tokens.

Parallel to this, it is also quite exciting to experiment with multi block phragmen. This will also eradicate this problem entirely. Moreover, imagine when we have Staking in its own parachain, only multi-block process makes a lot of sense. Because, in that parachain there are no other events/transactions, and the chain has all the time in the world to do its thing, it just needs to split that work into smaller blocks.

Again, parallel to all of this, we shouldn't be adding even more complexity to staking. I am working on a `type ElectionProvier` that allows staking to be independent of its election and just call `T::ElectionProvider::electio(...)` when it wants to. I think similarly, the reward with all of its reward curves and whatnot need to also be decomposed from core staking. The rewarding sub-system can be its own pallet, store its own state, collect reward points, and communicate with staking when needed. Then, `fn delegate` is a small addition to this sub-system, where once the there are any payouts being make to a nominator `N`, its delegator automatically take a share.