In Sub0 Online General Assembly on October 13, Boca founder Dr. Gavin Wood a keynote speech, and the developer community synchronize the progress of the development of parallel chains and other functions, parallel chains and Substrate advantage, Polkadot how to deal with supervision . The following are articles translated and summarized by PolkaWorld based on the content of the speech.
Hello everyone, today I will quickly talk about three things.
First of all, I will reiterate what Substrate is and the advantages of the parachain it supports.
Then, I will synchronize the progress of some Substrate-related projects that Parity is developing.
Finally, I will talk about some of the latest industry current events and their relationship with Polkadot and Substrate.
Changes brought by Substrate
First, let’s talk about the role of Substrate and the parachain model.
Parachains based on Substrate have the following four characteristics-uninterruptible, upgradeable, unlimited, and no handling fees. I will expand on each point a bit to let everyone clearly understand why we want to do this.
Cannot be interrupted
Parallel chains based on Substrate, or any chain based on Substrate, the most important thing is that they are truly decentralized. In contrast, some other blockchain projects are not completely decentralized, they may be designed to be a little bit decentralized.
At Substrate, we truly pursue peer-to-peer and decentralization, which makes the chain uninterruptible. For example, a full node saves all data, and it is easy to become a validator on a Substrate chain. We have also invested a lot of energy to ensure the availability, efficiency and high performance of light nodes. Therefore, we are working hard to achieve scalability while ensuring decentralization. We will not compromise on the degree of decentralization in exchange for scalability.
The second point is scalability. Although many of you may be familiar with this point, it is necessary to emphasize it again. It is the important slogan and core spirit of Substrate and Polkadot. The Substrate chain and the Polkadot created based on Substrate are both meta protocols (Meta Protocal). So it allows us to efficiently upgrade, update and absorb new technologies.
These two pictures can be displayed vividly. We saw some chains as if they were struggling in the mud, and we were like kitesurfing.
One big difference between the Substrate/parachain model and the smart contract model is that the Substrate chain is unlimited. I often get asked this question. If you are a team that wants to be a parachain, you may also want to ask this question, so I will make it clear.
The Substrate/ Parachain model is a “free execution model”, which means that you rent a certain amount of distributed CPU for a whole period of time. This model is essentially different from the smart contract model. The smart contract model is a transaction execution model, that is, users can pay to let your code execute for them.
As a free execution model, it will ensure that you are scheduled in the time interval, and ensure that you are scheduled once at a regular interval, such as every 6 seconds for the Polkadot parachain. This model gives you a lot of freedom, you can decide how your application should work, and implement it according to your needs. It is very important that you have the final say on which transactions are executed, not the transaction as in the smart contract model. If for some reason, you or your users cannot make a transaction, it will be difficult for your app to grow, which makes a huge difference in what the app can do.
Here are the benefits that the free execution model can bring to you: on-chain scheduling, transaction priority sorting, and so on. In simple terms, runtime upgrade, on_initialize, on_finalize and some in Ethernet Square does not support the type of contract intelligent platform thing, you can easily get in Substrate years.
No handling fee
The last feature is no handling fees. This does not mean it literally, because obviously many Substrate chains have fees. The no fee here has two meanings:
The first is for Substrate-based parachains. As long as you get a parachain slot, then you don’t need to let your users contact DOT/KSM or even any kind of token. Of course, many teams will have their own tokens, and they will want to use these tokens on their own chains to charge users a fee. This is fine. But it all depends on your chain’s decision. In theory, you don’t need to force your users to use any transaction fees.
You can limit user transactions to a certain number or within a certain range, and there is no need to introduce tokens at all. For example, you can issue authentication to users, and use an oracle to check that users have sufficient personal attributes to prove that they cannot carry out DDoS attacks. There are many ways to do similar checks. This opens up a possibility for non-procedural applications to run on parachains, and this is a very interesting progress, because I think it will open a door to attract the public, and currently we can only attract those who do not Mind those who have a token, or who already have a token, I think this is a hindrance to the masses.
Technical progress report on all aspects
Next is a report on some development progress related to Substrate and Polkadot.
The first is the bridge, which allows the Substrate chain team to connect their own independent chains (Solo Chains). If for some reason, they do not want to become parachains, or are in the state of independent chains. The independent chain will have fewer security guarantees and will be slightly delayed, but it can gain connectivity with the relay chain. The bridge is also a very important component of something we want to do next year.
Then the progress of the bridge is that the code audit of the bridge is about two weeks away. This is actually the second audit, so it is mainly some minor adjustments. A bridge will be deployed soon, from the test network Rococo to the bridge test network Wococo, to test the feasibility. Before this year, we also hope to deploy a relay chain-to-relay chain bridge, that is, the bridge between Polkadot and Kusama. Of course, the premise is that there are not too many major problems found in the remaining two weeks of audit work. The bridge between parachains and parachains is hoped to be deployed early next year.
XCM v2 has been delivered, it is part of Polkadot 0.9.11, this version contains most of the features we are going to do.
Asynchronous error handler, that is, you can have code running on the chain to prevent some errors from occurring on the remote chain, and this function is implemented in a better way, all with Dispatchables and status reports, Allows the status of some XCM commands to be reported back to other chains, since other chains may want to use the code processor to register the status.
Asset capture is essentially remembering the contents of the holding register at the end of the XCM message. In many cases, whether it is an error or just an accident, it may be accompanied by a message that is not done at the end of the message execution, and some assets are left behind. In the holding register. This function allows these contents to be remembered and can be retrieved later.
Exeption handling, the language model of XCM now has Exeption handling. Currently we are using a virtual machine model, which I think is easier to understand and extensible than before. There is also version management, which allows different XCM versions to exist in a multi-chain network at the same time. The v2 specification has also been written.
The following is the progress of the parachain. I know that many viewers today are very concerned about this aspect.
At present, the function of the parachain code has been completed, that is, all the security mechanisms in the Polkadot specification have been implemented, tested and audited. That’s right, the audit has been completed, and half of the amendments proposed in the audit should be completed before November. And we really look forward to completing the initial deployment of these functions soon and adding the security code to Kusama. We will set aside three weeks before actually putting the code into production, but we don’t think there will be any major problems with the code. Therefore, based on this, the timetable for the launch of the Polkadot parachain can be calculated.
Our own assessment of the code status is that the parachain will be technically available in December, and we can look forward to deploying it on Kusama at the end of October. So from a technical point of view, Polkadot is now ready to prepare for Lease 6 to Lease 13 Auction.
We also believe that the number of parachains on Polkadot should be maintained at a maximum of 75% of the number of Kusama. Kusama is Polkadot’s canary network, so this ratio will be maintained at least until the code matures. Until we understand the number of parachains, transaction throughput, and message throughput that the current architecture can handle.
We believe that during the initial parachain expansion period, it would be more reasonable to adopt a shorter auction cycle, so we will continue to use the previously announced cycle, which is approximately two weeks for each auction.
Looking to the future, I would like to talk a little bit about the recent events and trends in some industries, and how these events will affect Substrate, and what changes you may see in the next year or so.
One thing I noticed is that in pursuit of high transaction throughput, many chains ignore the fact that decentralization and security are not optional features, although if you sacrifice the network Centralization can have higher transaction throughput.
This is why it took so long to upgrade ETH 2.0. In fact, there are many reasons, one of which is that they, like us, are unwilling to sacrifice the degree of decentralization of the network. If you are unwilling to do this, then the network architecture and design, especially the security design, need to be more thoughtful. So when you see some networks claiming to be public chains with high TPS, then in many cases, these chains and some real decentralized networks are no longer comparable.
If we look at the current state of supervision, we will find some important points. I have mentioned this in some previous reports. Although I am not an expert in this area, and certainly not a lawyer, I still talk about my views on some policy documents. If we look at FATF, it is an international entity. I remember that it is roughly equivalent to the G20 national alliance. They have a clearer policy.
The good news is that software development, operation, and maintenance of the network are blameless and should be allowed to continue without regulatory restrictions, because this is the livelihood of our developers. If people want to deploy such peer-to-peer networks, it is very important. One thing is that such activities should be free and unrestricted.
However, it is obvious that global regulators are looking at some other activities with a very strict eye, and I think these activities are involved in most peer-to-peer networks and decentralized projects, some of which rely heavily on these activities. . One type is service provision, such as RPC, wallet, and App website. The second category is multi-signature, such as DAO, or you have a few designated people who can spend money from the DAO vault. This is also the case in Polkadot and Kusama. There is also custody, custody wallets, non-peer-to-peer stablecoins all fall into this category. The last category I call it convenient functions, such as some wallets/applications, through centralized means to make decentralized applications easier to use, but in my observations, this category should be regulated later.
Service provision is the most interesting here, because obviously peer-to-peer networks, such as Ethereum, still rely heavily on centralized RPC services. Sometimes centralized wallets and websites are used to host decentralized applications. By observing the language of regulators , I think this one should be included in the scope of supervision in the near future.
But one thing I think is certain: the more centralized you are, the more likely you are to be targeted by regulators and strictly require you to obtain relevant licenses; the more peer-to-peer and decentralized you are, the more likely this is Low, so moving towards a point-to-point direction seems to be a reasonable choice.
Another thought when I read these documents is that it seems that those relatively neutral encryption projects that are not point-to-point enough need to obtain a license. I think this type of license may be similar to the standards of the banking regulations. If this is the case, it means that most encryption projects may not be able to continue in their current form within a year or two. I think supervision may be implemented within two to three years, but it is always good to prepare early. Especially when the technology you need to reduce risk is difficult to achieve.
At Parity, we are committed to making everything peer-to-peer, and we want to ensure that our technology will be classified as a category that does not require supervision. This means that we have a lot of points that need to be paid attention to, especially where decentralization is not enough. For example, Boot Node and RPC nodes have centralized components. We will focus on light client, class The browser client side transfers. In terms of governance, we will ensure that we adopt an on-chain decentralized governance approach and will not violate any multi-signature regulatory provisions. There are also privacy mechanisms, such as Mixnet.
I want to emphasize that the solution based on Substrate should be a real Web3.0 solution, and it should be truly peer-to-peer. Similarly, for Polkadot, we will make it the first peer-to-peer, secure, and scalable free execution platform.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/web3-should-develop-in-a-more-decentralized-direction/
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.