In the past, deploying a Rollup on Polkadot was never an easy task. The more flexible the system tends to be, the more complex the deployment process: from SDK updates to slot auctions, to governance and runtime upgrades, each step can become a challenge for the team.
To change this situation, Parity launched the Polkadot Deployment Portal (PDP) this year — a one-stop portal from building, deploying to accessing. Its goal is clear: lower the threshold, simplify the process, and enable any team to quickly and stably start and run their own Rollup on Polkadot.
In this article, Santi Balaguer, the head of product development at Parity, will take us through the evolution of the deployment experience on Polkadot over the past few years, analyze the design philosophy behind PDP, and share how this tool is gradually changing the way Rollups are launched.
Deployment experience on Polkadot: the more flexible the system, the more complex it often is.
Jay: Welcome to Space Monkeys. Today we have invited Santi Balaguer, who is responsible for product development at Parity. Today we are going to talk about PDP; what does PDP stand for?
Santi: It is the Polkadot Deployment Portal — the Polkadot deployment portal.
Jay: Before starting PDP, what have you mainly been responsible for at Parity in the past four or five years?
Santi: In the past, we have always been closely in touch with the developer community, mainly helping them launch parallel chains and Rollups on Polkadot. As you said, I have been at Parity since before parallel chains were even online.
Jay: Among some projects you frequently interact with, which ones are we relatively familiar with?
Santi: I was previously in charge of the Substrate Builders project, which includes many well-known projects. I remember the Hydration team most vividly. I still recall when Jakub was doing a demo, introducing their Omnipool idea and the problems Hydration wanted to solve. He showed a classic meme of a 'money printer goes brrrr' to explain why they needed to propose a new solution. I still joke with Jakub about that to this day.
Jay: Haha, that's great. You've definitely seen many projects successfully land on Polkadot, and you must have heard a lot about their pain points. Can you talk about what has been the most troublesome part of deploying projects on Polkadot in the past few years?
Santi: Of course. Polkadot itself is a very complex system. You have to really understand it for the project to run smoothly. This complexity actually comes from its flexibility — the more flexible a system is, the more complex it tends to be.
In the early days, if you wanted to run a parallel chain on Polkadot, you first had to find a way to deal with the various 'disruptive updates' of the SDK. At that time, there was no Polkadot SDK, only Substrate, which was different from now. Once you sorted out the development environment, you also had to rally support in the community and participate in the slot auctions. The auction itself was also very challenging; you needed enough people to support you, and the auction results were only known at the last moment. Even if you won, you would have to wait for three months before the parallel chain could actually go live. Moreover, the slot would only be rented to you for two years. So at that time, you had to go all out in both technical development and community mobilization to secure a place on Polkadot.
Jay: Right. The experience has indeed improved a lot over the past few years. Can you talk about the process of this change?
Santi: Of course. I think Parity has made significant efforts, especially in reducing the disruptive updates of the Polkadot SDK.
Although there are still updates now, it is much more stable compared to before, and the compatibility between versions has improved a lot. Developers can now rely on the SDK version they are using with much more confidence. Some parallel chains are even still using older versions of Substrate but can still run normally on Polkadot.
Additionally, the introduction of Coretime (although it also has a certain complexity) has indeed greatly lowered the threshold for developers. It makes it easier for everyone to try, lowering the barrier to entry for Polkadot significantly; I think we should make good use of this as much as possible.
Why do projects choose to deploy on Polkadot now instead of making an L2 on Ethereum?
Jay: Despite there being many challenges at that time, many have already been resolved. Why do you think a project today would choose to deploy on Polkadot? Why not go to Ethereum to do L2 or directly launch their own L1? What is the reason?
Santi: This is a very interesting question. First of all, I think as a community, we should do more communication and promotion in this regard. In my personal understanding and opinion, Polkadot is currently the only blockchain designed from the ground up to natively support Rollups. It provides developers with a lot of infrastructure that is not available elsewhere.
For example, Polkadot provides a very large data availability layer for Rollups, while if you are on Ethereum L2, you have to rely on some external systems or 'blobs' to solve it.
Another example is the native message passing (cross-chain communication) between parallel chains, which does not exist on other Rollups. The lack of this feature compromises the system's security.
Looking at performance, Spamming has already verified that the TPS level of Polkadot's Rollup is outstanding in the entire industry.
Another point is elastic scaling; Polkadot is currently the only system that can scale infrastructure up or down as needed at any time. For example, if Mythical suddenly wants to launch a new game and expects user growth to surge by 10 times in the first week, they can almost make no changes and immediately support this traffic.
I think in our past discussions about 'partition and Rollup', we did not make Polkadot the protagonist and missed a bit of opportunity. But it’s not too late; we still have a chance to put it back on center stage.
Jay: Yeah, you mentioned before that Polkadot was designed from the ground up for Rollups. We just didn’t call it a Rollup back then.
Santi: Exactly! And another point we often overlook is shared security. Looking back at the entire blockchain development context: it started with Bitcoin, then Ethereum came along. Later, people began launching various new 'Ethereums', advertising that 'my chain is better because it has features A, B, and C'. But the problem is that ensuring the security of a new chain is very difficult. You need a sufficiently large and strong set of validators, which is not an easy task.
At that time, Gavin thought: why not provide security as a service, built into the base layer? This is the uniqueness of Polkadot. It can not only provide shared security but also achieve efficient communication between these Rollups, which is where Polkadot excels.
How did the idea of PDP come about?
Jay: That's great. If a Rollup wants built-in data availability (and at a large scale), instead of relying on piecing together other projects, and also hopes for strong TPS and throughput while seamlessly communicating with other Rollups, then Polkadot is indeed very attractive. However, before the emergence of PDP, deploying a parallel chain was still quite complex and time-consuming. So why was there initially an idea to create this tool called PDP?
Santi: This idea has been brewing for a while, although we really started working on it last November.
Our team started to fully invest in this project around March or April of this year, and now the team is making rapid progress, gradually turning this idea into reality. This has been in the works for a long time, and there have already been some similar solutions in the industry. For instance, in the Ethereum ecosystem, there are Conduit and Gelato; on the Polkadot side, there was Tanssi before, but they mainly shifted to Ethereum later, with a similar approach.
We saw that Polkadot had not been successfully implemented for a long time, so we decided to step in ourselves to ensure this could happen. After all, we have a deeper understanding of Polkadot and know better how to make it easier for developers to deploy projects, which is the goal PDP aims to solve.
We do not make decisions for developers, but rather provide guidance and options.
Jay: So who exactly is PDP aimed at? I remember there was an early issue with Polkadot where some projects started out trying to do Rollups, but it would have sufficed to create a smart contract. What kind of projects do you think are truly suitable for having their own Rollup?
Santi: That’s a good question, but I think there is no fixed answer. Even now, we still find some projects where it might also make sense to create a contract. But sometimes the project teams need independence, and they do not want to rely on the infrastructure of other chains; at other times, they anticipate that future throughput will be very high, so they prefer to choose to do Rollup from the beginning. Such reasons may lead them to need their own chain or require higher independence in infrastructure.
Another example is Hydration's Omnipool. We can also debate whether it could just be a contract, but I think it wouldn't make sense; making it a chain is reasonable. On the other hand, look at Ethereum's Uniswap, which started as a contract and later went on to create its own chain. But do they really need their own chain now? Maybe not, but they have their own business considerations.
So there is actually no absolute answer; it's more of a result driven by both technology and business. For me, the most important thing is: we shouldn’t make decisions for developers; what we should do is provide guidance so they can make their own choices. Whether they're doing a Rollup or a contract, they should be able to easily try and experiment.
PDP full process experience reveal: from building, deploying to accessing, launching Rollups is that simple.
Jay: Okay, so let's assume a team made a decision, whether it's their own decision or guided by teams like Magenta Labs or BD. Ultimately, they decide to deploy a Rollup on Polkadot. What will their experience be like when they enter PDP? What is the current deployment process?
Santi: In the design of PDP, we divide the process into three main stages: Build — Deploy — Access. These three parts are interconnected.
In the 'building' phase, the core issue is 'how do I start'. Our idea is that the best way is through runtime templates. Currently, OpenZeppelin is developing related templates, and the Pop CLI team and ROG team are also working on this. The Pop CLI is essentially a tool you can use on your own computer to write Rollups. We are collaborating with them to integrate it with the other two stages of PDP (deployment and access).
For example, once you build a Rollup on Pop CLI, you can directly connect to PDP to deploy the Rollup. This is how we designed and implemented it. In this way, developers can complete the entire process using the CLI, just like Heroku or Vercel in Web2, which both have their own CLI. If you are used to this method, you can use the CLI directly; of course, you can also completely follow the graphical interface route. Both ways are fine.
Jay: In other words, besides building with templates, you can also build using Pop CLI, and then deploy. Will PDP itself help developers make some choices? Or is it just a tool that relies more on the team to operate?
Both options exist. We hope PDP can serve as a self-service tool for developers to use themselves. But if they encounter critical issues, we will certainly be there to support them, ensuring they receive the necessary help. Of course, if someone just wants to try it out themselves, that’s completely fine too, haha.
Jay: That sounds fun. Can you give a few specific examples of templates? Which ones do you like?
Santi: For example, the ROG team has a ready-made Pilot Revive template that you can use to start directly. OpenZeppelin has a Frontier template that you can use if you want to run a chain with EVM capabilities.
Jay: That's pretty cool; it's equivalent to several options related to smart contracts.
Santi: Exactly. And there are templates without smart contracts. For instance, if someone just wants to create a chain for custodial assets, especially for real-world asset (RWA) related projects, there are corresponding templates as well. In short, there will be a lot of options available at the beginning, and then you can continue to expand based on that.
Jay: Can the template add new Pallet according to its own needs?
Santi: It was not possible at first. The design idea was that you would start from a template, and then we would guide you step by step to do runtime upgrades. We hoped to help teams gradually find their product-market fit through this method. This design is actually very interesting and is one of the key features we are currently focusing on; we are now using a very interesting tool created by a Puppet team, which can compare your upcoming upgraded runtime with the currently deployed runtime, generating a report that tells you what has changed, what might affect developers, and what to pay attention to.
Jay: Yes, yes, yes, I see you just integrated this, awesome.
Santi: Yes, it was just completed this week. This way, you will receive a report on the runtime upgrade to ensure that what you are about to push matches your expectations. Next, we also want to add a function: to help you simulate running several blocks in the background to test the new runtime. If everything is normal, we will prompt you that 'you can go live'; if there are issues, we will tell you that 'our tests did not pass, you better check again'. This can prevent teams from making mistakes during upgrades. We believe one of Polkadot's advantages is supporting this kind of flexible runtime upgrade, and teams can fully leverage this to iterate quickly and find product-market fit.
Jay: Wait a minute, so is this part already considered the 'deployment' phase? What we just mentioned, from building to runtime, does this count as being in the deployment?
Santi: Right, there is actually some overlap here. It can be understood this way: building often starts from templates; deployment involves the underlying infrastructure. In the past, you needed your own DevOps team to set up collator nodes and do various operations and maintenance; now, at the initial stage, you don't have to worry about any of that. If the project develops well and has the funds and resources, you can fully establish your own operations team later, and we can help you with the migration then. But at the beginning, we will help you handle these matters.
Jay: So who is doing these now?
Santi: Currently, it is Parity providing it. But in the future, we will allow developers to freely choose which cloud platform to deploy on, and it might even be an IBP (Infrastructure Provider). It just takes some time to abstract out this layer, so for now, to ensure a good experience, we are using Parity's own infrastructure to support it, but ultimately, we will open up more choices.
We also introduced a concept called BDU (Basic Deployment Unit). As long as you want to deploy a Rollup on the production network, we will deploy a standardized infrastructure for you, which includes three collator nodes, one of which can also serve as an RPC endpoint for you, and we will also provide you with an indexer.
We are currently working with Subscan; they have an open-source solution, and we plan to integrate it into PDP. This way, you not only have an indexer but also a block explorer. In the past, these things took teams a long time to set up, and now we help you sort it out all at once. This design is quite good.
Jay: Wow, that sounds great. Is this part of the building process?
Santi: This is deployment.
Jay: Understood. So at this point, the Rollup has already been running? It has started producing blocks, and the team can also perform runtime upgrades to keep iterating and finding product-market fit? Then the next step is the final step 'Access', right? What is that?
Santi: Right! Access is the highlight of Polkadot. I think this is where Polkadot can bring unique value to Rollup teams. Building and deploying involve runtime and infrastructure, which everyone can probably figure out relatively quickly, but truly leveraging Polkadot's features is where the differentiation comes. For example, Coretime is part of Access; PDP will pre-purchase Coretime, so once developers want to deploy a Rollup, they can use it immediately without waiting 28 days to start producing blocks, which is a huge improvement for user experience.
Jay: If I want to deploy, do I need to buy Coretime from PDP myself?
Santi: We will help you purchase it and then charge you a fee. In fact, we offer different options for Coretime. For example, if you want to go all out from the beginning, you can use a complete core directly. But we also provide 'sliced core', which is a part of the core; for instance, if you want to test the waters without spending too much money and see how it goes, you can use just a small part of the core.
Jay: Is this feature already available?
Santi: It is already available on PDP. It is currently running on the Westend and Paseo networks. Paseo just recently launched the sliced core, and on Westend, you can directly trade out a part of the core. The downside is that your block time will become longer, but the advantage is that it greatly lowers the threshold, allowing you to test the waters at a very low cost. If the results are good, you can upgrade to a complete core to enjoy the six-second block time, and all of this can be done on PDP. However, the access mechanism still needs to address how to effectively utilize Polkadot. Currently, the Polkadot Hub as an important functional module is about to go live, and we are looking forward to it.
Original video: https://www.youtube.com/watch?v=HkIrGOOf26c
