R0GUE: Reimagining Polkadot Development with Pop Network

[alejandro]

Introduction

R0GUE is back with the next piece of its vision, carefully designed to enhance the developer experience in the Polkadot Ecosystem. We have already introduced pop-cli , which makes setting up a project simple — with just a single command. However, a single tool is not an e2e solution. It helps developers start their journey, but there needs to be more. This post introduces the second piece of our vision, one in which we create a seamless experience for dApp deployment into the Polkadot ecosystem.

Motivation

The existing developer experience on Polkadot is widely recognized as problematic — marked by fragmentation, complexity, high barriers to entry, insufficient guides/documentation and persistent developer challenges. These are not only our observations. Based on the heavily discussed forum post: Developer Experience must be our #1 Priority and our survey: Polkadot Smart Contract Developer Survey, we found the following patterns:

• Developer experience and onboarding must be improved
• Better tooling and documentation needs to be created
• Users should be able to pay fees in DOT on a parachain
• More focus needs to be placed on smart contracts and dApps
• Smart contract developers want easier access to composable functionality, made available from both the local runtime and the wider ecosystem

There is a crucial need for an improved developer experience, facilitating the deployment of innovative dApps to spur a new wave of user adoption while fostering an accessible and supportive environment. Whilst we believe the ink! smart contract language provides the perfect entry point for dApp developers starting their Polkadot journey, its deployment opportunities remain limited, especially in comparison to the EVM.

Pop Network

Introducing the Pop Network, which aims to be the deployment entry point in Polkadot, offering the best developer experience with reduced complexity, ease of deployment, superior tooling, and outstanding documentation.

Pop Network concentrates on excellence in one focus area: native¹ Polkadot smart contracts, supporting ink! (or Solidity via Solang), ensuring seamless execution in WASM and eventually RISC-V. It will allow developers to deploy contracts and interact with DOT. Not another new token, but a token that already has the infrastructure in place for easy acquisition and usage.

We are committed to empowering dApp developers by expanding the capabilities available at the runtime level, specifically designed for smart contract utilization. Our vision encompasses providing seamless access to the ecosystem via cross-chain interactions (XCM), as well as targeting Governance, DeFi, Identity and NFT use cases in a more composable way. With a strong commitment to community-driven development, we plan to tailor these building blocks based on valuable community feedback. This involves interfacing with existing pallets, developing new pallets, contributing to standards and libraries for ink! and providing exceptional documentation alongside our technical solutions.

This is to ensure easy access and utilization from smart contracts, further enhancing the development experience. A development experience which aspires to be compatible with Ethereum tooling and still aligned with our core focus, offering a smooth transition for developers and users from the Ethereum ecosystem to leverage the Power of Polkadot.

Our mission is to empower dApps through all stages of their growth. We see the pop-cli as the perfect entry point to rapidly prototyping ideas, and generating starter contracts based on use cases. Ready to deploy? The pop-cli will allow deployment to the Pop Network to find your audience. But we also want to allow dApps to scale out when needed, to realize the promise of evolving into their own chains…

Pop Network: dAppChains

R0GUE strives to see your dApps gain adoption and grow as much as possible. We also strive to provide ‘on-demand’ scalability; allowing any dApp to scale to its own parachain, or dAppChain. Envisioned by the ink! team, dAppChains provide increased performance² and sovereignty over blockspace. This will enable dApps to scale using their preferred smart contract language instead of having to learn a new framework, like Substrate. dAppChains blur the lines between smart contracts and parachains.

However, with increased performance and control comes increased complexity and maintenance. In response, the Pop Network commits to provide a comprehensive dAppChain-as-a-Service solution. Alleviating these complexities means staying true to our promise of delivering the finest developer experience.

Pop Network services will automate dAppChain maintenance and eliminate complexity.

To accomplish this, we will develop the necessary instrumentation, some of which serves a similar purpose to the ‘The Merge’. Instrumentation will include:

1. Templating

   The templates provided by pop-cli will be expanded to offer dAppChain support, ‘flavoured’ by use case. All Pop Network functionality will also be made available via dAppChain templates, so that a dApp can easily scale out as required.

