Renaming "Parachains" to a More Generic Term

Ecosystem
21

Backed rollups? Decentralized Rollups?

22

The “layers” narrative is quite nontechnical.

Positioning DOT as a Layer 0 was supposed to emphasize the fact that smart contract platforms like Ethereum (L1) could run on top of a security layer (thus L0).

But practically speaking, the rollup story that Ethereum has been building toward makes Ethereum look at lot more like DOT.

I don’t think we as a community gain much on calling ourselves a Layer 0 blockchain, other than to confuse people.

The wording I prefer we use instead of “Layer anything” is:

  • Security Layer
  • Interoperability Layer
  • Settlement Layer
  • Data Availability Layer
  • etc…

These are actually terms which represent what Polkadot does, not where Polkadot is on an arbitrary stack.

Then parachains shouldn’t really be called “Layer 1” or “Layer 2”, they should be called rollups using our settlement layer.

I think we would be better served to drop Layer 0 narratives everywhere.

8 Likes
23

But this is just not true. Ethereum was not built for securing other chains. Rollups are a bandage for lack of proper sharding. Polkadot implemented proper sharding, which for starters means that parachains are not islands as rollups are on Ethereum, but can actually communicate with each other securely and fast. We should be able to capitalize on that, by fixing the on-boarding story (contracts) among others.

Hence I like the Layer 0 narrative: It uses terms people know from other ecosystem, but adjusts them to highlight that Polkadot is doing so much more.

3 Likes
24

While it may sound somewhat unfounded, I’ve always considered parachains to be a distinctive feature of Polkadot. In my view, rollups seem more like a workaround to improve Ethereum – something that Polkadot has conceptually built in from the start. Hence, I have a certain preference for the term “parachain,” which carries very positive connotations for me.

2 Likes
25

“Satellites” would be a good name that make perfect sense to new commers and a term that no one in the blockchain space hasn’t used

1 Like
26

@PolkadotLeader @tom1 I understand your concern regarding Polkadot pioneering sharding. I am not proposing to abandon the term parachain. I suggest the following:

  • start to think Polkadot as a rollup reactor
  • in this view, Polkadot cores get rollup data

Rollup is a more general term here than Ethereum rollups. It can be a chain, a contract, or anything that can be deployed as a service on JAM. An Ethereum rollup will be totally different from a Polkadot rollup.

As @eskimor pointed out, Polkadot implemented proper sharding, hence the L0 narrative that, in this view, does not go away.

Documentation specific to parachain will make clear that parachains are a type of rollup on Polkadot, and that a parachin can be fully-fledged L1. Anything going through the Relay Chain cores (or JAM cores) is secured by Polkadot Rollup Technology (ELVES, aka parachains protocol).

The Wiki will contain all appropriate comparisons. Using the term rollup will allow us to easily relate our tech with other ecosystems while still highlighting key differences. We need this to provide customers, investors, etc., with clear information that we are not on another planet, that Polkadot is in line with the competition, and that we are working to solve similar problems in different ways.

5 Likes
27

Given JAM’s ability to function as a rollup host for both
(1) parachains built with Polkadot SDK/Substrate
(2) foreign rollups
The shift to rename / extend (1) to be called “rollups” is very much a nice idea, but the rename / extension gets teeth when real people are actually aiming for (2).

GP hints at (2) with: “Smart-contract state may be held in a coherent format on the Jam chain, as long as any updates are made through the 15kb/core/sec work results, which would only need to contain the hashes of the altered contracts’ state roots.”

For me the rename is brilliant. The primary question is whether the rename is premature in the absence of observable efforts to do so.

People will divide into two camps:

  • Cynical/Pessimistic: “I’ll believe it when I see it”
  • Optimistic: “I’ll believe it before I see it”
    where “it” means “JAM Services will host (2)”.

The cynical camp may perceive the rename/extension as being desperate, but it is the optimistic camp that matters. In the world of actual people, there are 100K retail people and 100 bus dev / marketing / educator people relative to the 10 people who will decide to actually decide to build JAM Services to host (2). We should be optimistic that the rename is not necessary to trigger these 10 people, as they will have to be in the optimistic camp. But you will help them succeed with the 100K+100 others who make their work succeed long-term.

1 Like
28

