Full text of Gavin Wood's speech: How Polkadot has transformed into an application-centric

By Gavin Wood, PolkaWorld

On June 28, Polkadot's annual flagship event Polkadot Decoded Conference was held in Copenhagen, Denmark. Web3 enthusiasts, Builders, and investors from all over the world discussed the latest developments in Polkadot's ecology.

The most surprising part of this conference should be that Gavin Wood, the founder of Polkadot, attended as a mysterious guest and brought a very important point of view.

Gavin shared the future development direction of Polkadot, and proposed a new perspective on Polkadot: no longer limited by the original parachain and relay chain, but focusing on the lower-level resources required by the blockchain —— Computing core (core), regard Polkadot as a multi-core computer.

And Gavin proposed that Polkadot may cancel the existing slot bidding method in the future, and instead adopt a more flexible resource allocation method centered on cores, such as monthly "bulk purchases" of "cores" and "instant purchases".

The following text is compiled from Gavin's speech by PolkaWorld.

** Polkadot 1.0 **

At this stage, Polkadot can be called Polkadot 1.0 version.

At this stage, Polkadot's functions are complete, and all the functions mentioned in the white paper 7 years ago have been implemented, and the code base of Polkadot 1.0 will be released soon.

So what is Polkadot 1.0? In the original white paper, I wrote "Polca is a scalable heterogeneous multi-chain". That is to say, it is a blockchain, but it has a unique consensus mechanism "BABE", which can provide security for other blockchains (parallel chains).

To summarize artistically, it goes something like this.

In the middle is the relay chain, which is responsible for Crowdloan, Auction, balance management, pledge, governance, etc. It is a relay chain with many functions. The small dots on the side are parachains, and the relay chain must also ensure the security of the parachains. And these parachains can communicate with each other.

So what is the product form Polkadot provides? It is in the form of slots, with a lease period of 6 months, and a slot usage period of up to two years can be obtained in advance, plus the Crowdloan mechanism. But other than that, there is no other way to take advantage of Polkadot. **The only product in Polkadot 1.0 is the parachain slot. **

A new perspective on Polkadot: multi-core computer

This famous saying expresses such a truth: If a person wants to truly understand the world, then the change of perspective is crucial, even more important than going to the wider world.

So here we will change our perspective and re-understand what Polkadot is.

The concepts of parallel chain and relay chain are very good, and it is also the way many people and I understood Polkadot in the early days, and they are the objects we are trying to build.

But as time went on, we found that what we were doing was actually different from what we originally envisioned. Sometimes if you're lucky, or if you have a strong team, you can make something even better than you originally thought.

In computer science, abstraction and generalization are important. Later we discovered that the degree of abstraction and generalization we have carried out on Polkadot is far higher than we thought before.

So what is the new perspective on Polkadot?

** Polkadot is a multi-core computer **

First of all, what we do is not about the chain, but about the space and the underlying resources required by the chain.

Secondly, Polca is a platform for builders to create applications and users to use applications. Essentially, it is not a platform for hosting blockchains. Chaining happens to be one of the ways that Polkadot can be useful, but probably not the only way.

Finally, its resilience (Resilience) is also very strong. I think this is a more neutral word than Unstoppable, meaning that it can resist any attempt to make it do what it was not intended to do, that is, it can resist distortion of the original intention.

So in general, Polca is a very resilient, general-purpose, continuous computing provider. The meaning of continuous computing is that it is not that you have a job, you finish it, and the matter is over; what we want to do is a long-term task, even if it is paused in the middle, it can continue to be done. It is a bit similar to the vision of "world computer" mentioned in 2015 and 2016.

So what is Polkadot from this perspective? It's a multi-core computer, and multiple cores can run simultaneously, doing different things. Then we will find that the blockchain running on a core is a parachain, and the parachain runs continuously on a reserved core. Now we use this new paradigm to understand parachains.

What is a "Polca supercomputer"

So let's take a deeper look at this "Poca computer".

"Polkata supercomputers" are multi-core and more powerful than ordinary computers. It has about 50 cores running continuously and in parallel.

