Sharding is a clever way to address both the network latency and bandwidth problems, which clearly constrict blockchain’s scalability. It is well worth exploring the benefits of sharding and how it can improve some of the limitations of blockchain.
There are two major versions of sharding being used.
- Partitioned sharding, where shards don’t communicate with each other directly through a central relay
- State sharding, where shards communicate with each other through a state, or central, relay
There are quite a few interesting projects working on alternative implementations of sharding technology. We explore the four leading projects below.
|
|
Ethereum | NEAR | Polkadot |
Zilliqa |
|
Sharding type |
State | State | State |
Partitioned |
|
Name |
Beacon Chain | TxFlow | Parachain | BFT sharding |
|
Benefits |
Partition linearly reduces the requirement on all compute power, storage, and network bandwidth | Partition linearly reduces the requirement on all compute power, storage, and network bandwidth | Computations performed by each shard are inherently independent, increased network capacity. |
Exponential scalability increase due to increased processing power and distribution of information. |
| Risks | Lower data availability, cross-shard transactions required to validate data | Lower data availability, cross-shard transactions required to validate data | Lower data availability and security due to disperse mining, no way to validate date between shards |
Processing payments becomes very complex once the state is shared among shards, Dapps won’t execute transactions that affect the same smart contract in parallel |
Ethereum’s Beacon Chain
The Beacon Chain is part of the Ethereum 2.0 Serenity roadmap. The Beacon Chain is the “main chain” of the Ethereum’s upcoming Casper PoS system and its main responsibilities are to:
- Store and maintain the set of active, queued and exited validators
- Process crosslinks
- Process its own block-by-block consensus, as well as the finality gadget
The key function of the Beacon Chain is to manage the proof-of-stake protocol for itself and all of the shard chains. There are a number of aspects to this, including:
- Managing validators and their stakes
- Nominating the chosen block proposer for each shard at each step
- Organising validators into committees to vote on the proposed blocks
- Applying the consensus rules
- Applying rewards and penalties to validators
- Being an anchor point on which the shards register their states to facilitate cross-shard transactions
NEAR sharding
NEAR’s primary goal is to create almost real-time cross-shard transactions while keeping clients sufficiently light. Any low-end device should be able to run a node that operates a part of the network and processes a subset of the transactions. NEAR is a sharded proof-of-stake blockchain, highly scalable, and their approach allows nodes to run on low-end hardware, giving the network access to billions of additional devices, each of which makes it even faster.
The main problems are ensuring data validity and availability . Blocks are meant to be accompanied with a proof of validity that remains available to anyone to check for at least a certain period of time. Validators are responsible for ensuring the proof remains available. Unfortunately, it’s not possible (or at least very difficult) to prove that messages which were supposed to be sent haven’t been, without moving the message on-chain. The only way found to circumvent this issue is by having a more centralised infrastructure and governance setup.
Polkadot’s Parachain
In order to achieve an effective distributed database sharding, Polkadot uses a technology called Parachain.
A parachain (parallelisable chain) is a simpler form of blockchain. It attaches to the security provided by a relay chain, rather than providing its own. A relay chain not only lends security to attached parachains, but also provides a guarantee of secure message-passing between them. One key feature of parachains is that the computations they perform are inherently independent. Fully generalised systems of turing-complete smart contracts run into issues in determining which transactions will collide with each other. This means transactions which could potentially be parallelised are often run in sequence, wasting valuable computation time. Drawing clear boundaries between parachains means that we can execute all of them at once without fear of collision . If we have 10 parachains, we can perform 10 times the work using the same source of security.
Highly-specialised parachains have another purpose. They can implement data storage and transaction operations in a most efficient manner for their problem domain, without being shoehorned into a blockchain-specific scripting language or virtual machine. It’s possible to create parachains which have their own parachains, and so on. This creates a tree-like structure that can be used to perform highly distributed computations – without reducing the overall burden on the root relay chain itself.
The main issues are also data availability and validity.
Zilliqa BFT sharding
The way Zilliqa is trying to implement sharding is through a completely different path than Ethereum. The way it’s implemented follows the below logic:
- Execute all the single-shard transactions in parallel
- Do not execute transactions that affect the same smart contract in parallel
- Do not execute any transaction that affects more than one shard in parallel with any other transaction
In essence, Zilliqa’s proposal does not use a central coordinator, however, it makes sApps needing to reside in most of the shards, taking away its key advantage.
Conclusion
As businesses look to improve on the limitations of blockchain, more projects that use sharding will come to light. By addressing scalability issues, blockchain will become more attractive to a greater audience and eventually take a further step towards mainstream adoption.
Disclaimer: The views and opinions expressed by the author should not be considered as financial advice. We do not give advice on financial products.