What are voting-based consensus algorithms?

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:

  • Voting-based consensus algorithms explained
  • Real-world examples of voting-based consensus
  • Use of voting-based consensus beyond DLT

What you'll learn:

  • Voting-based consensus algorithms explained
  • Real-world examples of voting-based consensus
  • Use of voting-based consensus beyond DLT

What are voting-based consensus algorithms?

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 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 votes cast by nodes on the network. They have these key features:

  1. Decentralized. Unlike centralized systems where a single authority makes decisions, voting-based mechanisms rely on a distributed network of nodes. Each node plays a key role in making decisions, so no single entity can control or manipulate the outcome. This decentralized nature is a major factor in the security and resilience of these systems. Decisions are the collective result of many independent participants.

  2. Majority agreement. For a decision to be finalized, a predefined majority of nodes must agree on the outcome. This ensures that the decision is representative of the overall network, and not just a small subset of participants. Majority agreement enhances fairness and protects the network from malicious actors who might try to manipulate results, because they would need control over a significant portion of the network to succeed.

  3. Node participation. Every node in the network has a vote and contributes to the consensus process. This not only makes the system democratic but also spreads the workload across the network, improving fault tolerance. However, this participation comes with challenges, such as increased communication overhead and the need for each node to process a large volume of messages, especially in large-scale networks.

There is a major flaw in this method, however. Nobody does a pure voting-based system, because it would be incredibly slow and inefficient. Every project using a voting-based consensus algorithm is a hybrid system — voting-based consensus plus leaders or voting-based consensus plus something else.

Examples of hybrid voting-based consensus in distributed ledgers

Let's examine the flaws in pure voting-based consensus mechanisms. Imagine a network with 1,000 nodes where a decision needs to be made. On this network, each node must cast votes and, in some cases, send a receipt for every vote it receives. This creates a massive communication overhead — over 1 million votes being exchanged across the network in a single round of voting. If a new round is required for a more complex decision, the communication load increases to billions of messages.

In addition to these limits, this mechanism does not tell you the chronological order of each transaction submitted. To achieve transaction ordering that is fair and chronological, a distributed ledger system must allow for every node to propose an order. This adds to the inefficiencies of voting-based consensus algorithms, because the node that 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.

Hybrid systems — where voting-based consensus is combined with other mechanisms — have been developed to address some of these inefficiencies while keeping the benefits of decentralized decision-making models. Let's take a look at some of the key examples of hybrid voting-based consensus mechanisms used in distributed ledgers:

  • Practical Byzantine Fault Tolerance (PBFT). PBFT is designed to tolerate Byzantine failures by allowing nodes to reach consensus even if some nodes act maliciously. It operates efficiently in smaller, permissioned networks and is known for its use in permissioned blockchains.

  • Delegated Proof of Stake (DPoS). DPoS introduces a layer of efficiency by allowing stakeholders to vote for a smaller number of delegates, who then make decisions on behalf of the entire network. This reduces the communication load by concentrating voting power in a few trusted nodes while still maintaining a decentralized process.

  • Proof of Authority (PoA). PoA relies on a set of approved validators who are responsible for validating transactions and blocks. It’s less decentralized than other mechanisms but it provides high throughput and reduced latency because fewer participants are involved in the voting process.

  • Ripple Protocol Consensus Algorithm (RPCA). RPCA leverages voting-based consensus but is tailored for a smaller network of trusted validators. The validators agree on the network's state more efficiently than traditional Byzantine fault-tolerant models.

  • Tendermint Consensus. Tendermint employs a hybrid consensus algorithm that combines voting-based consensus with a leader-based approach. It focuses on transaction finality and security while reducing the communication burden across nodes, making it suitable for scalable blockchains.

  • Verifiable Byzantine Fault Tolerance (VBFT). VBFT integrates proof of stake, verifiable randomness, and voting-based consensus to enhance efficiency and security. It’s designed to reduce message complexity and improve performance in large-scale networks.

  • Istanbul Byzantine Fault Tolerance (IBFT). IBFT is a consensus protocol optimized for permissioned networks. Like PBFT, it tolerates Byzantine faults but improves message overhead and efficiency, especially in environments with a predefined set of validators.

  • Delegated Byzantine Fault Tolerance (DBFT). DBFT functions similar to DPoS but with additional layers of fault tolerance. Elected nodes reach consensus on behalf of the broader network, reducing the number of votes needed while maintaining strong Byzantine fault tolerance.

These hybrid systems, and others, have evolved to maintain decentralization without affecting performance. They can scale more effectively and reduce the communication burden across networks.

Voting-based consensus algorithms in databases and beyond

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).

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 for building a distributed ledger. However, it’s incredibly important to understand some of the mathematics that can be used to usher in consensus algorithms that are more suitable for real-world environments (such as virtual-voting consensus).

Proof-of-vote (PoV) consensus algorithm

The hybrid Proof-of-Vote (PoV) consensus algorithm is a highly efficient voting-based consensus designed specifically for consortium blockchains. It balances the need for a decentralized decision-making model with the practical demands of a closed, permissioned network. PoV is well-suited for environments where trust is distributed among a known group of participants, and it offers an efficient solution that mitigates the inefficiencies of pure voting-based consensus mechanisms.

Roles in the PoV ecosystem

To ensure smooth operation, PoV introduces distinct roles that participate in the voting and block-generation processes:

  • Commissioner. The Commissioner is responsible for overseeing the overall governance of the blockchain. It ensures that the network rules are followed and that the election process for key roles, like the Butler, runs smoothly.

  • Butler. A Butler is a key node responsible for validating and proposing blocks. Butlers help maintain network consensus by reviewing transactions and ensuring the blockchain's state is accurate.

  • Butler candidates. These are nodes that aspire to become Butlers. They enter the election process, where network participants vote to select a new Butler when necessary.

  • Ordinary User: Regular participants in the network who can vote on critical decisions, such as Butler elections and block proposals, but do not engage in block validation themselves.


Block generation in PoV

The PoV system categorizes blocks into three types to manage the voting process efficiently:

  1. Ordinary block. These blocks contain standard transaction data and are proposed and validated by Butlers. They represent the day-to-day operation of the blockchain.

  2. Special block. A special block is generated during extraordinary events, such as the Butler election process or when a major network decision requires consensus.

  3. Genesis block. This is the foundational block of the PoV system, which initializes the blockchain and contains the initial state of the network, including the first set of Butlers and other key parameters.


Voting process for blocks and Butlers

The voting process in PoV enables both block generation and the selection of Butlers. For block voting, network participants vote to approve or reject proposed blocks. Butlers are tasked with proposing valid blocks, and the rest of the network verifies if they are correct through the voting process. A block is only added to the blockchain when it achieves the necessary number of votes.

For Butler elections, Ordinary Users and existing Butlers vote on Butler Candidates, and the candidate with the most votes is assigned the role of Butler. This ensures that the network stays secure and functional under the supervision of trusted participants.

Excitation mechanism

To incentivize active participation and maintain fairness, PoV introduces an Excitation Mechanism that rewards nodes based on their contribution to the consensus process, such as voting on blocks or participating in Butler elections. By tying rewards to voting behavior, the PoV system encourages a high level of engagement from all network participants, ensuring that the network remains decentralized and resilient without the inefficiencies of pure voting-based algorithms.

Security properties of PoV

The Proof-of-Vote (PoV) consensus algorithm has key security properties that make it suitable for consortium blockchains:

  • Consistency. PoV ensures that all honest nodes maintain the same view of the blockchain, with no conflicting forks or versions.

  • Availability. The network remains operational even in the presence of faulty or malicious nodes, thanks to its Byzantine fault tolerance.

  • Partition tolerance. PoV can tolerate network partitions, allowing the system to continue functioning as long as a sufficient number of nodes are still connected and can vote.

  • Transaction finality. Once a block is approved by the network through voting, it’s considered final and cannot be reversed, ensuring certainty for participants.

  • Resistance to selfish mining. The PoV algorithm mitigates the risks of selfish mining by distributing decision-making authority among a diverse set of nodes. This reduces the chances of any single participant manipulating the block generation process for personal gain.


Applications and use cases

Proof of Vote (PoV) is versatile and has found applications in many industries. For example:

  • Blockchain-enabled QR code verification for healthcare supply chain. PoV can be used to verify the authenticity of medical products, ensuring transparency and traceability from manufacturer to patient.

  • Real-world asset tokenization on Bitcoin blockchain. By using PoV, assets such as real estate or commodities can be represented digitally on the blockchain, enabling secure and efficient transactions.

  • Tokenizing AI models for ownership, royalties, and transferability. PoV facilitates the creation of tokens representing AI models, allowing for transparent ownership, royalty distribution, and easy transferability between parties.


Related concepts and algorithms

Several other algorithms and concepts share similarities or complement PoV in distributed systems.

  • Boyer-Moore Majority Voting Algorithm. This algorithm efficiently identifies the majority element in a dataset, which can be applied to consensus decisions in voting-based systems.

  • Surprisingly Popular Voting Algorithm. This method leverages the "wisdom of the crowd" by identifying the most confident answers within a group. This is useful for decision-making in decentralized networks.

  • Virtual Voting. A technique that minimizes message passing by allowing nodes to vote virtually, reducing communication overhead and improving efficiency in consensus protocols.

  • Gossip about Gossip Mechanism. Used in distributed ledger technologies like Hedera Hashgraph, this mechanism spreads information efficiently between nodes, allowing them to reach consensus without excessive communication overhead.


Voting-based consensus algorithms like Proof of Vote demonstrate the potential for achieving secure, decentralized decision-making in permissioned networks. While pure voting systems have their inefficiencies, innovations such as PoV show how combining voting-based models with other mechanisms can lead to more practical and scalable solutions.

HELLO FUTURE

Start building applications and ecosystems for the next generation of the web