TOP Network x NEAR Protocol Whiteboard Session | Part 2

Let’s continue the analysis of the whiteboard session and discussion between TOP Network CTO Taylor Wei and NEAR Protocol’s CTO Illia Polosukhin. Part 1 can be found here.

The whiteboard session can be found here: https://www.youtube.com/watch?v=PXLjORNlqlE&t=1s

Dynamic Sharding 22:27

After digging into TOP Network’s overall sharding design, NEAR’s Illia Polosukhin had a few questions regarding security. The conclusion was that in order to produce malicious blocks, ⅔ of the nodes in a shard and ⅔ of the nodes in its governing cluster would need to be malicious. Taylor then went on to explain how this is prevented, and part of the reason for having two layers of sharding.

TOP Chain employs dynamic sharding. This means nodes are continuously reshuffled throughout shards and clusters. Taylor used the fitting analogy of nodes flowing like water between shards/clusters. Dynamic sharding is an important concept in TOP’s sharding design, so let’s take some time to go over it.

Dynamic sharding prevents what’s called “Adaptive Adversaries” from taking over shards and clusters. Adaptive adversaries attempt to slowly take over a particular shard or cluster by finding out which nodes are within that shard/cluster, and then bribing or extorting them to hand over their private keys. This is a very unlikely process on its own, but if a shard/cluster is static — meaning it always contains the same nodes — it is possible over a long enough period.

With dynamic sharding, this becomes extremely difficult. Even without dynamic sharding, finding which nodes reside in a shard or cluster is difficult on TOP, as the internal network is hidden behind the Edge Network. Recall that Edge Nodes are the ones that connect with clients and relay transactions to the Core/Routing Network. Additionally, it is not beneficial for an attacker to simply attack a shard on TOP Chain. They must attack the shard, and the governing cluster, as the cluster will prevent anything bad from happening in the case that a shard sends out malicious blocks.

Let’s suppose that an adversary targets shard 1 and cluster 1. To do real damage, the attacker would need to bribe/take over a ⅔ majority of nodes in shard 1 and cluster 1.

With dynamic sharding, the attacker is on a time limit. As Taylor explained, shards and clusters are partially reshuffled every 30 mins. The attacker would need to find out which nodes are in shard 1 and cluster 1, contact them and bribe them to help them collude, and then initiate a coordinated attack in a time span on the order of 30 mins. However, just 30 minutes after the adversary started the attack process, the system would look something like this:

This shows why this kind of attack is practically impossible on TOP Chain. Attacks from adaptive adversaries require time to take control of nodes within a particular shard (and cluster in the case of TOP). However, by the time they figure out which nodes are in which shards/clusters, gain contact with the nodes, and then collude, bribe, or steal their private keys, the original shard/cluster looks completely different. The nodes they manage to win over will be shuffled to another shard, which renders them useless.

This is just a toy example. In the real implementation, nodes are shuffled randomly, and there are a minimum of 127 nodes per shard and cluster.

Synchronization

While dynamic shuffling provides great security, it causes another issue. Every time a node is shuffled into a new shard or cluster, it must synchronize with the new state. This can require a great deal of bandwidth, and if the state continuously grows, it will require more and more time for a node to synchronize.

As Taylor noted, TOP Chain gives nodes a 15 min period to synchronize with their destination shard/cluster. If the state continuously grows, this time period would eventually not suffice. However, TOP Chain employs a lattice data structure which helps solve the issue. Essentially, each account has its own chain, and the state of each account is fully specified by the last entry (the account balance). This means that nodes only need to synchronize the last entry of each account chain, which greatly reduces bandwidth load. It also means that the state required to be synchronized does not grow with time.

We’ll finish the rest of the analysis in part 3. Stay tuned!