Consensus Validations

← Back to Consensus II: UNLs and Ledger Amendments

---

Introduction

Consensus Validations is the central validation management system in XRPL's consensus mechanism. It collects, validates, and manages validation messages from network validators, enabling distributed agreement on ledger state across the network. This subsystem is critical for ensuring Byzantine fault tolerance, preventing double-spending, and maintaining network integrity.

What are Consensus Validations?

Definition: Consensus validations are cryptographically signed statements from validators declaring that they have accepted a specific ledger as the next valid state of the network.

Core Components:

• Central validation management system

• Collects and verifies validation messages

• Manages trust-based validator assessment

• Calculates ledger support and preferred ledger

• Detects and mitigates Byzantine behavior

Why Validations are Critical

Byzantine Fault Tolerance:

• Resolves disagreements between servers about the last closed ledger

• Enables consensus despite malicious or faulty validators

Double-Spending Prevention:

• Ensures transaction finality through distributed consensus

• Prevents conflicting ledger states from being accepted

Network Integrity:

• Maintains trust and consistency across decentralized validators

• Provides cryptographic proof of network agreement

Consensus Foundation:

• Provides data structures and logic needed for consensus

• Enables efficient ledger acceptance and progression

---

Validation Message Structure

STValidation: The Core Message Format

Location: rippled/include/xrpl/protocol/STValidation.h and rippled/src/libxrpl/protocol/STValidation.cpp

Purpose: Represents a validation message in the XRP Ledger consensus protocol.

Components:

Signed Statements:

• Cryptographically signed declarations of ledger consensus

• Digital signatures prevent message tampering

• Ensures validation authenticity

Ledger Identification:

• Ledger hash: Identifies the specific ledger state being validated

• Sequence number: Provides ordering and prevents replay attacks

• Signing time: Enables freshness checks and temporal validation

Validator Identity:

• Public key: Establishes validator identity

• Node ID: Derived from public key for efficient lookup

• Master key: Links signing key to validator's master identity

Consensus Data:

• Transaction set hash: Optional, from the proposal phase

• Amendment votes: Indicates support for protocol amendments

• Fee votes: Proposes changes to base reserve and transaction fees

• Negative UNL data: Supports validator reliability tracking

Message Fields

Required fields include:

• sfLedgerHash - The hash of the ledger being validated

• sfLedgerSequence - The sequence number of the ledger

• sfSigningTime - When the validation was signed

• sfSigningPubKey - Validator's public signing key

• sfSignature - Cryptographic signature

Optional fields may include:

• sfConsensusHash - Transaction set hash agreed upon

• sfAmendments - Amendment votes

• sfBaseFee / sfReserveBase / sfReserveIncrement - Fee votes

Why This Structure?

Cryptographic Integrity:

• Digital signatures prevent tampering

• Only the validator with the private key can create valid signatures

• Impossible to forge validations

Temporal Ordering:

• Timestamps enable proper sequencing

• Freshness validation prevents replay attacks

• Allows detection of stale validations

Unique Identification:

• Ledger hashes ensure precise ledger reference

• Prevents ambiguity about which ledger is being validated

• Enables efficient lookup and matching

Extensibility:

• Structure allows for additional consensus-related data

• Can add new fields without breaking compatibility

• Supports evolving protocol requirements

---

Timing Parameters and Network Stability

ValidationParms: The Timing Framework

Location: rippled/src/xrpld/consensus/Validations.h

The ValidationParms struct defines critical timing parameters:

struct ValidationParms
{
    std::chrono::seconds validationCURRENT_WALL = std::chrono::minutes{5};
    std::chrono::seconds validationCURRENT_LOCAL = std::chrono::minutes{3};
    std::chrono::seconds validationCURRENT_EARLY = std::chrono::minutes{3};
    std::chrono::seconds validationSET_EXPIRES = std::chrono::minutes{10};
    std::chrono::seconds validationFRESHNESS = std::chrono::seconds{20};
};

Parameter Explanations

validationCURRENT_WALL (5 minutes):

• Maximum time window around current time that a validation's sign time is acceptable

• Based on validation's sign time vs. current network time

• Formula: signTime < (now + validationCURRENT_WALL)

• Protects against very old validations

• Accounts for close time accuracy window adjustments

validationCURRENT_LOCAL (3 minutes):

