TOP Network vs. Ethereum 2.0 | Part 2

As noted in part 1, blockchain sharding is incredibly complex, and there are numerous facets that most onlookers do not consider at first glance. On the surface, sharding seems relatively straight forward. Just divide the consensus network into many groups and process transactions in parallel. However, it turns out things are much more complex than they seem.

Sharding Challenges

Beacon Chain

Almost all projects implementing sharding use some sort of master chain, root chain, beacon chain etc. Having a central managing chain helps to solve many of the issues introduced by sharding, while also increasing performance. However, the Beacon Chain is usually the most resource intensive chain to run, even though it does not typically include transactions. Instead, it is used to orchestrate the shard chains, which themselves include transactions.

This presents an issue. How do you incentivise individuals to run Beacon Chain nodes? This is one of the most contentious parts about Ethereum 2.0. As of now, there is no method to reward Beacon Chain nodes on Ethereum 2.0, and Beacon Chain nodes do not receive transaction fees. We’ll compare the Beacon Chains of TOP Network and Ethereum 2.0 in part 3.

Storage Bottleneck

One of the biggest challenges associated with any high-throughout blockchain is storage space. Since sharding greatly increases the transactional throughput of a blockchain (TPS), this is something that both Etheruem 2.0 and TOP Network must contend with. As TPS increases, the rate at which the blockchain grows also increases. If a blockchain is able to process thousands of transactions per second, the size of the ledger will balloon to an astronomical size over time, even with state sharding.

The minimum size of an Ethereum transaction is about 100 bytes. If Ethereum is able to scale to say, 20,000 TPS, the total size added to the blockchain each day will be about 173 GB! Even with 200 shards, that would be around .9 GB added to each shard chain every day, or 328 GB each year. Without a solution, storage costs would eventually make operating nodes unfeasible for individuals, which would end up causing centralization.

TOP Network’s dual-lattice data structure helps solve this problem by allowing for real-time pruning.

Cross-Shard Transactions

Splitting a single blockchain into many loosely coupled shard chains introduces what are called cross-shard transactions. Whenever an account in one shard sends tokens to an account in a different shard, a special process is needed to execute the transaction. The speed of this type of transaction is heavily dependant on the network architecture.

Cross-shard transactions are a huge challenge, both from a security and performance perspective. As we’ll see in part 3, TOP has a unique layered network architecture with multiple types of nodes which specifically address the issues surrounding cross-shard transactions. Ethereum 2.0 has yet to specify the full details on how and exactly when they will introduce cross-shard transaction capabilities, although it is known to be sometime after phase 2, which will not come before 2021.

Staking

Staking in a sharded system must be carefully designed. If staking requirements are too high, then the network will not gain enough nodes, or the network will centralize around a few rich entities. If the requirements are too low, then Sybil Attacks become a problem.

For sharded systems in particular, it is very important to grow a large node count. Each shard must have a minimum number of nodes, otherwise security will become an issue. This is why it is important to adequately incentivise nodes to ensure that a large enough number of nodes join the network.

Security and Fault Tolerance

As described in previous articles, one major issue with sharding is that splitting the consensus network into smaller groups inherently reduces security. The BFT-PoS consensus mechanisms used by Ethereum 2.0 and TOP Network both have a fault tolerance threshold of 33%. In a given consensus group, as long as no more than 33% of nodes are faulty or malicious, consensus will run smoothly.

To see how this changes with sharding, consider a non-sharded blockchain with 100 validators. If this group of 100 validators is split into 4 shards, each shard will contain 25 nodes. Each shard still uses the same consensus mechanism to verify transactions, so now a malicious entity would only need about 9 nodes (33% of 25) to take over a single shard. Before sharding, a malicious entity would have needed to acquire over 33 nodes to do anything malicious. So the overall Fault Tolerance threshold was reduced from 33% to 9% as a result of spitting into 4 shards. Overall Fault Tolerance as a function of the number of shards is shown in the graphic.

This issue is so notorious that it has been given its own name: The Single-Shard Takeover Attack. We’ll see the approaches taken by TOP Network and Ethereum 2.0 to deal with this issue in part 3.

Next we’ll get into the specifics on how TOP Network and Ethereum 2.0 tackle these challenges, and how their approaches differ. For some of these challenges, Etheruem 2.0 has yet to provide solutions. As for TOP Network, all of these challenges have already been hashed out, which is why TOP Network will launch long before Ethereum 2.0.