TOP Network x NEAR Protocol Whiteboard Session | Part 3
In this article, we’ll finish up the analysis of the whiteboard session and discussion between TOP Network CTO Taylor Wei and NEAR Protocol CTO Illia Polosukhin. Click here for Part 1 and Part 2.
The whiteboard session can be found here: https://www.youtube.com/watch?v=PXLjORNlqlE&t=1s
Beacon Chain Time Blocks 26:50
At this point, Illia posed the question asking why the beacon chain is even needed when clusters directly manage shards. He was essentially asking the following:
It turns out the beacon chain is still necessary. On TOP, the beacon chain acts as a global clock that all nodes in the system can reference, and also handles voting, elections and more. Why is this global clock needed? Well one reason as Taylor pointed out is to prevent shards from producing blocks ahead of time, holding them, and then releasing them all at once to try and create a fork.
This is prevented using beacon chain time blocks. Every node in the system is distributed the latest time block, which are produced every 10 seconds. Each shard block must include a reference to the latest beacon chain time block. This means blocks cannot be produced ahead of time because they must wait for the latest time block to reference. Cluster nodes can easily audit shard blocks to see if they have been produced with the correct time block reference, as all nodes are distributed each time block.
Zones 29:20
As mentioned in part 1, Zones help organize nodes more efficiently. In random networks like Bitcoin, node connections could end up being between geographically distant nodes, which can reduce performance. On TOP, nodes are grouped together into zones, based in part by which region they reside in. The question Illia asked is who decides which zone a node will end up in?
Taylor explained that the beacon chain nodes are responsible for this process using something called Proof of Bandwidth (PoB). Beacon chain nodes will check a new node’s network conditions using this PoB process to see where it should end up.
However, Taylor stressed that node sorting is still random. A node’s network properties only give it a higher chance to end up in a particular zone. The result is that performance is improved, as nodes in the same geographic region are more likely to end up in the same zone, which in turn helps reduce latency.
Cluster Audit Subsets 39:19
Another question Illia brought up had to do with how clusters audit transactions. When a transaction is confirmed by a shard, it gets sent to its parent cluster. Here, a subset of all the nodes in the cluster is chosen at random to form a committee. This committee audits the transaction, and then a confirmation receipt is passed back to the shard. Illia asked what would happen if a shard sent two transactions for the same account at the same time, and two different subsets of cluster nodes received them.
For instance, say a transaction sending 1000 tokens from account A->B, and another transaction sending 100 tokens from account A->B, were sent for auditing at the same time. If different subsets within the cluster received each transaction, which transaction would go through? The potential problem is that both sets of auditing committees are unaware of the other transaction, so they will both see the given transaction as valid.
This is actually not an issue as Taylor explained. An auditing committee subset has a size of 61 nodes, while the total number of nodes in a cluster is at minimum 127. When an auditing committee finishes the audit process, all the nodes in the cluster which were not part of the committee (127–61) are sent the receipt, and they deliver it back to the shard. This allows cluster nodes which are not part of the audit process to see if a transaction at the same height was already processed, meaning only one of the transactions in this scenario can ever be confirmed.
You might ask, why choose a subset instead of just having all the nodes involved in the auditing process from the onset? The reason is that having a smaller group of nodes perform the pBFT audit helps increase performance.
The whiteboard session was likely a bit too technical for the average community member. However, even the non-technical community member can gain an appreciation of all the different facets that the developers must account for. The questions NEAR’s CTO Illia Polosukhin asked were the type of questions the development team is constantly having to ask and account for. Rest assured, this type of introspective analysis happens on a daily basis. Now, after many months of debate, iteration, code auditing, and man-hours, TOP Chain is finally about ready to launch, and we could not be more excited!
