I am currently preparing an on-chain wish-for-change track proposal to officially define the scope of Polkadot 2.0.
Through a series of discussions on several platforms the consensus that emerged so far is to define Polkadot 2.0 as Agile Coretime, Async Backing, and Elastic Scaling.
A draft for a proposal is here:
I’m asking to provide feedback on the definition
I plan to submit a consensus version on the WFC track next week Thursday.
I placed Ref 747 on Polkadot to make it official.
Looking for a 20k DOT decision deposit 
https://twitter.com/alice_und_bob/status/1788127462389391812
I don’t think 2.0 is an especially helpful term outside of the marketing sense of “OMG LOOK!1!! SOMETHING NEW!1!!”.
I’ve put my feelings on nomenclature here: https://hackmd.io/@polkadot/nomenclature
As it says, I’m not against having a version waypoint pre-JAM, but I’m not especially keen on calling that “2.0” and calling JAM “3.0” as it risks degrading the gravitas of the major version number months before we might wish to construe, outside of the ecosystem, the seriousness of the change.
I agree that major versions are primarily useful as communicative devices to signal significant improvements.
I think there is one crucial dynamic at play that speaks for signaling to the broader Web3 community that it is worth taking a closer look at Polkadot again: Sentiment towards Polkadot as a whole
While there is widespread agreement that Polkadot concepts and technology are exceptionally advanced, Polkadot is also seen as overly complex and impractical. It is an enormous task for chain developers to make something out of the substrate that they are given and developer support hasn’t been the best in the past. “End users” that have tried Polkadot (in the worst case through Polkadot.js) had bad experiences (and in the worst case have lost funds because they sent DOT to “their” CEX deposit address on AssetHub for which CEXes might deny support) have decided that Polkadot is not for them.
It is on us to mount a turnaround in sentiment and thus the question is how we can achieve it.
It took 7 years from whitepaper to Polkadot 1.0 (5 years to launch the first parachain on Kusama). But Polkadot 1.0 is only the base for parachains. Now it is the job of the ecosystem to make parachains actually buildable and usable and get the early kinks out of the way. Parachains still miss substantial tooling for development, QA, deployment, ops, and insights. All this tooling is developed as we speak and will be what makes Polkadot actually usable to developers and eventually users.
Our job for signaling to the broader Web3 community when to look at Polkadot again should not only revolve around JAM because the launch of JAM will not have a direct relation to when it will be practically usable for the developer and user. After the launch of JAM, we will “just” have a parachains/corechains service and for the outside observer everything will be the same and nothing will be new. Until we see JAM come into action, we will need CorePlay and other services to come live AND then actual constructs come live AND then become practically developable and usable.
It is thus my opinion that we should find a point in time to signal to the broader Web3 community when we have brought the existing parachain model into a state where it is easy, powerful, and fun to build with parachains and when users will have a UX that is judged as good.
The Web3 Foundation is undertaking an enormous campaign to bring Decentralized Futures teams into operations so that we can rewire agents in the ecosystem in a decentralized (and yet effective) manner. The folks at Parity, at the parachain teams, dapp teams, wallet teams, dashboard teams, etc… have spent a lot of work to improve UX, DevEx, and Marketing.
The situation for us out there is tough, as we try to uphold the best of Polkadot every day but have to fight against tendencies of teams leaving the ecosystems and long-standing community members turning their backs. We all believe that we can make Polkadot a success story and that our efforts will pay off.
But what we need is a rallying cry. Similar to the halving, on which you reflected in the Gray Paper interview. We need an opportunity to show off to the world that Polkadot has become better and that everyone should give it another try.
I believe that we need such a random point in time around which everyone can rally very soon. We need new devs, new attention, new community members, and new investments in the ecosystem soon.
Agile Coretime (+ Async Backing + Elastic Scaling) addresses one of the biggest pain points that the Polkadot 1.0 concept exhibited and also already points to a future of a highly efficient Polkadot. It already can offer a set of unique USPs that no other ecosystem can offer (high economic security + monthly guaranteed blockspace + scale to your needs).
Coretime with a finishing touch of Elastic Scaling is a huge thing and we should celebrate it as such.
Can you kindly share your feelings on “License” changes, and if/when that might be appropriate between Polkadot One / Too GNUv3 to Polkadot JAM / Play?
The concern/motivation is that we have seen many Substrate non-Polkadot chains (Avail, Bittensor, Cardano (?) …) with little value capture back to DOT holders in the 1.x era. Many other Web3 ecosystems attempt to capture value with Business Source Licenses (Uniswap, Arbitrum, Aave, Babylon, …) or at least give themselves a multi-year head start.
The desire is that the next wave of JAM / Play innovations have more serious value capture back to DOT holders, and to minimize trivial copycats (BSC, TRON, etc.) from JAM/Play/Solidity-to-PVM and so on. Can you imagine a Business Source License change being justified? Decided by a “Wish-for-Change”?
To echo Tommi’s statements, I believe Polkadot is at its first real crossroads that can signify to the broader crypto ecosystem that it’s no longer the “same old” Polkadot moving forward. There could have been other ways to signal this, but some of the community ran with this idea starting in late 2023 and folded it into a very public narrative about Polkadot 2.0. Trying to put the genie back in the bottle generally doesn’t work, so by creating a coherent story that highlights massive tech improvements, 2.0 can be used as a rallying point for developers, users, and supporters. We’re hoping to show the broader crypto community there are fundamental shifts underway within Polkadot and that they shouldn’t underestimate the community and tech here. Much of crypto is narrative-driven (for better or worse) and I believe 2.0 allows us to create that narrative vs. allowing outside circles to push a “same old” Polkadot story.
I respectfully understand you disagree with me from your high level technical viewpoint! You’re absolutely correct, it’s a Marketing term. Many organizations use these terms to market high achievements, even if not in line with certain debatable standards, in regard to upgrades. Since it has been used in relation to Polkadot it is giving the impression to us “normies” (majority of people) that milestone innovation isn’t currently occurring on Polkadot. As we know this is NOT the case! Everything Alice und Bob mentioned is true. Using roadmap terms like “2.0” signals tiny bits of information that people can easily absorb to explain a bulk upgrade narrative. It also psychologically signals to people to take a deeper dive (deeper look).
Jam being referred to as 3.0 is also an easy roadmap connection. It can have a deep mental connection to the term Web3, making it easier for people to understand and absorb the concept, in its entirety.
I am grateful that you’re doing this work for humanity, translating it for people to understand “why” these terms exist, it’s not an easy task, as we all have different technical competence levels. While I completely understand from your standards this doesn’t seem like a 2.0, for someone like me explaining it to people it does. I hope you can respectfully understand why I see this marketing transition as a useful tool for the mass majority.
Thank you for everything you’re doing and will continue to do! I cried happy tears on some pages of the Gray Paper.
Respectfully,
Hope
I’m very supportive of Tommi’s proposal to add some clarity around the “Polkadot 2.0” nomenclature. We’ve already seen a lot of interest in the term, inside and outside of the eco, because people want to know what the next wave of innovation will look like on Polkadot in the current market cycle. It has marketing utility for this purpose.
Very much understand the concerns around versioning and catering to the ‘marketingese’ nature of it. But like “Dotsama,” it’s already become so broadly used and adopted that the risk of NOT defining it will be that other people will lead this conversation. This is a narrative we can and should wholly own.
To give folks some sense of what I’m talking about, here are some search volume numbers (US-based, for the purposes of giving you a sample).
Searches for “polkadot 2.0” (monthly) = ~140/mo in the US
That’s a small percentage of overall searches for Polkadot (what we can assume are Polkadot Network-related searches, at least) but it shows a pretty strong interest and curiousity about the term and what’s next. Other than price chatter, the only categories where we see more interest than this are “polkadot staking” and “polkadot wallets” which isn’t terribly surprising.
Purely for comparison purposes, here is what the volume looks like for some other Polkadot-related terms (again, US-based just for simplicity)
Part of this, of course, will be promotion – how can we start amplifying some of these other features and storylines so that they get some visibility?
But I’m using this purely as a way to gauge demand and appetite for some very simplistic way to position “the next big wave” of Polkadot, and the 2.0 term does seem to have organic traction.
I think it’s a great idea to define Polkadot 2.0, tie some features to it, and also make it more tangible and discretely deliverable. Otherwise, the folks who are trying to figure out what’s next in this eco are depending on pay-to-play media sources to give them the information they’re looking for:
(pages 1-2ish of “polkadot 2.0” search results)
I don’t expect this will detract from the “holy shit!”-ness of JAM. Everyone I’ve spoken to has very much absorbed the potential impact that JAM could have, and IMO it would be underselling JAM to slap a “3.0” version on it. We (as marketing folks) need to find a better way to communicate just how many leagues ahead of current state JAM will bring us.
But in the meantime, Polkadot 2.0 brings us some much-needed tangibility for talking about the near-term upgrades and I for one am very excited that so many in the community are on board with putting some formality behind it.
https://hackmd.io/@polkadot/nomenclature - I don’t have access to this
Log in to HackMD, then you will
And for your proposal too please
As I say I’m not against using the term 2.0 per se and many of the provided arguments for using “2.0” are quite reasonable. Furthermore the three features that AliceundBob identifies are perfectly good features in their own right. They each make a tangible difference to Polkadot’s builder teams.
My point is simply that the three features which are proposed as “2.0” do not significantly alter the product model of 1.0 but merely make it faster (async backing & elastic scaling) and more streamlined (agile coretime). With them, the Polkadot proposition and network is still largely unchanged: it hosts only parachains, it still has a comparatively large amount of effort to write correctly on, deploy and maintain, still has limited capacity of around 50 slots/cores, benchmarks are still needed, synchronous composability is still not possible between chains, there is still just a single SDK made by a single development team in a single company, and still only one client which runs the whole network. If “2.0” is the big effort to request a re-appraisal of the Polkadot ecosystem, tech and network, then I fear it will be wasted. Furthermore if JAM, something which actually does reimagine what Polkadot’s limitations are, ends up having to be “3.0” to an uninspiring “2.0” then this will surely reduce its potential communications impact.
That all said, I’m not a marketing guru: I fully accept that it’s possible that timing is more important than meaning with naming major versions.
@gavofyork I do think you make perfectly accurate points, but I think you are also a bit home blind by how rare resilient scalability and speed is in the space and what a massive achievement that is. Polkadot is very fast considering 1) how little it has sacrificed decentralization, and also by 2) how long it has been operating and at the 3) scale. Few chains can claim all three.
Speed and quality are definitely something that can be touted as a big release. Apple did this with Snow Leopard: Mac OS X Snow Leopard - Wikipedia
I actually think that Mac OS X versioning style suits Polkadots somber calm style pretty well. Apple has had the same major since 2001, but it’s still big bang releases (even Snow Leopard which was just mostly performance and storage improvement - albeit impressive ones)
Snow leopard was actually technically a minor version bump (10.6), as all Mac OS X releases are. Nobody thinks of Apple releases as minor releases but they adhere to semver.
Apple has solved the semver problem by having their minor bumps be labeled - I think this is the best example of marketing done well around version bumps in the industry. It also has the additional benefit that one can add both descriptiveness and beauty into the communication, instead of simply a major bump which doesn’t really convey any information by itself.
I really do think that we need to take control of this, either by defining the 2.0 or adopting the labeled minor version strategy that Apple runs. We should NOT sit around and let Twitter define what 2.0 means.
Major releases have an additional, global/contemporary meaning among everyday people, it is not just semver. As a software developer, this frustrates me personally and for this really I really wish that semver would have been defined as to a.b.c.d instead of x.y.z, where a refers to the cohesive milestone of a software. Right now, both this and breaking changes are rolled into the first number because the people that created semver did not really have the foresight to consider anyone but software devs as their audience.
I postulate that this holds especially true for decentralized software. There is a strong need from the living narrative around a decentralized software to point to what the next big milestone actually is, and not taking control of that means that it will be emergent, which is hardly preferable.
