Gavin Wood: How should Polkadot transition from a chain-centric approach to an application-centric approach?

Speech: Gavin Wood

Compilation: PolkaWorld

In the previous article, we summarized the first part of Gavin's speech, which discussed how Polkadot transitions from a chain-centric to a "core"-centric approach. In this article, we will continue to summarize the remaining parts of the speech—transitioning Polkadot from a chain-centric to an application-centric model and how to build a resilient platform.

Chain-Centric → Application-Centric

Polkadot 1.0 is a chain-centric paradigm: allowing isolated chains to send messages to each other, which is essentially similar to a single chain with cross-chain bridges, except that the parachains are all connected to the relay chain.

This leads to a fragmented user experience. A user may use an application on one chain, but they want to use the same application on another chain, essentially using the application in a multi-chain manner.

However, if we have a chain-centric paradigm, we will also have a chain-centric user experience. If an application is not chain-centric, everything becomes difficult.

In reality, if we want to fully leverage Polkadot's potential, applications need to be deployed across chains, and it needs to be seamless across chains, at least for users, and ideally for developers as well.

This is an artistic illustration of "what Polkadot looks like":

To quickly launch Polkadot, we chose to place many application capabilities on the relay chain. But this is actually a trade-off.

The benefit is that we can deliver many features in a short time before the technical foundation is fully completed, such as great staking, governance, tokens, and identity systems.

But it also comes at a cost. If we tie many things to one chain, some problems will arise. For example, the relay chain cannot always use its resources for its primary job—ensuring network security and message delivery. It also induces a chain-centric mindset.

In the past, we could focus on one chain and put all of Polkadot's functionalities on the relay chain at launch; that was our earliest goal. But unfortunately, the relevant tools have not kept up with the era where both applications and users are cross-chain.

Now, system-level functionalities are shifting towards a cross-chain deployment paradigm. System chains are becoming more common, and the relay chain is handling less and less. Applications need to be able to traverse these chains without making the user experience difficult.

This is a diagram I just drew half an hour ago, which I believe provides a better perspective on understanding "what Polkadot is."

Polkadot is not a relay chain in the middle with parachains surrounding it; at least, it shouldn't be that way for those entering the Polkadot ecosystem. In fact, Polkadot should be an integrated system, a computer running many applications.

Yes, there are boundaries between the business logic components of different chains (i.e., parachains), but this may not be as important to users as we think. What matters more is that users can do what they want easily, clearly, and quickly.

The dots in the diagram represent applications, and the dashed lines separating the dots represent "paras." I don't want to call them parachains because that would lure us into the trap of thinking "each parachain corresponds to one core." This has been the model of Polkadot so far, but it is not the only option.

These dots should normally be able to communicate with each other and do so as easily as communicating within the dashed line area.

XCM

How do we achieve this? This brings us to XCM.

XCM is a language, while the actual message transmission layer is called XCMP. I admit these two names can be a bit confusing.

What does XCM do? Its role is to abstract common functionalities within chains; it creates a descriptive language to express what you want to do or what you want to happen.

As long as the chains honestly translate this message, everything is fine. But unfortunately, there is no guarantee that chains will honestly translate your XCM messages. In a trustless environment, XCM is not ideal.

For example, in trade, we would say that the XCMP transport method provides us with a secure trade route, and we won't be robbed along the way. What is sent can be ensured to be received. However, it does not provide us with a framework for creating binding terms between different trading entities.

A more intuitive example is the European Union. What is it? Essentially, it is an alliance that you can join; it is a treaty framework that requires different sovereign countries to adhere to specific treaties. However, it is not perfect because, although there is a common judicial body that can translate each country's laws to ensure compliance, it cannot prevent a country from changing its laws to no longer align with EU requirements.

In Polkadot, we face similar issues. XCM is a language for expressing intent, while WebAssembly expresses the laws that parachains must adhere to in Polkadot; you can think of it as the European Court of Justice (ECJ), ensuring that parachains adhere to the logic they propose. But this does not mean that this logic cannot be legally changed by parachains, thus refusing to comply with the XCM language.

XCM is a language for expressing intent, such as "I am ready to transfer assets" or "I am ready to vote." This is not an issue between mutually trusting system chains. But if they are between different governance processes and legislative procedures, problems will arise. We can do better in the Polkadot ecosystem.

Accord

Here I introduce a new term called Accord. Accord is a voluntary treaty across multiple chains. It is somewhat like saying, "I voluntarily adhere to this business logic, and nothing I do will change that." Chains themselves cannot violate the logic of the treaty.