2. Coretime Procurement

   Helping the transition to multi-core utilization on the Polkadot Relay Chain, any new dAppChain should be able to consume Coretime directly as required. The R0GUE team will work on a generic implementation of Agile Coretime usage for the Polkadot SDK³. A feature that will be instrumental to Pop Network’s ambitions and essential to the ecosystem. Integrations with existing Coretime marketplaces will also offer developers alternatives. Collectively, R0GUE wants to be at the forefront of exploring the on-demand era of Polkadot!

3. Infrastructure

   The primary objective of Pop Network dAppChains revolves around enabling smart contract developers to have access to the best possible development and deployment experience. Thus, we will offer a pivotal solution through a shared collator system that relieves developers from the intricate responsibilities of onboarding a parachain and managing its infrastructure.

4. Runtime Maintenance

   We strive to provide automated runtime maintenance, including storage migrations, allowing dAppChain solutions to receive timely security updates and to evolve with Polkadot.

5. State Migrations

   The state held by a contract needing to scale to a dAppChain will need to be migrated to its new destination in a coordinated way. Pop Network will provide additional services around the orchestration and execution of trustless state migrations.

Along with the above features, Pop Network will be forward-looking, incorporating aspects of CorePlay into its future milestones as the feature rolls out.

Proposal & Conclusion

At R0GUE, we envision Polkadot as THE place for developers, fostering creativity and innovation, and redefining the future of smart contract development. With Pop Network we want to revolutionize the current smart contract developer experience, by breaking barriers, simplifying complexities, and paving the way for a vibrant and inclusive ecosystem. Pop Network will become the home of innovation, adoption, growth and scalability for smart contract developers.

We enthusiastically embrace collaboration with ecosystem partners who offer solutions geared towards these goals, fostering an inclusive approach aimed at collectively fortifying and refining smart contract development and scaling possibilities!

At this stage we are asking for support from the Web3 Foundation’s Decentralized Futures program. This idea goes further than creating a smart contract platform, it speaks about building paths for streamlined creation of projects that will grow together with the broader ecosystem. Using pop-cli as the key to unlock the doors to a realm where imagination meets execution, Pop Network will become the ultimate stage for developer experience, innovation and growth.

Join us on this transformative journey. Expect our last post soon.

R 0 G U E

---

Footnotes

¹ Powered by the Polkadot SDK

² DAppChains offer increased performance compared to traditional contracts running on a parachain by 1) removing the sandboxed interpreter wasmi , required for untrusted code and 2) directly compiling contracts into the runtime WASM blob rather than loading them separately from storage.

³ Polkadot SDK - On-demand Cumulus Integration #1487

---

[TomH149]

Great idea and a solid project! Thanks for the post @alejandro, looking forward to seeing how this progresses!

[Daanvdplas]

For the people who are interested about the team behind Pop Network, let me introduce them to you: R0GUE.

We would really like to get feedback on this idea!

Feel free to contact us: gor0gue:matrix.org

[brad.olson.587]

I like the idea of “dapp chain as a service”, depending on what exactly it entails. Assuring smart contract developers that there is a convenient way to scale their services may encourage more smart contract use. On the other hand, generic smart contract chains wouldn’t be able to take advantage of the performance improvements available to customized Parachains.

Also, splitting off dapps into their own chains would complicate the XCMP landscape substantially and increase cross chain message traffic. If a dapp wanted to use external resources such as Hydra DX for liquidity, they’d have to initiate their own HRMP connection. Perhaps establishing and using that connectivity could also be offered as a service?

[bruno]

@brad.olson.587

If a dapp wanted to use external resources such as Hydra DX for liquidity, they’d have to initiate their own HRMP connection. Perhaps establishing and using that connectivity could also be offered as a service?

Yes! We have been looking into creating an abstraction layer around external parachain resources with DOT as the interface. Use DOT to interact with parachain services.

@brad.olson.587

On the other hand, generic smart contract chains wouldn’t be able to take advantage of the performance improvements available to customized Parachains.

We plan on closing this gap by strategically exposing runtime/pallet functionality directly to smart contracts.

This is also the reason we see the value in scaling to a dAppChain - for those dApp developers who want to fully leverage the performance benefits of a Polkadot parachain.

[Daanvdplas]

@brad.olson.587

Also, splitting off dapps into their own chains would complicate the XCMP landscape substantially and increase cross chain message traffic. If a dapp wanted to use external resources such as Hydra DX for liquidity, they’d have to initiate their own HRMP connection. Perhaps establishing and using that connectivity could also be offered as a service?

