burdges
commented
2 days ago we don't have any control over the usage of those cores, but hopefully that ramps up as well.
We should reserve half the cores for gluttons for the near future.
In theory, we could temporarily cap no-shows for glutton cores, but instead count no-shows, provided we foresee some benefits to pushing faster and collecting data like that.
At some later point, kusama gluttons, without no-show caps, could be transitioned into polkavm contract cores which accepted user transations compiled from solidity, and which we fill using some solidity glutton. This is purely political, but it provides a nice proof of throughput, before we sell off those cores to people who'll underutilize them.
alexggh
The majority of the optimisations we deem necessary for achieving 1k validators and 200 cores polkadot from this board had been finished or in progress to be finished.
This ticket's purpose is to track all the dependencies that need to happen to gradually reach 1k validators on Kusama and Polkadot. That will allow both networks to have a maximum total cores of 200, we don't have any control over the usage of those cores, but hopefully that ramps up as well.
Checklist to target
Note all the steps are mandatory and are meant to be performed one after the other, if at any step we discovered anything not going according to expectations or if new data is discovered we are meant to pause and reassess the plan.
Kusama
Polkadot
All steps have as a pre-requisite that the same step have already been performed on kusama.
Honorable mentions
Migrating from the CPU intensive libp2p to litep2p, https://github.com/paritytech/litep2p/issues/140