According to our prediction model, in a few years, when it has undergone extensive benchmarking and optimization, the number of post-cores can increase to 500-1000.

PERFORMANCE PER "CORE"

Let's take a look at each "core".

These cores are similar to CPU cores. It has many characteristics and attributes, and you can describe it. In essence, it is a thing that does calculations, similar to a CPU core.

• Bandwidth, that is, the total amount of data in and out of this core, is about 1 MB/s.
• The underlying computing power, that is, how much calculation can it do? Around 380 in the case of Geekbench 5.
• Latency, that is, the interval between doing two consecutive jobs, is about 6 seconds.

With the passage of time and the progress of hardware, these indicators will be improved to a certain extent.

In the past, the only way these cores could be useful was through parachains. But in fact, there are other ways to use the core to make it more affordable and accessible to everyone.

Poca needs a more flexible allocation method

What do these mean?

**The kernel is actually very flexible. **Instead of just processing one fixed task forever, it can easily switch what it does, just like a CPU can switch tasks. Since nuclear is flexible, nuclear procurement should also be flexible.

The slot auction model is not flexible enough, it is designed based on Polkadot's original paradigm - a long-running single chain. But then we had parathreads as a supplement, but it was only a small step towards the right paradigm.

And this model sets a high barrier to entry for the Polkadot ecology. If you are like me, you are a person who likes to tinker with various technologies by yourself. Take me as an example. I don’t want to do some fundraising and marketing. I just want to deploy the code and see if it can run . But under the current model, I think we're missing out on a lot of these potential collaborators.

A possible future - a flexible version of Polkadot

Below I will propose a possible future solution, which can be called "flexible Polkadot".

We can abandon the lease period and slot model, but treat Polkadot as some "cores". The time on these cores is now called "Core Time", but it was also called "Block Space" before. These times can be sold regularly, that is, everyone can buy and use nuclear time.

My advice is this. For Polkadot's original nuclear time sale (primary market), it can be divided into two methods: bulk purchase and instant purchase.

Bulk purchases are made once a month, and once purchased, you can use it for 4 weeks.

Just-In-Time Purchasing is a bit like Parathread's pay-as-you-go model, it's Purchasing as You Need. The cost of using Polkadot, to be precise, the cost of using Polkadot's core, will be determined according to market conditions. There may or may not be multiple cores available in the market, that's the way the market is. For instant use, it would be a continuity sale of nuclear time.

In other words, we maximize flexibility and leave the rest to the market.

BULK PURCHASE

Let's take a closer look at how bulk purchasing works. But this is not the final proposal, but a version put forward for discussion.

It is sold every four weeks, and each time it is sold at a fixed price for a core time of four weeks. All will pay the same price.

• Target is to lease out 75% of available core time through bulk purchases.
• The price will fluctuate according to the above ratio.
• Unleased cores go to the immediate market.
• There is special care for old customers who have leased before.

Instant Purchase

Let's talk about instant purchases. Essentially, it is a core that is purchased when needed.

• It adopts the market maker or broker model on the chain, with a prescribed price, and the goal is 100% usage.
• The nuclear time can be taken from the bulk market, divided into small pieces, and then sold in the instant purchase market.
• The total sales revenue obtained from instant purchases will be shared equally by nuclear time providers (including Polkadot itself).

The Essence of Instant Buying

• Procured by the chain through the collector
• Can be used to increase transaction throughput (up to double processing power when you have extra calls)
• Can be used to reduce latency (the chain originally produced a block in 12-18 seconds, after adding an additional core, it can produce a block in 6 seconds)
• Can support new forms such as "nuclear contracts"

The Essence of Bulk Purchasing

• It is a non-homogeneous asset. Cores are originally homogeneous, but when they are divided into many different parts, they become non-homogeneous assets. This kind of non-homogeneous assets can theoretically be displayed by XCM. Brokers can display these core times to other chains, which may want to trade them.
• This broker chain (system chain) can split these four-week periods into many NFTs.
• These slots can be consumed by broker parachains, allowing owners to assign computation to Polkadot's cores.

