The co-founder of Polkadot talks about the implementation process of the parachain, the development process and future plans

Original title: "Robert: Future Planning of Parachain and Rococo Reconstruction"

Original Author: Robert Habermeier, co-founder of Polkadot

Original compilation: PolkaWorld

Today I actually want to talk about parachains, including: how to realize it, what stage it is now, and what plans are there for the future.

I am one of the founders of Polkadot, and I have been working with Gav since 2016 Polkadot, I am also the lead programmer and team lead of the parachain code base and implementation. So what I share today is from the front line.

Parachain V1 Development Line Figure

First of all, let’s take a look at the timeline and see how the parachain has developed to today .

At the beginning of Polkadot's development cycle, we spent a lot of time building Substrate, BABE and GRANDPA consensus algorithms, and lib p2p. In fact, the development of the parachain needs to complete many basic components in advance. So we published the first draft of the Implementers Guide in May, which is actually a huge implementation document that describes our motivations, our thoughts when writing such a large amount of code.

Because when you get down to a big software development project, you really need to think about how all the pieces fit together. These parts don't fit together naturally, you can't write one piece today and another piece tomorrow, you need to think about how to put each piece in the correct position. So, if you're going to do something like we're doing - launch a parachain, then something like an Implementers Guide is critical to make sure the code is credible , which is a basic infrastructure component.

So the Implementers Guide was published in May 2020, so we Seriously start building. One of the things it does is divide the parachain code into four main parts:

1. Support and Availability: The validator finds the block from the collator, then says I think this block is good, includes it on the chain, and then ensures that the data required to check the block exists .

2. Approval Check: A large part of security is Coming from here, it's a way that once the parachain blocks are on-chain, the validators self-select at random in a secure way that checks whether they should recover the data, and then checks the blocks themselves.

3. Dispute handling: that is, if a verifier detects When something is malicious, it needs to contact other validators so they can participate and check. The probability of this happening is extremely low, such as around 20 decimal points, and no one finds out that the block is malicious during the approval check phase, and the situation will escalate rapidly. Therefore, these components are actually interlocking to ensure the security and scalability of the parachain. The chance that you won't lose millions of dollars if you attack the chain is one in ten trillion, and it's the same every time you attack.

4. Audit: In the past few months, We hired SR Labs to do a code audit, to check the implementation, to try to find bugs. They conduct independent reviews, examining different parts of the parachain. Now we also ask them to audit some other parts of the code. They raised a few bugs, not too many, we have fixed about 50% so far, and have solutions for the rest.

This leads to the concept of technical agility, which is auditing on Rococo and Kusama And after the major deployment, the parachain is ready for the initial product release, and it should be noted that we have to fix the significant audit issue, which is scheduled to be completed by December. Deployment in a real environment is also very important. We have a Rococo test network, which is a multi-region test network. Parity runs all its nodes. This network has no economic value, so it is only used to test whether the technology is feasible. We can see how this technique performs with a few hundred nodes.

We will also see the real environment test on Kusama, because after entering the real environment Before, you never knew what was actually going to happen. We can try to decentralize as much as possible on Rococo, but until you enter the real world, you really don't know what the real situation will be. There are 900 validators on Kusama, distributed all over the world. You don’t even know who is running these nodes. They just run a program on the computer they bought or rented.

Agile vs Maturity

Agile vs Mature

So what does it mean to be agile versus mature?

Agile means that it works, but it still did not reach its final form. The functions of the code are complete, and all the functions should be available. It has also been tested to a high standard, tested in various edge cases, and integrates well with various modules. There are also independent reviews by security professionals, and we simulate possible attacks to see if the system is reliable. In fact, if you look at the Rococo testnet now, you will find that there are hostile nodes trying to disrupt the network, but without success. However, if something is agile, it may still have bugs and may need major optimization.

The opposite is the mature type of code, when a Things have evolved to a stage where, after several years of use, it is already a basic, heavily loaded, and highly reliable infrastructure, and we would say it is mature. So there are many optimizations that can be done, and it has been tested in actual combat. For example, the Shanghai attack that Ethereum experienced in 2016, when everyone was really trying to destroy the Ethereum network. When something in the real world is proven to withstand economic attack, it's a big step toward maturity.

