Renaming "Parachains" to a More Generic Term

Hey @shawntabrizi, in my view, “rollup data” is intended to refer to anything being pushed through Polkadot cores. Now, it’s just chains, but in JAM, it could be anything, as you pointed out.

See the illustration below.

  1. Rollup data incoming into a core (box). Quorum 3/5 paravalidators.
  2. Backing into the state
  3. The core is occupied, data availability scheme to share data with other cores
  4. Building of receipt and Inclusion into the state

Currently, rollup data is coming from parachains. But in JAM, it will come from services that might not be chains. In this grand scheme of things, rollups are anything that batch data to be sent to Polkadot cores.

Thanks for the clarification. Then we are totally aligned on concepts and vision.

My questions would be:

  • Is the term rollup used anywhere in existing computing BEYOND blockchain?

If not, I think we benefit to not try to rebrand rollup as something bigger than it is, but for us to use a term, which is inherently bigger than rollups. But for sure, for what specifically Parachains are, rollup is the better term.

Anyway, I think we are aligned, and we also spoke on some of these things directly :slight_smile:

2 Likes

I just read through this entire thread so far and the impression I was left with is that some people believe that marketing and documentation can somehow be divorced from one another, and I think that’s a mistake. Marketing lives everywhere the rubber hits the road.

I say this as someone who is primarily technical and not in marketing at all professionally.

Personally, I think @shawntabrizi 's ideas around a hub and cloud are spot on and should permeate the technical documentation, too. I feel the term “rollup” should be avoided, even in documentation, specifically because of its narrower Blockchain connotation that competes with the more cohesive vision.

I’m proposing we consider renaming “parachains” to something more universally recognized, like “Polkadot Rollups.” This isn’t about discarding the term entirely; rather, it’s about making Polkadot more accessible, future-proofing our language for updates like JAM, and boosting visibility across the blockchain space. The term “parachains” is unique but limits us a bit in SEO and industry alignment. Shifting to a term like “rollups” could make Polkadot feel more connected to other blockchain trends while still keeping “parachains” in our core documentation where needed. I’d love to get the community’s thoughts on whether this resonates, and if there’s support, we could look at starting a referendum.

I think the “rollup-reactor” terminology can be helpful in positioning Polkadot within specifically the Ethereum ecosystem. We need to remember that rollups refer specifically to validity-scaling, not availability-scaling. For the latter we need DDA systems, which Polkadot Relay and to a much greater extent, JAM, provides. (As a nit-pick I interpret the term “roll-up”, now at least, as “rolling up general computation into some lesser computation, either using CE or ZK tech”, rather than “rolling up transactions”.)

I agree with Shawn that we shouldn’t be doubling-down too much on the “rollup” terminology when presenting Polkadot as a whole and to a more general audience. It’s very helpful with certain (generally technical and blockchain-native) audiences. But as wider product placement, something a little less technical and more product-focussed seems sensible. I do have one reservation with the use of “cloud” (that cloud services are generally incoherent), but overall think it a step in the right direction.

For the canonical language I’d say:

Parachains are L1 blockchains implemented using Substrate and configured with correctness and finality guarantees provided through a Polkadot Cloud service (the only service really supported by the Relay-chain, but “CoreChains” will be one of many by the JAM-chain). The Polkadot Cloud is implemented using cynical rollups and an erasure-coding-based DDA system.

I don’t think we need to ban the “JAM” or “Plaza” terms - they may ultimately become out-dated once these initiatives reach production and what they replace have faded from memory, but for now they can be useful to describe elements of Polkadot’s future. The “parachain” term may be sensible to drop from recommended usage for the reasons discussed above.

5 Likes

What is CE here?

If i understand your view on rollup, I think we should NOT call all of what Polkadot Cloud is doing as a rollup. I think we are actually better off isolating rollup to being something very specific to blockchain L2s. I have seen no evidence online of rollup being used anywhere but the blockchain space.

I think this is an opportunity to separate Polkadot from the others by saying we support any kind of “cloud service”, any kind of application.

One of the first cloud services on the Polkadot Cloud will be a “blockchain rollup service”, which is the whole parachain stuff, but the “rollup service” is just one of the many services that you can execute on the Polkadot Cloud.


So I would want to change this to be:

Parachains are L1 blockchains secured by the Polkadot Cloud using the ‘Polkadot Rollup Service’. They are built using the Polkadot Rollup SDK (substrate/cumulus).

Which leaves open the idea that there are other kinds of services and things Polkadot can do beyond securing L1 blockchains.

Speaking on this, I think we also have an opportunity to give and market the L1 blockchain that Polkadot has: The Polkadot Hub!

What I would say:

Polkadot is proud to announce The Polkadot Hub. The Polkadot Hub is a new L1 blockchain running on the Polkadot Cloud, and a launchpad for builders to tap into over 6 billion dollars in tokens across the Polkadot ecosystem. The Polkadot Hub will also be the home for the DOT token and the DOT community. blah blah

