Understanding leader-based consensus algorithms

Systems that rely on leader-based consensus algorithms are vulnerable to problems of security and fairness.

WHAT YOU WILL LEARN

  • Botnets can play follow the leader in a DDoS attack on a leader-based system.
  • Proof of work, the backbone of Bitcoin, is an example of a leader-based system.
  • Leader-based systems are vulnerable to DDoS attacks and problems with lack of order, access and fairness.

WHAT YOU WILL LEARN

  • Botnets can play follow the leader in a DDoS attack on a leader-based system.
  • Proof of work, the backbone of Bitcoin, is an example of a leader-based system.
  • Leader-based systems are vulnerable to DDoS attacks and problems with lack of order, access and fairness.

Some distributed ledger technologies use leader-based consensus algorithms. Although this consensus mechanism is used in a variety of ways, it presents problems with security and fairness.

What are leader-based consensus algorithms used for?

When Beyonce announces a new concert tour, thousands of people rush to their computers and phones to buy tickets. The ticket seller uses distributed computing to avoid selling the same seat to 12 people. A wide array of computers must coordinate the ticket requests and decide that Jane in Brooklyn gets Seat 12 in the front row for the New York show, and not Theresa from Long Island, who requested the same ticket at the same time.

With a leader-based DLT, the network uses a leader election process to decide on a lead computer or node. Every participant sends its transactions to the leader and then the leader sends out a signal: Here's the order the transactions need to be in. Or the leader sends out a block that has those transactions in that order, and it's added to the chain.

A more traditional consensus mechanism is to use rounds of votes to reach a consensus on how a transaction should be decided, based on Byzantine fault tolerance and the security it provides against malfunctioning Byzantine nodes.

However leader-based systems, as the name implies, use a leader node or computer to make final decisions on transactions. Proof of work, the backbone of Bitcoin, is an example of a leader-based system.

Flaws in leader-based consensus algorithms

The problem with leader-based consensus protocols is that they are vulnerable to DDoS attacks. A Distributed Denial of Service attack, in which many computers flood one computer with packets, can crash a leader.

Of course, leader-based systems are designed so that if the leader goes silent for a certain period of time, the network figures that the leader computer has crashed and switches to a new leader.

However, if one computer is infected with a virus or a worm, or is malicious or compromised, that one computer will detect the new leader and direct the attack to it. In this way, a botnet can play follow the leader and keep the leader shut down all the time.

Some systems that don't appear to be leader based are so – in effect. They are subject to some of the same problems. In a database, two-phase commit is actually a kind of leader-based system. When a system, such as two-phase commit, has a lock that requires a participant to obtain the lock so it can make a change and then release a lock, that system is leader based.

If there is a crash while someone is holding the lock, there's a problem. A DDoS attack can focus on whoever is holding the lock, which causes problems.

Any system is leader based if the community votes for several leaders to take turns, switching every two seconds. A DDoS can follow the leader with every switch.

In addition to the security flaws, leader-based consensus algorithms have fairness issues.

Fairness issues in leader-based systems

The leader in these distributed systems can control the order in which transactions are placed. So, maybe in a stock market one party bribes the leader to put its transactions ahead of a rival's. Unethical stock brokers would pay millions of dollars to have that happen even 1 percent of the time.

Fairness of access is another serious problem. One party could bribe the leader to not even put a rival's transaction into the block. That second participant would have to wait for a new leader to get access. However, what if several leaders in a row get bribed?

These consensus algorithms also present concerns over fairness of timestamps. The leader might, through some glitch, put inaccurate timestamps on transactions. A compromised leader might put bad timestamps on transactions on purpose.

Ideally, the entire community puts timestamps on transactions as they are received. They all weigh in and combine to give a single timestamp. Leader-based systems, however, don't allow that. Typically that all comes down to the leader.

Putting so much pressure on one point in the network makes leader-based consensus algorithms vulnerable to problems of security and fairness.