I echo many of the sentiments here in championing this proposal. The apples-to-oranges lack of comparative context has long hindered Polkadot. It wasn’t that long ago when Moonbeam’s booth was situated directly perpendicular to Polkadot’s at ETH Denver and I will never forget the dazed reactions that even crypto-savvy folks had to the Polkadot messages at the time around parachains, Substrate, Layer Zero, and so on. We’ll never be able to totally mitigate this, since Polkadot’s tech is intentionally differentiated, but we can help find common ground through common terminology.

If we look ahead to JAM, and the idea that many different kinds of services can live on it, it does seem inevitable that the concept of parachains will cease. So the questions are really: how do we replace this term and when?

IMO I associate “parachains” with slots. Already the concept of Agile Coretime has disrupted this model. Yeah, I get that you can dynamically occupy cores as a parachain technically… but would these teams naturally define themselves as parachain? Would all teams occupying 1, 7, 10… 1000 cores all be defined the same? If yes, then rollups probably works fine. It’s generic and flexible in this context.

But I know we also forecast a world where apps can run directly on JAM. How do we distinguish these things? How can we easily define what’s a dapp vs rollup vs something else entirely? IMO your recommendation to create initial documentation is spot-on. We’re not going to know how to define these things until we start to put pen to paper.

Only last comment is what to call this kind of rollup. I know we’ve seen the term “agile rollup” tossed around which has some marketing appeal… but does it have meaning on the technical side too? If the goal is to make the “apples to apples” conversation happen, how do our rollups succeed against those that have 3+ years’ head start in terms of awareness and education?

2 Likes
29

Thank you for chiming in :grinning: – just want to highlight something that we learned this summer as a slightly over-hyper JAM fan :sweat_smile: thinking “scalability, World Computer, zillions of TPS”.

I think many of us have wished for this “directly on JAM” forecast after thinking of JAM as the next world computer suitable directly for end users, but this forecast is NOT something that is reasonable from JAM 0.x GP paper with refine-accumulate. Maybe there is some secret trick in JAM 2.0, but no one knows about it yet. There is no “cat out of the bag”, no one is winking here.

In particular, users directly using JAM work packages, at this point, will be ridiculously unhappy with trading their transactions+extrinsics for work packages. JAM’s work packages are VERY optimized for rollup hosts that submit work packages that validate the activity of zillions of users, just in the same way Polkadot validates Moonbeam. It is truly possible to validate thousands of Moonbeams with JAM, and if there are thousands of Moonbeams servicing millions and billions of users, you can say that users are using JAM indirectly but not directly. But Apps will not run on JAM in its refine-accumulate form and make users happy.

JAM’s present path is very squarely is “rollup host”. The shift in positioning from (1) Polkadot rollups [formerly known as parachains or aka parachains, decision required] to (2) non-Polkadot rollups could happen from 2025 to 2026. Its debatable as to whether to actually start talking about (2) in the broad universe or not. You may be conservative, I may be aggressive, does a WFC help get the debate in center stage or that premature?

In the same way NVIDIA’s top partners/customers are now the leading AI companies serving up millions of people who probably have no idea what NVIDIA actually did to make their AI-powered service work – JAM will have its top partners/customers being leading rollup ecosystem operators serving millions of people. This is nothing really new in that users of 1000 Moonbeams don’t have know that Polkadot was validating their activity. NVIDIA had its top partners/customers buying its AI-centric chips YEARS before you had your first ChatGPT experience. You could hope that GP 2024 is like “Attention is All You Need” paper of 2017.

It would help tremendously for marketeers to ensure that the 0.1% of people who lead rollup ecosystems know that Polkadot is open for the Polkadot rollups business for thousands of Polkadot rollups, but specifically open for business in hosting rollups even and especially if they are NOT Polkadot rollups (formerly known as parachains). For all that 2.0 from early 2024 “its not ready until its ready” type discussion, is very difficult to time perfectly – but if you don’t ever say its ready then the 0.1% never bother to try to make NON-Polkadot rollups ready.

Timing is everything, in addition to everyone’s good leadership and judgement on reaching out to NON-Polkadot rollup ecosystems, which are left right and center from ETH rollups.

