TOP Network x NEAR Protocol Whiteboard Session | Part 1

A few weeks ago, NEAR Protocol invited TOP Network to attend a whiteboard session at NEAR’s headquarters.

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

For those of you who don’t know, NEAR Protocol is a PoS-based public blockchain being built by a team of experts in traditional database sharding. During the whiteboard session, NEAR Protocol’s CTO Illia Polosukhin and TOP Network’s CTO Taylor Wei went deep into some of the specifics of TOP Chain. In this article, we’ll go through and explain some of the things they talked about.

Three-Layer Ledger 7:22

To begin, Taylor explained TOP Network’s three-layer ledger solution, and how the goal of this architecture is to provide three main qualities:

• High TPS
• Low or zero transaction fees
• Flexibility

The main chain is only used for financial settlement (transferring tokens). The service chains provide flexibility, and handle the business logic for each service. The off-chain component adds built in layer-2 functionality, which helps to greatly increase the speed of each service chain.

As Taylor noted, state-channels fit naturally with the billing methods of cloud communications functions. For instance, a VPN service is usually billed by the MB. In a single session, a user is likely to use many MBs data. Instead of making a transaction for each billing unit, it makes sense for clients and service providers to open up state-channels between them, so that all the billing units used in a session can be aggregated into a single transaction.

So for instance, if a client uses 100MB of data in a VPN session, instead of creating 100 separate service chain transactions, layer-2 methods can be used to aggregate multiple billing units into a single transaction. This can help to greatly increase performance, while also reducing costs.

Two-Layer Sharding 10:12

Taylor then went on to explain the structure of the main chain and each service chain. TOP Chain implements what we call Two-Layer Sharding. The general structure, which was written on the whiteboard, is shown below.

TOP Network’s sharding design differs in several ways to what many other projects are doing. Most sharding projects have a global Beacon Chain which helps manage numerous shard chains. TOP Chain is similar, but adds a few layers to this with “Clusters” and “Zones.”

Instead of the Beacon Chain directly managing every shard, some of the duties are dispersed among clusters. Each cluster is responsible for managing a subset of shards. As Taylor explained, the reason for this is to prevent the Beacon Chain from becoming a bottleneck. If the Beacon Chain has to manage every shard, and the number of shards keeps growing, it could become a problem in the future.

If clusters help manage shards, this will not be a problem, as each cluster only manages a limited number of shards. The final goal is to have a system which scales horizontally, meaning the chain will scale with increasing node count.

The concept of Zones is a bit less tangible. Zones are not groups of nodes, but are instead logical divides in the network. Zones help with routing efficiency, and can work to group nodes in similar geographic regions together. This helps to increase speed by reducing latency.

Why Clusters? 14:51

NEAR’s CTO Illia Polosukhin then asked some questions regarding why TOP chose to use this sharding design. In particular, why use clusters instead of just using shards? There are several reasons for this. One reason which Taylor explained is for extra security. Advanced Nodes, which reside in clusters, perform secondary audits on all transactions.

When a transaction is first initiated, the raw transaction is sent to the appropriate cluster based on the sender’s address. The transaction then gets passed to the correct shard where it undergoes a pBFT round. Once it receives ⅔ of Validator Node (shard node) signatures, this proposal is passed back to a committee of Advanced Nodes in the cluster for an additional audit.

By using the original raw transaction as a comparison, the Advanced nodes can make sure the shard has not been overtaken by malicious nodes attempting to send a faulty transaction. If the audit passes by obtaining ⅔ of the signatures of the Advanced node committee, it will be passed back to the shard where it can finally be added to the shard chain.

Taylor then elaborated on how using both shards and clusters adds additional difficulty for attackers. The reason being that it is very hard for Validator nodes in a shard to know which Advanced nodes in a cluster will be auditing the transaction. As Taylor mentioned, committee selections are totally random through use of Verifiable Random Functions (VRF), which makes it impossible to know beforehand which nodes will be auditing the transaction, making collusion between Validator nodes and Advanced nodes practically impossible

We’ll continue the analysis in part 2. Stay Tuned!