Consensus Mechanisms

Detailed technical breakdown of Zeris's triple-consensus model including PoW micro-challenges, PoH timestamp integrity, and PoS finality guards.

2.1 PoW Micro-Challenge Layer

The Proof-of-Work layer in Zeris differs significantly from traditional blockchain PoW. Instead of global difficulty consensus, Zeris implements per-transaction micro-challenges with adaptive difficulty tuning.

Challenge-Response Mechanics

Each transaction submission requires solving a computational puzzle:

Where:

• nonce - Random value iterated by the prover
• tx_data - Serialized transaction payload
• difficulty - Adaptive difficulty parameter (1-32)
• target - Maximum hash value (2^(256-difficulty))

Adaptive Difficulty Algorithm

Zeris dynamically adjusts PoW difficulty based on network conditions and spam detection:

fn calculate_difficulty(
    base_difficulty: u8,
    recent_submissions: &[Timestamp],
    spam_score: f64
) -> u8 {
    let submission_rate = recent_submissions.len() as f64 
        / WINDOW_SIZE as f64;
    
    let rate_multiplier = if submission_rate > THRESHOLD {
        (submission_rate / THRESHOLD).log2()
    } else {
        0.0
    };
    
    let spam_multiplier = spam_score.powf(2.0);
    
    let adjusted = base_difficulty as f64 
        + rate_multiplier 
        + spam_multiplier;
    
    adjusted.clamp(MIN_DIFFICULTY, MAX_DIFFICULTY) as u8
}

Anti-Spam Model

The PoW layer provides quantifiable spam resistance. Given:

• Average hash rate: H hashes/second
• Difficulty parameter: d
• Expected attempts: 2^d

Time to solve: $$T = 2^d / H$$

For d = 20 and H = 1 MH/s, each transaction requires ~1 second of computation, making spam campaigns with millions of transactions infeasible.

PoW Validator Pseudocode

function validatePoW(
  proof: PoWProof,
  txData: Buffer,
  requiredDifficulty: number
): boolean {
  // Reconstruct challenge input
  const input = Buffer.concat([
    proof.nonce,
    txData,
    Buffer.from([requiredDifficulty])
  ]);
  
  // Compute hash
  const hash = sha256(input);
  
  // Convert hash to bigint
  const hashValue = BigInt('0x' + hash.toString('hex'));
  
  // Calculate target (2^(256-difficulty))
  const target = 2n ** BigInt(256 - requiredDifficulty);
  
  // Validate hash is below target
  return hashValue < target;
}

2.2 PoH Timestamp Integrity Layer

Proof-of-History provides cryptographic proof of the passage of time and deterministic event ordering through sequential hashing.

SHA256 Tick-Based Timekeeping

Zeris extends Solana's PoH by creating application-specific timestamp chains:

Each hash operation represents a "tick" of verifiable time. The chain is constructed such that computing Hₙ requires performing all n hash operations in sequence.

Verifiable Delay Mathematics

Given a hash function with execution time t_hash, computing n sequential hashes requires minimum time:

This provides cryptographic proof that at least T_min time has elapsed, preventing timestamp manipulation attacks.

Merkle-Anchored Time Proofs

Transactions are anchored to the PoH chain using Merkle trees:

struct PoHProof {
    // PoH chain state at transaction time
    poh_hash: [u8; 32],
    tick_count: u64,
    
    // Merkle proof anchoring tx to PoH chain
    merkle_path: Vec<[u8; 32]>,
    merkle_index: u32,
    
    // Transaction data hash
    tx_hash: [u8; 32],
}

fn verify_poh_anchor(proof: &PoHProof) -> bool {
    // Verify Merkle path
    let computed_root = compute_merkle_root(
        proof.tx_hash,
        &proof.merkle_path,
        proof.merkle_index
    );
    
    // Verify root is embedded in PoH chain
    let expected_hash = hash_with_tx_root(
        proof.poh_hash,
        computed_root
    );
    
    verify_poh_chain(proof.tick_count, expected_hash)
}

Deterministic Ordering Logic

PoH provides total ordering of events. For any two transactions T₁ and T₂:

• If tick(T₁) < tick(T₂), then T₁ occurred before T₂
• Ordering is deterministic and verifiable by all nodes
• No ambiguity in event sequencing

This property is critical for MEV protection, as it prevents transaction reordering after submission.

2.3 PoS Finality Guard Layer

The Proof-of-Stake layer provides economic security through validator consensus. Transactions achieve finality when backed by sufficient validator stake weight.

Validator Weight Rules

Each validator's weight in consensus is proportional to their staked SOL:

struct ValidatorState {
    pubkey: Pubkey,
    stake_lamports: u64,
    commission: u8,
    last_vote: Slot,
}

fn calculate_validator_weight(
    validator: &ValidatorState,
    total_stake: u64
) -> f64 {
    validator.stake_lamports as f64 / total_stake as f64
}

fn aggregate_stake_weight(
    votes: &[Vote],
    validators: &[ValidatorState]
) -> f64 {
    votes.iter()
        .filter_map(|vote| {
            validators.iter()
                .find(|v| v.pubkey == vote.validator)
                .map(|v| calculate_validator_weight(v, total_stake))
        })
        .sum()
}

Finality Criterion

A transaction achieves finality when it receives votes from validators representing ≥67% of total stake:

The 67% threshold ensures Byzantine fault tolerance, remaining secure even if up to 33% of validators are malicious or offline.

Consensus Safety Guarantees

The PoS layer provides the following safety properties:

1. Accountable Safety - Conflicting finalizations are cryptographically attributable to specific validators
2. Economic Security - Attacking finality requires stake worth more than potential gains
3. Slashing Protection - Validators lose stake for provably malicious behavior

fn verify_finality_signature(
    tx_hash: &[u8; 32],
    signatures: &[ValidatorSignature],
    validator_set: &ValidatorSet
) -> Result<(), FinalityError> {
    let mut total_weight = 0.0;
    let required_weight = 0.67;
    
    for sig in signatures {
        // Verify signature is valid
        if !sig.verify(tx_hash) {
            return Err(FinalityError::InvalidSignature);
        }
        
        // Get validator weight
        let validator = validator_set.get(&sig.pubkey)?;
        total_weight += validator.weight;
        
        if total_weight >= required_weight {
            return Ok(());
        }
    }
    
    Err(FinalityError::InsufficientStake)
}

Integration of Three Layers

The three consensus mechanisms work together to provide defense-in-depth:

Next Sections

• Cryptographic Foundations
• Architecture Deep Dive
• Security Model