TOP Technical Spotlight | Consensus Mechanisms: Service Chains (Part 2)
Each service chain is built to handle a distinct use case, and adopts one of several tailored consensus mechanisms developed predominantly for cloud communications services. The four consensus mechanism currently utilized by the TOP service chains are: Proof-of-Bandwidth, Proof-of-Calltime, Proof-of-Delivery, and Proof-of-Storage. In the future, additional service chains can be implemented to handle applications in other industries such as gaming and eCommerce.
The purpose of PoB is to ensure that the service nodes and the client are in agreement on the amount of bandwidth used during any given session. The Proxy and CDN service chains both make use of PoB. Let’s use the Proxy service chain which is used for VPN services as an example to see how PoB works from a high-level. Each time a client — typically a DApp — uses a VPN service on TOP to connect to the Internet, it involves at least three relay nodes and one Proxy server. The client will first enter into a service agreement with three randomly chosen relay nodes, and one proxy server. The traffic is sent between two transmission paths as shown:
Since the relay nodes are picked randomly, they are not familiar with each other, and only know the contact information of the next node in the transmission path.
The billing unit for the VPN service is 512KB of data. For every 512KB of data the client uses to browse the Internet, a billing unit is added to a service record. However, before a billing unit is confirmed and added to the service record, all parties must agree on the amount of data that was actually used. Once the service nodes involved transmit 512KB of data, they will submit proof to the client. The client then confirms if this is true or not, at which point two things can happen.
- If the client is in agreement with the amount of data consumed, a billing unit is added to the service record.
2. If the client does not agree with the amount used, the connection is cut, and a dispute is filed.
In case 2, the service nodes might show proof that 512KB was used, but the client only confirms its use of 256KB. In this sort of disagreement, only 256KB-512KB worth of value is at stake. This has a low chance of occuring, and the amount of potentially lost bandwidth is essentially negligible. To mitigate losses, when a client enters into a service agreement, they must offer a deposit as collateral, while the service nodes need to make a deposit on joining the network. If a service node or client attempts to cheat, some of their deposit could be confiscated, making it financially unfavorable to lie about the amount of bandwidth provided or consumed. Additionally, malicious service nodes could lose reputation or even be booted from the network permanently.
In a single VPN session, a service record might contain a large number of billing units. Instead of logging the entirety of all service records with all of their contained billings units on the service chains, off-chain processors combine them into a service log containing detailed information of the services used. This service log is then stored in TOP’s decentralized storage network, which is monitored by a network of validators. For payment and settlement, a billing record is generated that could combine multiple identical service records, which is then submitted as a single service transaction to the service chain. For instance, if the client used one hundred 512KB blocks of data, those one hundred records could be merged into one single record. This merged billing record is then submitted to the service chain as a single transaction, to be subsequently settled on the mainchain. This reduces the number of on-chain transactions needed.
Proof-of-Calltime is used in the Rich Communications Services (RCS) service chain, and the VoIP service chain. The point of Proof-of-Calltime is to verify the duration of calltime provided by the service nodes, and to ensure all participating nodes are in agreement. Proof-of-Calltime works in a similar fashion to PoB. When a client is using a service that requires calling, it enters into a service agreement with a random relay node and a VoIP node. The billing unit for VoIP calling services is 1 minute of calltime. After a service node provides 1 minute of calltime, it submits proof to the client. The client either confirms 1 minute of call time has elapsed, or disagrees, in which case the connection is cut, and a dispute is filed. If either party is cheating, they could automatically lose a portion of their deposit.
Proof-of-Delivery is used in the RCS service chain. The purpose is to verify the number of messages delivered by service nodes, where each message is considered a billing unit. Similar to PoB and Proof-of-Calltime, the service nodes submit proof they delivered a message, and the client confirms. If there is a disagreement, the connection is cut between the client and service nodes and a dispute is filed, where one party may end up losing some of their deposit.
In a decentralized storage network, files are partitioned into many smaller pieces and distributed to different nodes across the network. The goal is to allow anyone with spare storage space to become a service provider in the TOP storage network. The challenge is incentivising and rewarding these storage service providers fairly for the amount of disk space they provide, and the amount of time they store it for. The fragmented files must also be replicated across several nodes to ensure the data is not lost in the case a node goes down or clears its memory. This is why projects such as Filecoin have been developing unique consensus mechanisms such as Proof-of-SpaceTime (PoSt) and Proof-of-Replication (PoR) to account for these challenges. TOP uses similar consensus algorithms, however a full discussion will be reserved for another article, as Proof-of-Storage mechanisms are quite complicated.
This article has provided a high-level overview of how the main chain and service chain consensus mechanisms operate. The actual protocols are more detailed, and account for various situations. However, note the general idea. The service chains only log billing records, which are then financially settled on the main chain. The worst that can happen with a service chain consensus mechanisms is that a few billing units worth of value — which is an extremely small amount — could be compromised, whether intentionally or due to system malfunction. Even so, they are reasonably secure, and utilize various fail-safe mechanisms to ensure minimal or no loss.
Since each service chain “consensus round” has very low stakes, it allows for more simplistic and high-throughput consensus mechanisms. It would be foolhardy to attempt to ensure every KB of data, every message, or every second of calltime is unequivocally insured by creating an extremely secure algorithm that ends up ruining the user experience. Comparing this to financial transactions, a single botched asset transfer could be catastrophic, and so the consensus mechanism must be airtight.
The separation of financial and service transactions is in part what allows TOP Network to handle the extremely high transaction volume that real-world applications generate. Through use of its highly secure main chain with tailored service chain consensus mechanisms, TOP Network will seamlessly port 60 million users to the platform once ready, making it the first blockchain platform to successfully handle massively adopted consumer applications.
About TOP Technical Spotlight
TOP Technical Spotlight is a series that highlights specific features of the TOP Network stack, with the goal of giving the reader a deeper understanding of how the technology works, and the benefits it provides. We aim to produce articles that are geared for the technically inclined, but also simple enough for a non-technical audience to follow along. Through producing these articles, we hope to encourage more fruitful and engaging discussions within the community.