This thread is a discussion / pre-RFC topic focusing on the Core primitive and where it causes friction when looking into the future of Coretime allocation. Cores are an artifact of Polkadot’s architecture. These goals lead us to use cores: Loosely: Rate-limiting workload as a result of new inpu…

Related to Unifying bulk and mid-term blockspace with strided regions Coretime Scheduling Regions by rphmeier · Pull Request #3 · polkadot-fellows/RFCs · GitHub https://github.com/polkadot-fellows/RFCs/pull/1 ,

Is processes some new term for parachain? If so, it risks confusion, both the rebranding itself causes confusion, but also regular devs use terms like process and task, and those terms are quite generic anyways. Architecture terms like core remain safer since regular devs never touch them directly…

[image] burdges: s processes some new term for parachain? If so, it risks confusion, both the rebranding itself causes confusion, but also regular devs use terms like process and task, and those terms are quite generic anyways Changed the text to say parachain; process is probably a more gene…

It’s basically fine… backers should be assigned to parachains, not cores. Yes, this sounds fine. Relay chain block producers could arrange candidates into cores, with only one cores notion for both availability and approvals. backers may be assigned to multiple parachains simultaneously. A…

[image] burdges: We still keep them in the same groups though? I’m unsure if our reasons for doing this really matter now. Not clear if that’s important or necessarily what we get from it, except for maybe predictability in networking or some smoothing out of variance caused by coordinating c…

[image] rphmeier: In what sense? Yes it’s fine, proportional but bounded. [image] rphmeier: That’s pretty elegant, … We need back pressure anyway so right now the parachain team suggests we apply back pressure all the way to backing right away. Any validator has more approvals assign…

[image] rphmeier: With an algorithm that assigns backers to parachains more intelligently and adaptively we get much closer to fully solving (3) and (5). It’s not perfect for (5) as Polkadot still sells fixed ratios of data and execution as coretime. However, the decoupling of backing groups fro…

[image] sandreim: I think the PoV size and execution time for the parachain blocks needs to be known in advance for any algorithm that wants to assign backers to parachains efficiently We do probably need to set minimums of data/compute per candidate to account for constant overheads of valid…

[image] rphmeier: Sketch of the solution: Here’s a more concrete sketch of what this might look like: // The (maximal) rate of coretime consumption of this chain // This is a number treated as a rational over 57600 // (from RFC-5), where 57600/57600 means one core. This value may be greater…

With assigning backers directly to parachains, do we still even need the concept of cores? I’ve always found core regions very confusing and think this is simpler. Secondarily, and I realize this isn’t the most important concern for protocol design, but the metaphor of a distributed computer feels o…

Dynamic Backing Groups: Preparing Cores for Agile Scheduling

Tech Talk

rphmeier August 5, 2023, 11:08pm 2

Related to

Unifying bulk and mid-term blockspace with strided regions
Coretime Scheduling Regions by rphmeier · Pull Request #3 · polkadot-fellows/RFCs · GitHub
https://github.com/polkadot-fellows/RFCs/pull/1 ,

Topic		Replies	Views
Dynamic Backing Groups: efficient assignment of parachains Tech Talk	0	330	August 10, 2023
Elastic Scaling (fka Parachain Scaling by Parablock splitting) Tech Talk wasm	23	2293	April 5, 2023
Unifying bulk and mid-term blockspace with strided regions Tech Talk	12	2115	July 2, 2023
April 2025 Coretime Purchase Ecosystem	54	4512	June 12, 2025
Parachain Consensus Updates: Coretime, asynchronous backing, scalability Ecosystem	13	3489	January 5, 2024

Dynamic Backing Groups: Preparing Cores for Agile Scheduling

Related topics