We have identified there are possibly mis-configured elections-phragmen pallet.
The gist of the issue is that this pallet performs the full election process (phragmen algorithm by default) onchain, and on_initialize . This, if overweight, will cause your chain to stall.
To fix this, there are number of things you need to know:
- Foremost, set reasonably high deposits, so that at least if your chain stalls, someone needs to lock good amount of funds for it.
as a side note, low deposits also played a role in this attack: Thoughts on governance security and configs for parachains
- Set maximums. The pallet is configured so that if it has more candidates and voters, it will just not do any election:
The main problem we have seen is that some have set these numbers to really high values like 10,000 voters. These number are possible copy-pasted from substrate’s
kitchensink-runtime. Don’t do that! The configurations of this runtime are not meant for production use.
- As soon as this PR is merged, you will be able to control the number of voters per voter as well. This should help you further reduce the weight, and in turn have more voters:
- As soon as this PR is merged, you should be able to configure the pallet to use a simpler election process, such as simple approval voting, which should make your council elections more scalable.
- Finally, how should you determine the maximum voters? You can inspire from the newly added
fn integrity_testin https://github.com/paritytech/substrate/pull/13305. If you runtime is already setting a value too high, the test should emit a warning.