Can DPoS ever suffer a 51% attack?

Published in

aelf

5 min readApr 13, 2019

In a previous post, we outlined why the flaws with proof of work (PoW) and proof of stake (PoS) led aelf to choose a different consensus model. The DPoS model aligns closely with our philosophy that the token holders should have the greatest right in the future of the system, and that token holders’ interests are linked with the destiny of aelf.

In this post, we will look at a further benefit of using the DPoS consensus model — namely, how DPoS coordinates trusted nodes in order to defend against the risk of a “51% attack.”

But what are these attacks, and how do they come about in the first place?

The Byzantine General’s Problem

Because blockchain networks depend on consensus between many nodes in the network, they have no single “point of attack,” in contrast to centralized systems which rely on servers. As a result, they’re generally considered more resilient to traditional hacking, but even in a decentralized computing environment, bad actors can still band together to bring down the system, a dilemma that programmers have been confronting for the past four decades.

First described in a 1982 paper, the “Byzantine Generals Problem” describes a city under siege from multiple divisions of the Byzantine army, each led by a different general. To launch a successful raid, the generals must coordinate their attacks simultaneously, but each division is camped in a different location surrounding the city, and the generals can only communicate with one another via messengers.

The problem is that some of the generals may have different ideas about when to attack or retreat, and no one general can be sure that the others are all loyal. There may be one or more traitors. Each general also needs his lieutenants to implement instructions.

Therefore, the army needs an algorithm that fulfills two conditions:

1. All loyal generals agree to implement the same plan, and;

2. Any traitors cannot “trick” loyal members into adopting a bad plan.

Byzantine Fault Tolerance

When we replace the Byzantine generals with the nodes in a distributed blockchain network, those two core problems remain: coordination and trust. To maintain the integrity of the ledger and ensure that only valid transactions are added within each block, we need to verify that each node is a loyal “general” implementing the plan as agreed, and only that plan is implemented. Remember, within the context of a 51% attack, not all of the nodes have to be “bad” actors. A 51% attack simply means that 51% of the nodes agree to write bad data to the system, which may occur unwittingly.

This is the role that a consensus mechanism plays in a blockchain environment. A good consensus system should provide Byzantine Fault Tolerance, i.e., a means of successfully overcoming the Byzantine Generals Problem.

Using the PoW consensus model results in challenges at scale because more nodes have to reach a consensus which puts time pressure on the overall network. Enter: DPoS, the more scalable and resilient alternative.

How DPoS Achieves Both Scalability and Resilience

In DPoS, nodes are elected by token holders. In the case of aelf, the number of nodes is determined by the formula 2N+1, where N starts at 8 and increases by 1 each year. So, the first year there are 17 nodes, the second year 19 nodes and so on. This formula limits the number of delegated nodes, unlike in PoW where any untrusted node may join at will.

By incrementally increasing the number of nodes each year, this formula also allows for increases in the volume of transactions passing through the aelf network. Thus, DPoS provides a more scalable consensus mechanism than PoW.

However, some critics believe that , limiting the number of nodes under DPoS increases centralization and risks the rule of plutocracy. Dan Larimer, the inventor of the DPoS, disagrees, pointing out that these critics miss a crucial point — delegation decentralizes the control of the network to all of the token holders, which, in turn, provides a more effective means of preventing centralization.

Illustrating 51% Attack Resistance

Larimer uses the example of a radio station to illustrate the resilience of DPoS to attacks. On this radio station, anyone can broadcast (mine a block), and everyone must decide if they want to listen to these broadcasts (verify the block.)

With PoW, those who broadcast the loudest, or use the greatest hash power, have control of the network. This is especially true with mining pools which can become large enough to gain a 51% share of overall hash rate. Furthering this analogy, PoS awards those with the most money to stake with the greatest proportion of airtime.

Alternatively, DPoS gives each stakeholder a vote in who runs the radio transmitter. Unlike a pure PoS model, DPoS allows voters to elect the transmitters (nodes), giving everyone the opportunity for equal airtime. Under this system, nodes which act against the interests of the network can be voted out by the token holders, who have a vested interest in the future of the network.

Looking back at aelf again, they have taken this a step further with a performance upgrade which doubles as an extra security measure. Every node in the ecosystem is a cluster node, made up of many anonymous and remote workers all around the world. This makes it even more difficult to attempt an attack based upon accessing the equipment on the system.

While there is not yet any perfect consensus mechanism, DPoS provides a robust deterrent to bad actors. In a similar way to representative democracies in government, a node can only become a node, and remain a node, with the approval of a voting majority. Like the Byzantine generals, if a node is perceived as traitorous, then the token holders will exercise the power of their votes and remove it

· aelf Telegram community: English, Türkçe, Español, 한국, 日本語, 中文，русский, العربية, Deutsch, Italiano, Français, हिन्दी, and Tiếng Việt,