Gavin Wood: Four advantages of parallel chains

Gavin Wood: Four advantages of parallel chains -- Uninterruptible, Upgradable, Unlimited, and No Fees

Writing: PolkaWorld

At the Sub0 Onpne conference on 13 October, Boca founder Dr. Gavin Wood delivered a keynote address to update the developer community on the development of parallel chains and other features, the advantages of parallel chains and Substrate, and how Polkadot will respond to regulation. Below is PolkaWorld's translation and summary of the speech.

Hi, I'm going to talk about three things very quickly today.

First, I'll reiterate what Substrate is, and the advantages of the parallel chains it supports.

Then, I'll keep abreast of some Substrate related projects Parity is developing.

Finally, I will talk about some of the latest industry events and their relationship to Polkadot and Substrate.

Substrate changes

First, the role of Substrate and parallel chain models.

Substrate based parallel chains have four characteristics -- uninterruptible, upgradable, unconstrained, and fee-free, and I'll go through each of them a little bit to give you a clear idea of why we're doing this.

Unable to interrupt

The crucial thing about Substrate based parallel chains, or any Substrate based chain, is that they're really decentralized. In contrast, some other blockchain projects are not completely decentralized, they may be designed to be a little bit.

At Substrate, we really pursue point-to-point, decentralization, which keeps the chain going. For example, it is very easy to be a verifier on a Substrate chain when all the data is stored on the whole node, and a lot of effort has been put into ensuring the availability, efficiency and high performance of light nodes. So we're trying to be scalable, but we're also trying to be decentralized, and we're not going to compromise the degree of decentralization in exchange for scalability.

scalability

The second point is upgradability. While this may be a familiar point for many of you, it's worth emphasizing again. It is an important slogan and core spirit of Substrate and Polkadot. Substrate chain and Polkadot created by Substrate are both Meta Protocal. So it allows us to upgrade, update and incorporate new technologies efficiently.

These two pictures can be illustrated graphically. We saw some of the chains kind of floundering through the mud, and we were kind of kite-surfing.

unlimited

A major difference between Substrate/ parallel chain model and smart contract model is that Substrate chain is unconstrained. This is a question I get asked a lot, and if you're a team that wants to be a parallel chain, you might want to ask the same question, so I'll make it clear.

The Substrate/ Parallel chain model is a "free-execution model", which means that you lease a certain amount of distributed CPU over a period of time. This model is fundamentally different from the smart contract model, which is a transaction execution model, where users can pay to have your code executed for them.

As a free-execution model, it ensures that you are scheduled within a time interval and at regular intervals, such as every 6 seconds for Polkadot parallel chains. This model gives you a lot of freedom to decide how your application should work and implement it according to your needs. Importantly, you are in charge of which trades are executed, rather than being in charge of which trades are executed, as in the smart contract model. If for some reason you or your users can't make a transaction, then it's hard for your app to grow, and that makes a huge difference in what your app can do.

Here are some of the benefits of the free-execution model: on-chain scheduling, transaction prioritization, and so on. In short, some things that are not supported on ethereum-based smart contract platforms, such as Runtime upgrades, on_initiapze, on_finapze, etc., are easily available in Substrate.

No fees

The last feature is no handling fee. I don't mean that literally, because obviously there are a lot of Substrate chains that have fees. There are two meanings of no handling fee here:

The first is that with Substrate based parallel chains, as long as you get a parallel chain slot, then you don't have to expose your users to DOT/KSM or even any token. Of course, many teams will have their own tokens, and they will want to use them on their own chains to charge users fees, which is fine. But it's entirely up to your chain, and in theory, you don't have to force your users to use any transaction fees.

You can limit user transactions to a certain number, or within a certain range, and you don't need to introduce tokens at all. For example, you could authenticate a user, check through a predictor that the user has enough personal characteristics to prove that they are not capable of a DDoS attack, and there are many ways to do that. This opens up the possibility that let no formalities of application can run in parallel to the chain, and the progress of this is a very interesting, because I think it would open a door to attract the public's, and at present we can only attract those who don't mind have a token, or someone who has the token, I think that to go to mass is a kind of obstacles.

Report technical progress in all aspects

Next, some developments related to Substrate and Polkadot are reported.

The bridge

The first is the bridge, which allows the Substrate Chain team to connect their Solo Chains if, for some reason, they don't want to be parallel Chains, they're still independent Chains. Standalone chains will have less security and will be slightly delayed, but will gain connectivity to the relay chain. The bridge is also a very important component of some of the things we want to do next year.

So what's going on with the bridge is that the code audit for the bridge is going to be done in about two weeks, and this is actually the second audit, so it's mostly minor adjustments. - soon a bridge will be deployed from Rococo to Wococo to test the feasibility. By the end of this year, we hope to be able to deploy the relay chain-to-relay bridge between Polkadot and Kusama, assuming of course that the remaining two weeks of the audit do not reveal too many major issues. Parallel chain to parallel chain Bridges are expected to be deployed early next year.

XCM

XCM V2 has been delivered as part of Polkadot 0.9.11, which contains most of the features we need to work on.