I myself am quite confused about the role of TPS of all Polkadot rollups, which is widely seen as superficial and vanity oriented, but its what markeeters have to work with.

image
image354×1668 39.6 KB

While Base can give everyone a bit of TPS envy today, its quite clear the aggregate of the Polkadot ecosystem is pretty much up there at 15-30 TPS, most Polkadot rollups exceed most ETH rollups, and has hit a record 343.7 TPS [due to migration, not from “users”, but … should we care?]

https://dune.com/substrate/tps

Whereas the Polkadot Relay Chain can compute a TPS now, in the JAM future, there are NO transactions to even talk about – you are left to accumulate the transactions of the rollups of the rollup host and do basically what is implied there. The expected future is that these 15-30 TPS can go to millions of TPS. If workpackages submitted to JAM did work to validate millions of TPS for thousands of rollups for billions of users, Polkadot/JAM marketeers will have to market that as The World Computer.

2 Likes
30

The contentious point is whether, if zk-prover networks succeed in providing an economy of scale, redundant cryptoeconomic computation will no longer be needed. Instead, only ordering will be required, which is a simpler problem (that should leverage cryptoeconomic security to some extent but it’s a different scenario).

31

Here are some current thoughts which I am sharing, in the hopes of a “grassroots” movement around defining a strong vision for Polkadot.

TLDR: I really think we should think bigger. Talk about Web3 Applications and Services. Not parachains, or rollups, or whatever. Position Polkadot as the Web3 Cloud for the decentralized internet. We should be matching terms from AWS, Google Cloud, and really speak and dream bigger than what we have today, and more toward our long term vision.

There was a lot of positive feedback around my presentation at Tech Forum Argentina. (Perhaps biased, i guess i only see the people who post and repost my video)

They seem to resonate with the main images I shared here: Renaming "Parachains" to a More Generic Term - #14 by shawntabrizi

Positioning ourselves as a Web3 Cloud Provider seems to be extremely easy for people to understand, and DOES map well into what we are trying to do in the long term.

So when thinking about branding everything, it totally makes sense to pivot in this direction, and try to find a way to describe where we are going, not where we are at.

Vision Statement:

Polkadot is a platform for secure, scalable, and resilient Web3 applications and services.

My proposal is that the Polkadot platform has two core products:

  • The Polkadot Hub (or maybe a more branded name, open to ideas)
  • The Polkadot Cloud

NOTE: With this terminology, we never need to mention Plaza, JAM, Polkadot 2.0, or anything in between.

So what is the Hub and the Cloud?

The Polkadot Hub

The Polkadot Hub is the hub for the DOT token and the Polkadot ecosystem.

Through the hub, you get access to:

  • DOT
    • Staking
    • OpenGov
    • Treasury
  • Stablecoins
  • Other Universal Tokens
  • DAOs which embody the community of Polkadot
  • Account Abstractions
  • Smart Contracts which can interface with all of the above
  • and more!

The Polkadot Hub can also be a launchpad to build new products in the Polkadot ecosystem. You can acquire users, establish tokens, and eventually transition to the Polkadot Cloud if or when you need additional control or throughput.

The Polkadot Hub is deployed on the Polkadot Cloud, ensuring a secure, resilient, and scalable experience for all users in the Polkadot ecosystem.

The Polkadot Hub is name which captures, but also broadens the work we have been doing around Plaza, the Minimal Relay Chain, Smart Contracts on Polkadot, etc… Now we do not need to use these terms, and the Hub captures a vision MORE than any one of these specific ideas. It is something which will continue to get better upgrade to upgrade.

The Polkadot Cloud

The Polkadot Cloud is a scalable and resilient Web3 platform for Applications and Services. On the Polkadot Cloud, you are able to launch extremely high throughput applications and services, with native interoperability and shared security. Our cloud platform is, elastic, dynamic and multi-core. With over 100 execution cores we are able to achieve 150,000 transaction per second, and over 150 MB/s data availability throughput! You are able to use our cloud to scalably, cheaply, and easily deploy any kind of Web3 application or service.

The Polkadot Cloud is a name which captures, but also broadens the work we have done around building the relay chain and initially launching Parachains, Polkadot 2.0 (encompassing Agile Coretime, Elastic Scaling, Coretime Auctions, etc…), and even JAM.

