header-langage
简体中文
繁體中文
English
Tiếng Việt
Scan to Download the APP
Partnered With:

What is Substrate

Read this article in 27 Minutes
Why do I need Substrate?

Original title: "minimalist summary of Substrate"

Source: & NBSP; DmitriyKashitsyn  PolkaWorld


Today we'll talk about Substrate, a library that can help you build your own custom blockchain. Substrate is developed by ParityTech and provides the basis for Polkadot.


What is the Substrate?


3. A substance or layer that underlies something, or on which some process occurs.


As the name implies, a Substrate can be used to grow or build something on top of it. In our case, we can build a blockchain, or in Polkadot's case, we can build a whole family of blockchains.


Why do I need Substrate?


Software boils down to abstraction.


The history of computer science shows that we keep getting more and more abstractions: from discrete logic to integrated circuits and cpus; From machine code to assembly, from assembly to C, to C++, Rust, Haskell, and so on.


The same goes for programming APIs. For example, few people write the web in pure HTML these days.


"Every problem can be solved by introducing another abstraction layer. Except for a lot of abstraction layer problems... so we invented the framework." -- Andrew koenig, the financial times


Each abstraction layer attempts to solve a specific problem. So, what is a Substrate built to solve? As it turns out, there are a number of things you need to consider before you start implementing a new blockchain solution:


Why another blockchain? !

Various password primitives: encryption, signature, RNG, etc

Consensus algorithms and fault-tolerant voting

Proof of Waste, Proof of Stake, Proof of Authority? & have spent Or something completely different?

Block structure and efficient storage, message serialization

P2P network, peer discovery, block and transaction interchange

State machine, execution logic, smart contract

Light client support


Although the Substrate does not solve the first problem, the Substrate may help you solve the rest because it provides existing implementation tools. These are carefully designed, written and tested based on our years of experience in developing blockchain.


Of course, you can implement all of these tasks yourself, but I can say that you might end up with an untested and poorly documented solution. Not to mention, usually an encryption algorithm that you design or implement yourself is considered a very bad idea, unless you're a cryptographer and you really know what you're doing.


So, by providing a generic implementation of a typical algorithm, Substrate lets you focus on the project itself: the business logic of the chain, its state machine.


Let's take a look at the most important parts of the blockchain and see what Substrate can offer.


Blockchain as permanent storage


The sole purpose of any blockchain is to provide a verifiable, global, permanent way to store and transform data, which means all parties have to check and agree on what value can be recognized at any point in time, in a zero-trust manner. Moreover, once the data is sealed, it should be permanent and, by consensus, impossible to tamper with.


This property is widely used in cryptocurrencies where the permanent store contains the account key and its actual balance. However, it should be noted that cryptocurrency is not the only possible blockchain application. Basically, almost any system that requires global consistency, permanent storage, and verifiable transaction history can be implemented using blockchain in some way.


Substrate provides efficient storage, is very easy to use, and is tightly integrated with WebAssembly (Wasm) runtime.


Blockchain as functionality


In order to update the status of the chain and change its storage based on the pending operation, we need to have a decision point.


These decision points can be represented as a function that accepts the current state and a set of undetermined operations and produces another state that should be considered a new state. In the blockchain world, such a function is called the state transition function, or STF.


Substrate allows you to define such a function in a manageable and portable manner. Much like JavaScript executing on a web page, you can write a set of functions called runtime that will act as an STF. Furthermore, such an implementation would be portable and not dependent on the processor architecture, operating system, browser, or any other platform-dependent approach.




In fact, even the underlying technology of the Substrate is closely related. Substrate USES WebAssembly as the general language for its runtime, which is what Mozilla, Google, and Apple are currently integrating as a faster but still compatible alternative to JavaScript when writing the web.


Safety and speed


Writing the logic and smart contracts for the chains in Wasm means you will have the best tools to execute the logic in a fast and reliable way. Substrate, however, has a way to execute code faster without any virtual machine overhead.


The most revolutionary part of the Substrate is that the runtime image containing the STF is stored along the chain with other payloads. This means & NBSP; The business logic of the runtime and the entire chain can be updated in a secure and verifiable manner. More importantly, because Substrate and its Runtime Module Library & NBSP; Both are written in the Rust programming language, so they can be translated into native code and Wasm.



At any given time, the client software has two copies of the compile runtime: one is compiled natively in the software, and the other is the Wasm image to be executed in the VM. When the runtime function is executed, the client software checks that the Wasm version on the runtime chain matches the native built-in version it compiled. After doing so, the client software delegates the execution of the runtime function to the native code version.


Bifurcless upgrade


When the runtime image is updated on the chain, some clients have not yet updated their software. In this case, their nodes will execute the correct version by interpreting the runtime on the Substrate's integrated Wasm virtual machine. Thus, in any case, all nodes on the network are always able to properly synchronize the chain (albeit with varying efficiencies), thus preventing the chain from branching.


network


Blockchain relies on having many participants communicating over the network. The typical solution is to use point-to-point technology for this communication, and Substrate is no exception. P2P is a generic name for a set of technologies used to create distributed network applications.


The main idea is to create a self-sustaining network environment in which each participant (often referred to as a node) can run within the network without prior configuration or authorization.


