Consensus

Tenzro Ledger uses BFT consensus protocol with linear communication complexity and TEE-weighted validator selection.

Consensus Overview

Tenzro uses a leader-based BFT consensus protocol that achieves:

• Linear Communication — O(n) messages per block (vs O(n²) in traditional BFT)
• Responsive — Commits in two network round-trips under good conditions
• Safe — Tolerates up to f Byzantine validators where n = 3f + 1
• Live — Guaranteed progress with view changes and timeout mechanisms

Three-Phase Protocol

The consensus protocol operates in three phases per block:

TEE-Weighted Validators

Tenzro enhances security by giving TEE-attested validators higher weight in leader selection:

// Standard validator
{
  "address": "tenzro1abc...xyz",
  "stake": "100000 TNZO",
  "weight": 1.0,
  "tee_attested": false
}

// TEE-attested validator (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA GPU)
{
  "address": "tenzro1def...uvw",
  "stake": "100000 TNZO",
  "weight": 2.0,  // 2x weight for TEE attestation
  "tee_attested": true,
  "tee_provider": "IntelTdx",
  "attestation_hash": "0xabc123..."
}

TEE-attested validators are twice as likely to be selected as leader, incentivizing secure hardware deployment.

Epoch Management

Validators are organized into epochs for efficient rotation and staking management:

• Epoch Duration: Configurable blocks per epoch (default: 1000 blocks)
• Validator Set: Top N stakers (by total stake) selected each epoch
• Rewards: Distributed at epoch boundaries to active validators
• Slashing: Automated slashing detects double-voting; 10% of validator stake slashed on equivocation; conflicting vote evidence preserved for accountability

// Epoch transition
Epoch 5 -> Epoch 6
  - Finalize epoch 5 rewards
  - Apply pending slashing (equivocation evidence -> 10% stake reduction)
  - Recompute validator set (top 100 stakers)
  - Update TEE attestations
  - Select first leader for epoch 6

Mempool

The mempool stores pending transactions awaiting inclusion in blocks:

• Priority Queue: Transactions ordered by gas price (EIP-1559 priority fee)
• Nonce Ordering: Transactions from same sender ordered by nonce
• Size Limit: Configurable max mempool size (default: 10,000 transactions)
• Eviction: Lowest priority transactions evicted when full

Finality

The consensus protocol provides deterministic finality:

This contrasts with Nakamoto consensus (Bitcoin, Ethereum PoW) where finality is probabilistic.

View Changes

If a leader fails or is malicious, validators trigger a view change:

// View change timeout
1. Leader proposes block in View 10
2. Timeout expires (no PREPARE certificate)
3. Validators broadcast VIEW_CHANGE(11)
4. Quorum of VIEW_CHANGE messages collected
5. New leader selected for View 11
6. Protocol continues with new leader

View changes ensure liveness: the protocol always makes progress even if leaders fail.

Safety Properties

• Agreement: All honest validators finalize the same blocks
• Validity: Only valid blocks (correct signatures, state transitions) are finalized
• No Forks: Two conflicting blocks cannot both be finalized
• Byzantine Tolerance: Safety guaranteed with up to f Byzantine validators (n = 3f + 1)

Performance Characteristics

Communication Complexity: O(n) per block
  - Leader sends 1 proposal to n validators
  - Each validator sends 1 vote to leader (PREPARE)
  - Leader broadcasts 1 certificate to n validators
  - Each validator sends 1 vote to leader (COMMIT)
  - Leader broadcasts 1 certificate to n validators
  Total: ~3n messages (vs n² in traditional BFT)

Latency: 2 network round-trips (normal case)
  - RTT 1: PREPARE phase
  - RTT 2: COMMIT phase
  - DECIDE is broadcast only (no waiting)

Throughput: 10,000+ TPS
  - Depends on block size, transaction complexity
  - Multi-VM execution (EVM, SVM, DAML)
  - Block-STM parallel execution enabled

Finality: Sub-second (~500ms)
  - 2 network round-trips at ~250ms each
  - Deterministic — no probabilistic confirmation

Block Structure

{
  "height": 1207,
  "hash": "0xabc123...",
  "parent_hash": "0xdef456...",
  "state_root": "0x789abc...",
  "timestamp": "2026-03-20T12:30:45Z",
  "proposer": "tenzro1validator...xyz",
  "transactions": [
    "0xtx1...",
    "0xtx2..."
  ],
  "quorum_certificate": {
    "block_hash": "0xabc123...",
    "signatures": ["0xsig1...", "0xsig2..."],
    "signers": ["tenzro1val1...", "tenzro1val2..."]
  }
}