Tenzro Testnet is live. Get testnet TNZO

Consensus

Tenzro Ledger uses HotStuff-2 BFT consensus, a modern Byzantine Fault Tolerant protocol with linear communication complexity and TEE-weighted validator selection.

HotStuff-2 Overview

HotStuff-2 is 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

HotStuff-2 operates in three phases per block:

1. PREPARE Phase

  • Leader proposes a new block
  • Validators verify block validity (signatures, state transitions, TEE attestations)
  • Valid block: validators send PREPARE vote to leader
  • Leader collects quorum (2f + 1 votes)

2. COMMIT Phase

  • Leader broadcasts PREPARE certificate (quorum of PREPARE votes)
  • Validators verify certificate
  • Valid certificate: validators send COMMIT vote
  • Leader collects quorum of COMMIT votes

3. DECIDE Phase

  • Leader broadcasts COMMIT certificate
  • Validators verify certificate and finalize block
  • Block is now immutable and safe to execute
  • State updates applied, receipts generated

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

HotStuff-2 provides deterministic finality:

Once a block receives a COMMIT certificate (quorum of 2f+1 COMMIT votes), it is finalized. Finalized blocks are immutable and safe to execute. There are no reorganizations past finalized blocks.

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..."] } }
← SettlementNext: Networking →