4. Consensus Mechanism

Kortana decouples the ordering of events from the finalization of events. This is achieved through a dual-mechanism architecture: Delegated Proof of History (dPOH) for verifiable ordering, and Kortana Consensus (KSC) BFT for deterministic finality.

4.1 Delegated Proof of History (dPOH)

Delegated Proof of History (dPOH) acts as a high-frequency cryptographic clock for the Kortana blockchain. In conventional distributed ledgers, nodes must exchange network messages to agree upon the relative timestamps and order of transactions, creating significant latency and consensus bottlenecks. dPOH solves this problem by using a continuous sequential Verifiable Delay Function (VDF) running locally on a dedicated generator thread.

By recording transaction hashes directly into this continuous hash sequence, the protocol creates an immutable, cryptographically verifiable record proving that a specific transaction existed before a given hash tick and after the preceding tick. This eliminates timestamp ambiguity across distributed nodes without requiring synchronized physical clocks.

4.1.1 SHA-256 Hash Chain

The foundation of dPOH is an uninterrupted, recursive SHA-256 hash computation:

Hash(n) = SHA-256(Hash(n-1))

Because the SHA-256 compression function is strictly pre-image resistant and sequential, it cannot be parallelized across multiple processor cores. An attacker with a thousand CPU cores cannot compute N successive hashes any faster than a single CPU core running the sequential loop. This mathematical property guarantees that generating a sequence of N hashes requires a deterministic, physical duration of time, establishing a reliable, objective cryptographic clock for the entire network.

4.1.2 Ticks, Slots & Epochs

Time within the Kortana consensus layer is organized into strict, hierarchical mathematical intervals:

• Hashes per Tick: 9,375 consecutive SHA-256 iterations.
• Ticks per Slot: 64 discrete ticks compose a single slot.
• Hashes per Slot: 9,375 * 64 = 600,000 SHA-256 operations.
• Target Slot Duration: 1,500 ms (1.5 seconds) under nominal hardware execution speed.
• Slots per Epoch: 2,400 slots, corresponding to approximately 3,600,000 ms (~1 hour).

At every tick boundary (every 9,375 hashes), the generator records the current output hash as a checkpoint. These 64 checkpoints per slot provide verifiable milestone markers that light clients and validating nodes use to verify block timing.

4.1.3 Verifiable Time Ordering

When transactions are submitted to the leader node during its assigned slot, the transactions are not simply batched into an arbitrary list. Instead, the transaction payload hashes are combined with the current dPOH state:

State(next) = SHA-256(State(current) || TxHash)

This insertion binds the transaction to a specific tick within the 600,000-hash sequence. When peer nodes receive the block, they do not need to recompute the entire hash sequence sequentially. Because the intermediate tick checkpoints and transaction insertion points are published in the block, validating nodes can verify the entire 600,000-hash proof in parallel across dozens of CPU cores in just a few milliseconds.

4.1.4 PoH Delegation Model

Generating 600,000 SHA-256 hashes every 1.5 seconds requires continuous, dedicated processor execution, consuming approximately 0.97 of a modern high-frequency CPU core permanently. To ensure that validators with smaller hardware footprints can participate in consensus without risking block proposal degradation, Kortana introduces the PoH Delegation Model.

Using a specialized native protocol transaction (DelegatePoH, Type 0x33), a validator can formally delegate the computational burden of dPOH hash generation to a high-performance external generator node. The generator node produces the verifiable tick stream, while the validator retains exclusive possession of its BLS12-381 consensus signing keys, preserving validator security while maximizing throughput.

4.1.5 Generator & Verifier

The kortana-node implementation of dPOH separates hash production from verification into two distinct C++ classes: PohGenerator and PohVerifier.

The PohGenerator runs on an isolated high-priority operating system thread. To eliminate lock contention, it uses a short-critical-section mutex that is touched only once per tick (every 9,375 hashes) rather than on every hash. This design guarantees that the generator thread is never starved of CPU cycles and maintains zero jitter under ThreadSanitizer (TSan). The PohVerifier executes in parallel across worker thread pools during block sync, using SIMD-accelerated SHA-256 instructions to validate hash continuity and reject forged time claims instantly.

4.2 KSC BFT (HotStuff-Family)

While dPOH provides verifiable chronological transaction ordering, the Kortana Consensus (KSC) BFT engine provides finality and state agreement. KSC BFT is a pipelined, three-phase Byzantine Fault Tolerant consensus protocol belonging to the HotStuff family. It allows a distributed set of validators to reach agreement on block validity even in the presence of malicious, equivocating, or network-partitioned nodes.

