There is seemingly nothing about “cores” here in the technical sense, so the name makes little sense.
Just fyi…
If we push the polkadot v cpu+os analogy, then parachains resemble processes, coretime sales resembles accounting & prioritization like acct & nice, and our “cores” resemble cpu cores, into which the relay chain schedules processes. We’ll have more total processing if we have more cores, but parachains looks pretty independent, like maybe many parachains make blocks only once every 10 minutes.
We must limit total code size across all parachains of course, for which the polkavm folks envision doing dynamic linking eventually. I’d kinda expect dynamic linking would play poorly with the current codebase, but we’re far away from these costs being problematic, we could transition piecemeal towards dynamic limnking friendly code, and spree imposes more constraints than dynamic linking does.
At present, we add cores promarily through optimizing performance, but we expect one relay chain of 1000 validators cannot go beyond 300-500 full speed cores. We could improve node specs too of course, see trade offs. We could add multiple relay chains too, by using an improved analysis to omniledger so their byzantine assumptions agree, but even this does not improve the code size limit per se.
I’d expect 1000 cores likely means 2000 validators across 2 relay chains, but maybe more if optimizations work out poorly, too many low spec validators hold too much voting power, etc.
Anyways…
None of this is what you wanted to discuss. I just wanted to point out the name fits poorly.