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)
dPOH is a cryptographic clock. It proves that time passed between two events without relying on a system clock.
4.1.1 SHA-256 Hash Chain
dPOH runs as a continuous SHA-256 hash chain on its own dedicated thread. The output of the previous hash becomes the input for the next. Because hashing is strictly sequential and cannot be parallelized, a specific sequence of hashes mathematically proves that a specific amount of time has elapsed.
4.1.2 Ticks, Slots & Epochs
The chain is divided into strict intervals:
- Hashes per Tick:
9,375 - Ticks per Slot:
64 - Hashes per Slot:
600,000 - Slot Duration:
1,500 ms(1.5 seconds) - Slots per Epoch:
2,400(~1 hour)
4.1.3 Verifiable Time Ordering
Because the hash rate is fixed by the protocol, transactions can be inserted into the hash chain alongside a specific tick. A verifier (any node syncing the network) can quickly verify the hashes in parallel (since inputs and outputs are known) and confirm that the transactions occurred in the exact order stated by the proposer.
4.1.4 PoH Delegation Model
Not all validators generate the PoH chain. Generating 600,000 SHA-256 hashes every 1.5 seconds consumes roughly 0.97 of a CPU core permanently. Validators can delegate PoH generation to specialized generator nodes using the DelegatePoH transaction, while maintaining their own consensus voting power.
4.1.5 Generator & Verifier
- Generator: Uses a short-critical-section mutex rather than lock-free queues for thread safety (touched only once per tick), ensuring the generator thread is never starved.
- Verifier: Recomputes the segments of the hash chain to ensure continuity and refuses forged time claims.
4.2 KSC BFT (HotStuff-Family)
While dPOH orders transactions, KSC BFT decides what is final. It is a Byzantine Fault Tolerant protocol derived from the HotStuff family.
4.2.1 Quorum Certificates (QC) & BLS12-381 Aggregation
Validators vote on proposed blocks. Votes are signed using BLS12-381 cryptography. The leader aggregates these votes into a single Quorum Certificate (QC). Because BLS signatures aggregate mathematically, a QC carrying 100 votes is the same byte size as a QC carrying 1 vote, minimizing network overhead.
4.2.2 Leader Schedule & Rotation
Leaders are scheduled deterministically per slot, weighted by their active stake. A leader proposes a block spanning the 64 ticks of their assigned slot.
4.2.3 Validator Set & Weights
The network requires a minimum of 4 validators to start. The BFT mechanism tolerates f faults out of 3f + 1. With 4 validators, it tolerates 1 failure. Voting weight is strictly proportional to bonded stake. Stake amounts are scaled internally by a power of two to prevent precision loss, ensuring no validator rounds down to zero weight.
4.2.4 View Change Protocol
If a block is not finalized within the 4,500 ms slot timeout, the network initiates a View Change. Validators stop voting on the current leader's proposal and rotate to the next scheduled leader, maintaining liveness even if a leader goes offline.
4.2.5 Safety & Liveness Guarantees
- Safety: An fsynced high-water mark prevents a node from double-signing (voting for two different blocks at the same height) even across crashes.
- Liveness: Deterministic timeouts ensure the chain never stalls indefinitely.
4.3 Finality
[!IMPORTANT] Deterministic 1-Block Finality: Kortana does not use probabilistic finality (like Bitcoin or Ethereum before PoS). 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 bridges wait for finality before minting wrapped assets. On Polygon, relayers wait ~128-256 blocks. On Kortana, a relayer can act safely on a single block (1.5 seconds latency).