-
Book Overview & Buying
-
Table Of Contents
Rust for Blockchain Application Development
By :
This section is a deep dive into what makes blockchains so special. We will cover topics such as decentralization, forking, and mining, and we will understand how peers interact in a network and how the blocks are validated. Let’s dive in.
From a purely technical standpoint, Web 1.0 started with a client-server architecture, usually monoliths. When traffic and data started increasing, the monolithic architecture couldn’t scale well. Then, with Web 2.0, we had concepts such as microservices and distributed systems,which helped not only scale systems efficiently but also enhanced resilience and robustness, reduced failure instances, and increased recoverability.
The data was still centralized and private and the systems were mostly centralized, meaning they still belonged to a person/company and admins could change anything. The drawbacks were the following:
Web 3.0 ushers in a new age of decentralization that is made possible with blockchains where the entire blockchain data is copied to all the nodes. But even distributed systems had nodes and node recovery, so the question is, how is this any different?
Well, in the case of distributed systems, the nodes still belonged to the centralized authority or the company that owned the platform, and nodes were essentially their own servers in a private cloud. With decentralized systems, the node can be owned by another entity, person or a company other than the company that developed the blockchain.
In fact, in a blockchain network, having nodes owned by different companies is encouraged and this increases the decentralization of the network, meaning there is no real owner or authority that can block content, data, or users out and the data is accessible to all the nodes since all of them can store a copy of the data.
Even if one node goes down, there are others to uphold the blockchain, and this makes the system highly available. Advanced communication protocols among the nodes make sure the data is consistent across all the nodes.
Nodes are usually monetized to stay in the network and to uphold the security of the network (we will read more about this in the next section). Nodes also need to come to a consensus regarding the next block that’s to be added to the chain. We will also read more about consensus shortly.
In this section, we will further build upon the knowledge we have gained in the past few sections. A blockchain does not exist in isolation; it is a peer-to-peer network, and all full nodes save the complete copy of the blockchain, while some blockchains also permit other types of nodes that maintain state without necessarily possessing a full copy.
In the following diagram, we see this in a visual format:
Figure 1.6 – Multi-node networks
So, let’s dig a layer deeper. Nodes are listening to events taking place in the network. These events are usually related to transactions. It is important to reiterate that a transaction is anything that changes the state of the system.
As we know, a block contains the information of multiple transactions.
The following diagram shows a block with some example transactions:
Figure 1.7 – Transactions finalized to a block
Once a new block is added by a node, which is known as mining, this new event is advertised to the entire network. This is visually represented in the following diagram:
Figure 1.8 – The created block is advertised
Once the new block is advertised, the rest of the nodes act as validators that confirm the outputs of the transactions once the block has been validated by the rest of the nodes. The nodes come to a consensus that yes, this is the right block that needs to be added to the chain. We can visualize this with the help of the following diagram:
Figure 1.9 – Other nodes validate the block data
The new block is then copied to the rest of the nodes so that all of them are on the same page and added to the independent chains being maintained at each node. This can be seen in the following diagram:
Figure 1.10 – A block gets finalized
Once the blocks are added to the node, and the blockchain at each node is updated on any other node. Another block could be listening to all the new transactions that have happened, and these are then collated onto a block and the entire process then repeats.
The following criteria vary from blockchain to blockchain in terms of the following:
Contemporary chains improved upon the Bitcoin and Ethereum blockchains by varying and innovating on either all or some of these criteria, but the consensus mechanism is something that is most often innovated upon. This is done to try and save the time required for new nodes to be added and copied by the entire network, which is what really slows down the network.
We learned earlier that the nodes need to be incentivized to stay in the network and keep adding the blocks to the chain. In chains such as Ethereum, this is achieved using gas fees, which are simply small fees that users pay to carry forward their transactions. We know that blocks can contain only a few transactions, and if the users want their transactions to get priority, they need to pay gas fees.
The gas fee depends on what other users are willing to pay to get their transactions forwarded; the higher the gas fee, the higher the chance of getting your transaction accepted. Think of gas fees as the rent that the nodes get paid for the users to use the nodes’ processors to process and validate their transactions. The words peers and nodes are used interchangeably, and validators and collators can also be used interchangeably depending on the blockchain you are on.
In the last section, we learned that a node listens to transaction events, collates these transactions, and creates a block. This is called mining. After a block is mined, other nodes need to validate it and come to a consensus.
In this section, we want to peel the layers of consensus to understand it deeply. Understanding the mechanics behind some popular consensus mechanisms will help us to learn by running through actual examples, rather than learning in an abstract way. So, let’s understand some of these concepts:
In this section, we’ve developed a rich understanding of consensus mechanisms, and this will help us throughout the book, especially while building the blockchain.
By now, we have a very basic idea of what mining is and why it’s necessary. In this section, we will dive into the specifics of mining. Mining happens quite differently in different consensus mechanisms. We will look at mining for the two major consensus mechanisms: PoW and PoS. For instance, in PoS, let’s consider the example of Ethereum 2.0, where validators are chosen to create new blocks and secure the network based on the amount of cryptocurrency they hold and are willing to “stake” as collateral.
In a PoW blockchain, to add a block to the blockchain, a cryptographic problem needs to be solved. The node that comes up with the solution first gets to win the competition. This means that nodes with the highest computational power usually win and get to add a block.
The blockchain’s cryptography challenge adjusts in complexity over time to ensure consistent block creation. Nodes predict a specific hash, focusing on a segment that aligns with the existing blockchain, maintaining chain coherence.
Nodes employ a nonce, a unique value, to address the challenge. Incrementing from zero, this value is adjusted until a matching hash is computed, pivotal for generating a valid hash in line with the network’s rules.
Solving the cryptographic problem validates transactions and creates new blocks. A successful node broadcasts its solution, swiftly verified by others. The first to find a valid solution is rewarded with newly minted cryptocurrency, incentivizing participation and bolstering network security.
The following diagram shows the different fields that add up to produce a hash:
Figure 1.11 – All the data that makes up a hash
Now, this means the following:
Now that we understand what mining is and how it works, it’s time to learn about forking—an important blockchain concept.
There is one small detail about blockchains that we have talked about but haven’t discussed in detail yet, and that’s immutability. In one of the earlier sections, we learned how SHA-256’s properties translate into immutability for blockchains. This means all transactions that happen on-chain are immutable, and tokens once sent from one account to another cannot be reversed unless an actual transaction is initiated from the second account.
In traditional payment systems, this is not the case. If money is sent to the wrong account by mistake, this can be reversed, but this feature has been manipulated by centralized authorities and therefore immutable transactions are valued highly.
Let’s take as an example the decentralized autonomous organization (DAO) attack in 2016 that led to $50 million being stolen from the Ethereum blockchain due to a code vulnerability. The only way to reverse this was to create an entire copy of the chain where this particular transaction didn’t take place. This process of creating a different version chain is simply called forking. This event divided the blockchain between Ethereum and Ethereum Classic.
The following diagram demonstrates what forking looks like:
Figure 1.12 – Forks in a blockchain
Forking also comes into use when rules for the blockchain need to be modified. Traditional software gets upgraded and new updates and patches are applied, whereas the way to upgrade a blockchain is to fork (though some blockchains such as Polkadot have invented mechanisms to have forkless upgrades).
Forks typically occur intentionally, but they can also happen unintentionally when multiple miners discover a block simultaneously. The resolution of a fork takes place as additional blocks are appended, causing one chain to become longer than the others. In this process, the network disregards blocks that are not part of the longest chain, labeling them as orphaned blocks.
Forks can be divided into two categories: soft forks and hard forks.
A soft fork is simply a software upgrade for the blockchain where changes are made to the existing chain, whereas with a hard fork, a new chain is created and both old and new blockchains exist side by side. To summarize, both forks create a split, but a hard fork creates two blockchains.
Blockchains can be permissionless or permissioned depending on the use case. A permissionless blockchain is open to the public with all transactions visible, but they may be encrypted to hide some crucial details and information if required. Anyone can join the network, become a node, or be a validator if the basic criteria are met. Nodes can become a part of the governing committee as well once they can meet additional requirements, and there are no restrictions on who can join the network. You can freely join and participate in consensus without obtaining permission, approval, or authorization.
Most of the commonly known blockchains, such as Ethereum, Solana, and Polkadot, are all permissionless chains and are easily accessible. Their transaction data is publicly available. So, a perfect use case for permissionless chains is hosting user-facing and user interaction-based applications.
Permissioned chains have gatekeepers that define a permission, approval, or authorization mechanism that only a few pre-authorized nodes can operate. So, to be a part of the permissioned blockchain network, you may need a special set of private keys and may also need to match some security requirements. Since the nodes copy the entire data of the chain and are also involved in adding blocks to the chain and being a part of the governing committee for the blockchains, some use cases where data and information need to be kept private can use permissioned chains.
The following diagram shows the difference between a public and a private blockchain network:
Figure 1.13 – Permissioned versus permissionless chains
Governments, institutions, NGOs, and traditional corporations have found plenty of use cases for permissioned chains, where only a few actors trusted by the centralized authorities are permitted to join the network. Permissioned blockchains also have multiple business-to-business use cases and may be centrally stored on a single cloud provider.
Blockchains help us decentralize computing and resources, and we have been using the word decentralization quite often. In the next section, we will understand the concept of decentralization in more depth.
Change the font size
Change margin width
Change background colour