Proof of History

Traditional consensus:
Node A: "I have transaction at 10:00:00.001"
Node B: "I have transaction at 10:00:00.002"
Node C: "I have transaction at 10:00:00.001"

Problems:
- Clocks drift (even atomic clocks)
- Network latency varies
- Malicious actors can lie about timestamps
- No way to verify time claims without communication

hash_0 = hash("genesis")
hash_1 = hash(hash_0)
hash_2 = hash(hash_1)
hash_3 = hash(hash_2)
...
hash_n = hash(hash_n-1)

Each hash MUST come after the previous one.
The sequence proves time has passed.

interface PoHEntry {
  hash: Buffer; // Current hash
  numHashes: number; // Hashes since last event
  transactions?: Transaction[]; // Events mixed in
}

function generatePoH(
  previousHash: Buffer,
  hashesPerTick: number,
  events?: Transaction[],
): PoHEntry {
  let hash = previousHash;
  let numHashes = 0;

  // Hash continuously
  for (let i = 0; i < hashesPerTick; i++) {
    hash = sha256(hash);
    numHashes++;

    // Mix in events when they arrive
    if (events && i === Math.floor(hashesPerTick / 2)) {
      const eventHash = computeEventHash(events);
      hash = sha256(Buffer.concat([hash, eventHash]));
    }
  }

  return { hash, numHashes, transactions: events };
}

PoH sequence without events:
H0 → H1 → H2 → H3 → H4 → H5 → H6 → H7

Event occurs between H3 and H4:
H0 → H1 → H2 → H3 → [Tx] → H4' → H5' → H6' → H7'

Where: H4' = hash(H3 || hash(Tx))

The event is now PROVABLY ordered:
- After H3 (3000 hashes from start)
- Before H4' (3001 hashes from start)

Time ────────────────────────────────────────────────────────►

     ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
PoH: │ H0│→│ H1│→│ H2│→│ H3│→│ H4│→│ H5│→│ H6│→│ H7│→ ...
     └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘
                         │           │
                         ▼           ▼
                      ┌─────┐    ┌─────┐
Events:               │ Tx1 │    │ Tx2 │
                      └─────┘    └─────┘
                         │           │
                      count=     count=
                      3000       5000

Tx1 provably happened BEFORE Tx2
(separated by 2000 hashes ≈ X microseconds)

Generation: SEQUENTIAL (single CPU core)
H0 → H1 → H2 → H3 → H4 → H5 → H6 → H7

Verification: PARALLEL (many CPU cores)
Core 1: Verify H0 → H1 → H2
Core 2: Verify H3 → H4 → H5
Core 3: Verify H6 → H7 → H8
Core 4: Verify H9 → H10 → H11
...
Then verify boundaries match

async function verifyPoHSequence(entries: PoHEntry[]): Promise<boolean> {
  // Split work across CPU cores
  const numCores = navigator.hardwareConcurrency || 4;
  const chunkSize = Math.ceil(entries.length / numCores);

  const verificationPromises = [];

  for (let i = 0; i < numCores; i++) {
    const start = i * chunkSize;
    const end = Math.min(start + chunkSize, entries.length);
    const chunk = entries.slice(start, end);

    verificationPromises.push(
      verifyChunk(chunk, i === 0 ? null : entries[start - 1].hash),
    );
  }

  const results = await Promise.all(verificationPromises);
  return results.every((r) => r === true);
}

function verifyChunk(
  entries: PoHEntry[],
  expectedStartHash: Buffer | null,
): boolean {
  let hash = expectedStartHash;

  for (const entry of entries) {
    // Verify hash chain
    for (let i = 0; i < entry.numHashes; i++) {
      if (entry.transactions && i === Math.floor(entry.numHashes / 2)) {
        const eventHash = computeEventHash(entry.transactions);
        hash = sha256(Buffer.concat([hash!, eventHash]));
      } else {
        hash = sha256(hash!);
      }
    }

    if (!hash.equals(entry.hash)) {
      return false;
    }
  }

  return true;
}

Without PoH (Traditional BFT):
─────────────────────────────────────────────────
1. Leader proposes block
2. Validators receive block
3. Validators wait for timeout (ensure they've heard from everyone)
4. Validators vote
5. Wait for vote collection timeout
6. Finalize

Problem: Waiting for timeouts limits speed

With PoH:
─────────────────────────────────────────────────
1. Leader produces block with PoH entries
2. Validators receive block
3. Validators verify PoH (no waiting!)
4. Validators vote immediately
5. PoH provides timeouts automatically
6. Finalize

No network timeouts needed = faster finality

// Conceptual vote logic
fn should_vote(
    current_poh: &PoHHash,
    last_voted_poh: &PoHHash,
    min_hashes_between_votes: u64
) -> bool {
    let hashes_elapsed = current_poh.count - last_voted_poh.count;

    // PoH provides reliable timing without network communication
    hashes_elapsed >= min_hashes_between_votes
}

Traditional consensus limited by:
- Network round-trip time: ~100ms between regions
- Need 2-3 rounds for consensus
- Practical limit: ~100 TPS

With PoH:
- No waiting for network timing
- Single round sufficient
- PoH provides ordering
- Limit: Hardware/bandwidth

Theoretical improvement: 100x - 1000x

One Slot (400ms):
├── Tick 0 ────────── Tick 1 ────────── ... ────────── Tick 63
│   6250 hashes       6250 hashes                      6250 hashes
└────────────────────────────────────────────────────────────────┘
                        400,000 total hashes

Solana Block (Slot):
┌────────────────────────────────────────────────────────────────┐
│ Slot Header                                                    │
│ - Slot number                                                  │
│ - Parent slot hash                                             │
│ - PoH hash (at slot start)                                     │
├────────────────────────────────────────────────────────────────┤
│ Entry 0                                                        │
│ - PoH hash                                                     │
│ - Num hashes since last entry                                  │
│ - Transactions []                                              │
├────────────────────────────────────────────────────────────────┤
│ Entry 1                                                        │
│ - PoH hash                                                     │
│ - Num hashes since Entry 0                                     │
│ - Transactions []                                              │
├────────────────────────────────────────────────────────────────┤
│ ...                                                            │
├────────────────────────────────────────────────────────────────┤
│ Entry N (Last Tick)                                            │
│ - Final PoH hash for this slot                                 │
│ - is_tick: true                                                │
└────────────────────────────────────────────────────────────────┘

Scenario: Attacker pre-computes 1 hour of PoH

Problem: They don't know what transactions will arrive
- Transactions include signatures on recent PoH hashes
- Transactions with wrong PoH hash are rejected
- Pre-computed PoH has no valid transactions to mix in

Result: Pre-computation is useless

Defense 1: GPU/ASIC resistance
- SHA-256 is relatively ASIC-resistant
- Sequential nature prevents parallelization

Defense 2: PoH rate limits
- Network enforces expected PoH rates
- Too-fast PoH is suspicious

Defense 3: Validator set economics
- Becoming a leader requires stake
- Attack cost = stake at risk

1. Sequentiality:
   f(x) cannot be computed faster than T steps
   Even with unlimited parallel processors

2. Uniqueness:
   For any input x, there's exactly one valid output y

3. Efficient Verification:
   Verifying f(x) = y takes << T steps

SHA-256 chain satisfies these:
1. Sequential: Each hash needs previous hash
2. Unique: SHA-256 is deterministic
3. Efficient: Verification parallelizes