The code is stable, it's more about maintaining the code than developing it. This means that there is not so much innovation at this point, because its infrastructure and growth are more fringe innovations.

The road to maturity< /h3>

So, what is our path to maturity? What are some steps along this path? I will describe some main steps.

Some of the upcoming things that I think are very important are context execution, parallel threads and General network optimization. So I'm going to talk about those three things in depth.

If you watch the Kusama or Rococo networks, you'll see that a block is included every 12 seconds. This is not a limitation of the protocol, but an implementation limitation. So the context execution is to speed up the block generation from 12 seconds to 6 seconds. In our current very short block execution time on Rococo and Kusama, very little time is actually used for block execution.

The idea of contextual execution is to significantly increase block execution time, it's basically about preparing in advance Blocks are a bit like further building parallel chains off the chain, and then slowly putting these things on the main relay chain. Instead of building parachain blocks when they are about to be included in the relay chain. It's an optimization that we've worked out, we've got a design for it, and it's one of the next priorities.

Another interesting thing that is about to happen is parathreading, which is built on a block Dynamic scheduling of parachain slots on a block-by-block basis. What does it mean? At present, the parallel chain has a dedicated execution time. These time are purchased through auctions. It may be 6 months, 12 months or 24 months. I can execute a time whenever I want to use the system. blocks. Whereas parathreads are more of a pay-as-you-go model, which is very similar to parachains, the code is actually not particularly different, it really only affects what we call the support and collection phase. For some of the stages I mentioned earlier, like availability, approval checks, and disputes, parathreads and parachains are exactly the same.

Network optimization is a relatively large part. This is peer-to-peer networking, and as Gav mentioned in his previous talk, peer-to-peer networking is a challenge, it's very difficult because in the client-server model, you have to tag some servers, and you can reply quickly. But when you're doing peer-to-peer networking, the challenge is to distribute data as efficiently and quickly as possible, with low redundancy and high delivery guarantees, and it's really hard to do that. I think there's a lot to come in terms of network optimizations that will greatly improve the performance of the implementation.

So I think these are some points that the parachain side can pay attention to in the near future.

Refactoring Rococo

h3>

Next I want to talk about the Rococo testnet, including what it means to the community and what you can do Get involved.

Before I mentioned that Parity is running All Rococo nodes, its role is mainly focused on internal testing, we will run cutting-edge code, quickly modify, deploy adversarial nodes and the like. But it does mean that when we find bugs during development, we occasionally break the chain, which makes it a very difficult deployment for teams that want to deploy their own parachains on it environment.

Substrate developers need a place to deploy and test cross-chain solutions. As the current version of XCM becomes more stable, everyone can really use those cross-chain innovations, so a testing environment becomes very important.

So here I would like to introduce you to the Rococo renovation plan

b>.

The idea is that Parity will maintain backwards compatibility on the Rococo testnet to ensure it doesn't reboot. So when you register a parachain, you don't have to update your node or runtime like in Kusama and Westend, which means you can plan to use Rococo for a longer period of time and really use it as a link with other teams place for collaboration.

Another point is the Automatic Parachain Slot. We built a scheduler that allocates time on Rococo to teams that sign up to use it so they get a week-long slot. These slots are automatically and fairly allocated to teams based on availability. However, we will give special preference to teams that have deployed chains on the live network, and will also give priority to teams that have joined the Substrate Builder Program.

Of course we will also be very community-focused. We encourage cross-chain communication and experimentation on Rococo, especially at a higher level, not only deploying parachains, but also deploying things on top of parachains, such as we hope to see the user interface or decentralization Application developers, can take advantage of multiple parachains and enjoy creating in this testnet. It's not just those super hard-core developers who are particularly low-level.

Here I put a timeline of what the plans for some Rococo revamps look like of.

Today I announced our intention to revamp Rococo, which we will soon describe in a longer blog post.

Then there is technical follow-up, including the formulation of new chain specifications and some parameters, For example, how long is the session, how often to replace the validator, etc., we will automate these.

Finally, towards the final restart of Rococo, we will no longer use this chain tested internally. The goal is to complete this step by the end of November.

The above is my speech, thank you!

Original link

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