This post is about setting some context before you get started with Substrate.
Substrate is a framework for building blockchains. But what does that mean?
I was recently at a hackathon/conference, and many of the participating developers asked me - “How do I get started with Substrate and deploy smart contracts on it?”
Most of the time I give a brief reply, that, with Substrate, you could build custom blockchains not just smart contracts. Think a layer below.
That answer is not generally enough. People ask me to elaborate. Well, here I am, elaborating.
Anatomy of a Blockchain
Before we go into Substrate, let’s first understand the anatomy of a blockchain. Blockchains generally have the following major components:
Networking: For nodes to connect and talk to each other.
Storage: To store the state of the blockchain. This is generally structured as some form of a Merkle tree on top of an underlying key-value store.
Consensus: For reaching an agreement on the state of the blockchain, among all nodes.
Transaction Queue: To receive, hold, and validate incoming transactions.
State Transition Function (STF): The business logic to process/execute transactions and then produce blocks.
There are a few other components as well, but not relevant here.
Now, that’s pretty much it. Every node in a blockchain, receives transactions in the transaction queue, gossips or broadcasts them using networking, produces blocks using the STF, participates in consensus using the consensus algorithm and stores the state in the storage. This way the blockchain continues to produce blocks and life goes on.
Every single blockchain, at a high level, works pretty much in this way. Bitcoin, Ethereum, etc, all of them. Just like this.
Of course, at a lower level, there are differences in how consensus is reached, how blocks are produced, how transaction fee is charged, and so on. But at a higher level, the components listed above are common in pretty much all blockchains.
State Transition Function
Now, let’s double click on the state transition function. This is the component that is pretty much different in all blockchains and mainly relevant from the application developer point of view.
For example, in the Bitcoin blockchain, the STF mainly features processing of transactions to spend bitcoin from an unspent output. It also rewards the miners on the production of a valid block.
In the case of Ethereum, the STF goes one step further, and allows a couple of more things. Transfer of Ether, deployment of smart contracts, and calling of smart contracts. In addition, the rewards for miners.
Yes, the deployment and calling/execution of smart contracts is the feature of the STF of Ethereum blockchain. For deploying and calling smart contracts, you need to pay gas as per the rules coded in the STF of the Ethereum blockchain. You are also limited by the opcodes and other limitations of the EVM. These limitations exist so that the network stays secure while the users upload any random logic on the chain as part of smart contracts. To allow fully permission-less deployment and deterministic execution of decentralized logic, we have to deal with limitations and inefficiency of a custom virtual machine.
Now, let’s compare the two blockchains - Bitcoin and Ethereum - in terms of their use-cases. While one is just a peer to peer money transfer system (Bitcoin), other other one is a generalized DApp platform (Ethereum). Bitcoin is purpose built and optimized for one use-case, while Ethereum allows you to build for many use-cases but does not allow you to optimize at all. And, my readers, optimization and efficiency are very important when it comes to blockchain-based applications.
Let’s take a few examples:
- Logic for a supply chain needs different optimizations as compared to a token transfers.
- NGO and public sector apps need different transaction fee processing as compared to gaming apps.
- Data storage optimizations for NFTs are different than those needed for fungible assets.
- And the list can go on.
Different use-cases have different needs when it comes to building DApps. Not just in terms of transaction fee and logic execution, but also for consensus and block production.
But smart contract platforms do not allow case-by-case optimizations. The STF of Ethereum treats all smart contracts in exactly the same way, no exceptions and no custom optimizations allowed.
Is there an alternative?
What if we could build custom blockchains for specific use-cases with fully optimized STFs?
There are already several examples of that - The Flow blockchain is custom built for NFTs, the ZCash blockchain is custom built for private transactions, and Bitcoin is custom built for money transfer.
Awesome, so we could just build our custom blockchain? Is it that simple? Maybe not if you build everything from scratch.
To build a custom blockchain from scratch, you need to build and integrate all those components that I listed above - networking, storage, consensus, transaction queue, STF, and many more. All this requires very careful design and implementation, and a lot of time.
So, if it takes so much time and effort to build a custom and use-case optimized blockchain, then what to do? Should we just deploy smart contracts on Ethereum (or other platforms)? But that’s not optimized for execution.
One thing is not optimized for time and effort, the other is not optimized for execution and efficiency. WTF!?!
Now that we have gone through the problems with smart contracts and with building custom blockchains from scratch, let’s look at the solution - Substrate.
Substrate is a framework for building custom and use-case optimized blockchains with minimal effort and extremely high efficiency.
Just like React is a framework for building web applications, Substrate is a framework for building blockchains.
Similarly, Substrate is based on Rust and comes with all the main components to build blockchains - networking, storage, consensus, transaction queue, STF template, and many more. All you have to do is to code your pallets (modules) and hook them up in the runtime (STF), and your blockchain is pretty much ready. Again, you didn’t have to do things from scratch. Pretty cool, eh?
Ok, so now we know how to build custom and use-case optimized blockchains without spending years in time and millions in dollars. Just use Substrate!
Smart Contracts in Substrate
Now, I am not going to shy away from the initial question of - “How do I build smart contracts for Substrate?”. Let me answer that too.
When you build a custom blockchain and when you already code most of the functionality in the STF itself, you don’t need smart contracts on that chain (well, 99% of the time). Smart contracts are needed when you want your users to also be able to upload and execute custom logic on top of the logic that you have already written in the STF. You are not building a smart contract platform, you are building a highly optimized blockchain for a specific use-case. Hence, most of the time, you won’t need smart contracts.
If you still need smart contracts on your Substrate chain, you can have them. Substrate supports two kinds of smart contracts that can be added to a chain - EVM based and Wasm based. If you are building a Substrate chain and you need to add smart contracts to it, all you have to do is just add the relevant pallets in your chain’s runtime. But you should always ask, do I really need smart contracts on my chain or not.
So, that’s pretty much it, I guess. I hope this post helps you understand Substrate from an approach perspective.
To start hacking on Substrate, you can read my other post that give an overview of how to start building - https://www.gautamdhameja.com/getting-started-parity-substrate/.