Scalability and Blockchain

One of the most pressing matters in the development of blockchain is the scalability issue. The majority of blockchain implementations have yet to solve this age old issue, mainly because the nature of the decentralization itself. To understand what the relation between scalability and decentralization, we have to take a look at the core of blockchain itself: Distributed Ledger Technology (DLT).

Distributed Ledger Technology

Distributed Ledger Technology is a consensus of replicated, shared, and synchronized digital data that is geographically spread across multiple sites, countries, or institutions. There is no central administrator or centralized data storage. To achieve this, multiple nodes running in various sites talk with each other to create a consensus of which version of the ledger is valid.

One of the earliest ways to implement DLT was to totally replicate all data to each node. This made it easy for the nodes to agree on the correctness of data, because each node had a copy of all of the data. However, this was also the reason why there was no scalability: adding new nodes doesn’t speed up the whole network, as the new node also needs to have all the data.

Many implementations try to address this issue by increasing their throughput (the amount of transactions that can be done in a period of time) via forking: making a new network that is preconfigured to handle more transactions (by increasing the block size, reducing block time, etc.). But this also doesn’t solve the scalability issue. Why?

Definition of Scalability

The definition of scalability is “the capacity to be changed in size or scale.” To fork for a new network every time upscaling is needed does not fit that definition, because it doesn’t address the capacity issue; it just creates a new network that has a bigger capacity. To illustrate, imagine buying a newer, faster, and better computer every time your computer slows down running an application. Replacing the old computer doesn’t mean that it scales, but adding a new computer to work together with the old one does.

Blockchain and DLT are actually scalable, but just not in throughput. By definition, the DLT is actually very scalable in terms of security, as adding new nodes to the network makes it more difficult to “cheat” the network. But in the throughput department, it is difficult to make it scalable because of the speed-security tradeoff: when the throughput is scaled up, the security actually goes down.

Proposed Solution

There are a lot of ideas floating around for solving the scalability issues. This article explains some ideas in a clear and detailed manner. In our perception, the most promising solution is sharding.

The simple explanation of sharding is that the network is divided into multiple shards. Each node connected to the network is put into one of these shards, and each shard is responsible for a certain kind of transaction. Because of this division, nodes no longer have to process all of the data, but just the part their shard is responsible for.

The main obstacle for sharding is determining which transaction belongs to which shard, so that inter-shard transactions are minimized. Ideally, this is done at the protocol level, so that dApps (decentralized Applications) don’t notice the sharding process. But while we’re waiting for the sharding solution to mature, we could implement it directly in a dApps algorithm.

So how can we create sharding in a network where every node replicates all the data? We don’t! To create a makeshift-dApps level-sharding solution, we would need to treat the entire network as a shard. Thus as a prerequisite, the dApps itself should be multi-network first, and then we can treat a whole network as a shard.

The Multi-chain Solution

Decentralized applications need to be decentralized to begin with, and it doesn’t get more decentralized than distributed across multiple blockchain networks. In applications, there are bound to be several components that build up into a complete application. Some of the components need to be secure, while others need latency and speed more than security. The same can be said about a blockchain network: some big rigid networks have the utmost security with a low throughout, while others have more throughput with less security.

This can translate into having different components in different networks, creating a multiple network (multi-chain) decentralized application. The components can talk to each other via inter-network connectivity, such as an oracle service. However, the problem is usually that the oracle service can’t talk directly to another network, and unless that services is available, components will not be able to talk to different networks.

To solve this problem we can provide an internet-facing interface for each component, so that the oracle service is communicating with this interface. If needed, we can create a separate auditing component to make sure that the interface is working properly.

Afterword

The solution to the scalability issue is not a trivial one, and needs various implementations and testing. The development of blockchain and dApps is also a long, hard, and ever-changing process, but nevertheless needs to be done.

At HARA, we are looking into a customized sharding solution started with our multi-chain ERC-20 token. We are using one token component in the public Ethereum network, and another one in our private network, which will connect to the other parts of the ecosystem. We believe this solution will provide us with the scalability we need. Stay tuned for more details of our multi-chain solution!

Check and Contribute to our solutions on our Github!

We at Hara invite and encourage you to check our solutions and feel free to contribute to our decentralized solutions.

Join our community on Telegram!

Learn more about HARA

• Visit the HARA website
• Read our White Paper
• Join our Telegram Community
• Follow our Social Media
  Facebook, Twitter, Instagram, Medium & LinkedIn