TOP Technical Spotlight | Consensus Mechanism: Main Chain (Part 1)
TOP Network is a public blockchain platform that is designed to handle massive amounts of volume from large-scale consumer applications. In particular, TOP Network is initially being built to provide cloud communications services, which are typically associated with an immense amount of transactions, messages, and data transfer. Each communication function is different, and has a distinct business workflow. To account for this, the TOP blockchain employs a flexible three-layer ledger architecture which includes: The main chain, service chains, and off-chain ledger processors. The main chain handles all financial transactions, while the service chains handle service transactions from various cloud communications applications. The off-chain processors are built to process and store the extremely large amount of business data that cloud communications applications generate.
Why Separate Financial and Service Transactions?
Financial transactions and service transactions require different levels of security. With financial transactions involving asset transfer, there is much at stake. If something goes wrong, or someone is able to compromise the system even temporarily, potentially millions of dollars could be lost or stolen. For this reason, financial transactions must be extremely secure.
For service chain transactions, the stakes are not as high. A service transaction usually involves logging a billing record showing the quantity of a service used by a DApp, such as the number of messages, MB of VPN data, call time etc. These types of transactions are not as high-value, which means they do not necessarily require the airtight security a financial transaction processed by the main chain needs. As an example, consider the VPN service where the billing unit is 512KB of data. While in rare cases it may be feasible to misappropriate a single billing unit, 512KB of VPN data has extremely low monetary value, so there is little to gain by any party.
Because of these differing standards, financial and service transactions are confirmed using different consensus mechanisms. The main chain consensus mechanism must be very secure, while in general the service chain consensus mechanisms trade-off security for throughput and flexibility. This allows service chains to handle complex, high volume cloud communications applications. If every action from a cloud communication service was treated with the same standards as a high-value financial transaction — as is the case on Ethereum and Bitcoin — it would be impossible to keep up with real-world application volume. Since all financial settlement involving billing and asset transfer is settled on the main chain where security is very high, there is little risk involved with this system.
Financial Transactions
On TOP Network, all financial transactions are handled by the main chain. The consensus mechanism used by the main chain must not only be extremely secure, but also provide sufficient throughput for micro-payments involved with high volume applications, such as those using cloud communications services. For these reasons, TOP implemented a unique pBFT-DPoS* consensus mechanism. Let’s see why TOP chose this particular consensus mechanism, and what benefits it provides.
pBFT
pBFT stands for Practical Byzantine Fault Tolerance. The name refers to a quandary called the Byzantine Generals’ problem. At its core, the Byzantine Generals’ problem articulates the dilemma of how a group of Byzantine generals communicating at a distance can reach a consensus on whether to attack a city or not, given that there could be some traitors in the group. As it relates to distributed computing, it asks how can a group of nodes reach a consensus on some computation or state given that a number of them may be down or malicious (Faults). Byzantine Fault Tolerant (BFT) consensus algorithms aim to deal with this issue. The key takeaway from this family of consensus algorithms is that in order to reach consensus, the proportion of honest nodes must be greater than or equal to ⅔ of the total number of nodes participating in consensus. This means the number of dishonest nodes must be less than or equal to ⅓ of the total number of nodes, which is the tolerance for faults within the system.
pBFT is an optimized BFT algorithm. It was developed to hold up in turbulent environments like the Internet. Let’s see generally how transactions are processed by a group of consensus nodes using a pBFT algorithm.
- The client sends a candidate transaction to one of the nodes, sometimes referred to as the leader.
- The leader multicasts (sends to every other node simultaneously) the candidate transaction to the backup nodes.
- Once the transaction receives the signatures of more than ⅔ of the nodes, the transaction is considered confirmed.
In pBFT systems, all the nodes are in direct communication with each other. As a result, there is very low latency from the time a candidate transaction is proposed, to the time it is propagated to all the nodes in the network, and then subsequently confirmed after receiving ⅔ of the signatures. Unlike PoW systems, once a transaction is confirmed by the pBFT algorithm, it has instant finality. Finality means that the moment a transaction is confirmed and the nodes agree upon the state, it becomes irreversible at that point. There is no need to wait for additional block confirmations as in PoW systems like Bitcoin to be sure that your transaction won’t be reversed. This quality is crucial for real-time applications that cannot wait minutes — or even more than a few seconds — for a transaction to have finality.
The benefits of pBFT are high throughput and instant finality. Also note that there is no mining process in pBFT, and so energy expenditures are minimized. However, there are some downsides. pBFT nodes must be in constant and demanding communication with one another. The required bandwidth increases exponentially with the number of nodes, which means the network must remain small, with 21 nodes the commonly used maximum number.
The TOP main chain is sharded, which means the consensus nodes are divided into separate groups that confirm transactions in parallel. Each group consists of 21 active consensus nodes, with 9 standby nodes in case one of the active nodes is found to be malicious or goes down. The issue is consensus networks with a small number of nodes are more susceptible to Sybil attacks, which occur when a malicious entity creates many nodes in an attempt to compromise the system by breaking the assumption that greater than ⅔ of the nodes are honest. There is nothing in the pBFT algorithm that prevents this, and there is not much to lose for a would be attacker. Clearly, pBFT is not sufficient on it’s own.
Where does DPoS* fit into this
For pBFT to work in a permissionless environment, there needs to be a way of preventing Sybil attacks in networks with a low number of consensus nodes. One method is to make it more difficult to become a consensus node, which deters malicious entities from attempting to create large numbers of nodes. Delegated Proof of Stake (DPoS) is a system in which nodes are delegated in some fashion according to stake offered as collateral by either the nodes themselves, or participants in the network.
TOP uses DPoS* to govern how nodes are elected to become consensus nodes. DPoS* nodes are selected according to a unique comprehensive stake factor. The comprehensive stake takes into account a node’s computational capacity, bandwidth capabilities, asset stake, and accumulated reputation. The nodes that meet the requirements are entered into a pool of eligible nodes. From this pool, a Verifiable Random Function mechanism randomly places the eligible nodes into shards.
So how does this prevent Sybil attacks, and keep at least ⅔ of the nodes acting honestly? First, consider that in order to do any harm, a malicious entity would need to create or take control of at least 7 of the 21 active consensus nodes simultaneously within a given shard. However, thanks to sharding and the VRF mechanism, the bad actor would need to create far more than 7 nodes to achieve this, as each node it creates is placed into shards randomly. The chance that all 7 of a malicious entities nodes end up in the same shard is exceedingly low.
In reality, a bad actor would need to create tens, or even hundreds of nodes to compromise a single shard. However, with the comprehensive stake requirements, becoming an eligible node is no easy feat. For each node, the attacker needs to purchase powerful hardware to prove computational capacity, prove bandwidth capabilities, and buy tokens to put up as collateral. There is also a reputation component, which means the malicious entity is competing against honest nodes who have already accumulated reputation by acting honestly for a period of time.
pBFT-DPoS*
DPoS* remedies what is referred to as the “Nothing-At-Stake” dilemma that pBFT on its own is subject to. Usually, there is no barrier to entry for creating a consensus node, and nothing is lost for behaving maliciously. In the pBFT-DPoS* system, creating a single node is expensive, time consuming, and competitive, let alone creating the tens to hundreds that may be required to compromise just a single shard. Additionally, if an active node misbehaves, its collateral is confiscated — which means it is financially disadvantageous to act maliciously. The comprehensive stake both deters the creation of faulty nodes, and deters nodes from behaving maliciously once they are participating in consensus.
The combination of a pBFT algorithm with DPoS* provides a very secure consensus mechanism for the main chain which handles financial transactions. With a VRF based sharding architecture, this consensus mechanism also has the property that as the number of DPoS* nodes increase — and as a result the number of shards — it gets harder for a malicious entity to compromise the system. The more shards there are, the more unlikely it is to have over 7 nodes randomly placed into the same shard, which is the requirement to do any harm. Not to mention there are other fail-safes in place, but those will be explained another time.
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.