Polkadot ensures the faithful execution of this logic. Accords will target specific functions. Any chain that joins the Accord must adhere to the rules, which will pertain to that specific function.

To ensure a low barrier to entry, proposing an Accord does not require permission. Since it is voluntary to join, it will not affect anyone before passing and registration.

This diagram is not the most precise, but it conveys the general idea. The outer circle represents Polkadot, with some small dots inside; we can place this diagram horizontally. Thus, Accord is a separate mechanism governing its local sovereignty.

Accord cannot exist in all systems. To my knowledge, Polkadot is the only system that can support its existence because Polkadot is the only one with a security layer of equal strength and can provide specific state transition functions for each shard. These characteristics enable Polkadot to achieve collaborative models that are impossible in other architectures (like cross-chain bridges).

Those familiar with Polkadot may have heard of "SPREE," which is the technology that can realize Accord.

Some Use Cases of Accord

Let's look at some possible cases for Accord.

One of them is asset hubs.

Currently, if two chains want to interact with assets, they must go through a third chain, i.e., the asset hub chain. If one of the chains is a local asset chain, it will be slightly different. But theoretically, if two unrelated chains want to trade third-party assets, you must additionally establish a path.

With Accord, this is no longer necessary. You can think of it as an embassy; it exists in a universal process space, scheduling with parachains at the same time on the same core, but it is not part of the parachain business logic; it exists separately. This is somewhat like an embassy having its own country's laws, but its geographical location is in the host country. Similarly, Accord is like external business logic, but it is recognized by everyone and exists locally.

Another case is multicast XCM routers. It can send a message but cross over to multiple chains, and it can also be done in a certain order. For example, perform one operation here and another operation there, but always with my permission. This is also something that cannot be done currently.

Another case is decentralized exchanges, which can set up outposts on multiple different chains to allow exchanges to happen directly locally without needing to open a bidirectional channel.

These are just a few examples I can think of for now, and I believe the potential of this technology will be further realized in the future.

Project CAPI

Let me briefly talk about the user interface—Project CAPI. Its purpose is to provide a smooth and well-experienced user interface for Polkadot applications that span multiple chains, even when using lightweight clients.

Hermit Relay

This means transferring all user-level functionalities from the relay chain to the system chains. For example:

Balances
Staking
Governance and Identity
Core Leasing

Ultimately allowing Polkadot's functionalities to span multiple parachains, freeing up space on the relay chain.

Building a Resilient Application Platform

In the last part, I want to reiterate what we are doing and why we are doing it. Everything is about resilience.

The world is always changing, but if everyone has clear intentions, it is important that these intentions can be respected. The systems we currently use are not resilient enough; they are built on very old-fashioned ideas.

When your system lacks cryptography and game theory, some bad situations can occur. For example, the large-scale cyberattack mentioned in this news led to the leakage of information from 6 million people, which is one-thousandth of the world's population. And these things happen frequently.

So how do we build a system that is not vulnerable to these threats? First, of course, we need to construct a decentralized, cryptography-based system that can withstand the tests of game theory. But what exactly should we do?

Although we advocate "decentralization" every day, if everything has to go through the same RPC provider, it does not count as true decentralization.

Decentralization needs to be provided by multiple factors:

Use of Lightweight Clients: Smoldot and CAPI will allow high-performance UI based on lightweight clients.
ZK Primitives: Build a feature-rich, high-performance ZK primitives library. The first library is almost complete and will provide privacy protection for on-chain collectives (including Fellowship).
Sassafras Consensus: A new consensus algorithm without block separation. It improves security and randomness, with high-performance transaction routing. It enhances the performance and user experience of parachains, and encrypted transactions prevent front-running, potentially bringing in MEV profits.
Mixed Networks / Onion Routing: Avoid leaking transaction IP information. It is a universal messaging system between users, chains, and OCWs.
Human Decentralization: Introduce many diverse participants into the system. Incentivize participation through governance, treasury spending, salaries, grants, etc., and absorb and maintain collective knowledge.

Remembering Our Original Intention

Finally, I want to reiterate our original intention. Polkadot does not exist to create a specific application but to provide a platform that offers a way to deploy various applications in an environment where applications can leverage each other's functionalities to enhance the well-being of a broad user base. And we must ensure that this vision can be realized as quickly as possible; that is the mission of Polkadot.

If Polkadot cannot maintain a certain resilience to changes in the world, then building Polkadot would be meaningless. These changes could be other ways to achieve the same goals or threats from external organizations that despise trustless worlds.