Reader small image

You're reading from  Rust for Blockchain Application Development

Product typeBook
Published inApr 2024
PublisherPackt
ISBN-139781837634644
Edition1st Edition
Concepts
Right arrow
Author (1)
Akhil Sharma
Akhil Sharma
author image
Akhil Sharma

Akhil Sharma is a Software Engineer and an entrepreneur. He is the CTO of Dominate, a SaaS product company, and the founder of Myrl Tech, a tech services company providing technology consulting to some of the top enterprise companies in the world such as HP, 3M, Honda, Bose, and Adobe. He has 12+ years of industry experience and a solid understanding of building digital products. He is adept at multiple programming languages such as Golang, Rust, Ruby, Python, and JavaScript. He has mentored hundreds of engineers offline and discovered that they knew the programming language and the concepts around it but were unable to use them in real-world applications. He aims to close this gap by teaching how to apply the concepts practically and build projects in real time.
Read more about Akhil Sharma

Right arrow

Exploring the backbone of blockchains

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.

Decentralization

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:

  • A failure at the company’s end took the system down
  • Admins could edit the data and block users and content from platforms
  • Security was still not prioritized, leading to easy data hacks, although this could vary depending on the company’s approach to safeguarding information
  • All the data generated on the platform belonged to the platform
  • Content created and posted on a platform became the property of the platform

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.

Peers, nodes, validators, and collators

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

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

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

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

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

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:

  • The number of transactions that the block will store
  • The mechanism that nodes use to collate the transactions (time-based or number-based)
  • The validation mechanism
  • The consensus mechanisms

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.

Consensus

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:

  • Proof of work (PoW): Nodes need to solve a particular cryptography problem (we will look at this in detail in the Mining section), and the node with the highest processing power is usually able to solve faster than others. This keeps the system decentralized but increases electricity consumption by a huge amount. It’s not considered to be very efficient and is even considered bad for the environment, as it increases power wastage since all the nodes are up against each other trying to solve the problem. Examples are Bitcoin, Litecoin, and Dogecoin.
  • Proof of authority (PoA): This is a consensus mechanism in blockchain where transactions and blocks are verified by identified validators, typically chosen due to their reputation or authority. Unlike energy-intensive mechanisms such as PoW, PoA offers efficiency by requiring validators to be accountable for their actions. It’s commonly used in private or consortium blockchains, ensuring fast transactions and reducing the risk of malicious activities. However, PoA’s centralized nature may raise concerns regarding decentralization and censorship resistance compared to other consensus methods.
  • Proof of stake (PoS): Nodes need to buy stakes in the network—basically, they buy the cryptocurrency native to the network. Only a few nodes with a majority stake get to participate in the mining activity in some cases. This is highly power efficient, and this is the reason why Ethereum recently switched from PoW to PoS. However, it is considered to be less decentralized, as only the nodes with enough resources get to add the next blocks and it can be seen that some big players have been slowly taking ownership of the majority of the network since Ethereum switched to PoS. The main benefit of PoS is that since nodes have a stake in the system, they are de-incentivized to add unscrupulous blocks to the chain. Since the copy of the chain exists with all the nodes of the entire network, the nodes are running the software of the blockchain where the output hashes need to be consistent with the rest of the chain. Hence, when a node tries to add the wrong block, the rest of the nodes do not validate this block, and if such a scenario takes place, these nodes are then penalized where the amount of native cryptocurrency owned by the node that is taken away can differ depending on the seriousness of the violation. Generally, this penalty entails a partial loss of funds rather than a complete forfeiture of all holdings. Some examples are Cardano, Ethereum, and Polkadot.
  • Proof of burn (PoB): Burning is a process where cryptocurrency is sent to a wallet address from which it’s irrecoverable. The nodes that can burn the highest amount of cryptocurrency get to add a node. Miners must invest in the blockchain to demonstrate their commitment to the network. Even though PoB is the most criticized consensus model, it can actually be highly effective for some blockchains that want to ensure deflationary tokenomics. Slimcoin is an example of PoB.
  • Proof of capacity: In this consensus mechanism, the nodes with the highest storage space get to add a node. This means that the nodes that partake in the network can use their hard drive space to compete with each other to win the mining rights. An example is Permacoin.
  • Delegated PoS: Participants in the network, such as end users buying cryptocurrency, can stake their coins in a pool, and the pool belongs to a particular node that can add blocks to a chain. The more tokens you stake, the bigger your payout. Examples are EOS, BitShares, and TRON.

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.

Mining

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

Figure 1.11 – All the data that makes up a hash

Now, this means the following:

  • This can only be solved with brute forcing, iterating from zero to a particular number, and cannot be solved smartly
  • All the nodes in the network compete with each other regardless of whether they ever win, and this means a lot of computational energy gets wasted
  • Nodes need to keep upgrading their computational power to win the competition

Now that we understand what mining is and how it works, it’s time to learn about forking—an important blockchain concept.

Forking

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

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.

Permissioned versus permissionless

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

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.

Previous PageNext Page
You have been reading a chapter from
Rust for Blockchain Application Development
Published in: Apr 2024Publisher: PacktISBN-13: 9781837634644
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime

Author (1)

author image
Akhil Sharma

Akhil Sharma is a Software Engineer and an entrepreneur. He is the CTO of Dominate, a SaaS product company, and the founder of Myrl Tech, a tech services company providing technology consulting to some of the top enterprise companies in the world such as HP, 3M, Honda, Bose, and Adobe. He has 12+ years of industry experience and a solid understanding of building digital products. He is adept at multiple programming languages such as Golang, Rust, Ruby, Python, and JavaScript. He has mentored hundreds of engineers offline and discovered that they knew the programming language and the concepts around it but were unable to use them in real-world applications. He aims to close this gap by teaching how to apply the concepts practically and build projects in real time.
Read more about Akhil Sharma