** How to use bulk purchases **

So what do you do with the time you get?

• They can be assigned to a certain parachain, which is the current situation, but it is not carried out month by month, but one chain exclusively occupies one core.
• It can be assigned to multiple parachains to share and use a core in turn.
• Can be placed on the instant market.
• It can also be divided and sold separately. It may be possible to use NFT XCM through a separate parachain.

Rent Control in Bulk Purchases

So what if you want to lock a core for a long time? Then of course you need to predict the price trend.

I suggest setting such a rule. When allocating a new month's block core time, the broker records the price and who was allocated as a backup. In the next month, this person can buy it with a limit price (a price increase cap will be set).

**What does this mean for existing parachains? **

• **Existing parachain rental appointments remain the same. **Such as you have taken the slot for two years, then will continue. *Pricing for bulk purchases is determined by Governance.
• I personally think that we should start with a relatively low price to lower the threshold for participation.
• For those who have already set up floor price, rent control and priority transfer right to ensure long-term guarantee of price. At present, we only guarantee the use time of two years at most, but theoretically, it can be guaranteed to renew indefinitely.

**In addition, the parallel chain will have a more flexible block time. **

At present, the parallel chains have a fixed block generation time, which is about 12 seconds, and after further optimization, it will be about 6 seconds. In the future, I think the block generation time of the parachain will be more flexible.

Parachains will have a "base speed". For example, a parachain shares a core with one or several other parachains, and a block is generated every 12 or 18 seconds. But if you need higher throughput, you can go to the instant market or buy more core time through OTC on some enterprise chains.

Kernel time can also be compressed (lower latency by sacrificing bandwidth). Compressing multiple parachain blocks into a relay chain core will reduce latency, but will increase some bandwidth costs, because you have to pay for the opening and closing of a block.

Core times can also be combined (by adding additional cores to improve performance and reduce latency). You can engage in two cores at the same time period to obtain two complete parachain blocks. In this way, the block generation time can be reduced from 12 seconds to 6 seconds or even down to 3 seconds.

The meaning of all the above things for the existing parachains is:

• Get more transaction bandwidth when you need it
• Lower cost when you don't need it
• Can become a high-performance multi-core chain
• Can become a chain that runs periodically
• Can become a pure pay-as-you-go chain
• Can become a low-latency chain (for example, one block every 1 second)
• Long-term capital expenditure planning can be carried out

So how can the core be used? Kernel time can be split apart and then reassembled.

Nuclear usage for fools

This picture is the current situation, the idiot's usage of nuclear time. From left to right, time gradually goes backwards. Each row is equivalent to a core on Polkadot. Currently 5 parachains each occupy a core.

But in fact, it doesn't matter which core each chain is assigned to, it doesn't matter. That is, parachains can run on any available core without affecting performance, and these cores do not have a special affinity for a certain chain.

Flexible Usage of Kernel

Flexible core usage is also called exotic scheduling.

You can divide the interval

Zones can be divided, and the owner of the zone can divide the zone and trade. A parachain can run for a period of time, then stop its own transaction processing and let another parachain run.

We see this parachain in light blue and it stops for a while and then continues again. The same goes for the green chain.

** Can span intervals **

Multiple chains can take turns running on a single core to spread the cost. Maybe you take 2/3 of the time, and another chain takes 1/3, such as the light blue and yellow chains in the picture.

The core can be compressed

The same core can process multiple blocks at the same time. Validate multiple blocks on a single core for higher block rates and lower performance latency.

Nuclei can be combined

Gain more computing power using multiple cores, which can be either transient or long-lived.

The same paraID, the same "task", can be assigned to multiple cores at the same time. It can use two cores, thus processing two blocks in this time period. For example, the orange here has a core that is used constantly, but another core that is used intermittently.

Possible future direction: multiple chains share one core

Two to three chains can share the same core at the same time to reduce cost without reducing latency. This is a more speculative usage.

Possible future direction: mix and match the above usage

Theoretically, all the usages mentioned above are composable. If you mix and match them together, you will get an extremely flexible pervasive computing resource.

