Consensus Model
Introduction to the Venn Consensus Model
The Venn Consensus Model is a fundamental component of the Venn Security Network, designed to ensure secure and efficient transaction validation. This model is essential for maintaining network integrity and achieving agreement on transaction legitimacy among distributed participants.
The Need for a Consensus Mechanism
Achieving consensus is crucial for maintaining the network's security, reliability, and decentralized nature. It ensures that all participants have a consistent view of the blockchain and agree on the secure state of transactions.
The consensus algorithm helps resolve intersubjective decisions. Intersubjective decisions require broad-based agreement among participants, which is essential for the network's integrity. Security exploits on the blockchain are also intersubjective, as recognizing and responding to them depends on shared belief and understanding among participants. The consensus mechanism enables this collective judgment, ensuring the network can identify and mitigate threats.
Leverage Diverse Security Opinions and Methods: The Venn Consensus Model allows for incorporating diverse security methods and opinions from different participants. By enabling multiple security perspectives, the consensus mechanism ensures that a broader range of potential threats is considered, reducing the likelihood of vulnerabilities being overlooked. This diversity in security approaches enhances the network's resilience and adaptability to emerging attack vectors.
Security Concerns: Assuming all node operators act honestly in a high-stakes security environment is inherently risky. A consensus mechanism addresses this by enforcing collective validation and decision-making, reducing the likelihood of dishonest behavior and enhancing overall network security.
Even well-intentioned nodes can harm the network if they engage in blind voting to maximize rewards without properly validating transactions. This issue becomes particularly problematic in a permissionless stage where economic incentives heavily influence behavior.
The potential economic value of a breach can be substantial, making it crucial to implement a robust consensus mechanism. This mechanism ensures that securing the network remains economically advantageous and prevents potential cheating by making dishonest actions unprofitable.
Key Components
Validation Process
Node Operators: All node operators participate in validating transactions and maintaining the network infrastructure.
Voting: Transactions are validated through a voting process in which node operators vote on their legitimacy.
Consensus Algorithm: Venn's consensus algorithm aggregates votes and determines whether the transaction will be reverted or passed, making the final decision on transaction validity.
Proof of Stake (PoS)
Staking Requirements: Validators must stake tokens as collateral, incentivizing honest behavior and penalizing misconduct.
Weighted Voting Power: The amount of stake a validator holds influences their voting power, giving more weight to those with higher stakes. This also includes weighted voting power for validators with native Venn staking, enhancing their influence within the network.
Correlated Agreement (CA) Model
The CA model ensures validators' decisions are consistent with the overall network by analyzing the correlation between different validators' reports. This helps to detect and prevent collusion or coordinated attacks.
Validators’ decisions are cross-checked for consistency with others. High agreement among validators is required to finalize decisions, ensuring the integrity and reliability of the consensus process.
Lazy Node Detection
Venn employs a 'BOMB' mechanism similar to proofs of custody, where bomb transactions are sent in random time intervals to test node availability and security performance. This ensures nodes meet the expected Service Level Agreements (SLA).
Bomb transactions randomly test nodes, requiring them to prove their activity and responsiveness. Failure to respond appropriately results in penalties, incentivizing consistent performance.
Governance and Oversight
Security Council: Oversees the consensus process and resolves disputes related to validation and slashing events.
Community Participation encourages active participation from the community through staking, voting, and governance proposals.
Transaction Outcomes in the Venn Consensus Model
Each transaction in the Venn Security Network can result in one of four possible outcomes, depending on how validators vote and the transaction's actual security status:
Secure Transaction, Voted Secure: A legitimate transaction that is correctly identified as secure by the validators.
Secure Transaction, Voted Not Secure (False Positive): A legitimate transaction is incorrectly flagged as malicious by the validators. This is known as a false positive.
Not Secure Transaction, Voted Not Secure: The validators correctly flag a malicious transaction as a threat and block it.
Not Secure Transaction, Voted Secure (False Negative): A malicious transaction is incorrectly voted secure by the validators.
Exception for Subnet Consensus Mode
In Subnet Mode, a protocol can deploy Venn while delegating transaction validation and security measures to a selected subset of node operators. These nodes operate within a defined subnet, maintaining collective validation while adhering to the protocol's specific security policies. Each node in the subnet contributes to the consensus, sharing voting power rather than concentrating it on a single node. This approach enables a decentralized yet controlled validation, balancing flexibility and protocol-specific customization while maintaining the security and resilience of a broader network consensus.
Exception for Standalone Consensus Mode
A unique validation process is implemented in scenarios where a protocol deploys Venn and opts for Standalone Mode. Here, a single node operator is designated to handle all transaction validation and security measures. This node possesses 100% of the voting power, making it the sole authority in decision-making. This centralized approach allows for tailored and protocol-specific security mechanisms, ensuring that the chosen node can apply specialized measures to meet its custom requirements and security standards. This exception provides flexibility for protocols needing a more controlled and customized security environment.
Last updated