• Maximum time after we first saw a validation that it remains current

• Based on local observation time (seenTime), not validator's sign time

• Formula: seenTime < (now + validationCURRENT_LOCAL)

• Provides faster recovery when network produces fewer validations than normal

• Helps handle late-arriving but still useful validations

• Prevents rejecting useful validations due to propagation delays

validationCURRENT_EARLY (3 minutes):

• Earliest acceptable sign time relative to current time

• Formula: signTime > (now - validationCURRENT_EARLY)

• Prevents accepting validations with timestamps too far in the past

• Protects against extreme clock errors and timestamp manipulation

• Ensures validation is reasonably recent

validationSET_EXPIRES (10 minutes):

• Duration before validation sets for a specific ledger hash expire

• Keeps recent ledger validations available for reasonable interval

• Allows pruning old validations from memory

• Prevents memory exhaustion from historical validation accumulation

• Applied to both byLedger_ and bySequence_ data structures

validationFRESHNESS (20 seconds):

• Time window since validation was seen to consider validator "live"

• Formula: now < (seenTime + validationFRESHNESS)

• Used for validator participation scoring and Negative UNL decisions

• Must be significantly > ledgerMAX_CONSENSUS (15s)

• Prevents marking validators as offline when they're waiting for laggards

• Measured from seenTime (when we observed it), not signTime

Critical Distinction:

