Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more
Polkadot 2.0 Definition
Summary
This proposal aims to define Polkadot 2.0 as being scoped around the themes of Coretime.
If accepted, the first Polkadot runtime version that fully supports Agile Coretime, Async Backing, and Elastic Scaling will be the version considered Polkadot 2.0
Motivation
Giving versions to software products primarily acts as an attention coordination mechanism. Major versions are typically assigned for significant improvements in the feature set of software (or significant breaking changes).
After the delivery of Polkadot 2.0, attention in the developer and user community shifted towards what the next big evolutionary steps of Polkadot are going to be. Agile Coretime, as most notably publicly introduced by Gavin Wood at Decoded 2023, was the first major focal point of public attention and quickly became referred to by many as Polkadot 2.0.
The only other major theme next to Coretime-related development effort is JAM, which is still in research and with a yet unclear delivery timeline. It is more suitable for a future major version.
It is the opinion of the stakeholders voting AYE on this proposal that Coretime is a significant evolution in the efficient allocation of Polkadot blockspace and should be marked as Polkadot 2.0.
Specifically, we consider 3 epic features to be part of this development track:
- Agile Coretime, which is the ability to acquire bulk and on-demand coretime and dynamically allocate it to parachains
- Async Backing, which allows parachains to submit parablocks for inclusion into the Polkadot relay chain more flexibly
- Elastic Scaling, which will allow parachains to consume more than one core if they need additional resources
Instructions
If accepted, this proposal instructs the Polkadot Technical Fellowship and any other actor that respects this proposal to declare the first Polkadot runtime version that supports all of the three described features as Polkadot 2.0.
Since the exact definition of the circumstances and implementation of those features is complex, subject to change, and intersubjective, it is up to the Technical Fellowship to apply its best judgment on what constitutes the delivery of the features.
Comments (12)
Proposal Passed
Great initiative, well motivated by "marketing", but based on Gav's comment: https://forum.polkadot.network/t/polkadot-2-0-definition/7673/3 lets have the founder decide the versioning.
@Colorful Notion
I have provided a response here: https://forum.polkadot.network/t/polkadot-2-0-definition/7673/4?u=alice_und_bob
Essentially, there are two views on versioning: A strict technical one understanding the attention economy. We are currently under very harsh conditions regarding attention and I strongly believe that Polkadot has delivered great efforts to improve the conditions to build in the ecosystem. We should show this off by signaling to people that it is worth taking another look.
JAM will undoubtedly be a significant technical milestone, but calling it Polkadot 2.0 will lead to a situation where people will look at it and on the surface nothing will have changed, because the actual innovations coming from JAM will only show a few years later.
Right now with Agile Coretime we can show that surface things have changed markedly for devs and we should do so.
In business the mention of 2.0, 3.0.... voices achieved accolades to an industry. These accomplishments should be more visible! Making these accomplishments 2.0 will allow, (at a quick glance) people to know they should read further to see the innovations occurring in Polkadot! I am grateful this proposal is up!