But such an announcement or repositioning can bring a spark back into what we are doing, and it finally stops people who are deadlocked in the L0/L1 thing. We HAVE an L1, and we HAVE an L0! Although I would personally like to also step away from the L0 thing.

What I would say:

Polkadot has an L1 smart contract platform. Its called the Polkadot Hub. It is runs on the Polkadot Cloud, along side many other sovereign L1s, all using Polkadot’s innovating flexible, secure, scalable, resilient Web3 cloud architecture. When you build an L1 on the Polkadot Cloud, you only need to worry about building your business. Everything else (security, technology, scalability, interoperability, etc…) are handled for you.


Why call these chains? If Polkadot will be a Web3 Cloud, these should be services. There is no “relay-chain” there is a “Polkadot Cloud Settlement/Finality/Security Service” (choose one). This is one of the products you can access when you use the Polkadot Cloud, among others like the “Data Availability Service”, “Privacy Service”, “P2P Communication Service”, “Object Storage Service”, or anything else!

6 Likes

I’m planning to initiate a significant update to the Wiki, which will include:

  1. Replacing “Parachains” with “Rollups”: We’ll transition terminology from “parachains” to “rollups” to align with the latest discussions.
  2. Enhancing the Comparison Section: I’ll revamp the comparison section to clarify that rollups are Layer 1 solutions (formerly referred to as parachains), ensuring a more accurate understanding and placement within the broader blockchain context. This will allow us to easily compare our rollups with optimistic and zk rollups.

This update is just the beginning. Simultaneously, IMO we should work on a comprehensive narrative for Polkadot Hub (L1) and Polkadot Cloud (L0). I’m excited about the direction; I think it’s time to reposition our offerings assertively to capture market attention.

Proposed Structure:

  • Polkadot Cloud will serve as Polkadot’s core product, focusing on security and interoperability (Relay Chain, potentially JAM in the future, though we may want to avoid these terms for simplicity).
  • Polkadot Hub will be the platform for everything powered by DOT—whether as a standalone service or potentially part of CoreChains, hosting both system and non-system chains.

A Few Key Considerations:

  • “Service” Terminology: The term “service” should be used thoughtfully. The Cloud could be considered “the service” by providing secure computation via Polkadot cores, while additional layers may need careful positioning to avoid confusion.
  • “Smart Contracts” or “Hub” Terminology: We might consider shifting from “services” to terms like “smart contracts” or simply “hub” (e.g., Polkadot Hub) to reinforce familiarity with Web2 concepts. This would enable the deployment of hubs permissionlessly, with CoreChains Hub hosting parachains and Polkadot Hub managing system chains. By limiting “service” usage to where it matters most, we create a cohesive narrative with a strong, relatable market position.

This direction places us firmly in line with familiar concepts from Web2, making the transition more accessible for users.

IMO, I don’t think we should use the terms L1 and L0 to describe the Hub and the Cloud. I understand the logic behind using the terms L1 and L0 for talking to technical people and doing technical documentation.

I think that all future technical achievements can be considered improvements/new features to either the Hub or the Cloud. For example, plaza is an improvement to the Hub because it allows smart contracts to be deployed directly on the Hub. JAM would be an improvement to the Cloud because of xyz. This way, we always keep talking about the Hub and the Cloud ( the two key components of Polkadot).

IMO, this could create a bit of confusion. I think it is better to just have one Hub ( The Polkadot Hub). And then we can describe what is part of the Hub.

If you mean the CoreChains service: The “CoreChains service” is named so because a) it’s a JAM (“Polkadot Cloud”) service; b) it uses JAM cores; c) it the transitions of isolated, linear state transition functions aka block-chains. I guess it could also be called the “Chains service”, “Chain Security, Message-passing and Finality Service” or something else in this vein.

If you mean the Polkadot JAM chain: Because JAM is the protocol it implements, as opposed to the Relay-chain which is very much its own thing, and it’s a blockchain. If Polkadot were only ever the JAM-chain, then it would be a lot less of an issue. But right now Polkadot is something very different and it’s helpful to have something to call the thing that it will become. I touch on this at the start of the JAM paper.

Just because there is a blockchain called the Polkadot JAM chain doesn’t mean it needs to be emphasised or promoted. But trying to remove labels for useful concepts because (I can only assume) fools might see them and get confused is hardly a sensible communications strategy.

6 Likes

Where do DApps fit into the definition of “Web3 Applications”?

A DApp being (typically a serverless) application (usually a web app) that interacts with a blockchain (or perhaps more broadly with JAM services).

Can we just load a DApp up into the Polkadot Cloud like you might loud a DApp into Vercel?

If Polkadot Cloud is a like Amazon I am thinking about the abstraction layers that make interacting with PCloud simple, like what vercel does for web2 web app hosting.

Also aware this is diverting from OP topic. Lets make a topic about Polkadot Cloud.

There is a dedicated thread here: The Polkadot Cloud