On June 28, Polkadot’s annual flagship event, the Polkadot Decoded conference, was held in Copenhagen, Denmark, where Web3 enthusiasts, builders, and investors from around the world discussed the latest developments in the Polkadot ecosystem.
The most surprising part of this conference was probably the attendance of Polkadot founder Gavin Wood as a mysterious guest, who brought some very important opinions.
Gavin shared the future development direction of Polkadot and proposed a new perspective on Polkadot: no longer limited to the original parallel chains and relay chains, but focusing on the lower-level resources required by the blockchain - the computing core (core), and viewing Polkadot as a multi-core computer.
In addition, Polkadot will shift from being chain-centric to being application-centric and strive to build a resilient platform. The following text is compiled by PolkaWorld from Gavin’s speech.
Polkadot 1.0
At this stage, Polkadot can be called Polkadot version 1.0.
At this stage, Polkadot is fully functional, having implemented all the features mentioned in the white paper 7 years ago, and is about to release the Polkadot 1.0 codebase.
So what is Polkadot 1.0? In the original white paper, I wrote that "Polkadot is a scalable heterogeneous multi-chain". That is, it is a blockchain, but it has a unique consensus mechanism "BABE" that can provide security for other blockchains (parachains).
To summarize it artistically, it goes something like this.
The relay chain is in the middle, 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 also needs to ensure the security of the parachains. Moreover, these parachains can communicate with each other.
So what is the product form provided by Polkadot? It is in the form of slots, with a 6-month lease, and the longest slot use period can be obtained in advance for two years, plus the Crowdloan mechanism. But other than that, there is no other way to use Polkadot. The only product in Polkadot 1.0 is the parachain slot.
A new perspective on Polkadot: multi-core computers
This famous quote speaks to the truth that if a person wants to truly understand the world, a change of perspective is crucial, even more important than going into the wider world.
So here we will change our perspective and re-understand what Polkadot is.
The concepts of parachains and relay chains are all good. They are also the way I and many people understood Polkadot in the early days, and they are what we are working hard to build.
But as time went on, we found that what we were doing was actually different from what we had originally envisioned. Sometimes if you are lucky or your team is strong, you may be able to make something better than what you originally wanted.
In computer science, abstraction and generalization are very important. Later we found that the level of abstraction and generalization we made on Polkadot was much higher than we had previously imagined.
So what is this new perspective on Polkadot?
Polkadot is a multi-core computer
First of all, what we are doing is not about the chain, but about the space and the underlying resources required for the chain.
Secondly, Polkadot is a platform for builders to create applications and for users to use applications. It is not a platform for hosting blockchains, per se. Chains happen to be one of the ways that Polkadot becomes useful, but it may not be the only way.
Finally, its 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 something it had no intention of doing, that is, it can resist the distortion of its original intention.
So in general, Polkadot is a very resilient, general, and continuous computing provider. Continuous computing means that it is not that you have a job, you finish it, and the job is over; we want to do long-term tasks, even if you pause in the middle, you can continue to do it. It is a bit similar to the vision of the "world computer" mentioned in 2015 and 2016.
So what is Polkadot from this perspective? It is a multi-core computer, where multiple cores can run at the same time and do different things. Then we will find that the blockchain running on one core is a parachain, and the parachain is running continuously on a reserved core. Now we use this new paradigm to understand the parachain.
What is the “Polkadot Supercomputer” like?
So let’s take a closer look at this “Polkadot computer”.
The Polkadot supercomputer is multi-core and more powerful than a normal computer. It has about 50 cores, running continuously and in parallel.
According to our prediction model, in a few years, after it has undergone extensive benchmarking and optimization, the number of cores can be increased to 500-1000.
Performance per core
Let’s look at each “core”.
These cores are similar to CPU cores. They have many characteristics and properties, and you can describe them. Essentially, they are just something that does computation, much like a CPU core.
Bandwidth, or the total amount of data flowing into and out of the core, is about 1 MB/s.
The underlying computing power, that is, how many calculations can it do? In the case of Geekbench 5, it is about 380.
The delay, that is, the interval between two consecutive tasks, is about 6 seconds.
As time goes by and hardware advances, these indicators will be improved.
In the past, the only way these cores could be used was through parachains, but there are other ways to use cores that make them more accessible to everyone.
Polkadot needs a more flexible distribution method
What does all this mean?
The core is actually very flexible. It is not just able to handle a fixed task forever, it can easily switch what it does, just like a CPU can switch tasks. Since the core is flexible, the procurement of cores 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. Later, we had parallel threads as a supplement, but it was only a small step towards the correct paradigm.
This model sets a high barrier to entry for the Polkadot ecosystem. If you are like me, you are someone who likes to tinker with various technologies. For example, I don’t want to do fundraising or marketing. I just want to deploy the code and see if it works. But under the current model, I think we have missed a lot of potential partners like this.
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 and slot model and think of Polkadot as a number of "cores". The time on these cores is now called "Core Time", but it was previously called "Block Space". This time can be sold regularly, that is, everyone can buy and use core time.
My suggestion is this. For the sale of Polkadot’s native core time (primary market), it can be divided into two methods: bulk purchase and instant purchase.
Bulk purchases are made once a month and each purchase can be used for 4 weeks.
Instant purchases are a bit like the pay-as-you-go model of parathreads, which is on-demand purchases. The cost of using Polkadot, or more precisely, the cost of using Polkadot's cores, will be determined based on market conditions. There may be multiple cores available in the market, or there may not be, the market is like this. For instant use, it will be a continuous sale of core time.
In other words, we maximize flexibility and leave the rest to the market.
What does this mean for existing parachains?
Existing parachain leases will remain the same. For example, if you have already won a two-year slot, it will continue.
Pricing for bulk purchases is determined by governance.
I personally think that we should start from a relatively low price to lower the threshold for participation.
We have set floor prices, rent controls and priority transfer rights to ensure long-term price guarantees. We currently only guarantee a maximum of two years of use, but in theory we can guarantee an indefinite renewal.
In addition, parachains will have more flexible block times.
Currently, the block time of all parachains is fixed, which is about 12 seconds. After further optimization, it will be about 6 seconds. In the future, I think the block time of parachains will be more flexible.
Parachains will have a "base speed". For example, a parachain shares a core with one or several other parachains, producing a block every 12 or 18 seconds. But if higher throughput is needed, more core time can be purchased in the instant market or through OTC on some enterprise chains.
Core time can also be compressed (lowering latency by sacrificing bandwidth). Compression of multiple parachain blocks into a single relay chain core will reduce latency, but will increase some bandwidth costs because you have to pay for the start and end of a block.
Core times can also be combined (adding extra cores to increase performance and reduce latency). You can use two cores in the same time slot to get two complete parachain blocks. This can reduce the block time from 12 seconds to 6 seconds or even 3 seconds.
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 plus a cross-chain bridge, except that all parallel chains are 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 the application on another chain, that is, using a multi-chain approach to use the application.
But if we have a chain-centric paradigm, then we also have a chain-centric user experience. If an application is not chain-centric, then everything becomes difficult. In reality, if we want to fully utilize Polkadot’s potential, then applications need to be deployed across chains, and they need to be seamless, at least for users, and ideally for developers as well.
Here’s an artistic illustration of what Polkadot looks like:
Now, system-level functions are moving to a cross-chain deployment paradigm. System chains are more common, and relay chains handle fewer and fewer things. Applications need to be able to cross these chains without making the user experience difficult.
This is a diagram I just drew half an hour ago, and I think this is a better perspective to understand "what Polkadot is".
Polkadot is not actually a relay chain in the middle with parachains surrounding it, at least it shouldn’t be like this for people who come to the Polkadot ecosystem. In fact, Polkadot should be an integrated system, a computer that runs 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 is more important is that 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 that separate the dots are “paras”. I don’t want to call them parallel chains, because that would tempt us into the thinking trap of “each parallel chain corresponds to a core”. This is the model that Polkadot has adopted 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 they can communicate in the space within the dotted line.
XCM
How do we do this? This is where XCM comes in. XCM is a language, and the transport layer that actually delivers messages is called XCMP. I admit that these two names are a bit confusing.
What does XCM do? It abstracts the common functions in the chain, and it creates a descriptive language to describe what you want to do or what you want to happen.
In Polkadot, we face a similar problem. XCM is a language that expresses intent, and WebAssembly is a language that expresses the laws that parachains must follow in Polkadot. Think of it as the European Court of Justice (ECJ), which ensures that parachains follow the logic they propose, 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" and "I am going to vote". This is not a problem between mutually trusted system chains. But if they are between different governance processes and legislative procedures, there will be problems. We can do better in the Polkadot ecosystem.
Accord
Here I propose a new term called Accord. An Accord is a voluntary treaty across multiple chains. It's a bit like saying "I voluntarily abide by this 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. The agreement will target a specific function. Any chain that joins the agreement must abide by the rules, which will target this specific function. In order to ensure a low barrier to entry, proposing an agreement is permissionless. Because it is voluntary to join, it will not affect anyone before it is approved and registered.
This diagram is not the most accurate, but it roughly means this. The outer circle is Polkadot, and there are some small dots inside. We put this diagram horizontally. Then Accord is a separate mechanism that governs its local sovereignty.
Accord is not available in all systems. As far as I know, Polkadot is the only system that can support it because Polkadot is the only system with the same level of security layer and can provide specific state transition functions for each shard. These features allow Polkadot to achieve cooperation models 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.
Project CAPI
A quick word about the user interface — Project CAPI. Its purpose is to allow Polkadot applications across multiple chains to have a smooth, user-friendly interface, even when using a light client.
Hermit Relay
That is to transfer all user-level functions in the relay chain to the system chain. For example: balance, pledge, governance and identity, core leasing. Ultimately, Polkadot's functions will span multiple parallel chains, freeing up space on the relay chain.
Building a resilient application platform
In the last section, I want to reiterate what we are doing and why we are doing it. It's all about resilience. The world is always changing, but if people have clear intentions, it's important that these intentions are respected. The systems we have now are not resilient enough, they are built on very old-fashioned ideas.
So how do we build a system that is not vulnerable to these threats? The first step is of course to build a decentralized system based on cryptography that can withstand the test of game theory. But what exactly should we do?
Although we are promoting "decentralization" every day, if everything has to go through the same RPC provider, it is not truly decentralized. Decentralization needs to be provided by multiple factors:
- Use of light clients: Smoldot and CAPI will allow high-performance light-client based UIs.
- ZK Primitives: Build a feature-rich, high-performance library of ZK primitives. The first library is almost complete and will provide privacy protection for on-chain collectives (including Fellowship).
- Sassafras consensus: A new consensus algorithm with no forked blocks. Improved security and randomness, with high-performance transaction routing. Improved performance and user experience of parachains, encrypted transactions prevent front-running, and may bring potential MEV benefits.
- Mixed network/onion routing: avoid leaking IP information of transactions. It is a universal messaging system between users, chains and OCW.
- Decentralization of people: Introduce a large number of diverse people into the system. Encourage participation through governance, treasury expenditures, wages, subsidies, etc., and absorb and maintain collective knowledge.
Finally, I want to reiterate our original intention. Polkadot does not exist to create a specific application, but to provide a platform, a way to deploy multiple applications in this environment, and allow applications to utilize each other's functions to improve the welfare of the majority of users. And we want to ensure that this vision can be realized as soon as possible. This is the mission of Polkadot.
There would be no point in building Polkadot if it could not maintain a certain level of resilience to changes in the world, whether in the form of other ways to achieve the same ends, or in the form of existing threats from external organizations that abhor the trustless world.