Asynchronous error handlers, which means you can have on-chain code running in case something goes wrong on the remote chain, and this is implemented in a nice way, all with Dispatchables and status reports, which allow the status of some XCM instructions to be reported back to other chains. Whereas other chains might want to register this state with a code handler.

Asset capture is essentially remembering the contents of the hold register at the end of an XCM message. Many times, either by mistake or simply by accident, some assets are left in the hold register with a message that is not ready at the end of the message execution. This feature allows the content to be remembered so it can be retrieved later.

XCM now has Exeption Handpng in its language model, currently we are using a virtual machine model which I think is easier to understand and more extensible than before. There is also version management, which allows different versions of XCM to coexist in a multi-linked network. The specification for V2 has been written.

Parallel to the chain

So this is where parallel chains are going, and I know a lot of people in the audience today are concerned about this.

The parallel chain code is now functional, that is, all the security mechanisms in the Polkadot specification have been implemented, tested, and audited. Yes, the audit has been completed, and half of the revision suggestions proposed in the audit should be completed before November. And we do look forward to completing the initial deployment of these features and adding security code to Kusama soon. We'll allow three weeks before we actually put the code into production, but we don't think there will be any major issues with the code. So, from this, you can calculate the timeline for the Polkadot parallel chain to come online.

Our view

Our own assessment of the status of the code is that the parallel chain will be technically available by December, and we can expect to deploy to Kusama by the end of October. Therefore, from a technical point of view, Polkadot can now start to prepare the Auction of Lease 6 to Lease 13.

We also believe that Polkadot should have at most 75% of the number of parallel chains in Kusama, Polkadot's canary network, so at least until the code matures. Until we understand the number of parallel chains, transaction throughput, message throughput that the current architecture can handle.

We thought it would make sense to take a shorter auction cycle during the initial parallel chain expansion period, so we'll stick with the cycle we announced earlier, which is about two weeks per auction.

future

Looking ahead, I'd like to talk a little bit about some of the recent developments and trends in the industry, and how they're going to affect Substrate, and what changes you might see in the next year or so.

One thing I've noticed is that in the pursuit of high transaction throughput, quite a few chains ignore the fact that decentralization and security are not optional features, although you can have higher transaction throughput if you sacrifice the decentralization of your network.

There are many reasons why it took so long to upgrade ETH 2.0. One of the reasons is that they, like us, didn't want to sacrifice the degree of decentralization of the network. If you're not willing to do that, then the architecture, design, and especially security aspects of the network need to be more thoughtful. So when you see networks that claim to be public chains with high TPS, a lot of the time it's no longer a like-for-like comparison between those chains and some truly decentralized networks.

If we look at the current state of regulation, we will find some points. I've mentioned this in previous reports, and while I'm not an expert on the subject, I'm certainly not a lawyer, HERE's my take on some of the policy documents. If we look at the FATF, which is an international entity, I think it's the equivalent of the G20, they have a fairly clear policy.

The good news is that software development and running and maintaining networks is blameless and should be allowed to continue without regulatory restrictions, because that's what we developers do for a living, and if people want to deploy these kinds of peer-to-peer networks, it's important that these activities be free and unfettered.

However, it is clear that regulators around the world are taking a very hard look at some of the other activities that I think are involved in most peer-to-peer networks and decentralized projects, some of which rely heavily on these activities. One is service provision, such as RPC, wallet and App website. The second type is multi-signature, like the DAO, or you have several designated people who can spend money from the DAO vault, which is also the case in Polkadot and Kusama. There is also hosting. Hosted wallets and non-peer-to-peer staboins fall into this category. The last category is what I call convenience features, such as some wallets/apps, which make decentralized apps easier to use by means of centralization, but this is a category that seems to have been regulated late in my observation.

Service is the most interesting, because obviously a point-to-point network, such as Ethernet, remains highly dependent on centralized RPC service, sometimes also will use centralized wallet and website hosting decentralized application, by observing the regulators of language, I think it's a piece should be classified into the scope of regulation in the near future.

But one thing I think is certain: The more centralized you are, the greater the chance that regulators will look at you and demand a permit; The more peer-to-peer and decentralized you are, the less likely that is, so moving in a peer-to-peer direction seems like a logical choice.

The other thing THAT struck me when I read these documents was that it seemed that less peer-to-peer, more neutral encryption projects would require a license, which I thought would be similar to the standard of banking regulations. If that is the case, then most encryption programs may not survive in their current form in a year or two. I think regulation will probably come into force in two or three years, but it's always good to be prepared. Especially if the technology you need to reduce risk is difficult to implement.

At Parity, we're committed to making everything peer-to-peer, and we want to make sure that our technology falls into the category where we don't need regulation. This means that we have a lot to focus on, especially in areas where decentralization is not done enough. For example, Boot nodes, RPC nodes have a centralized component, and we will shift it to light clients, browser-like clients. On the governance side, we will make sure that we adopt a chain up centralized governance approach and do not violate any regulatory provisions. There are privacy mechanisms, such as Mixnet.

One thing I want to emphasize is that Substrate based solutions should be true Web3.0 solutions that are truly point-to-point. Similarly, with Polkadot, we will make it the first point-to-point, secure, scalable platform for free execution.

That's all I have to say. Thank you for listening.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia