Like @florentina57 mentions let’s remember the community already voted for a future JAM configuration of 32 cores with 96 validators(maybe less initially), I’ve been cooking a proposal for a while checking with some of the affected parties if it makes sense to progressively reduce Kusama’s capacity not only to accommodate for “lightweight JAM” but also to arrive to a sweet spot that reflects better current demand and gives people room to adapt to the changes. I’ll soon make a root proposal with a batch to:
- First set validators to match the 700 paravalidators(
staking.set_validator_count?)
Then following in the a batch with separatescheduler.schedule_named_after - 1 month later: set cores to 120, validators to 600
- 2 months later: set cores to 100, validators to 500
- 3 months later: set cores to 80, validators to 400
- 4 months later: set cores to 60, validators to 300
- 5 months later: set cores to 40, validators to 200
- 6 months later: set cores to 24, validators to 120
I’m still not sure if it’s enough to do configuration.set_max_validators/configuration.set_coretime_cores in the relay or if broker.request_core_count in coretime chain and staking.set_validator_count in AH are need separately. I didn’t have much time to do the full research but expect something soonish.
Whether it passes or not I do think we need to do something similar to adapt to our current nonexistent demand, first let’s have a sustainable ecosystem with economics that make sense and scale back up once demand requires it.