> 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/miscellaneous/proof-of-work-tps-challenge.md). # Proof-of-Work TPS Challenge *Classic* single-chain Proof-of-Work **does** hit a wall once you cut block time below \~2 s and stuff thousands of transactions into each block. Our **Proof-of-AI (PoAI)** sidesteps that wall by **decoupling “useful work” from ordering.** *In this section we cover what we do and also highlight another approach by Kadena (multi-chains) and blockDAGs.* | Layer | Classic PoW | PoAI-HotStuff (our 10 k + TPS design) | | ------------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | **Eligibility** | First node to hash < difficulty wins | Any validator may propose, **but** the proposal must carry a zk-LLM proof whose Poseidon hash < difficulty | | **Ordering & Finality** | Longest-chain race | HotStuff-derived BFT → ≤2 RTT, deterministic | | **Throughput bottleneck** | sequential mining & block propagation | network bandwidth + execution sharding (same as Monad/MegaETH) | | **Security budget** | wasted SHA-256 | socially useful LLM inference | So we keep PoW’s *Sybil resistance* (you still burn energy/GPU cycles), but we plug it into a **pipelined BFT** engine that is already known to hit 10 k – 100 k TPS in real deployments (Monad, MegaETH). *** ### 1. Why “hash-rate = throughput” is no longer true The article you quoted is correct **for single-chain Nakamoto PoW**: * sequential block discovery * fork risk ⇡ as block time ⇣ * bigger blocks ⇒ propagation pain ⇒ centralisation risk PoAI breaks the sequential lock-step: 1. **All proposers** pre-compute a verifiable LLM batch while the *previous* BFT view is finalising (perfect overlap). 2. The zk-LLM proof is only 2 kB, so it travels almost for free. 3. Finality comes from HotStuff’s quorum certificate, not from “deep chain” confirmations. That turns the old “security vs throughput” slider into two independent knobs: * **Security budget** = total GPU hours you’re willing to pay for proofs. * **Throughput** = how fast HotStuff can order 200 kB blocks.\ (Monad shows ≥10 k TPS with the same trick of pipelined HotStuff plus parallel execution) *** ### 2. Lessons from Monad & MegaETH applied to PoAI | Technique in Monad / MegaETH | How PoAI re-uses it | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | **Pipelined HotStuff** for 1-slot finality | Identical; zk-LLM proof attached in the *PRE-PREPARE* message | | **Asynchronous / parallel execution** | PoAI validators execute txs while the next view is reaching PRE-COMMIT, identical pipeline | | **Custom state DB on SSD (MonadDB)** | PoAI ships the same design so RAM is not the bottleneck | | **Role specialisation (MegaETH sequencers / provers)** | Optional: a non-voting “prover cluster” can build zk-LLM proofs and hand them to validators | *Result*: A single shard easily clears **4-5 k TPS**; three execution shards (like Monad’s 3-thread EVM) break the **10 k TPS** bar, which is **12× faster than Bitcoin’s theoretical max** and on-par with Monad’s advertised figures *** ### 3. What about the Kadena-style multi-chain boost? Nothing stops PoAI from **braiding multiple BFT shards** exactly as Kadena braids PoW chains: * Each shard runs its own HotStuff + PoAI proofs. * Cross-shard Merkle links give the same “exponential security” property Kadena claims. * TPS adds linearly: 20 shards × 10 k TPS ≈ **200 k TPS**, still well under Kadena’s bandwidth-proven 480 k TPS ceiling [medium.com](https://medium.com/kadena-io/kadena-completes-hybrid-blockchain-scaling-to-480-000-transactions-per-second-on-20-chains-5a652295533c?utm_source=chatgpt.com)—but with instant (sub-second) finality and zero-gas LLM calls baked in. *** ### 4. Propagation & fork concerns * **Proof size** is fixed (≈2 kB) ⇒ blocks stay ≤200 kB ⇒ fits in a single UDP fragment after erasure coding. * **Forks** are impossible once a QC forms; HotStuff resolves view changes without wasting the previous work proof. * Even if the *proof* itself is late, the leader can ship a cached proof over an empty prompt—liveness never stalls. *** ### 5. Energy & decentralisation *GPU time* spent on forward-passes isthe *security deposit*—but unlike Bitcoin’s hashes it **produces usable LLM inference**.\ Because the work is **batchable** and doesn’t require exotic ASICs (model rotates every 6 months), small validators can **rent cloud GPUs on demand** and remain competitive—avoiding the centralisation spiral the article flags. *** ### 6. Bottom line vs the challenges listed | Challenge in the article | PoAI-HotStuff answer | | --------------------------------- | ------------------------------------------------------------------- | | Sequential mining bottleneck | Work is pre-computable; ordering is BFT | | Propagation delay/forks | QC gives finality; proof ≤2 kB, block ≤200 kB | | Centralisation with bigger blocks | Block size stays modest; GPU rental keeps entry barrier low | | Energy waste | All joules go to LLM calls (public good) | | Need 100 k TPS | Multi-shard HotStuff or braided chains scale linearly to that range | **TL;DR** — PoAI is *logically* a form of Proof-of-Work, but the *ordering* layer is modern BFT, so we inherit the throughput tricks of Monad & MegaETH while preserving PoW’s Sybil resistance and turning the energy bill into free, on-chain AI compute. ### 7. BlockDAGs — another way past the PoW throughput wall Most “classic-PoW-is-slow” arguments hinge on a *chain* structure: blocks **must** sit in a single file, so the network wastes orphans any time two miners collide.\ A **block-directed-acyclic-graph (blockDAG)** keeps *all* concurrently found blocks, then orders them afterwards with a deterministic algorithm (e.g. **PHANTOM/GHOSTDAG**). | Property | Nakamoto chain | BlockDAG (PHANTOM / GHOSTDAG) | | ---------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Orphans | discarded ⇒ wasted work | retained ⇒ ➟ security weight | | Block rate limit | must satisfy `Δ·λ ≪ 1` (Δ = propagation) | λ can approach network capacity; k-parameter later filters “blue” sub-DAG | | Final ordering | longest-chain | greedy heaviest-k-cluster (GHOSTDAG) | | Implementations | Bitcoin, Litecoin | **Kaspa** (PoW, 10–12 blocks / s, > 7 k TPS on test-net) [forbes.com](https://www.forbes.com/sites/tomerniv/2025/05/29/kaspa-the-israeli-answer-to-scaling-bitcoin/?utm_source=chatgpt.com)[kaspa.org](https://kaspa.org/about-kaspa/?utm_source=chatgpt.com) | PHANTOM’s theory shows that, for any propagation delay Δ, you can pick **λ (block rate)** close to bandwidth limits and still tune *k* to keep the probability of a successful double-spend negligible. [eprint.iacr.org](https://eprint.iacr.org/2018/104.pdf?utm_source=chatgpt.com)\ GHOSTDAG replaces PHANTOM’s NP-hard step with a greedy rule that runs in real time. Kaspa’s mainnet processes thousands of TPS on commodity hardware while staying 100 % Proof-of-Work. [forbes.com](https://www.forbes.com/sites/tomerniv/2025/05/29/kaspa-the-israeli-answer-to-scaling-bitcoin/?utm_source=chatgpt.com) *** **How a PoAI blockDAG would look** ``` B15 (π15)──► ╱ \ B14─► B16 (π16)──► B18 (π18) ╱ ╱ ╱ …─►B12───►B13 (π13)───►B17 (π17)───► … ``` * Every block `Bi` still carries a **zk-LLM proof πi** whose Poseidon digest must beat the PoAI difficulty target. * Miners broadcast immediately; no waiting for global consensus. * Full-nodes run **GHOSTDAG** on arrival, colouring “blue” blocks (honest density) and topologically ordering them. * Finality = first “blue-score” depth **f + k** (Kaspa finalises in <10 s today). *** **What a blockDAG gives PoAI** | Gain | Why it matters for AI-work PoW | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Higher λ** (block rate) | More block *slots* → more zk-LLM batches/second ⇒ the *security budget* grows linearly with real-world compute, not with waiting time. | | **Lower latency** | Agents calling `LLMCall` see answers in a few seconds—even without BFT. | | **No wasted GPU** | Orphan blocks still contribute their zk-LLM proof to cumulative weight. | | **Natural sharding** | You can run *colored* sub-DAGs per application (DeFi, NFT, on-chain AI KB) without a hard split—similar to Kadena’s braided chains, but all inside one graph. | *** **Trade-offs & open research** * **Complexity ↑** – clients must run GHOSTDAG logic and track blue/red sets. * **Bandwidth is still king** – if blocks are 200 kB you need \~16 Mb/s per peer to sustain 100 block/s safely. * **Selfish-mining analysis** is younger than for longest-chain or HotStuff; current proofs assume partial synchrony and bounded k. * **Finality lag vs. BFT** – HotStuff finalises in ≤2 RTT; GHOSTDAG finality grows with k (security parameter). For 1 s P99 latency you often set k≈600 ms → 5–8 s practical finality. *** **Where PoAI-HotStuff vs. PoAI-blockDAG makes sense** | Scenario | Use PoAI-HotStuff (BFT) | Use PoAI-blockDAG | | -------------------------------------------------------------------- | ----------------------------- | -------------------------- | | **DeFi / exchanges** need sub-second deterministic finality | ✅ |  Maybe | | **Massive micro-payments, IoT telemetry, gaming** (needs 100 k TPS+) |  Shard or braid BFT instances | ✅ blockDAG scales λ easier | | **Regulated environments** (auditable consensus, simple proofs) | ✅ |  More complex | | **Ultra-open mining, home rigs** |  Higher stake requirements | ✅ single-GPU friendly | *** #### Take-away BlockDAGs show that *even pure PoW* can climb into the **10 k – 100 k TPS** tier by letting blocks arrive concurrently and sorting them later—Kaspa and multiple newcomers already prove it in the wild.\ For **Esperchain** the choice is not *BFT vs blockDAG*, but **which ordering layer best fits the app mix**: * Keep **PoAI-HotStuff** for ultra-low-latency DeFi shards. * Spin up a **PoAI-blockDAG shard** for high-volume agent chatter or game state, still secured by verifiable LLM work. Both share the same **zkLLM-secured work function**, turning every joule of GPU time into useful inference instead of empty hashes, and both escape the classic PoW throughput ceiling—just by two different engineering routes. --- # 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/miscellaneous/proof-of-work-tps-challenge.md?ask= ``` 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.