• signTime: When the validator signed the validation (validator's timestamp)

• seenTime: When we first observed the validation (local observation time)

• Different parameters check different times for different purposes

• This separation handles network delays and clock skew independently

Why These Specific Timeframes?

Network Latency Accommodation:

• Accounts for message propagation delays across global network

• Ensures validators on different continents can participate

• Tolerates typical internet latency variations

Clock Skew Tolerance:

• Handles minor time differences between servers

• Prevents rejection due to small synchronization errors

• More lenient than strict NTP requirements

Stale Data Prevention:

• Ensures validations remain relevant and current

• Prevents interference from old validation messages

• Maintains consensus on recent ledger state

Consensus Window Management:

• Balances speed with reliability

• Fast enough for quick finality

• Slow enough to accommodate network conditions

Impact on Network Stability

Prevents Fragmentation:

• Keeps validators synchronized within reasonable time bounds

• Ensures all validators consider the same validation set

• Maintains network-wide consensus view

Handles Network Partitions:

• Allows recovery from temporary connectivity issues

• Validators can rejoin consensus after brief disconnects

• Maintains network stability during transient failures

Maintains Liveness:

• Ensures consensus can progress despite timing variations

• Accommodates validators with varying network conditions

• Prevents stalls from timing mismatches

Security Boundaries:

• Prevents attacks based on timestamp manipulation

• Makes it difficult to influence consensus with stale data

• Provides clear boundaries for validation acceptance

---

Core Data Structures

Validations Template Class

Location: rippled/src/xrpld/consensus/Validations.h

Purpose: Manages current and historical validations, enforces sequence rules, tracks trusted/untrusted validators, and maintains a ledger trie for efficient consensus operations.

Key Data Structures:

current_ Map:

• Type: hash_map<NodeID, Validation>

• Purpose: Stores the latest validation from each node

• Usage: Quickly lookup most recent validation per validator

byLedger_ Map:

• Type: AgedUnorderedMap<LedgerID, (NodeID, Validation) pairs>

• Purpose: Index validations by ledger hash

• Usage: Find all validators who validated a specific ledger

• Auto-expiry: Old entries automatically removed based on age

bySequence_ Map:

• Type: AgedUnorderedMap<SequenceNumber, (NodeID, Validation) pairs>

• Purpose: Index validations by ledger sequence

• Usage: Find all validators who validated a specific sequence

• Auto-expiry: Prevents memory growth from historical data

Why These Structures?

• Scalability: Handle thousands of validators efficiently with O(1) lookups

• Consistency: Maintain data integrity under concurrent access

• Performance: Enable fast consensus decisions without scanning all validations

• Memory Management: Auto-expiry prevents unbounded growth

SeqEnforcer: Sequence Validation

Location: rippled/src/xrpld/consensus/Validations.h

Purpose: Ensures validation sequences increase properly, prevents replay attacks, and identifies Byzantine validators.

Functionality:

• Monotonic Ordering: Ensures validation sequence numbers strictly increase per validator

• Duplicate Prevention: Blocks replay attacks and duplicate submissions

• Per-Validator Tracking: Maintains sequence state for each validator independently

• Byzantine Detection: Identifies validators submitting invalid sequences

How it Works:

1. Tracks the highest sequence number seen from each validator

2. When a new validation arrives, checks if sequence number is greater than previous

3. If sequence is not greater, rejects validation with ValStatus::badSeq

4. Updates tracking on successful validation acceptance

Why SeqEnforcer Matters:

• Prevents validators from rewinding to earlier ledgers

• Detects malicious validators attempting to fork the chain

• Ensures temporal progression of validations

• Provides clear evidence of misbehavior

LedgerTrie: Hierarchical Ledger Organization

Purpose: Organizes ledgers in parent-child relationships for efficient ancestry tracking

Key Features:

Tree Structure:

• Organizes ledgers based on parent-child relationships

• Each ledger points to its parent ledger

• Forms a tree of possible ledger chains

Branch Support:

• Tracks which validators support each ledger branch

• Counts number of validations per branch

• Enables efficient preferred ledger calculation

Preferred Ledger Logic:

• Determines the most supported ledger chain

• Follows the branch with most trusted validator support

• Resolves forks automatically

Memory Efficiency:

• Compact representation of ledger relationships

• Shared storage for common ancestors

• Automatic pruning of old branches

---

Validation Lifecycle and Trust Management

Validation Journey

The lifecycle of a validation message involves several stages:

1. Creation and Broadcasting: RCLConsensus::Adaptor::validate

Location: rippled/src/xrpld/app/consensus/RCLConsensus.cpp

Process:

1. Create Validation: Constructs an STValidation object for the newly built ledger

2. Set Fields: Fills in ledger hash, sequence, signing time, and optional fields

3. Ensure Monotonic Time: Signing time must be strictly increasing

4. Sign Message: Applies cryptographic signature using validator's private key

5. Add to Hash Router: Registers for suppression (prevents duplicate relaying)

6. Process Locally: Calls handleNewValidation to process own validation

7. Broadcast: Sends to network peers via overlay network

8. Publish: Notifies local subscribers (RPC clients, monitoring tools)

Important Notes:

• Only operates if node is configured as a validator

• Signing time must strictly increase to prevent replay attacks

• Includes amendment and fee votes if applicable

2. Reception and Authentication

When a validation message arrives from the network:

1. Receive Message: Validation arrives via overlay network

2. Deserialize: Parse the validation from wire format

3. Extract Key Information: Ledger hash, sequence, signing key

4. Signature Verification: Cryptographically verify the signature

5. Trust Assessment: Check if validator is in trusted UNL

3. Validation Handling: handleNewValidation

Location: rippled/src/xrpld/app/consensus/RCLValidations.cpp

Process:

1. Extract Signer Public Key: Get the public key from the validation

2. Lookup Master Key: Find the master key for the signing key in the trusted validator list

3. Mark as Trusted: If master key is found and validation not already trusted, mark it as trusted

4. Add to Validations Set: Call Validations::add() and receive a ValStatus

5. Check Ledger Acceptance: If validation is "current" and from a trusted validator, call LedgerMaster::checkAccept to see if the ledger should be accepted as validated

6. Handle Non-Current Status: If validation is not "current" (stale, badSeq, multiple, or conflicting), log Byzantine behavior including:

   • Conflicting validations (same sequence, different hash)

   • Multiple validations (duplicate submissions)

   • Bad sequence numbers

   • Raw serialized validation for forensic analysis

4. Adding to Validation Set: Validations::add()

Returns: ValStatus enum indicating the result

Possible Return Values:

enum class ValStatus {
    current,      // Validation accepted and current
    stale,        // Validation too old or not timely
    badSeq,       // Sequence number invalid for this node
    multiple,     // Node submitted multiple validations for same ledger
    conflicting   // Node submitted conflicting validations for same sequence
};

Process:

1. Acquire Lock: Ensure thread-safe access to validation data structures

2. Check Sequence: Use SeqEnforcer to verify sequence number is valid

3. Check Timing: Use ValidationParms to verify validation is current (not stale or too early)

4. Check for Duplicates: Ensure validator hasn't already submitted a validation for this sequence

5. Update Data Structures:

   • Update current_ with latest validation for this node

   • Add to byLedger_ index

   • Add to bySequence_ index

6. Return Status: Indicate success or reason for rejection

5. Ledger Acceptance Checking

If a validation is current and trusted, the system checks if enough validations exist to accept the ledger:

LedgerMaster::checkAccept Process:

1. Count Trusted Validations: Query Validations::getTrustedForLedger(hash, seq)

2. Check Quorum: Determine if number of validations meets quorum requirement

3. Accept Ledger: If quorum is met, mark ledger as validated and advance

4. Update State: Set the validated ledger as the new Last Validated Ledger (LVL)

6. Expiration and Cleanup

Automatic Cleanup:

• Aged unordered maps automatically expire old entries

• Based on validationSET_EXPIRES parameter (10 minutes)

• Prevents memory exhaustion

• Maintains only relevant validation data

Trust Management Philosophy

Explicit Trust Lists:

• UNL (Unique Node List) defines trusted validators for each node

• Only trusted validators' opinions count for consensus

• Each operator independently chooses their UNL

Reputation Tracking:

• Historical behavior influences trust levels

• Validators can be added to Negative UNL for poor performance

• Trust is not binary but can have gradations

Dynamic Adjustment:

• Trust can change based on validator performance

• Negative UNL automatically adjusts participation

• System adapts to changing network conditions

Byzantine Tolerance:

• System functions even with some untrustworthy validators

• Up to 20% of UNL validators can be Byzantine

• Quorum requirement (80%) provides safety margin

Trusted Validation Queries

currentTrusted():

• Returns: Vector of all current, trusted, and full validations

• Purpose: Get snapshot of all trusted validators' current positions

• Usage: Calculate overall network validation state

getTrustedForLedger(hash, seq):

• Returns: Vector of trusted, full validations for specific ledger and sequence

• Purpose: Determine if a specific ledger has enough validation support

• Usage: Check if ledger meets quorum for acceptance

---

Validation Flags and Enums

Validation Flags

vfFullValidation:

• Indicates validation is a full validation (not a partial/proposal)

• Required for validation to count toward ledger acceptance

• Set after consensus is fully reached

vfFullyCanonicalSig:

• Indicates signature is fully canonical

• Ensures signature follows strict encoding rules

• Prevents signature malleability

ValStatus Enum

Usage: Returned by the add() method in Validations to indicate result of adding a validation

Values and Meanings:

current:

• Validation is accepted and current

• Will be counted for consensus

• From a validator in good standing

stale:

• Validation is too old or not timely

• Outside validationCURRENT_WALL or validationCURRENT_LOCAL windows

• Ignored for consensus

badSeq:

• Sequence number is invalid for this node

• Either regressed, duplicate, or out of order

• Indicates potential Byzantine behavior

multiple:

• Node submitted multiple validations for same ledger/sequence

• All after the first are rejected

• May indicate misconfiguration or attack

conflicting:

• Node submitted conflicting validations for same sequence

• Different ledger hashes for same sequence number

• Strong indicator of Byzantine behavior

BypassAccept Enum

enum class BypassAccept : bool { no = false, yes };

Usage: Indicates whether to bypass certain acceptance checks when processing a validation

Purpose: Allows special operational modes or testing scenarios

---

Byzantine Behavior Detection

The validation system detects and rejects Byzantine behavior through multiple mechanisms:

1. Sequence Violation Detection

SeqEnforcer Class (Validations.h:73-107)

Enforces monotonically increasing sequence numbers per validator:

bool operator()(time_point now, Seq s, ValidationParms const& p)
{
    if (now > (when_ + p.validationSET_EXPIRES))
        seq_ = Seq{0};  // Reset after expiration
    if (s <= seq_)
        return false;   // Reject non-increasing sequence
    seq_ = s;
    return true;
}

Detects:

• Sequence numbers that regress (older than previous)

• Duplicate sequences from same validator

• Returns ValStatus::badSeq on violation

2. Conflicting Validation Detection

Code: Validations.h:600-640

Tracks multiple validations per sequence and detects conflicts:

// If same sequence but different ledger hash → conflict
if (seqit->second.ledgerID() != val.ledgerID())
    return ValStatus::conflicting;

Detects:

• Validator proposing different ledgers for same sequence

• Evidence of attempted chain fork

• Strongest indicator of malicious behavior

3. Timestamp Validation

isCurrent() Function (Validations.h:129-147)

Validates timing using three parameters:

return (signTime > (now - p.validationCURRENT_EARLY)) &&
       (signTime < (now + p.validationCURRENT_WALL)) &&
       (seenTime < (now + p.validationCURRENT_LOCAL));

Detects:

• Sign times too far in past (>3 min before now)

• Sign times too far in future (>5 min after now)

• Observations too old (>3 min since first seen)

• Returns ValStatus::stale on violation

4. Signature Verification

Built into validation processing (before reaching Validations class)

Detects:

• Invalid cryptographic signatures

• Signature doesn't match claimed validator key

• Rejected immediately at protocol layer

5. Duplicate Detection

Code: Validations.h:640-650

Prevents same validation from being processed multiple times:

if (byLedger_.find(val.ledgerID()) != byLedger_.end())
{
    if (existing validation found)
        return ValStatus::multiple;
}

Detects:

• Duplicate submissions of identical validation

• Spam/DOS attempts

• Returns ValStatus::multiple

Byzantine Response Chain

1. Immediate Rejection: Invalid validations never stored or propagated

2. Status Reporting: ValStatus enum provides rejection reason

3. Logging: All rejections logged for operator analysis

4. Negative UNL Integration: Persistent misbehavior tracked via validationFRESHNESS

5. Operator Action: UNL managers can remove consistently Byzantine validators

Response Strategies

Automatic Filtering:

• Reject validations from detected Byzantine validators

• Prevent misbehaving validators from affecting consensus

• Immediate response to detected attacks

Reputation Penalties:

• Reduce trust scores for misbehaving validators

• Feed into Negative UNL calculation

• Gradual response to consistent issues

Network Alerts:

• Log Byzantine behavior for operator awareness

• Include raw validation data for forensic analysis

• Enable manual intervention if needed

UNL Updates:

• Remove consistently Byzantine validators from trust lists

• Validators can update their UNL configuration

• Maintains network health over time

---

Thread Safety and Concurrency

Multi-Threading Challenges

Concurrent Access:

• Multiple threads reading/writing validation data

• Network thread receiving validations

• Consensus thread checking validation status

Data Consistency:

• Ensuring atomic operations on shared state

• Preventing race conditions in validation tracking

• Maintaining consistency across indices

Performance:

• Minimizing lock contention for high throughput

• Allowing concurrent reads where possible

• Optimizing critical paths

Deadlock Prevention:

• Careful lock ordering to avoid circular dependencies

• Avoiding nested locks where possible

• Using lock guards for exception safety

Thread Safety Mechanisms

Mutex Protection:

• All shared data structures in Validations protected by mutexes

• Critical sections guarded by appropriate locks

• Ensures exclusive access when modifying state

Atomic Operations:

• Lock-free operations where possible for performance

• Cached signature verification results

• Immutable validation objects after creation

Immutable Data:

• STValidation objects are immutable after creation

• Reduces mutable shared state

• Enables safe sharing between threads

Lock Guards:

• RAII-style lock management

• Automatic unlock on exception

• Prevents lock leaks

Thread-Safe Operations

All public methods in Validations class:

• Acquire appropriate lock before accessing shared data

• Release lock before returning

• Exception-safe through RAII

Iterator Safety:

• Iteration over validation sets performed under lock

• Prevents modifications during iteration

• Avoids iterator invalidation

Cached Results:

• isValid() in STValidation caches its result

• Safe for repeated calls from multiple threads

• No lock needed for cached reads

Why Thread Safety Matters:

Consensus Speed:

• Parallel processing accelerates validation handling

• Multiple validations can be processed simultaneously

• Reduces latency in consensus rounds

System Reliability:

• Prevents data corruption and crashes

• Maintains consistency across threads

• Ensures correct consensus operation

Scalability:

• Efficient use of multi-core systems

• Enables high validation throughput

• Supports large numbers of validators

Real-Time Requirements:

• Consensus has strict timing constraints

• Thread safety cannot compromise performance

• Must maintain low latency

---

Integration Patterns

Adaptor Pattern Implementation

RCLValidationsAdaptor:

Location: rippled/src/xrpld/app/consensus/RCLValidations.h

Purpose: Adapts the generic validation handling framework to XRPL-specific types

Key Responsibilities:

Interface Abstraction:

• Generic validation handling regardless of specific types

• Bridges STValidation to generic Validation template

• Provides XRPL-specific logic to generic framework

Type Safety:

• Template-based design ensures compile-time correctness

• No runtime type checking needed

• Enforces proper type usage

Flexibility:

• Easy integration with different consensus algorithms

• Can adapt to future validation formats

• Supports protocol evolution

Testability:

• Mock implementations for unit testing

• Can test validation logic independently

• Simplifies test scenarios

Consensus System Integration

Event-Driven Architecture:

• Validations trigger consensus state changes

• New validations cause ledger acceptance checks

• System reacts to validation events

Callback Mechanisms:

• Notifications when validation state changes

• Alerts when quorum is reached

• Integration with ledger master

Data Flow:

• Seamless integration with proposal and consensus phases

• Validations follow proposals in consensus lifecycle

• Clear handoffs between components

State Synchronization:

• Keeps validation state aligned with consensus state

• Ensures all components have consistent view

• Coordinates state transitions

Integration Benefits

Loose Coupling:

• Components can evolve independently

• Validation logic separate from consensus logic

• Clear interfaces between modules

Testing:

• Individual components can be tested in isolation

• Mock adaptors for unit tests

• Simplified debugging

Performance:

• Optimized data flow between components

• Minimal overhead from abstraction

• Efficient memory usage

Reliability:

• Well-defined interfaces reduce integration bugs

• Clear contracts between components

• Easier to maintain and extend

---

Inter-Module Relationships

The validation subsystem interacts with several other key modules:

Validations Module:

• Central repository for all received validations

• Manages timing, status, and scoring

• Provides queries for consensus logic

RCLValidationsAdaptor:

• Adapts generic validation logic to XRPL specifics

• Handles ledger structure and transaction sets

• Bridges protocol and consensus layers

LedgerTrie:

• Organizes and traverses set of validated ledgers

• Supports efficient lookup and ancestry queries

• Determines preferred ledger chain

LedgerMaster:

• Coordinates current ledger state

• Tracks the validated ledger

• Uses validations to determine consensus

• Advances ledger when quorum reached

ValidatorList:

• Maintains list of trusted validators

• Provides public keys and associated metadata

• Filters and scores incoming validations

• Tracks validator performance for Negative UNL

Consensus Process Flow:

1. Validators submit signed validations after reaching consensus locally

2. Validations module receives and verifies them using signature checks

3. LedgerTrie organizes the validated ledgers into a tree structure

4. LedgerMaster uses the results to determine if ledger has enough support

5. ValidatorList scores and tracks validator participation for reliability

---

Summary

Key Takeaways

• Consensus Validations is the central system for managing validator agreement

• Cryptographic signatures ensure validation authenticity and prevent tampering

• Timing parameters balance network stability with consensus speed

• Byzantine detection identifies and mitigates malicious validator behavior

• Trust management through UNL ensures only reliable validators influence consensus

• Thread-safe design enables high-performance concurrent validation processing

The Big Picture

The Consensus Validations subsystem is what makes XRPL a reliable, secure, and scalable distributed ledger technology. By carefully managing validation messages, enforcing strict timing and sequence rules, detecting Byzantine behavior, and maintaining trust-based validator assessment, the system achieves fast consensus while maintaining security and decentralization. The robust design handles network latency, clock skew, and malicious actors—all while processing thousands of validations per second with sub-second consensus finality.

---

References to Source Code

• rippled/src/xrpld/consensus/Validations.h - Core validation data structures and logic

• rippled/src/xrpld/app/consensus/RCLValidations.h - XRPL-specific validation handling

• rippled/src/xrpld/app/consensus/RCLValidations.cpp - Validation processing implementation

• rippled/src/libxrpl/protocol/STValidation.cpp - Validation message implementation

• rippled/include/xrpl/protocol/STValidation.h - Validation message structure

• rippled/src/xrpld/app/ledger/detail/LedgerMaster.cpp - Ledger acceptance logic

• rippled/src/xrpld/app/ledger/LedgerHistory.cpp - Historical ledger tracking

• rippled/src/xrpld/app/misc/ValidatorList.h - Trusted validator management

• rippled/src/xrpld/app/misc/NegativeUNLVote.cpp - Validator reliability tracking