> For the complete documentation index, see [llms.txt](https://esper.gitbook.io/esperchain-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://esper.gitbook.io/esperchain-docs/architecture/proof-of-ai-consensus/10-000+-tps-speed.md).

# 10,000+ TPS speed

The fastest blockchains currently are using a modified Byzantine Fault Tolerant mechanism derived from HotStuff. This includes Hyperliquid L1 which processes trading orders and Monad. To achieve extraordinary speed with Proof-of-AI consensus mechanism we can add elements of BFT to Esperchain.

Below is a **full-stack design sketch** for **PoAI-HotStuff**, a *Byzantine-Fault-Tolerant* (BFT) variant of Proof-of-AI that sustains **10 000+ TPS** while still treating *verifiable LLM inference* as the work function securing the chain.

***

### 0 Quick recap

| Old PoAI (longest-chain)                          | New PoAI-HotStuff (BFT)                                                            |
| ------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Nakamoto fork-choice, 1 – 2 s finality, ≤ 300 TPS | Deterministic finality ≤ 2 network RTT, ≥ 10 k TPS                                 |
| One miner does all inference                      | **All proposers** pre-compute a micro-batch and share a succinct zkLLM proof       |
| Security = cumulative work                        | Security = quorum certificates (2f + 1/3f + 1) **and** zkLLM proof tied to each QC |

We keep **useful work** (forward passes + zk proof) but move *ordering* to a HotStuff-like pipeline.

***

### 1 Actors & quorum sizes

* **n** validators, up to **f = ⌊(n – 1)/3⌋** Byzantine.
* Each validator runs two threads:
  * **Consensus thread** → BFT ordering.
  * **Exec/Proof thread** → verifies zkLLM, executes tx, updates state Merkle root.

The same machines *may* share their GPUs to help build zkLLM proofs, but that is an optimisation, not a requirement for safety.

***

### 2 Block structure

```
Block {
  view        uint64          // HotStuff round
  parentQC    QuorumCert
  proposer    bls_pubkey
  tx_batch    Vec<Tx>         // ≤ 1 k tx  (≈ 150 kB)
  ctx_ids     Vec<ContextId>  // MCP references
  llm_commit  Poseidon512     // hash(B || logits)
  zk_llm_proof STARK∘Halo2    // 2 kB
  agg_sig     BLS<proposer>   // only after QC forms
}
```

*Total size* ≈ 200 kB → fits in a single MTU-sized UDP chunk after erasure coding.

***

### 3 Consensus pipeline (4-phase HotStuff, *pipelined*)

{% @mermaid/diagram content="sequenceDiagram
autonumber
participant Leader\_r as "Leader (view r)"
participant V1
participant V2
participant V3

```
Note over Leader_r: Step 0 – build block B_r (includes zkLLM proof π_r)

%% ── PRE-PREPARE ────────────────────────
Leader_r ->> V1: PRE-PREPARE (B_r)
Leader_r ->> V2: PRE-PREPARE (B_r)
Leader_r ->> V3: PRE-PREPARE (B_r)

%% ── PREPARE VOTES ─────────────────────
V1 ->> Leader_r: PREPARE vote σ1
V2 ->> Leader_r: PREPARE vote σ2
V3 ->> Leader_r: PREPARE vote σ3

alt quorum reached (2f+1)
    Leader_r ->> V1: PRE-COMMIT (QC_r)
    Leader_r ->> V2: PRE-COMMIT (QC_r)
    Leader_r ->> V3: PRE-COMMIT (QC_r)
end

%% ── COMMIT VOTES ──────────────────────
V1 ->> Leader_r: COMMIT vote
V2 ->> Leader_r: COMMIT vote
V3 ->> Leader_r: COMMIT vote

alt quorum reached (2f+1)
    Leader_r ->> V1: DECIDE (finality)
    Leader_r ->> V2: DECIDE (finality)
    Leader_r ->> V3: DECIDE (finality)
end
```

" %}

#### Where the AI work lives

* **PRE-PREPARE** already carries the *verified* `zk_llm_proof`.
* Each voter only needs **10 ms** CPU to check π (same as PoAI-Nakamoto).
* Safety ➜ if a malicious leader proposes conflicting tx order **or** malformed AI proof, honest replicas refuse to sign.

***

### 4 Throughput math

| Parameter              | Value                        | Note              |
| ---------------------- | ---------------------------- | ----------------- |
| Batch size             | 1 000 tx                     | ≈ 0.15 MB         |
| Block per view         | 1                            | HotStuff linear   |
| Network RTT (geo-dist) | 120 ms                       | assume /w QUIC    |
| Pipeline depth         | 2 views in flight            | standard HotStuff |
| **TPS ≈**              | **(1 000 ÷ 0.24 s) ≈ 4 200** | single shard      |

Now add:

* **Execution sharding (k = 3)**: split key space → 3 parallel HotStuff instances.
* **BLS aggregation**: votes aggregated by sub-leaders, cut signatures to 96 B.
* **Narwhal-style mempool DAG**: decouples *data dissemination* from *consensus*.

> **Result:** 3 × 4 200 = **12 600 TPS** sustained on commodity 10 G links.

***

### 5 Optimisations unique to PoAI-HotStuff

| Trick                        | How it helps                                                                                                                                              |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pre-Proved Vacant Blocks** | If leader is slow generating π, it can propose a *cached* empty block with an older π; this keeps liveness without burning compute.                       |
| **Batch-level zkLLM**        | One proof covers *all* `LLMCall`s in the batch, amortising 4–5 ms/tx of verifier time down to < 10 µs.                                                    |
| **Threshold-GPU Pools**      | A committee of t = f + 1 validators collaboratively runs forward-passes; their partial traces combine into one STARK via AggProof (similar to DAS-STARK). |
| **Speculative Execution**    | Replicas execute tx + verify π *before* final QC; roll back only on view change (optimistic responsiveness).                                              |

***

### 6 View-change & Fault handling

*Leader fails to broadcast QC within Δ = 400 ms*\
→ timeout triggers **NewView**; next leader re-uses parentQC; no need to redo π because parent-block is already proven.

*Equivocation (double PRE-PREPARE)*\
→ Honest replica attaches both signed headers → **slash** 1 % stake + confiscate compute credits.

*Invalid or low-accuracy AI proof*\
→ zkVerify fails → vote -nil; after Δ a NewView is triggered; slashing weights proportional to ▶ hidden-set accuracy metric (§7 in white-paper).

***

### 7 Interface to MCP (Model Context Protocol)

*Block header* carries `ctx_root`; consensus ordering finalises **which context version** the LLM used, eliminating race conditions where two leaders might build proofs against different context states.

***

### 8 Reference pseudo-code (leader)

```rust
loop {
    view += 1;
    let parent = highest_qc();
    let batch  = mempool.pop(BATCH_SIZE);
    let ctxs   = collect_context(batch);
    let prompt = build_prompt(ctxs, batch);
    let llm_out, logit_root = run_llm(prompt);
    let poseidon_r = poseidon512(prompt || logit_root);

    if poseidon_r >= target_difficulty { continue; }

    let proof = zk_prove(prompt, llm_out);
    let block = Block { view, parent, batch, ctx_root(ctxs), llm_commit: poseidon_r,
                        zk_llm_proof: proof };

    broadcast(PrePrepare(block));
    qc = gather_prepare_and_build_qc();
    broadcast(PreCommit(qc));
    gather_commit_and_decide(qc);
}
```

***

### 9 Security summary

* **Safety** – inherits HotStuff’s two-phase-QC proof; zkLLM proof integrity adds a *cryptographic floor* on “work honesty”.
* **Liveness** – optimistic responsiveness ≤ 2 × network RTT so long as ≤ f Byzantine.
* **Synergy** – an attacker must both(\*) break BLS-threshold *and* forge a STARK; forging either alone is useless.

(\* actually both under classic PBFT assumption; under adaptive adversary must also break VRF unpredictability.)

***

### 10 Implementation checklist

| Milestone              | Tech                                                          |
| ---------------------- | ------------------------------------------------------------- |
| **Phase 0** – POC      | Tendermint-Core fork + zkLLM pre-prepare plugin               |
| **Phase 1** – 4 k TPS  | HotStuff-Rust, BLS12-381 sig-agg, GPU provers                 |
| **Phase 2** – 10 k TPS | Execution sharding, Narwhal DAG mempool, QUIC multi-stream    |
| **Phase 3** – Mainnet  | Hardware remote attestation (TEE) for validator GPU integrity |

***

#### TL;DR

Switching PoAI’s *ordering* layer from Nakamoto to a **HotStuff-derived BFT pipeline**:

* cuts finality to < ½ s,
* scales linearly with execution shards to **10 k – 20 k TPS**,
* **keeps** the “security-budget-is-useful-LLM-compute” super-power.

The result is a post-quantum, AI-native chain that feels Web2-snappy yet remains cryptographically un-cheatable.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://esper.gitbook.io/esperchain-docs/architecture/proof-of-ai-consensus/10-000+-tps-speed.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.