chain-centric → application-centric

Polkadot 1.0 is a chain-centric paradigm: Allowing isolated chains to send messages to each other, this method is essentially similar to a single chain plus a cross-chain bridge, except that the parallel chains are all connected to the relay chain .

This leads to a fragmented user experience. A user may use an application on one chain, but he also wants to use this application on another chain, that is, use the application in a multi-chain manner.

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

In reality, if we want to take full advantage of Polkadot's potential, applications need to be deployed across chains and seamlessly, at least for users, and ideally for developers .

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

In order to launch Polkadot quickly, we chose to put many of Polkadot's application capabilities on the relay chain. But it's really a trade-off.

The good thing is that we can deliver many functions in a short period of time before the technical foundation is fully completed, such as great pledge, governance, token, identity system.

But it also has a price. If we tie many things to one chain, some problems will arise. For example, the relay chain cannot always use its resources for its own job - ensuring network security and ensuring message delivery. And it induces everyone to form a chain-centric thinking mode.

In the past, we could only focus on one chain and put all the functions of Polkadot on the relay chain when it went online. This is our earliest goal. But unfortunately, the relevant tools have not kept up with the era when applications and users are cross-chain.

** Now, system-level functions are shifting to a paradigm of cross-chain deployment. The system chain is more general, and the relay chain handles less and less stuff**. Apps need to be able to cross these chains without making the user experience difficult.

This is the schematic diagram I just drew half an hour ago, which I think is a better viewing angle to understand "what is Polkadot".

In fact, Polkadot is not the relay chain in the middle, and the parachains surround it, at least for those who come to the Polkadot ecology, this should not be the case. In fact, Polkadot should be an integrated system, a computer running many applications. **

Yes, there is a boundary between the business logic components of different chains (ie parachains), but this may not be as important to users as we think. More importantly, users can do what they want to do, and do it easily, clearly, and quickly.

The dots on the diagram are applications, and the dotted lines separating the dots are "paras". I don't want to say it is a parachain, because that will lure us into the thinking trap of "each parachain corresponds to a core". This is Polkadot's model so far, but it is not the only option.

**The dots should be able to communicate with each other under normal circumstances, and almost as easily as the space within the dotted line. **

XCM

How to do this? That's it for XCM.

XCM is a language, and the transport layer that actually passes messages is called XCMP. I admit that the two names are a bit confusing.

What does XCM do? Its role is to abstract away the common functionality in the chain, and it creates a descriptive language to describe what you want to do or what you want to happen.

As long as the chain translates the message honestly, then all is well. But unfortunately, there is no guarantee that the chain will honestly translate your XCM messages. **XCM is not ideal in a trustless environment. **

For example. In trade, we will say that XCMP, a means of transportation, gives us a safe trade channel, and we will not be robbed in the middle. What is sent can be guaranteed to be received. However, it does not give us a framework for creating binding terms between different trading parties.

To give a more intuitive example - the European Union. What is it? Essentially it's an alliance that you can join, it's a framework of treaties for different sovereign nations to abide by specific treaties. It's not perfect, though, because while there is a common judiciary that can translate each country's laws and ensure it complies with them, it can't stop a country from changing its laws so they don't align with EU requirements.

In Polkadot, we also face a similar problem. XCM is a language for expressing intentions, and WebAssembly expresses the law that parachains must abide by in Polkadot. It can be imagined as the European Court of Justice (ECJ), which ensures that parachains abide by the logic proposed by themselves, but this does not mean that This logic cannot be legally changed by parachains to refuse to comply with the XCM language.

XCM is a language for expressing intentions, such as "I am going to transfer assets", "I am going to vote". Between chains of systems that trust each other, this is not a problem. But if they are between different governance processes, legislative processes, there will be problems. We can do better in the Polkadot ecosystem.

Accord

Here I propose a new term called Accord (agreement). **Agreement is a voluntary treaty across multiple chains. ** Kind of like saying "I voluntarily abide by this one business logic, and nothing I do will change that". The chain itself cannot break the logic of the treaty.

