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?
Leader-based consensus algorithms are commonly employed in distributed systems where multiple nodes must agree on a single, consistent state. A typical use case involves transaction ordering in high-throughput environments where concurrent requests for the same resource must be resolved deterministically.
The consensus mechanism ensures that when multiple clients attempt to access or modify the same data simultaneously, only one request succeeds, preventing conflicts such as double-spending or duplicate resource allocation.
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.