DPoS* vs. DPoS: Maintaining A Permissionless Network

What Is DPoS*, and How Does It Differ from DPoS?

You may have wondered what the “*” placed after DPoS is all about. The reason is simply to distinguish TOP’s version of DPoS when compared to the usual implementation. While there are some similarities between DPoS* and DPoS, they are quite different. Core to their divergence is the coupling to either horizontal or vertical scaling strategies, and the resulting differing levels of permisionless-ness.

What does it mean to be permissionless?

One of the core tenets regarding public blockchains is that they should be permissionless, a notion that goes hand in hand with decentralization. Permissionless means that nodes do not require special permissions in order to participate in maintaining and updating the blockchain ledger. In other words, for a permissionless ledger, the network should be open to everyone. An example of a permissionless blockchain is the Bitcoin blockchain, where anyone can download the relevant software and use their equipment to mine and participate in consensus. This property is vital if a blockchain aims to remain decentralized. If nodes need permission to join the network, there typically must be some authority involved who gives the permissions, which introduces centralization.

Issues with permisionless-ness

While being permisionless is vital for any public blockchain platform, it has its disadvantages. Since there are no standards in terms of who can participate in consensus, there is no stopping nodes with very weak equipment or low bandwidth capabilities from joining. This can hamper performance, as consensus must be designed around the reality that rate limiting nodes will inevitably be included. Therefore in the hopes of increasing scalability, a new type of consensus mechanism emerged which falls somewhere in between permissioned and permisionless.

Delegated Proof of Stake (DPoS) and Vertical Scaling

DPoS Is a consensus algorithm which typically uses an artificially capped number of high-power consensus nodes to update and upkeep the blockchain. Since DPoS nodes are required to have powerful hardware and high band-width capabilities, performance can be increased. Also, since there are fewer nodes participating, consensus can be reached much faster.

The clear downside to this type of strategy is it is by nature somewhat of a centralized solution. Capping the number of nodes at a low number will increase speed, but puts control of the network into the hands of a few. This concentration of power can lead to collusion, and makes the network less secure due to fewer points of failure. To help compensate for a centralized consensus network, DPoS aims to provide a decentralized way of deciding which nodes can participate in consensus. This is where the Delegated part of DPoS comes into play. Typically, the token holders vote on which nodes get to partake in consensus, with their voting power being proportional to the number tokens they hold.

While this seems like a very democratic way of electing nodes, it has some shortcomings. Since vote power is based on the number of tokens held, rich individuals can simply buy elections if the voting scheme is not carefully designed. Furthermore, if these same rich individuals team up and vow to only vote for each other, they can form cartels, which can become very hard to deal with.

Some examples of DPoS based blockchains are EOS and TRON. Both projects have received criticism regarding the fairness of their voting mechanisms. The issue is highlighted by the distribution of EOS and Tron tokens among addresses. In each case, the top 100 addresses hold the majority of tokens, meaning elections can be decided by a relativity small number of individuals. This suggests that being elected can have a lot to do with politics and relationships instead of merit. Furthermore, node rewards — which can be very substantial — act to further distance the active nodes by providing them more and more voting power, leading to a rich-get-richer situation.

So it seems the voting schemes employed by conventional DPoS based blockchains can contribute to nodes becoming too entrenched. However, there is another factor that can add even more difficulty to becoming a node. For DPoS blockchains like EOS and TRON, the capabilities of nodes must increase in order for scalability to increase. This is a result of the node cap. If demand rises, but the number of nodes stays the same, each node must become more powerful. If these blockchains one day become massively adopted, each node will need to have monumental compute power, bandwidth capabilities, and memory. This method of scaling is called vertical scale-up, and describes a situation where the number of nodes stays constant, but their power is continuously increased to keep up with rising demand.

Both the large start-up costs associated with running a very powerful node, and the potential challenges involved with campaigning against rich nodes or cartels can make becoming a DPoS node prohibitively difficult. The result is that the consensus network is not really permissionless anymore. It is not feasible for anyone to just create a super powerful node, and then oust the entrenched active nodes through campaigning. While anyone is technically allowed to participate, the consensus network becomes effectively permissioned due to the extreme difficulty of becoming an active node. The term semi-permissioned could be used to describe conventional DPoS based blockchains.

Please note that DPoS is not necessarily bad. The issue comes when only a few nodes control everything about the blockchain, and also get all the rewards.

DPoS/Vertical Scaling Pros:

• Simple to implement

DPoS/Vertical Scaling Cons:

• Nodes require increasingly powerful equipment
• Depending on the voting scheme, it can become unfair if only a few individuals hold the majority of tokens
• Small total number of nodes is less secure from both a potential collusion and technical standpoint
• Consensus network can become effectively permissioned.
• A small number of nodes get all the rewards

DPoS* and Horizontal Scaling

DPoS* is the form of Delegated Proof of Stake used by TOP Network. DPoS* was developed according to TOP Network’s firm belief that a public blockchain network should be permissionless. The reason why DPoS* can avoid the semi-permissioned fate of DPoS has much to do with horizontal scaling.

Horizontal scale-out strategies work through increasing the node count instead of increasing the power of each node. This allows for lower node requirements in terms of compute power, bandwidth capabilities, and memory. Additionally, rising demand will not cause node requirements to increase, as is the case with vertical scaling strategies.

TOP Network employs sharding, which is the main horizontal scale-out strategy used in relation to blockchains. Unlike conventional DPoS based blockchains, there is technically no node cap in TOP Network’s sharded architecture, although once reaching a certain number of nodes there are diminishing returns.

To determine node eligibility, DPoS* uses something called “comprehensive stake.” This factor takes into account compute power, bandwidth capabilities, total asset state, and reputation. Unlike DPoS, minimum DPoS* node requirements are not prohibitive, and can remain constant while scalability increases through upping the total number of nodes and shards.

While there are still some minimum requirements for nodes to join the network, they are not overwhelming. Anyone can join the consensus network given they meet these minimum requirements. Furthermore, since there is technically no node cap, the negative consequences of entrenched nodes can be avoided. These factors ensure the network can remain permissionless, decentralized and open.

DPoS*/Horizontal Scaling Pros:

• Lower minimum node requirements
• No node cap, allowing more nodes to participate
• Minimum node requirements are relatively constant, allowing the network to avoid becoming semi-permissioned
• Rewards spread among more nodes

DPoS*/Horizontal Scaling Cons:

• Horizontal scale-out through sharding is very complex