Polkadot guarantees the faithful execution of this logic. Contracts target specific functions. Any chain that joins the agreement must obey the rules, which will be specific to this particular function.

To ensure low barriers to entry, the proposed agreement is permissionless. Because it's voluntary, it doesn't affect anyone until you pass and sign up.

This diagram is not the most precise, but it roughly means this. The outer circle is Polkadot, and there are some small dots inside. We place this graph horizontally. The Accord is then a single mechanism governing its local sovereignty.

Accord is not available on all systems. As far as I know, Polkadot is the only system that can support its existence, because Polkadot is the only system with the same strong security layer, and can also provide specific state transition functions for each shard. These characteristics allow Polkadot to achieve cooperation modes that are impossible in other architectures (such as cross-chain bridges).

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

Some Accord usage scenarios

Let's look at some possible cases for Accord.

One of them is Asset Hub.

At present, if two chains want to interact with assets, they must go through the third chain, the asset hub chain. If one of the chains is the chain of the native asset, it will be slightly different. But in theory, if two unrelated chains want to trade third-party assets, you have to open up an additional path.

With Accord you don't need to do this. You can think of it as an embassy, which exists in the general process space and is scheduled on the same core as the parachain at the same time, but it is not part of the business logic of the parachain, but exists separately. It's a bit like embassies have their own country's laws, but their geographic location is in the local country. Likewise, Accord is like external business logic, but recognized and local.

Another example is the multicast XCM router. It can send a message, but across multiple chains, and in some order. Like doing one operation here, another operation there, but always with my permission. This is currently not possible.

Another example is Decentralized Exchange, which can set up outposts on multiple different chains so that the exchange can happen directly locally without opening a two-way channel.

These are just a few examples that I can think of temporarily, and I believe the potential of this technology will be further developed in the future.

Project CAPI

Briefly talk about the user interface - Project CAPI. Its role is to allow Polkadot applications across multiple chains to have a smooth and well-experienced user interface, even when using light clients.

Hermit Relay

That is, all user-level functions in the relay chain are transferred to the system chain. For example:

• Balance
• Pledge
• Governance and Identity
• Nuclear lease

Finally, let Polkadot's functions span multiple parallel chains, freeing up the space of the relay chain.

Creating a Resilient Application Platform

In the last part, I want to reiterate what we are doing and why. It's all about resilience.

The world is always changing, but if people have clear intentions, it's important for those intentions to be respected. The systems we have today are not resilient, they are built on very old-school ideas.

When your system doesn't have cryptography, game theory, some bad things happen. For example, the large-scale cyber attack mentioned in this news leaked the information of 6 million people, that is, one in a thousand people in the world. And these things happen often.

So how do you create a system that is free from these threats? First of all, of course, is to build a decentralized, cryptography-based system that can stand the test of game theory. But what exactly are we going to do?

Although we preach "decentralization" every day, if everything has to go through the same RPC provider, it is not truly decentralized.

Decentralization needs to be provided by a combination of factors:

• Use of light clients: Smoldot and CAPI will allow high performance light client based UI
• ZK Primitives: Build a feature-rich, high-performance ZK primitive 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 splitting blocks. Improved security and randomness, with high-performance transaction routing. The performance and user experience of the parachain are improved, and encrypted transactions prevent Front-Running, which may bring potential MEV benefits.
• Hybrid Network/Onion Routing: Avoid leaking IP information of transactions. It is a common messaging system between users, chains and OCW.
• Decentralization of people: Introduce many and sufficiently diverse people to participate in the system. Incentivize participation through governance, treasury spending, salaries, grants, etc., and absorb and maintain collective knowledge.

Keep in mind the 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 provides a way to deploy multiple applications in this environment, and allows applications to use each other's functions to improve the user experience. of well-being**. And we want to ensure that this vision can be realized as soon as possible, which is the mission of Polkadot.

**If Polkadot cannot maintain some resilience to changes in the world, then there will be no point in building Polkadot. **These changes could be other means of achieving the same end, or existing threats from outside organizations who hate to trust the world.