Verifiable timestamps and ordering of events.
Voting-based consensus algorithms achieve consensus on transactions (and sometimes network decisions) by tallying the number of votes cast by nodes on a distributed ledger network.
What you'll learn:
What you'll learn:
Voting-based consensus algorithms go back decades and have been in mathematical literature for a very long time. They’re Byzantine fault tolerant and have had very strong mathematical proofs to ensure their security and stability.
Voting-based consensus mechanisms are democratic by nature, achieving consensus on transactions and key network decisions by counting the number of votes cast by nodes on the network. Every project using a voting-based consensus algorithm deploys them as hybrid systems, which do voting-based consensus (plus leaders) or voting based consensus (plus something else). Nobody does a pure voting-based system because a pure voting-based system is going to be incredibly slow and inefficient.
Imagine you have a network with one thousand nodes and a decision which needs to be made. On a network that size, over 1 million votes being passed throughout the network. In addition, depending on the distributed ledger, each node might also have to send a receipt to the other nodes per each votes it receives. That’s over a billion votes being sent over the internet, and that's only one round of voting.
Once a vote is received by each individual node, that node then has to review all votes in order to continue the decision-making process. Upon a decision being made, they send out new votes and that's a new round. This voting-based consensus system has multiple rounds containing billions of messages, and that's just to decide on a single yes or no question.
And while this does work as a decision-making mechanism, it does not tell you the chronological order of each transaction submitted. To achieve fair, chronological transaction ordering, a distributed ledger system must employ a system where every node proposes an order — this adds to inefficiencies of a voting-based consensus algorithm, because the node which ends up winning an election places the transactions in whichever order they deem correct. They could have been bribed to place them in non-chronological order, which isn’t reflective of when the transactions were truly performed. So, you don't have fairness, and you have inefficiency and you have lots of problems with the pure voting based systems.
Although pure voting-based consensus mechanisms are not the gold standard for distributed ledgers, they are in other technology circles. In other high-tech communities, voting-based consensus goes back decades in distributed systems, fault tolerant systems, and theorems, such as the CAP (consistency, availability, partition tolerant) theorem.
Pure voting-based consensus is probably not the best underlying mechanism to build a distributed ledger. However, they are incredibly important for understanding some of the mathematics that can be used as part of ushering in consensus mechanism more suitable for real-world environments (such as virtual-voting consensus).