What is important about these names is that they are Polkadot forward and Polkadot first.

Terminology

So going now back to the start of this thread, here are the core terms we should be using with these ideas:

  • Polkadot Hub
  • Contract (app on the hub)
  • Polkadot Cloud
  • Cloud Service (app on the cloud)
  • Universal Tokens

Never say: polkadot 2.0, jam, or plaza
No need to say parachain, rollup, etc…

With every feature, or milestone, we are one step closer to a more feature rich Polkadot Hub, and a more powerful scalable Polkadot Cloud.

Here are these terms used in Headlines:

  • “Introducing Ethereum Compatibility to the Polkadot Hub”
  • “Introducing Staking and Governance, directly on the Polkadot Hub”
  • “Introducing Universal Tokens on the Polkadot Hub”
  • “Introducing Elastic Scaling to the Polkadot Cloud”
  • “Introducing General Cloud Services to the Polkadot Cloud”

Here are these terms used in sentences:

  • The Polkadot Cloud was first deployed in 2021 with the launch of Parachains.
  • The Polkadot Cloud just completed Milestone 2 of its vision toward creating a scalable Web3 cloud server. This milestone introduced Elastic Scaling, On-Demand Payments, On-Demand Deployment, and more.
  • With milestone 2 complete, all eyes are on Milestone 3, which will allow even non-blockchain applications and services to use the the Polkadot Cloud and provide more than 3x more computational bandwidth than milestone 2. You can learn more about Milestone 3, code name JAM, by reading the Gray paper
  • The Polkadot Hub will soon get Ethereum compatible smart contracts, bringing general programmability to the DOT token. In combination with our Universal Tokens, the Hub is now the perfect place to launch your next project.
  • On the Polkadot Hub, you can launch quickly and cheaply, and build a community around your project. As you need more flexibility or scalability, you can bring your project to the Polkadot Cloud and unlock the full power of Polkadot.
  • The Polkadot Hub has access to USDC and USDT, which when paired with OpenGov, the Polkadot Treasury, and a large collection of active DAOs, makes Polakdot the largest decentralized Web3 community in the world.
8 Likes
32

Before discussing this post, just wanted to say that the Argentina presentation was great and recommend anyone to *watch the video posted above.

As far as POLKADOT HUB & POLKADOT CLOUD terminology - the different terms make each value proposition much more clear - it’s also audience friendly, familiar and much less daunting than heavy tech terms that may / may not resonate - hub and cloud are much more inviting.

That being said - there are two statements that really stand out.

CLOUD - “You are able to use our cloud to scale-ably, cheaply, and easily deploy any kind of Web3 application or service.”

HUB - “The Polkadot Hub can also be a launchpad to build new products in the Polkadot ecosystem…ensuring a secure, resilient, and scalable experience for all users”

Differentiating between established projects, user-focused applications, enterprise and speculative (not yet built / involved) participants from all levels - is very important.

Polkadot Hub
Polkadot Cloud

Just has a nice ring to it.

J.

2 Likes
33

Not in love with “Hub,” but I completely agree with the taxonomy & reasoning, really good idea.

1 Like
34

First of all, thank you, @shawntabrizi, for your great presentation in Argentina. I highly recommend everyone to watch it.

Regarding this post, the concept of Polkadot Hub and Polkadot Cloud is very good. They are very user-friendly terms that most people ( technical and non-technical) can understand. These terms can resonate more with people outside the ecosystem than plaza, parachains, etc.

It also paints a clear user journey, where everyone starts on the Hub, and then can transition to the Cloud if needed.

I think this makes it easier to market/explain how JAM relates to Polkadot to people outside of the ecosystem.

Overall, I like the concept of the Hub and the Cloud. Curious to hear more feedback form the community.

1 Like
35

The “app on the hub/cloud” bit confuses me.

Would it be clearer if it was:
“Web3 applications on the Polkadot Hub, and Web3 services on the Polkadot Cloud”?

Another discussion is do we want to call them onchain apps and services, rather than web3 apps and services…

36

Sorry, maybe my bullets are not clear. “app on the hub” and “app on the cloud” is just a clarification / description, not part of the words we should use.

You can deploy Contracts on the Polkadot Hub, and Cloud Services on the Polkadot Cloud.