To ensure that nodes can join or leave the network at any time without affecting the connectivity of the entire network, the Substrate USES the Rust implementation & cake; Libp2p (https://github.com/libp2p/rust-libp2p), which is a promising network stack, it has everything you need for a distributed network environment is established.


Custom message


In the simplest case, you don't even have to think about the network, because the Substrate does everything for you. All you have to do is provide the block chain state transition capability and leave all network interactions to the Substrate. However, if the blockchain requires sending custom messages, the network subsystem can be customized and extended by providing specific network protocols that specify the custom messages and their processing logic.


consensus


It's good to have a state transfer function that allows you to move from one state to another, but it's not enough. You also need a way for all nodes to agree on what the next state should be.


As the owner of a bank account, this is the last thing you want to meet you and the bank how much money in "your account" differ. Block chain allows the parties agreed in the case of distrust each other (and therefore zero trust), even in a malicious participants tried to disrupt the system and steal your money situation also is such.


This is done using a consensus algorithm with Byzantine fault tolerance (BFT) properties. If a system is BFT, this means that nodes can agree even if some of them behave badly, including colluding, intercepting messages and going offline. The BFT consensus system can withstand varying degrees of network problems where messages can be reordered or delayed. Some BFT consensus systems are designed so that when nodes misbehave (for example, by voting two blocks at a time), they can be penalized and the tokens they pledge cut down the chain.


For each consensus engine supported in the Substrate, there will be a runtime module that handles the proof of the wrong behavior. The impact of evaluating bad behavior can be determined by the runtime.


It is mathematically proven that the protocol is feasible as long as two-thirds of the nodes in the network are not malicious and run according to the protocol. This is one of the reasons why it is important to have many nodes in the network.


Consensus is a key part of any blockchain application. Fortunately, Substrate provides an already-available BFT consensus, almost out of the box.


Depending on the usage scenario, you can either use the existing block authoring logic or provide your own block authoring logic. In the latter case, you can use a generic version of BFT and tailor it to your needs.


Substrate will continue to develop, and have more consensus algorithm is added to (https://medium.com/polkadot-network/grandpa-block-finality-in-polkadot-an-introduction-part-1-d08a24a021b5), Includes the final determination widget GRANDPA (GHOST-based Recursive Deriving ving Prefix Agreement) developed at the Web3 foundation.


Additionally, since Substrate is a fully extensible and customizable framework, you can define your own custom consensus algorithms. In fact, Substrate is so flexible that it can support solutions that are not based on the classic blockchain architecture. For example, we are looking at how to solve the block chain throughput problem by designing a consensus that is not based on traditional block concepts.


Light client support


Early blockchain implementations were designed so that each node in the network maintained a complete blockchain database locally. This is now called the full client, which means that the client has everything it needs to run as a network node.


Full clients (also known as full nodes) are important for chain security. But as blockchain grows, customer databases get bigger and bigger. Currently, mainstream cryptocurrencies have hundreds of gigabytes of databases.


When the entire node is initialized, the first thing it needs to do is synchronize with the rest of the network. For security reasons, such a node would not be able to download the database randomly from one node as is, but would need to build its own database from scratch, resynchronizing all transactions since genesis (the first block of the chain). In addition to being computationally expensive, this task requires the transfer of large amounts of data over the network.


I think everyone would agree that downloading half a Megabyte of data to your phone is just to buy a sandwich... This is either impractical or absurd. That's why, almost from the start, blockchain developers have been thinking about ways to reduce node maintenance costs, including storage space and network throughput.


Finally, the concept of light customer was born. In short, a light client is a mode of operation for a blockchain node in which only the most important data is stored locally, network interactions are minimized, and acceptable security is preserved for almost all possible interactions.


Modest resource requirements eventually allow light client nodes to boot easily, so they can be executed on mobile devices.


Unfortunately, integrating light client support into an existing blockchain is a serious task. It is much easier to integrate light clients in the initial design of the blockchain. Substrate is specifically designed with light client support in mind. Cpl-based blockchains have off-the-shelf support for light clients.


conclusion


In this article, we skim over the main objectives and characteristics of the Substrate framework. It will take a longer article to cover all aspects of Substrate, but hopefully you have a general understanding of these concepts by now. It's not enough to start writing your code, but at least for now you should know what to expect.


For more information, please check Jack Fransham before article "what is a Substrate" : https://www.parity.io/what-is-substrate/.


If you want to dive in and start implementing your blockchain, the best place to start is the Parity Substrate Wiki (https://wiki.parity.io/).


Also, don't hesitate to look at the source code, especially the ReadMe file:https://github.com/paritytech/substrate.


annotation

RNG stands for random number generator. Not every RNG is suitable for blockchain applications.

Substrate itself is now in a very active stage of development. The code base is very unstable and documentation is ongoing. We're actively populating the wiki, which is a good place to look for more details: https://wiki.parity.io/

The Runtime module library is an optional set of Rust crates to handle common tasks such as parameter serialization and call dispatch, and to help you build the Runtime with minimal cost. The library is completely optional, so it's nice to design your own runtime from scratch, or use any language that can be compiled into Wasm. In addition to Rust, only C and C++ currently support Wasm as the target architecture.


Original address:https://dwz.cn/KuDo0SkY




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

举报 Correction/Report
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit