Skip to content

vote.md

Latest commit

 

History

History
56 lines (38 loc) · 3.18 KB

vote.md

File metadata and controls

56 lines (38 loc) · 3.18 KB

vote.go - Leader Vote Tracking and Aggregation

This file implements the vote tracking and aggregation mechanisms used by the leader node in the Canopy blockchain's Byzantine Fault Tolerance (BFT) consensus protocol. It enables the leader to collect, validate, and count votes from replica validators to reach consensus.

Overview

The vote tracking system is designed to handle:

  • Collection of votes from replica validators
  • Verification of vote signatures
  • Aggregation of voting power
  • Determination of consensus majority
  • Processing of additional information like high quorum certificates (QCs) and evidence

Core Components

VotesForHeight and VoteSet

The voting system uses a hierarchical structure to organize votes:

  • VotesForHeight is a map that organizes votes by round, phase, and payload hash
  • VoteSet represents a collection of votes for the same proposal, tracking:
    • The original vote message
    • Total accumulated voting power
    • Aggregated signatures from validators

This structure allows the leader to efficiently track which validators have voted for which proposals and calculate when a majority has been reached.

Majority Vote Determination

The system provides mechanisms to determine when consensus has been reached:

  • GetMajorityVote() checks if any proposal has received votes representing at least 2/3 of the total voting power
  • GetLeadingVote() identifies the proposal with the most voting power behind it

These functions are crucial for the consensus process, as they allow the leader to determine when a decision can be finalized and communicated to all participants.

Vote Processing

When a vote arrives from a replica validator, several steps occur:

  1. The appropriate vote set is located or created
  2. The vote is validated to ensure it comes from a legitimate validator
  3. The validator's voting power is added to the total for that proposal
  4. The validator's signature is added to the aggregate signature

This process ensures that each validator can only vote once per proposal and that their voting power is correctly accounted for.

High QC and Evidence Handling

During election votes, replicas may submit additional information:

  • High Quorum Certificates (QCs): These represent the highest block the replica has seen a quorum certificate for, helping the leader catch up if it has fallen behind
  • Verifiable Delay Functions (VDFs): These are cryptographic proofs that help secure the election process
  • Byzantine evidence: Proof that a validator has behaved maliciously, such as by signing conflicting blocks

The leader validates this information and updates its state accordingly, which helps maintain the security and liveness of the blockchain.

Security Mechanisms

The voting system incorporates several security features to prevent attacks and ensure consensus integrity. These include signature verification to prevent vote forgery, duplicate vote detection to prevent double-voting, validation of high QCs to prevent long-range attacks, and collection of evidence of Byzantine behavior for potential validator punishment. The requirement for a 2/3 majority ensures that consensus can only be reached if a significant portion of honest validators agree.