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

Scaling the blockchain

Multiple nodes are involved in a blockchain network, and the number of nodes determines the decentralization coefficient, or the Nakamoto coefficient.

The Nakamoto coefficient measures the number of nodes required to maintain healthy decentralization in the network. This means the higher the number of nodes, the higher the Nakamoto coefficient.

Now, we know that all of the nodes in a blockchain network not only need to be aware of the transactions that are taking place in the network but also need to process these transactions and communicate with the other nodes to reach a consensus on the block to be finalized.

Since so many operations are taking place between the nodes in a network at any given point in time, it makes it difficult to scale transactions beyond a particular point. For example, the limit for Ethereum is 20 transactions per second. Many new blockchains are trying to solve this problem, and some companies are trying to solve this problem for existing blockchains such as Ethereum using some innovative solutions. In this section, our focus will be the problem of scalability.

In the next few sub-sections, we will cover the factors affecting blockchain scalability and some solutions to help scale blockchains with ease.

The blockchain trilemma

Before we dive deeper into scalability and look at the factors affecting it and its possible solutions, we first need to understand the blockchain trilemma, as just looking at scalability in isolation and solving for scalability does not provide us with an efficient solution.

Three different elements are highly desirable in blockchains: decentralization, security, and scalability. The blockchain trilemma states that as a blockchain network evolves, it becomes difficult to maintain all three of these traits, and usually there’s an imbalance. One of the traits ends up being more dominant than the other two, and trying to enhance the others may end up weakening the dominant one.

The more nodes in the network, the higher the decentralization, but the scalability (number of transactions) goes down, as all nodes need to process these three elements and come to a consensus. Also, security can be more easily compromised since there are more points of entry.

So, to address scalability without affecting the other two elements and solving the problem effectively, we have a few options. We will go over them now.

Sharding

Blockchain sharding is a technique used to scale blockchain networks and improve their performance by dividing the network into smaller, more manageable components called shards. Each shard is like a separate blockchain with its own set of validators and transaction history, but they are all interconnected.

The primary goal of sharding is to increase the transaction processing capacity of a blockchain network by enabling parallel processing. In a traditional blockchain, every node in the network has to process and validate every transaction, which can result in bottlenecks as the network grows larger. Sharding overcomes this limitation by dividing the network into smaller shards, each capable of processing a subset of the total transactions.

Here’s a simplified explanation of how blockchain sharding works:

  • Shard creation: The blockchain network is divided into multiple shards, with each shard assigned a subset of accounts or addresses. For instance, one shard could manage transactions related to addresses starting with the letter A, while another shard takes care of addresses starting with the letter B, and so forth. However, when considering sharding methods, the approach described resembles range partitioning, where data is distributed based on predefined ranges or categories. However, there are alternative methods such as hashing. Hash-based sharding involves distributing data across shards based on the outcome of a hash function applied to the data, offering a different way to achieve load distribution and network efficiency.
  • Shard processing: Each shard operates independently and processes transactions related to the accounts or addresses assigned to it. This allows for parallel processing of transactions within each shard, significantly increasing the overall transaction throughput.
  • Cross-shard communication: Since transactions can involve accounts or addresses from different shards, a mechanism is needed for communication between shards. This is typically achieved through a cross-shard communication protocol, where transactions that affect multiple shards are coordinated and validated.
  • Consensus and security: Each shard has its own set of validators responsible for validating transactions within that shard. This means that the consensus mechanism of the blockchain network must be designed to handle cross-shard transactions and ensure the overall security and integrity of the network.
  • Shard coordination: To maintain the consistency of the blockchain across shards, some form of coordination is required. Techniques such as cross-links, where the state of one shard is included in the block of another shard, or periodic checkpoints can be used to synchronize the shards and maintain a consistent global state.

By implementing sharding, blockchain networks can achieve higher transaction throughput, lower latency, and improved scalability. However, sharding introduces additional complexity in terms of shard coordination, cross-shard communication, and consensus mechanisms. Designing an efficient and secure sharding solution is an active area of research and development in the blockchain space.

Interoperability

Interoperability is an interesting concept and has multiple implications. An indirect implication of interoperability can be scalability. Each blockchain has its own set of data, digital assets, and tokens stored on the chain, but if a user wants to move this data to another chain, there can be various migration and compatibility issues.

Interoperability is when you have different blockchain protocols built with different technologies and their own way of operations to work together and exchange resources and assets seamlessly.

A lot of companies are trying to solve the interoperability problem by building bridges that make it possible to transfer assets across multiple blockchain networks. This also means that if a blockchain is unable to scale beyond a particular point in terms of storage of assets and transactions, these can be shipped off to other chains.