4.2.1 Quorum Certificates (QC) & BLS12-381 Aggregation

In KSC BFT, validators express their agreement on a proposed block by signing a vote message containing the block hash, height, and view number. These votes are signed using BLS12-381 elliptic curve cryptography.

The block leader collects these individual BLS signatures and aggregates them into a single Quorum Certificate (QC). Due to the linear aggregation properties of BLS12-381 pairing curves, an aggregated QC representing 100 or 1,000 validator signatures occupies exactly the same number of bytes as a single signature (96 bytes for G2 signatures plus a bitfield indicating signer indices). This constant-size certificate minimizes P2P network bandwidth consumption and keeps block header sizes bounded.

4.2.2 Leader Schedule & Rotation

Block proposer leadership rotates deterministically from slot to slot. At the beginning of each epoch (every 2,400 slots), the consensus engine computes a deterministic Leader Schedule for all upcoming slots in that epoch.

The selection algorithm uses a deterministic pseudo-random seed derived from the previous epoch's final block hash. The probability of a validator being selected as the leader for any given slot is strictly proportional to its active bonded stake. If a scheduled leader fails to propose a valid block within the slot deadline, the pacemaking protocol triggers an automated view change, rotating leadership to the next validator in the schedule without halting the chain.

4.2.3 Validator Set & Weights

The Kortana network enforces a minimum validator set size of N = 4 active nodes at genesis, satisfying the classical BFT fault tolerance threshold:

N >= 3f + 1

Where f represents the maximum number of simultaneously Byzantine (arbitrarily malicious or offline) nodes that the network can tolerate while maintaining absolute safety and liveness. With 4 validators, the system tolerates 1 failure. Voting weight in consensus is strictly proportional to bonded DNR stake. To prevent precision loss and rounding errors when calculating quorum thresholds (2/3 + 1 of total active stake), voting weights are scaled internally by a power of two, ensuring that no fractional stake rounds down to zero.

4.2.4 View Change Protocol

If a scheduled leader experiences network failure, hardware crashes, or acts maliciously by withholding blocks, the consensus engine prevents chain stalling via the View Change Protocol.

Each validator maintains a local timer calibrated to the slot timeout of 4,500 ms (three times the nominal 1,500 ms slot time). If a validator does not receive a valid proposed block accompanied by a valid QC within this window, it broadcasts a signed Timeout message for the current view. Once 2f + 1 timeout messages are aggregated into a Timeout Certificate (TC), the network advances to the next view, advancing the leader schedule and restoring block production liveness.

4.2.5 Safety & Liveness Guarantees

KSC BFT provides rigorous, mathematically proven safety and liveness guarantees:

• Safety (No Double Finalization): An honest validator will never vote for two conflicting blocks at the same view or height. To survive power loss and sudden crashes without violating safety, every node maintains an fsynced High-Water Mark on disk. Before broadcasting a vote, the node flushes its latest voted height and view to durable storage; if the node reboots, it refuses to vote on any proposal at or below that high-water mark.
• Liveness (Guaranteed Progress): As long as at least 2f + 1 of the total stake is controlled by honest, connected validators, the view-change pacemaking protocol guarantees that the network will eventually synchronize on an honest leader and finalize blocks indefinitely.

4.3 Finality

Kortana provides deterministic 1-block finality. Unlike legacy blockchains (such as Bitcoin or pre-PoS Ethereum) that rely on probabilistic finality where users must wait for multiple block confirmations to decrease the likelihood of a chain reorganization, Kortana's consensus guarantees that a block carrying a valid Quorum Certificate is permanently settled.

[!IMPORTANT] Deterministic 1-Block Finality: Kortana does not use probabilistic finality. Once a block carries a valid Quorum Certificate, it is finalized permanently.

No Uncles, No Reorgs: There are no uncle blocks, and no chain reorganizations can occur past a certified block. A finalized block is mathematically guaranteed to remain in the canonical chain.

Implications for Bridges & DApps: Cross-chain bridge protocols, decentralized exchanges, and institutional custodians operating on Kortana do not need to introduce artificial 20-minute confirmation delays. A transaction included in a certified block is final within approximately 1.5 seconds, enabling instantaneous atomic settlement for cross-chain liquidity and financial primitives.

---