What is Substrate?
Substrate is a blockchain framework that is open-source. Substrate includes all of the essential components for constructing a distributed blockchain network. Database, Networking, Transaction Queue, and Consensus are just a few examples.
Although these layers are extensible, Substrate considers that the average blockchain developer is unconcerned about the implementation specifics of these key components. Substrate makes it as simple and flexible as possible to design a blockchain’s state transition function. Substrate runtime is the name given to this layer.
Substrate Components
We assume that you have a basic knowledge of Blockchain i.e, about blockchain nodes, its production, finalization, etc. So we will now see how Substrate works as a foundation for creating a blockchain. The Substrate framework’s initial claim to fame is that it is extensible. This means it makes as few assumptions as possible about how your blockchain is designed and tries to be as general as possible.
Database
The heart of a blockchain, as we’ve seen, is its shared ledger, which must be maintained and kept. Substrate makes no assumptions about the data in your blockchain’s content or structure. A modified Patricia Merkle tree (trie) is implemented on top of the underlying database layer, which employs simple key-value storage. This unique storage structure allows us to quickly determine whether or not an object is stored there. This is especially crucial for light clients, who will rely on storage proofs to deliver lightweight but trustworthy interactions with the blockchain network.
Networking
A peer-to-peer networking protocol must be established for a decentralized blockchain system to communicate. Libp2p is a modular peer-to-peer networking stack used by Substrate. Substrate-based blockchains can share transactions, blocks, peers, and other system vital details without the use of centralized servers thanks to this networking layer. Libp2p is unusual in that it makes no assumptions about your specific networking protocol, which is in accordance with Substrate’s philosophy. As a result, alternative transports can be implemented and used on top of a Substrate-based blockchain.
Transaction Queue
As previously stated, transactions are gathered and organized into blocks, which determine how the state of the blockchain changes. However, the order in which these transactions are completed might have an impact on the ledger’s final state. Substrate gives you complete control over transaction dependencies and queue management on your network. Substrate simply assumes a transaction has a weight and a set of prerequisite tags for creating dependency graphs. In the simplest situation, these dependence graphs are linear, but they can get more complex. Substrate takes care of all of the intricacies for you.
Consensus
Remember that a blockchain network can reach a consensus on updates to the chain in a variety of ways. Traditionally, these consensus engines have been inextricably linked to the rest of the blockchain. Substrate, on the other hand, has gone to great lengths to establish a consensus layer that can be easily altered during development. In fact, it was designed in such a way that when the chain went live, consensus could be hot-swapped! Multiple consensus engines, including standard Proof of Work (PoW), Aura (Authority Round), and Polkadot consensus, are built into Substrate. Polkadot consensus is unusual in that it isolates the block production process (BABE) from the block finalization process (GRANDPA).
Substrate Runtime
So far, we’ve covered all of the key blockchain components that Substrate offers. The substrate has made every attempt to be as general and extendable as possible, as you have seen. The modular runtime, on the other hand, is likely the most configurable aspect of Substrate. Substrate’s state transition function, which we discussed earlier, is the runtime.
Substrate thinks that the common blockchain developer doesn’t need to be concerned with the above-mentioned blockchain components. The implementation details are generally unimportant as long as the components have been battle-tested and are ready for production. The underlying blockchain logic that defines what is and is not acceptable for a network, on the other hand, is frequently crucial for any chain.
As a result, Substrate’s main goal is to make blockchain runtime development as simple and versatile as possible.
Substrate Runtime Module Library (SRML)
The runtime of a Substrate is separated into logical components known as runtime modules. These modules will be in charge of some components of the blockchain’s on-chain functionality. These modules can be thought of as “plug-ins” for your system. As a Substrate developer, you have complete control over whatever modules and features you choose to include in your chain.
The currency of the chain, for example, is managed by a module called “Balances.” There are other modules for decision-making and governance for the chain, such as “Collective,” “Democracy,” and “Elections.” There’s even a “Contracts” module that can convert any Substrate-based chain into a smart contract platform. When you develop on Substrate, you get these kinds of modules automatically.
However, Substrate’s modules are not the only ones available. Developers can easily create their own runtime modules, either as standalone logical components or by interacting directly with other runtime modules to create more complex logic. I believe that, in the long run, Substrate’s module structure will function similarly to a “app store,” where users can simply pick and choose whatever features they wish to include, and construct a distributed blockchain network with minimal technical knowledge!
Forkless Runtime Upgrades
If we consider the Substrate module ecosystem to be similar to an app store, we must also consider how we update our runtime. The substrate has made changing your runtime a first-class operation, whether it’s for bug patches, general enhancements to current modules, or even new features you wish to add to your blockchain.
Changes to your chain’s state transition function, on the other hand, affect the network’s consensus. If one node on your network has one version of your runtime logic and another has another, the two nodes will be unable to reach an agreement. They will have fundamental disagreements about the true state of the ledger, resulting in a fork, as we stated earlier. Irreconcilable forks are problematic because they weaken your network’s security by requiring only a small number of nodes to accurately construct and validate new blocks.
The substrate has addressed this problem by allowing the network to agree on the runtime logic! We can put the Substrate runtime code on the blockchain as part of the shared ledger using the Wasm binary format. This means that anyone running a node can check to see if their node has the most up-to-date logic. If it doesn’t, it will directly execute the on-chain Wasm! This means that your blockchain may be upgraded in real-time, on a live network, without forking!
To understand more in-depth about the basics of Substrate Codes you can visit here.