A Roadmap to a More Accessible Polkadot

Since a blog post by Polkadot co-founder Rob Habermeier, the idea of a "Polkadot Plaza" has gained traction in the Polkadot community.  This idea revolves around several protocol changes that make Polkadot more accessible and easier to use. After several months of discussions following this post, I present in this article a set of concrete deliverables that, although independent projects on their own, all contribute to the motivation behind this idea.

Polkadot offers a sharded, decentralized system that can support large-scale projects that need dedicated throughput. However, getting started on the technology is difficult for startups and tinkerers. Parachains -- practically speaking, rollups -- are an end-stage product for businesses that know they need the scale and also have the resources to commit to development and maintenance.

At an early stage, most projects value a fast time-to-market over scale. Even for later stage projects, many are still experimenting with blockchain tech stacks. With parachain development costs, Polkadot did not offer a compelling entry point. Further, with the prior parachain auction model, founders did not have the confidence that they could even launch their product due to the limited number of parachain cores available and highly variable auction outcomes. This combination has turned away many projects from Polkadot and led to the network having less activity than some of its competitors.

For developers who want to integrate Polkadot into their systems or build user-facing applications, Polkadot has also proved a challenge. Much like monitoring all Ethereum activity requires integrations with the Ethereum chain and all of its rollups, a Polkadot integration requires monitoring multiple parachains, the custom events and assets within each one, as well as the cross-chain messages that pass between them. Although a good user experience and chain abstraction are possible on Polkadot today, possible does not mean easy. Most applications have been unwilling or unable to commit the necessary resources to it. In addition, many users complain, understandably, of high deposits and base costs for access to features like proxy accounts and multisigs.

But it's not all bad news. While other L1 and L2 protocols have prioritized speed and cost by taking centralized and/or long-finality-time approaches, Polkadot developers have focused on resilience, safety, and decentralization (while still having competitive speed and cost with current L2s). And although the market seemingly values the former over the latter (to the detriment of their users in my opinion), now Polkadot can address core speed, cost, and the development time-to-market for applications on top of its secure and scalable foundation.

The parachains core team at Parity has already made dramatic improvements to the parachain product. Auctions are no more; projects can now access Agile Coretime with flexible time-to-market and predictable costs. Async Backing and Elastic Scaling bring notable performance improvements like faster block times and contemporaneous core access. Other improvements like sub-second block times are in a beta phase, which would make even a single parachain rival top L1 performance.

Joe explains more about smart contract compatibility on the regular monthly OpenDev call

With all that in mind, Parity is working on several projects in parallel. While each project stands alone, what ties them together is their objective of making Polkadot more approachable for everyone. We want to make Polkadot easy to get started on for on-chain application developers, services like exchanges, and user interface developers to create better experiences for their users.

Underlying these several projects is our commitment to provide enough API stability and protocol consolidation to abstract chain architecture from developers and by extension users. Instead of having to select "Polkadot (Asset Hub)" in a menu, users should just see "Polkadot". The reason that Polkadot was designed with shared security and stateless validation was to allow applications to build on multiple components without exposing that "backend" architecture to users.

Ethereum Compatibility: An Easy On-Ramp and Access to a Bigger Ecosystem

With all that said, let's start unpacking these projects and what they will bring to Polkadot. First, following the public referendum that supported Ethereum compatibility, Parity is working on bringing this to Polkadot.

Adding Ethereum compatibility addresses a number of problems. By leveraging existing tools and standards in the Ethereum ecosystem, it will be much faster and easier for newcomers to get started. It also allows easy integration into websites that onboard new developers into Web3. Developers getting started with Solidity should see Polkadot as a deployment option just as much as any other network.

Ethereum compatibility also simplifies other integrations, for example Circle's CCTP, which allows native minting and burning of USDC across multiple networks. A custom CCTP implementation in the runtime would be difficult and wouldn't be reusable for similar applications. The customizability of smart contracts is perfect for simple applications. Furthermore, for applications that typically deploy on multiple chains instead of choosing one, it makes sense to have compatibility and make Polkadot a viable, low-barrier option for them.

The Polkadot implementation will use the new PolkaVM, which will bring performance improvements over EVM and allow heavier computation (with executables written in languages like C or Rust). A Solidity compiler and Ethereum RPC proxy will ensure that contracts written in Solidity -- and standard Ethereum development tooling like Metamask -- work with Polkadot out of the box.

Adding Ethereum compatibility into the Polkadot system provides an entry point that will bring more developers and applications into Polkadot. The parachain offering remains, and is a scaling path for projects that require that level of performance or customizability and have the resources to maintain it.

Application development under the parachain model was notoriously difficult in its early days. While other blockchain ecosystems currently struggle with scaling and fragmentation, Polkadot has spent several years addressing those problems, perhaps at the frustration of people wanting to build applications. Now this technology is more mature and can be accessed by a larger market; Ethereum compatibility is the gateway to that market.

We at Parity expect to have a playground on Westend for developers to start experimenting with contracts before the end of the year, and to propose this functionality on Polkadot in Q2 of 2025.

Lowering Integration and UX Barriers

The second pillar of this program centers on protocol consolidation. Our approach for the last several years has been to pursue tightly-scoped system parachains, e.g. collectives, bridges, identity, etc. The holy grail has been the "minimal relay", where we move anything user-facing like staking, governance, and even balances off of the Relay Chain.

While moving this functionality off of the Relay Chain brings value, isolating these functions into separate chains has several ergonomic downsides for application development. With the scaling improvements that the parachains core team has brought to Polkadot, it started to make more sense to move all of these functions to a single parachain rather than disparate ones.

This consolidation will bring major benefits to application developers and by extension their users. Instead of requiring integrations with several parachains, applications can integrate a single point of entry that supports the vast majority of user stories. The fees and deposits (including the much denounced existential deposit) will also be two orders of magnitude lower than their current levels, making things like proxy setup and multisigs much more accessible.

Joe and other Parity devs speaking to Jay Chrawna (The Kusamarian) at Polkadot Decoded

Although parachains share similarities with L2s, the Polkadot protocol actually uses parachains for its system features. Because the protocol functionality like staking and governance will sit alongside a smart contract environment, developers can write contracts to interact directly with what one could consider the Polkadot L1 protocol (viz. the user-facing logic like governance and staking). This makes the Relay Chain truly a layer zero providing validation services to the network -- unlike rollups, each parachain block is actually validated immediately -- with the user-facing features directly and synchronously available to smart contract developers.

With the enhancements to parachains, using a system parachain is even more powerful than keeping this functionality on the Relay Chain. The Relay Chain will likely keep ticking along at six seconds per block, and acts as a clock to many systems in the network. With Elastic Scaling, any system can handle surges in demand and scale to multiple cores or provide sub-second block times for smooth user experience.

Pending approval from Kusama OpenGov, we expect to have this migration complete on Kusama in Q1, where we will ensure that everything goes to plan over a long period of time (as in, we will wait for a full staking slash period to pass). Considering release cycles, audits, and governance times, that probably results in having the Polkadot migration done in Q3.

Chain Abstraction for Developers

The upgrades are not limited to on-chain changes though. Parity is also working on tools and APIs that will make application development easier.

Storage format changes have routinely caused problems for application developers. Any time a module migrates data to a new storage format, anyone trying to read that data runs into decoding problems. We will harness the runtime API infrastructure to build more powerful view functions, which will also allow subscription.

These view functions will protect users from storage format changes by providing a stable API for development. But we can even extend the concept beyond individual storage items. Reading storage directly forces application developers to be familiar with low-level details like which information is stored on which parachain and in which module. For example, there is no "Governance module"; Polkadot governance consists of the configuration and composition of multiple modules. An API for Polkadot governance should not expose this implementation detail to application developers. Instead, a set of view functions defined at the runtime level will provide a unified governance API.

The end-stage product for this concept is an API that will even abstract individual parachains from developers. One can imagine that an account has a DOT balance on multiple different parachains. This API would return the aggregated balance in a single query. It could even have an intent-based write API, so that developers can call things like "set identity" without needing to know about the People Chain.

We are working on unstable APIs in Q4 this year and plan to provide stable read APIs in Q2 of 2025.

Data Aggregation and Visualization

Finally, many dashboards misrepresent Polkadot accounts, performance, TPS, etc. as only the activity on the Relay Chain. We hope to change this with more outreach but also building our own monitoring tools and dashboards to make data aggregation and visualization easier. These metrics will include things like time to inclusion and finality for transactions, Relay Chain and parachain block time reliability, and transactions per second on the entire network. These tools and metrics will make it easier for us and others to display the true power of the Polkadot network.

Conclusion

From an implementer's perspective, all of these projects are seemingly independent. However, together, they give the network L2-like costs with direct access to the L1 user features, fast verification and finality, and simplified integrations. The gestalt of Polkadot in a year will be the best overall infrastructure product suite that suits a larger developer and business audience and ultimately improves user experience.