This paper finishing from October 14 Boca co-founder Robert Habermeier in “Sub0 Online 2021” Substrate Developers Conference presentation on parallel chains.
I actually want to talk about today is the parallel chains , including: how to achieve, what stage to present, and future plans.
I Polkadot one of the founders from 2016 and began doing Polkadot Gav together, the main programmer and team leader I am also a parallel chain code base and implementation. So the content I shared today is from the front line.
Parachain V1 development circuit diagram
First, 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 to build Substrate, BABE and GRANDPA consensus algorithms, lib p2p. In fact, the development of parachain requires many basic components to be completed in advance. So we published the first draft of the “Implementer’s Guide” in May . This guide is actually a huge implementation document. It describes our motivation and our thoughts when writing such a large amount of code. Because when you dive into a large software development project, you really need to think about how all the parts are put together. These parts will not blend together naturally. You cannot write this piece today and that piece tomorrow. You need to think about how to put each piece in the right place. So, if you want to do something, just like what we are doing-online parachain, then something like the “Implementer’s Guide” is very important, it can ensure that the code can withstand scrutiny , It is a basic infrastructure component.
So the “Realizer’s Guide” was published in May 2020, at which time we solemnly began to build. One thing it does is divide the parachain code into four main parts:
1. Support and availability : The validator finds the block from the collector, and then says that I think the block is good, include it on the chain, and then ensure that the data needed to check the block exists.
2. Approval check: A large part of the security comes from here. It is a way. Once the parachain block is on the chain, the validator randomly selects itself in a safe way. This way will check whether They should restore the data and then check the blocks themselves.
3. Dispute handling: that is, if a validator detects that something is malicious, then it needs to contact other validators so that they can participate and check. The probability of this occurrence is extremely low, for example, the probability is about 20 decimal points. No one finds that this block is malicious during the approval check stage, and the situation will escalate rapidly at this time. So these components are actually interlocking to ensure the safety and scalability of the parachain. If you attack this chain, the probability that you won’t lose millions of dollars is only one in ten trillion, and it is the same every time you attack.
4. Audit: In the past few months, we hired SR Labs to do code audits, to check implementations, and to try to find bugs. They conducted independent reviews and checked different parts of the parachain. Now we also ask them to do some other part of the code audit. They raised a few bugs, not too many, we have fixed about 50% of them, and there are solutions for the rest.
This leads to the concept of technical agility, that is, after audits and major deployments on Rococo and Kusama , Parachain is ready to release the initial product version. It should be noted that we need to fix significant audit issues and arrange for Complete before 12 months. Deployment in a real environment is also very important. We have a Rococo test network, which is a multi-regional 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 technology performs in the case of hundreds of nodes.
We will also see real environment testing on Kusama, because you never know what will actually happen before entering the real environment. We can try to be as decentralized as possible on Rococo, but you don’t actually know what the real situation will be until you enter the real world. There are 900 validators on Kusama, which are distributed all over the world. You don’t know who is running these nodes. They just run a program on a computer they bought or rented.
Agile vs mature
So, what does it mean to be agile compared to maturity?
Agile means that it can be used, but it has not yet reached its final form. The functions of the code are complete, and all the functions that should be provided. It has also been tested with high standards, tested in various edge situations, and it is well integrated with various modules. There are also security professional organizations that have conducted independent reviews, and we have also simulated possible attacks to see if the system is reliable. In fact, if you look at the Rococo testnet now, you will find that hostile nodes are trying to destroy the network, but they are unsuccessful. However, if something is agile, it may still have bugs and may require major optimization.
The opposite is mature code. When something has evolved to a stage, after several years of use, it is already a basic, heavy-load, and highly reliable infrastructure. Would say it is mature. So there are many optimizations that can be done, and it has been tested in actual combat. For example, Ethernet Square in 2016, Shanghai experienced the attack, when we really worked hard to try to destroy Square Ethernet network. When something in the real world proves to withstand an economic attack, this is a big step towards maturity.
The code is stable, and it is more about maintaining the code than developing the code. This means that there is not so much innovation at this time, because its infrastructure and growth are more of edge innovation.
Road to maturity
So, what is our path to maturity? What are some steps along this path? I will introduce some of the main steps.
I think some of the very important upcoming things are contextual execution, parallel threads, and general network optimization. So I will talk about these three things in depth.
If you have observed Kusama or Rococo networks, you will see that there is a block every 12 seconds. This is not a limitation of the agreement, but a limitation of the implementation. So the context execution is to accelerate the block generation from 12 seconds to 6 seconds. In our current short block execution time on Rococo and Kusama, only a small amount of time is actually used for block execution.
The idea of contextual execution is to significantly increase block execution time. It is basically about preparing blocks in advance, a bit like building a parallel chain further off the chain, and then slowly putting these things on the main relay chain. Instead of constructing these blocks when the parachain blocks are about to be included in the relay chain. This is the optimization plan that we have developed, we have developed a design for it, and it is one of the next priorities.
Another interesting thing about to happen is parallel threads , which are dynamic scheduling of parachain slots based on block after block. What does it mean? At present, parachains have dedicated execution time. These times are purchased through auctions. It may be 6 months, 12 months, or 24 months that are exclusively for me. I can execute one whenever I want to use the system. Block. Parallel threads are more like a pay-as-you-go model. It is very similar to parachains. In fact, the code is not particularly different. It actually only affects what we call the support and collection phase. For some of the stages I mentioned before, such as availability, approval checks, and disputes, parallel threads and parachains are exactly the same.
Network optimization is a relatively large part. This is a peer-to-peer network, as Gav mentioned in the previous talk, peer-to-peer network is a challenge, it is very difficult, because in the client-server model, you have to mark some servers, you can quickly reply. But when you are doing a peer-to-peer network, the challenge is to distribute data as efficiently and quickly as possible, with low redundancy and high delivery guarantees. In fact, it is difficult to do this. I think there are a lot of results that are about to be achieved in network optimization, which will greatly improve the performance of the implementation.
So I think these are some points that parachains can pay attention to in the near future.
Next, I want to talk about the Rococo testnet, including what it means to the community and how everyone can participate.
I mentioned earlier that Parity is running all Rococo nodes. Its role is mainly focused on internal testing . We will run cutting-edge code, quickly modify, and deploy adversarial nodes. But this does mean that when we find errors in the development process, we occasionally break this chain, which makes this chain a very difficult deployment for teams who want to deploy their own parachain on it. environment. Substrate developers need a place to deploy and test cross-chain solutions. With the current version of XCM becoming more stable and everyone can really use those cross-chain innovations, then a test environment becomes very important.
So here I am going to introduce to you the Rococo transformation plan .
Our idea is that Parity will maintain backward compatibility on the Rococo testnet to ensure that it will not restart. So when you register for parachains, you don’t need to update your node or runtime like in Kusama and Westend. This means you can plan to use Rococo for a longer period of time and really use it as a team with other teams. Place of cooperation.
Another point is the automatic parachain slot . We built a scheduler to allocate time on Rococo to the teams registered to use it so that they can get slots of one week in length. These slots are automatically and fairly allocated to the team based on availability. However, we will especially prioritize teams that have deployed the chain on the real-time network, and will also prioritize teams that have joined the Substrate Builder Program.
Of course we will also pay great attention to the community . 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, for example, we want to see the user interface or decentralization Application developers can use multiple parachains and enjoy creating in this testnet. It’s not just the low-level developers who are super hardcore.
I have listed a timetable here to illustrate what some Rococo transformation plans look like.
Today I announced that we intend to transform Rococo, and we will soon publish a longer blog post to describe it in detail.
Then there will be technical follow-up, including formulating new chain specifications and formulating some parameters, such as how long the session is, how often the validator is replaced, etc. We will automate these.
The last is to move towards the final restart of Rococo, we will no longer use this chain for internal testing. The goal is to complete this step by the end of November.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/robert-co-founder-of-polkadot-the-future-planning-of-parachain-and-the-reconstruction-of-rococo-2/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.