Look at it from this perspective: When a dApp gains considerable traction and proves its utility within a particular use case. Polkadot offers shared security, an interoperable environment, and a framework for the dApp to transition to its dedicated Parachain.

The concept of a dAppChain comes down to the same. However, in stead of writing the blockchain logic in pallets, dAppChains will have smart contracts as primary focus.

Both Parachains and dAppChains should harness the capabilities of XCM. But echoing Bruno, we are actively exploring ways to simplify the utilisation of XCM within these dAppChains.

[muraca]

Great job guys.

I think the workflow to deploy and evolve new dApps is well defined, and something like this is what we need to simplify the development and deployment for new developers that approach this ecosystem.

I’ve always thought that Polkadot needed some kind of system parachain to run smart contracts. Paired with the new Coretime features, the dAppChains-as-a-service can become hubs of dApps with similar runtime functionalities that don’t require much resources, reducing the barriers to entry.

[IkerParity]

Great intro!

I believe this project is addressing something that for one or other reason, the ecosystem has been lacking for too long. And I think that pushing this idea forward at the same time as Coretime is deployed is perfect timing.

I am really looking forward to getting further details of this project. Particularly interesting to me are the “Runtime Maintenance” and “State Migrations” points above. Just a couple of initial questions on them:

• Is R0GUE expected to be the only maintainer of the runtime? Will runtime upgrades happen via a certain governance mechanism?
• If the state of a given smart contract is replicated from Pop Network dAppChains to its own chain, is the “legacy” smart contract expected to be automatically “deprecated” or is the idea to let them both versions co-exist in the ecosystem?

[Daanvdplas]

Thanks for your questions Iker!

Is R0GUE expected to be the only maintainer of the runtime? Will runtime upgrades happen via a certain governance mechanism?

To clarify, automated runtime maintenance will be provided to dAppChains. Our pop CLI tooling will maintain a range of templates, along with some for dAppChains, which will be updated with each new Polkadot release. We will dogfood our own tooling, using it to maintain the Pop Network runtime and to improve and streamline the process over time. Most dAppChains will spin off from Pop Network’s runtime, so any update work can be leveraged and executed on the dAppChains’ runtimes. dAppChain owners will have the choice to perform those upgrades themselves or let Pop Network do it.

As for the runtime maintenance and governance model of Pop Network. Initially the chain will run with sudo and R0GUE will be the sole maintainer of the runtime. This is for the following reasons:

1. We believe it’s crucial to invest our time early on in building the essential features of Pop Network and validate its value propositions. While governance is important, we’ll delay its implementation to ensure we give it the serious attention it deserves.
2. Governance is extremely complicated and requires a lot of consideration.
3. We want to iterate quickly, simply put; deliver, collect feedback, improve or adjust, and on to the next feature (following the lean development methodology). The priority is to deliver the core features of Pop Network with our main goal; empowering ink! smart contract development within the Polkadot Ecosystem by improving the accessibility and usability of its features (in a timely manner). We believe that running these iterations additionally through a decentralized governance model will slow down the pace of development.

Nevertheless, once Pop Network is providing true utility to the Polkadot Ecosystem (and the world), decentralizing governance and infrastructure will be our main priority. We are committed to decentralization.

If the state of a given smart contract is replicated from Pop Network dAppChains to its own chain, is the “legacy” smart contract expected to be automatically “deprecated” or is the idea to let them both versions co-exist in the ecosystem?

That is ultimately the decision of the smart contract owner/deployer. For migrating the state of a contract to its own dAppChain, we will provide something along the lines of “maintenance mode”. This will enable the filtering of calls to a given contract, so that the contract state can be locked to help ease the migration. This will be an opt-in feature and access will be limited to the contract owner. Its primary use case is around state migration, but it could also find additional usage around contract security, coupled with governance controls, enabled in the case of a contract security issue. The contract owner would then be free to terminate the source contract once a migration has been completed successfully, provided that their contract supports such a function. Ownership, upgradeability and termination are additional considerations specific to contracts.

[IkerParity]

Thanks for the detailed answer @Daanvdplas !

I am totally inline with the governance model path chosen for Pop Network, particularly given the purpose of it.

It makes sense what you say about smart contract migration. I am looking forward to seeing the details of this use case when ready.