Yes, at first glance the TAM for the cloud narrative is huge, but the SAM should be scaled to a comparable market size. Should this be the BaaS (Blockchain-as-a-Service) market? According to some reports, “the Blockchain-as-a-Service market is projected to grow from USD 4.13 billion in 2024 to USD 32.25 billion by 2032, with a compound annual growth rate (CAGR) of 29.27% during this period.”
With established cloud providers already including BaaS in their offerings, is this the market to target for competitive market share? Or is there perhaps another market that’s more suitable?
I just had a super busy weekend, so I’m only getting back to you now. Everything you mentioned about the HUB is spot on—it’s for the DOT holders. I referred to it as the web3 community to make it sound bigger, especially since Gavin is the “godfather” of web3. But I realize now that sticking with the name Polkadot is probably the way to go.
You’re right about the UI for both products (Cloud and Hub) being completely different. They cater to 2 distinct target audiences. But in the Cloud, you have two types of customers: developers (what I call the Cloud) and clients who want to use Polkadot (partner)products or services from suppliers to build web3 solutions. I think of the latter as Web3 Connect.
This approach allows you to engage all your developers through “the Cloud” while focusing via Web3 Connect on clients. (We might need a more generic term here like web3connect, as clients don’t really care what technology something is built on; they just want it to work and be supported.) I envision Web3 Connect as a place where all products built on Polkadot can reside—supporting our partners who believe in Polkadot is crucial. Currently, we’re not doing enough of that.
We need to actively support our entrepreneurs building on Polkadot, and this central portal (web3connect) can showcase all offerings, giving every partner equal exposure. This essentially can become a new lead channel.
Is this new ? Not really—I borrowed this idea from Salesforce, which has a marketplace (AppExchange) where partners showcase their products.
Lastly, I want to highlight that simplifying our offerings within Polkadot is one of the toughest challenges developers face. It’s in our nature to complicate things, while the outside world craves simplicity. If we can achieve this, we can market ourselves much better because it will clarify WHO we’re targeting with our message. If you’d like to brainstorm this with a few people, just let me know!
Enjoy your working week everybody, and thanks for making Polkadot better !
I’ve been thinking about Polkadot’s target audience and how they might interact with the Hub or the Cloud. Currently, I see our audience divided into four main groups (though there may be more I haven’t identified):
Developers (Hub and Cloud)
Retail/Consumers (Hub)
Clients (Hub, Cloud, and utilizing rollups on the Cloud)*
Community Contributors/Ambassadors/Champions ( Hub and Cloud)
*Web3 applications go either on the Hub or the Cloud. Web2 businesses, enterprises, and governments/institutions do not go on the Hub or the Cloud; they use different services offered by rollups built on the Cloud (e.g., Aventus, KILT, Origintrail, Mandala etc).
Here are more details about the audience groups and their sub-groups.
This is not a “decided” list but rather a structured view of the groups I think we can aim to serve. As the ecosystem evolves, our understanding of who interacts with Polkadot’s products will improve. Throughout our journey to achieve the 10-year vision ( both for the Hub and the Cloud), we will discover which audience groups we should prioritize. The prioritization will change over time based on what the community thinks is missing in Polkadot at a particular point in time.
1. Developers
Developers Improving the Polkadot Cloud: These are developers working to enhance the Polkadot Cloud’s infrastructure. For example, members of the technical fellowship working on improving the Cloud.
Developers Building Web3 Applications on the Cloud: These developers create highly scalable Web3 applications, such as rollups, directly on the Cloud.
Developers Starting on the Hub: Most developers enter through the Hub, the primary entry point (the top of the funnel) for building dApps within the ecosystem. Some developers will transition to building on the cloud if their applications need to scale more.
2. Retail/Consumers
Non-Crypto Retail/Consumers: These users are on the Hub. Since these users don’t know much about crypto/blockchain, they will probably start their journey on the Hub reading documentation.
Crypto-Native Retail/Consumers: These users are also part of the Hub. Since they are crypto natives, they journey might start with buying tokens, staking DOT, engaging in OpenGov, etc.
3. Clients (perhaps there is better term/clasification?):
Web3 Applications:
Simple dApps: These typically launch on the Hub and may transition to the Cloud if they require more scalability.
Web3 Applications that require high scalability: Some launch directly on the Cloud to leverage its high scalability, like rollups.
Web2 Applications (includes enterprises):
Do not operate directly on the Cloud or Hub. Instead, they leverage services provided by rollups built on the Cloud. For example, businesses might use solutions offered by Web3 applications (like Aventus, KILT, OriginTrail, etc.) to integrate Web3 functionalities into their operations. But these Web2 applications/enterprises do not directly on the Cloud.
Governments / Institutions:
Governments and institutions don’t go on the Cloud or Hub. Instead, they rely on services provided by specialized rollups built on the Cloud, such as Mandala, for public sector solutions.
4. Community Contributors/Ambassadors/Champions
These are highly engaged individuals who actively drive Polkadot’s growth and visibility. Unlike general retail consumers, they play a pivotal role in community building and ecosystem expansion. They engage across both the Hub and the Cloud , depending on their focus. Some examples include:
Content Creators: Producing educational material to help new users and developers understand Polkadot’s value and applications.
Business Development Champions: Bringing new businesses to Polkadot, spreading awareness, and managing business development activities.
Investor Relations: Engaging with potential investors to showcase opportunities within the Polkadot ecosystem.
Event Organizers: Hosting or supporting events and conferences to increase Polkadot’s visibility and presence in the broader blockchain community.
And much more!
Closing toughts:
Understanding the unique user journeys of each audience group and sub-group through the Hub and the Cloud will be essential. Keeping these core products at the center of our design will help us create tailored and meaningful experiences for every user.
I loved this post and absolutely support everything you said, @shawntabrizi! It will take time to discuss and reach a common consensus, but I can already see a lot of benefits from using these simple terms in the Polkadot Wiki.
As I stated in my previous comment, I resonate with this sentiment, but I consider it a Goal of Polkadot, which is a pillar below the vision and mission.
I think I would like to attempt to make this goal more a more general statement which I more deeply resonate with.
If we can agree on the vision and mission of Polkadot as outlined in my original post, consider this goal:
The current goal of Polkadot is to translate Web3 technologies into products that can be understood and used by the world.
I think such a goal can capture many high quality KPIs to measure our success:
Mindshare / Awareness - a measure of our ability to present a compelling vision / mission / product.
Builders (Our users) - a measure of how our products are bringing value to application builders.
End-Users (Their users) - a measure of how applications on our platform are actually making an impact to the world.
DOT price - a measure of the speculation on our platform’s future value to the world.
I would argue that we are probably not so great on many of these metrics today, which is probably a result of the fact that we have not established such a specific goal statement.
I think we can see that the creation of the Polkadot Cloud and the Polkadot Hub is def an attempt at reaching this goal.
I prefer such a goal because it has the right outcome, which is NOT just focused on pumping up the price, but actually measures the direct effects of what a Web3 platform should achieve, but also does not ignore the fact that to keep forward momentum, we need people to continue to speculate in our future success.
It seems like the Polkadot cloud narrative is overlooking a few key challenges:
Scope Confusion: Some people might assume that Polkadot cloud functions like a backend provider for web applications, similar to platforms like Vercel or other “serverless” services. But that’s not really in its scope. This kind of misunderstanding can lead to unrealistic expectations.
System Mismatch: There’s also a fundamental difference between “S-type” and “E-type” systems that is not addressed. JAM is an “S-type” system that operates in a deterministic, isolated way. In contrast, “E-type” systems are meant to adapt and evolve based on external changes. Running E-type systems on JAM is not realistic.
Recognizing these limitations can help avoid some common misconceptions and guide developers toward the right tool for the job.
Incredibly effective talk by @shawntabrizi at sub0, specifically focused on JAM as the true beginning of the Polkadot Cloud, a scalable, secure, resilient host for all kinds of apps, not just blockchains, representing the evolution of blockchain technology and the dawn of real web 3.
This is the message Polkadot agents should be propagating far and wide–people do not yet understand the vast implications of what’s being built here.
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 (and its modules or smart contracts).
Can we just load a DApp up into the Polkadot Cloud like you might load a DApp into Vercel (or digital ocean droplet)? Or are these Web3 Apps specifically on-chain apps like pallets or parachain rollups?
Would Polkadot Cloud store the web hosting on its cloud too?
I ask this because in your recent presentation you made a very convincing case that Polkadot Cloud rivals general cloud services in products and performance benchmarks.
You definitely could host websites on the Polkadot Cloud.
For example, the Polkadot JS Developer Console is hosted on IPFS: https://ipfs.io/ipns/polkadot.dotapps.io/
In most cases, this is probably not necessary unless you are specifically worried about your website being taken down. There are ways to create a Web3 Application using a combination of Web2 and Web3 primitives. For example many Web2 front-end applications in our ecosystem use light clients to provide trustless access to chains in the Polkadot ecosystem.
There should be no reason we could not build such end to end scenarios.
The Polkadot Cloud will probably not do this directly, but there will be “3rd party service providers” which will repackage the Polkadot Cloud resources, and create streamlined scenarios just like this. This is probably exactly the same as Vercel or Digital Ocean, which probably uses the big cloud providers in the background (not sure, just assuming).
Teams like Apilon seem to already be doing exactly this in our ecosystem.
This is the more likely use of our Web3 Cloud. A Web3 Cloud is most useful for deriving consensus over state, not being a raw execution engine. Where there is important processes which require consensus in a trustless way, the Web3 Cloud can provide that.
You will be surprised how many scenarios this can apply, but it wont be relevant for every single website on the internet today, and certainly not their whole stack.
That being said, there is no reason you cannot use any of the raw resources on the Polkadot Cloud in whatever way you want. You just need to pay the fees.
I need to work on the narrative around this thought, but indeed JAM does have impressive specs, but we need to put it all in context.
If we look at the Polkadot Cloud in comparison to AWS, it is like our cloud as a “single supercomputer”. And that is what JAM is. This is why Gav is always saying “JAM is a supercomputer”.
You can think of JAM as some “virtual hardware”. It is a protocol which takes 1023 individual computers around the world (validators), and creates a new “decentralized supercomputer”, which has the hardware properties of:
341 Cores
85x CPU load of the single validator specification
852 MB/s I/O Bandwidth
2 Petabytes of Data Availability
1,000,000+ Transactions per Second
But this is just one supercomputer, and obviously Web2 clouds scale using more than one computer. In this context, you could imagine that the Polkadot Cloud would actually scale further by running multiple “JAM chains”.
These JAM chains would be bridged together using trustless bridge technology we have developed for the ecosystem.
This means that data would not immediately be synced and settled across the different computers, but data could be transferred from one computer to another (via the bridge), if you needed to access data on a different computer. This would give up on some of the coherency you get from a single machine.
In fact, such a design was already planned in the past for the Polkadot Cloud with ideas like “polkadot squared”.
Let’s break down a concrete example to understand: the current Polkadot governance applications.
Following the terminology used here, these apps consist of two tiers:
A Web3 tier that manages the logic of tracks, preimages, voting mechanisms, and onchain actions like transferring funds from the treasury.
A Web2 centralized database and web API that holds the semantic content—essentially, the information about what each proposal entails, including its meaning and the discussions surrounding it.
Switching to IPFS to host this content only slightly changes things. While it eliminates reliance on the web API of a single provider (currently Polkassembly), you’d still need a way to reconstruct the entire structured discussion and content. Related regarding IPFS Seeking Feedback on Minimizing Trust in Decentralized App Distribution
Moreover, if we include elements like identity attestations, historical interactions, and similar factors, the app’s usability will depend on extensive external context.
So, how do Polkadot Cloud and JAM alter this landscape?
So I first want to mention that some of the things in Polkadot Cloud are vision based, as in, not something you can do today, but something we should aim to do, given the fact that this is the vision of the service we want to provide. I hope you think this is fair, and know that all the technology is not something imagined, just something that takes work.
So one new primitive coming from JAM is a much more abundant and flexible DA layer which services can access. You can think of DA like computer memory, since it is non-persistent, but sticks around long enough to be useful for applications.
In the example you describe around Polkadot Governance application, you mention that we rely on centralized sources of truth for the proposal details, which is true.
BTW, we could already use Polkadot’s Preimage pallet to bring all of that data on-chain, but truthfully it is a little clunky and probably expensive. But the fact that things are pretty “web2” around the governance apps is not a result of what we could do, but truthfully a result of this kind of scenario not being natively supported by our most popular UIs.
In any case, with a JAM + Cloud future, I would expect that we provide:
a generally cheaper long term storage option like IPFS
an even cheaper short term storage option through our DA layer
In this scenario, you could imagine that a proposal is submitted to DA, with a hash. In the DA, we probably have the flexibility to update the proposal content, based on feedback from voters. Probably we could even be clever to have votes which reset when the proposal hash is changed.
Then, when the proposal passes, we translate the final version of the proposal from DA into a long term IPFS-like storage for archival references.
Indeed, there is probably more than needs to be done to make these things “perfectly web3”, but the point is that the Polkadot Cloud should be offering raw resources for any kind of Web3 application or service.
One key reason why JAM is so exciting is not really captured by your question, but is the topic of my most recent presentation:
The summary here is that normally, as an application developer, you would need to design your Web3 applications with the limitations that your app would be “running on a blockchain”. This has many deep implications for an app developer, for example forcing yourself to write an app which can execute in a block-by-block fashion.
JAM brings the PVM, which is able to do “save states”, allowing users to deploy any kind of application to the Cloud, with zero concern or knowledge that it is a blockchain underneath, and our VM does the work to break down and run the app in a way compatible with the underlying blockchain technology.
This is how an app can have the properties of Web3, without needing to be designed for blockchain. This is why Polkadot, and the Polkadot Cloud, is really not “blockchain-centric” anymore. Like our technology stack is powered by blockchain, but you need not know that. If you simply want to properties of a Web3, you can choose our cloud provider, rather than a Web2 one, and get those properties.
Yes, you could literally run DOOM on the Polkadot cloud. Deploy the game to the Web3 cloud, output all pixels into our DA layer (since they change every frame, and is not needed to be persistent), then display the pixels to the end user.
It would not be possible to run “regular applications” before these kinds of technological leaps forward.
Now should we run an FPS video game on a blockchain? Obviously not. But the point is we have the capability to do it, which ultimately points to the much broader capabilities the Polkadot Cloud has over what everyone else is building in crypto.
Everyone else seems to be focused on just making DeFi better, and designing systems around blockchains, rather than designing blockchains around systems.
Once you realize that JAM is just a protocol which defines how to create a “virtual computer hardware” using decentralized set of computers, then you can see that the Polkadot Cloud will be able to do anything a computer can do. And afaik, this is the basis of everything on the internet.
Even Ethereum could not say “fully Turing complete”, because of the limits of a block. Perhaps we have achieved that now.
The Polkadot Cloud is not, in itself a solution for everything, at least not yet. If we do not limit ourselves to building just blockchain technology, you can imagine that any kind of technology service which leads to a world with less trust and more truth is something we could invest our time into building, and providing through the cloud.
This is also why I do not agree with you on the naming. For me, it is super important Polkadot not be any product in particular, but the brand describing a vision and mission.
At some point, Polkadot and our community will need to transition from just building technology, to actually changing the world. Whether it be through general Web3 education, political lobbying, community building, event planning, these are all part of the Polkadot mission.
The Polkadot Cloud describes to me a specific product (with sub-products/services).
I think I would compare this with Meta, whose name now represents a broader mission than any specific product.
Indeed we could probably bike-shed names here, and talk about renaming everything, but my goal here is really about describing the vision, mission, goals, products, and eventually strategies.
I think if you have further questions or comments @sodazone i would love to know at which point, you think we are not aligned, and use that as a way to simplify our communication.
A great advantage of this model is that we can all demystify JAM now:
JAM is an update to the Polkadot Cloud ONLY, not the Hub.
I have some reservation about the strategy towards “path to scale”.
Scaling horizontally is something that we should ack is at the moment not a great choice. You should only consider doing it IFF:
You have technical needs that cannot be met in a smart contract chain (altering txpool)
You have such high throughput that after careful consideration, you are sure a multi-core Polkadot Hub is still not enough for.
You have other economical reasons, such as wanting to buy coretime and having a feeless chain.
If you decide to be a dedicated parachain, you lose out on sychnonicity and liquidity of the Hub, and we should be hesitant in forwarding users toward this path.
I would keep the idea of scaling as-is, but inject into it the fact that the Hub is a multi-core service and will SCALE A LOT. We are also working on super low block times (pre-confirmations). So you can be pretty sure that you get a decent throughput on the Hub already.
The underlying reason for this is actually the fact that you have equated Parachain with cloud service, but this is not the case. The real service here is CoreChains: a single cloud service for running blockchains, as you have put it. Since we don’t have other services (perhaps except Hyperbridge, a settlement cloud service for L2s), we think that a new parachain is a new cloud service, while it is not.
Once we have JAM, this will be fixed. All parachains will be part of the same service. Moreover, the synchronous composition and liquidity issue will be fixed. Until then, we should be hesitant in pushing builders into a new parachain.
If you agree, I think investing too much into a universal language is also not a high priority. I would love to have a single-contract-parachain-template though, with a nice tutorial on how you can become one.
Suggested action items:
Parachain is not a cloud-service. In the meantime, we should call a parachain just a parachain: A resident of the blockchain service of the cloud.
Emphasize the inherent scaling properties of the Hub before inviting people to scale outwards of the Hub.
Thanks @kianenigma for calling out the “Journey to Scale”.
I do agree with what you wrote.
Since writing that initial post, I have more clear vision on the path of a contract. Specifically, through the “Contract Hosting Service” (codename CorePlay), we will be able to provide a JAM Service which can take a smart contract OFF of an L1 blockchain, and all the limits of that environment, and onto its own dedicated or shared core (or multiple cores? not sure).
So contracts will be able to basically access the full throughput of an L1 blockchain for just their application. This is certainly a journey to scale.
In this context, the perfect world would mean the same bytecode used with PVM on the L1, would directly work with the PVM inside of JAM, but I guess that is something which depends on how the Contract Hosting Service is implemented, and what is possible.
In many ways, the Contract Hosting Service may lead to the obsolescence of L1 smart contract chains, since as you mentioned, it should allow for synchronous composability when two or more contracts share a single core, but also all the scaling horizontal scaling of parallelization of contracts which do not interact with one another. It is the best of both worlds, probably at some additional technical complexity, but complexity which should be entirely handled by the Smart Contract Hosting Service.
I agree with both of these checkpoints.
Calling a parachain a cloud service is wrong. But we should also be able to reference them as “rollups”, or blockchains hosted on the cloud via the “Blockchain Hosting Service”
Thanks for sharing your thoughts! I don’t think there’s any misalignment here, but I can see how the term “cloud” might add some confusion around Polkadot’s core offering, especially when hardware specs and bandwidth come into play (better to avoid it IMO).
Maybe using “Polkadot Core Services run in/by the Polkadot Network” would be less confusing than referring to it as “in the Polkadot Cloud”?
On another note, I’d suggest clarifying what the user can expect when deploying or running on the cloud/network and highlighting the advantages this setup offers. Using more precise naming would help, as it frames expectations.
For instance, if someone wants to run their own chain, would they simply deploy a program that acts as the node for their custom chain (making it accessible to light clients, geo-distributed in multiple AS, with archive nodes and public RPCs/GraphQL, etc.) without needing additional infrastructure? Or would they still need to run their own nodes and infrastructure with a cloud provider to ensure public access to their RPCs, etc.? One would expect that running infrastructure on a cloud provider is not necessary.
Cloud computing is the on-demand availability of computer system resources, especially data storage (cloud storage) and computing power, without direct active management by the user.
Cloud sounds like the perfect term here, certainly for the long term vision.