Consensus for scale

The developers of Solana figured out that the consensus mechanism of the chain itself can be a factor that limits the scalability of the network.

Solana has implemented a novel Proof of History (PoH), which is used in tandem with practical Byzantine Fault Tolerance (PBFT). PBFT addresses Byzantine Faults, where malicious nodes can disrupt consensus. By integrating PoH, which cryptographically validates time passage and event order, Solana streamlines the chronology crucial for Byzantine Fault Tolerance. However, this integration adds complexity, as each node needs to execute sophisticated software for consensus participation.

Using PoH enables Solana to theoretically process 65,000 transactions per second (TPS) (currently, it is around 3,000 TPS) as opposed to the 20 TPS provided by Ethereum. This proves that innovating with different consensus mechanisms can enhance the speed and scalability of a network.

Parallel processing

Many blockchain systems lack parallel processing, hindering scalability and speed. Without this capability, transactions are processed sequentially, causing bottlenecks and slower network performance. This limitation restricts their ability to handle a high volume of transactions efficiently, ultimately impeding widespread adoption and real-world applications of blockchain technology.

Newer blockchains such as Aptos and Sui, developed using Rust, have introduced a groundbreaking Layer-1 scaling solution known as parallel processing. This innovation significantly enhances scalability by allowing multiple transactions or tasks to be executed simultaneously within individual blocks. Unlike Layer-2 solutions that build upon existing blockchains, Layer-1 solutions such as parallel processing directly optimize the blockchain’s core protocol. This approach fundamentally increases transaction throughput and network efficiency, paving the way for nearly limitless scalability and improved performance, thus addressing a major limitation of traditional blockchain systems.

In older blockchains, all the present nodes in the network process all transactions individually. The new transactions that are recorded on the blockchain are all present in the mempool. All of the nodes create new blocks using the same transactions. So, this means the more nodes in the network, the more decentralized the network is.

But this does slow down the network because instead of leveraging the processing power of the nodes in the network to divide and process the blocks to enhance speed, all the nodes are essentially processing the same transactions and a lot of computational energy is used up.

Aptos (the new blockchain we talked about) processes pending transactions from the mempool. At the same time, the nodes in the network divide these transactions among themselves and process different transactions instead of processing the same transactions. This makes the process way more efficient and highly scalable at the same time since the more nodes you add, the more transactions you can theoretically handle. Adding more nodes speeds up the network rather than slowing it down (as in the case of older blockchains).

Layer 2s and side chains

Sharding, consensus, and parallel processing are all Layer-1 scaling solutions. What if, instead of trying to scale at Layer-1, which may require us to make changes to the blockchain’s architectural structure, we try to solve the blockchain trilemma by building on top of the blockchain on Layer-2? It’s important to note that all the layers are imaginary and the terminology is used for better understandability.

An example of a Layer-2 solution is a sidechain, which is essentially a separate blockchain connected to the main chain. It’s set up in a way that assets can flow between the chain flawlessly. The biggest difference is that sidechains can be configured with different modes of operation and rules, which can make them way faster than the main chain.

Transactions can be shipped off to the side chain for faster speeds, but they may still be verified by the main chain once the side chain sends the output of the transactions back to the main chain.

ZK rollups and optimistic rollups

Rollups are another highly popular Layer-2 scaling solution for blockchains. They take the transactions off-chain and, at the same time, ensure storage on the main chain for high security.

The way they do this is by compressing the transaction data to a great extent so that it becomes a fraction of the size and can be stored very easily on-chain. This results in significant throughput enhancement. Prominent examples of this approach include Arbitrum (an optimistic rollup) and PLONK (a zero-knowledge rollup). These rollups employ different techniques but share the common goal of enabling seamless and secure scaling, making them pivotal in advancing the capabilities of blockchain technology.

Now that we have understood rollups, it’s time to talk about the two types of rollups: zero-knowledge (ZK) rollups and optimistic rollups. Optimistic rollups don’t need to provide any proof when sending the compressed transactions to the main chain, whereas ZK rollups need to submit cryptographic validation proof.

Since with optimistic rollups there is no validation proof being submitted, they are essentially operating on the assumption that the nodes are not going to submit any fraud transactions, and this is why these are called optimistic. On the other hand, ZK rollups assume that they have no knowledge of the type of transactions that can be submitted, and thus comprehensive crypto validation is required.

Now that we have learned about blockchain basics, let’s now understand how smart contracts work.

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