This text has the aim to be understandable & to give the tech-interested trader a basic understanding of sharding. Therefore not every single technical aspect of sharding is described.
Right now, every single node on the (e.g. Ethereum) blockchain has to process every single transaction of the whole network. While this is good for the security of the network, it is either limiting scalability (read speed) or decentralization. Why decentralization you ask? Well, the network is only as fast as its slowest part (node, computer, whatever you wanna call it). And if you raise the bar, only the fastest and most expensive supercomputers can serve your network. Which in return, reduces decentralization.
It seems like a Trilemma, where you can only have 2 of 3 options.
That's one of the main reasons why Bitcoin is providing only 3-7 transactions per second (tps) and Ethereum 7-15 tps. That is not much for a global network striving for adoption. Does anyone remember CryptoKitties?
Over the years, processed transactions have risen. This is a logical consequence of more widespread usage. This clearly shows the main problem: blockchains need to be able to handle more tps! This is what we are referring to when we talk about scalability. For example, VISA alone is handling around 2,000 tps. But yes, VISA is not decentral and don’t ask me about security…
You probably know that when a node processes a transaction, it has to tell all other nodes in the network about this transaction. And then all other nodes have to check if this transaction is valid. This slows down the process. And the larger the network gets, the slower it becomes.
Now, let's talk about sharding!
In sharding, we basically divide the network into smaller sub-networks (shards). These shards are a bunch of nodes working together. A transaction is then assigned to a specific shard and approved by that shard. If successful, it gets reported to the main blockchain (root). The throughput of all shards combined is much higher than if a „single shard“ has to do all the work (which kinda is the situation right now).
Sounds great, but what if we divide the network in, let’s say, 100 smaller sub-networks, don't we create the possibility of a 1% attack, where only 1% of the network hash rate is enough to dominate a single shard and change the truth? One solution to this problem could be that the transaction gets randomly assigned to a validator. That way, you can’t validate your own transaction. However, this is still an area under heavy development. But for Ethereums future, „Proof of Stake“ will make solving this problem a bit easier.
But what happens if sender & receiver are not within the same shard? Good question! Because the basic idea was to divide the network into independent sub-units to increase speed, not to let each shard talk to other shards validate everything again. For this problem, a possible solution is the „receipt paradigm“, where a transaction inside a shard will not only change its own state but also create a „receipt“ which is stored in a shared ledger that can be seen by every other shard (but not modified by them). That way a single shard can make information accessible for other shards before the transaction is completed and written to the main chain.
I don’t want to shill ETH, but Vitalik Buterin once said in an interview, that Sharding and Plasma together can bring the current 15 tps up to 150,000 tps. You see, the increase could be huge if successfully implemented.
Even more fun is Superquadratic-Sharding, where you divide the network further into sub-sub-levels or shards of shards. This would not only incredibly increase the speed, but also drive the transaction costs almost down to zero!
The good thing is: sharding is executed at the protocol layer (behind the scenes so to say). So once Vitalik and his boys have figured it out, developers of apps or wallets don't need to get their heads around it.
Want to know more in detail? Check: https://github.com/ethereum/wiki/wiki/Sharding-FAQs
There are also other ideas on how to improve scalability. You might want to have a look at „Increasing the block size“, „Segwit“, „Plasma“, „Proof of State“ or „Off-chain state channels“. Each of them has its own pros and cons. Just a quick opinion: Increasing the block size is only a short term solution, if at all!
If you find this article useful please consider giving it a star, as this keeps me motivated to write more articles. Thank you very much for reading!