Or at least that is my proposal.

In this situation “contract”, perhaps with or without “smart” (doesn’t really matter to me), is the most well understood term for what you would deploy to an L1 contract chain.

And “cloud service” is what I would consider the closest wording to Web2, emphasizing that we want to position Polkadot Cloud as a mirror to the “Web2 Cloud” we are all familiar with. If there is a more popular word within web2 clouds, we should use that.

1 Like
37

Will we have it on Kusama? What are the plans for Kusama in your vision?

1 Like
38

This is how I envisioned it ( which could be wrong):

There are two types of Web 3 application:

  1. Super ( placeholder) applications: Parachains are the example. They are deployed directly on the Cloud and provide services to other applications ( both Web 2 and Web 3). For example, Peaq is a supper application that allows DePin specific applications to be build on top of it ( could this be considered a “service” ?). Kilt is another example of a supper application that can provide ID services/solutions to other apps ( web2 and web3).

  2. Normal (placeholder) applications: These are dApps that can be deployed either directly on the Polkadot Hub via smart contracts ( Plaza) or on top of another supper application on the Cloud ( see Peaq example). Normal applications can start on the Hub and then scale to the Cloud if they need it.

Usually, I prefer not using the terms parachain, dApp, Web 2, Web 3, etc. I used these terms in the examples to provide clarity.

Good question. Not sure.

39

@shawntabrizi, it seems the discussion here is diverting a bit from the original topic. I am not discussing the upcoming branding of Polkadot as a hub and/or cloud. I would like to redirect the discussion back to the “rollup” topic.

To rethink the whole “Polkadot comparison” section in the Polkadot Wiki, I think it is important to get the whole community on track with the following:

  • Polkadot is a rollup reactor, very much like JAM will be
  • A Polkadot core receives rollup data
  • A rollup in this context is anything that can send data to Polkadot cores
  • We use parachains when a rollup is a chain/L1 (Relay Chain is L0)
  • The main product that Polkadot offers is security and interoperabillity through Polkadot Rollup Technology (ELVES / parachain protocol)

It seems to me that the general sentiment to accept the above is positive. The idea is to keep this as simple as possible so that we can easily build comparison tables between between zk, optimistic, and polkadot rollup technology.

A wish for change referendum would expose this to the broader community, and if it passes, we could start to update the relevant documentation.

Polkadot Cloud / Hub in the context of JAM can be a subsequent thing built on top of this discussion.

1 Like
40

I agree that Parachains are rollups. I would agree that in technical parts of the documentation, where we refer specfically to parachains, we would be better suited to update that documentation to frame it as rollups.

My comments about Hub + Cloud are about putting in context yet a bigger picture under which Polkadot rollups live.

Which is that the Polkadot Cloud extends beyond being just a platform for rollups, both in vision, and technically as well. As such I think it would benifiet the documentation to keep this in mind as you go and update stuff.

Here are some examples based on what you wrote just now:

IMO, Polkadot Cloud is a Web3 Cloud Platform, which can act as a rollup reactor when you deploy an application/service to the Polkadot Cloud using our rollup application SDK.

Obviously doesn’t need to be this long winded, but I think what I would want to clarify is that Polkadot (and specifically Polkadot Cloud) has a vision which is not limited to just rollups.

You can help correct me here, but I believe rollup to be an exclusively blockchain related word. In which case, it would be important to note that we will not be limited to just rollups accessing Polkadot cores in the future.

If you think rollup is NOT exclusive to just blockchains, then my suggestion remains that we should call this most general term “Cloud Services”, and state that rollups are one of the kinds of cloud services that Polkadot is best equipped to support.

In general yes. To me as well! I just want to make sure we don’t pigeon hole ourselves into the fact that Polkadot must be some platform for other blockchains. I understand that today this is the case, but the tone of our writing can capture something bigger.

“The blockchain of blockchains” narrative or whatever is quickly becoming obsolete, and i really think with every word we write moving forward, we must embody the fact that we want Polkadot to be more than just that.

It of course can be a blockchain itself, because it needs the properties of decentralization, resilience, verifiability, etc… that you get from a blockchain. But its secret power is that it can transfer those same properties to the Cloud Services which run on them, no matter what kind of service they are.

2 Likes