Sharding has morphed from an obscure concept in 2017 into the buzz-word of 2018. The need for blockchain scalability has become glaringly obvious, and several projects have turned to Sharding as a solution.
However, Sharding a blockchain is not a simple task. In fact, it poses challenges that have our best thought-leaders scratching their heads. Several projects have made lofty promises of future scalability using Sharding. But, only few have provided a viable Sharding solution for mass adoption. RadixDLT is one of the rare projects that brings forth a novel approach to Sharding –– an approach that seeks to meet the demands of mass adoption
Right from its conception, the goal for Radix was:
Every single person, on every single device using a single protocol simultaneously.
The RadixDLT Sharding architecture was designed (unlike other projects that approached Sharding “after-the-matter”) to allow for unbounded scalability while maintaining security, and maximizing decentralization.
In this post, I will explain how Sharding works in Radix in a simple way – without any technical jargon.
Break a window, and you have shards of glass. Break an iceberg and you have shards of ice. A shard is simply a broken piece of ‘something’. So, when you “shard” something, you’re simply breaking it into smaller pieces.
But, why do we shard? Well, you usually shard something because it’s easier to manage. For example, we ‘shard’ a large pizza because it’s easier to eat one slice at a time. It also allows us to share (distribute) the pizza with friends a lot easier.
Similarly, when a database gets too large to handle, we shard it and distribute it across multiple computers. There you go –– you now understand distributed computing & Sharding. It’s really that simple.
Sharding has been used to partition databases for a long time. You simply cut the database (think of an excel sheet) horizontally into several pieces and distribute across multiple “database servers” (machines that ‘serve’ you data when you need it). When the data needs to be retrieved or processed, the relevant database server is called upon to do the task.
In Blockchain these “servers” are what we call “nodes”. However, Sharding a decentralized system isn’t as straightforward as we’d like. There are complications that a centralized system doesn’t need to concern itself with.
Every distributed system requires a Consensus Method. But, developing a Consensus Method for a Sharded blockchain is tricky. You find yourself sacrificing security in favor of scalability.
Why? Well, a huge component of the security comes from the fact that every node stores all the data. Since every node keeps a copy of the entire database – you can’t cheat/lie about past events. But when you shard that database, each node stores partial data. Suddenly, you can tell Node Bob one thing, and tell Node Lisa another.
Remember when your Mom grounded you and your Dad didn’t know about it? If you were anything like me, you tried to sneak out by asking your Dad for permission. Dad didn’t have all the info. And you took advantage of it.
Mom and Dad represent a Sharded database. Sure, together they have all the info needed to run the household. But as individuals, they don’t – and can be lied to about past events (like you being grounded or not)
Founder & CTO Dan Hughes identified the scalability issues that would plague Bitcoin back in 2012. After several attempts at improving the protocol, he realized that the only solution is a brand new architecture and consensus method. Six years and a lot of sweat later, he brought us Radix DLT – a unique Sharding approach and consensus algorithm.
Radix DLT approaches Sharding in a unique but simple manner. Most projects take existing Consensus Methods and build a Sharding solution on top of it. But as discussed, this leads to sacrificing security. For example, Sharding on PoS network could result in a One Percent Shard Attack.
Radix, however , started with a Sharded network –– and built a unique consensus method on top of that network. This “Sharding-first” approach allowed them to bypass the limitations faced by other consensus methods.
RadixDLT Sharding
The RadixDLT network is sharded into 18.4 Quintillion shards of 2mb >>each – enough to store the entirety of Google’s data and throughput! And we all know that Google stores a lot of data. The goal was to have at least as many people using Radix as there are people using Google.
Essentially, Radix began with the end state in mind, which is: every single person on every single device using a single protocol.
Radix’s pre-sharded network serves as a fundamental around which they have designed their consensus method (Tempo).
The size of each shard, and the number of total shards are predetermined. Nodes then place themselves atop shards – and can overlap with other nodes in layers.
This is where it gets interesting…
Remember, every shard has already been created. They all live in the same “Universe” and their location ID is known. Every transaction is stamped with a blend of the sender’s ID and shard ID.
This makes it extremely simple to locate the Shard from which the transaction that has been sent. Now, if Node Bob tries to double-spend his $10, we don’t need to check every other shard to catch him cheating. We can simply check his shard.
To better understand this let’s go back to our Mom & Dad analogy
Your Mom grounds you. But this time, she stamps your forehead with the word “Grounded”. You now go to your Dad’s study room and ask him if you can out to play. Your Dad simply looks at your forehead and says “Nope”.
He didn’t need to go check with your Mom. He didn’t need all the info – and was still able to stop you from cheating.
Similarly, the overlapping of nodes and easy cross-shard communication allows each node to store partial info. Which essentially means: not all nodes have to store all the data! This plays a significant part in Radix’s massive scalability without sacrificing security.
(I simplified this, of course. But we will discuss more on Atoms, Universes timestamping & Temporal Proofs in future posts)
As mentioned earlier, the need to store and process every transaction is a huge limitation for blockchains. Radix is a cleverly designed network that avoids this limitation.
Radix has presented an innovative and noble approach to solving the scaling issues of DLTs.
Over six years of sweat and frustration, Dan Hughes and team remained true to the goal: Every single person, on every single device using a single protocol simultaneously. The project is still in alpha and the team urges us to participate and help find any potential issues or flaws.
Although this was an introductory explanation, I’m sure you can’t help but wonder... Will Radix DLT be the answer to the burning question for mass adoption? Time will tell.
Originally published at
Mango Research - Blockchain & DLT Simplified!
