> 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/proof-of-ai-vs-proof-of-intelligence.md).

# Proof-of-AI vs Proof-of-Intelligence

In this section we're going to compare Esper's Proof-of-AI with Bittensor's Proof-of-Intelligence, which is currently the closest to what we want with decentralized AI.

### 1. What Bittensor actually means by “Proof-of-Intelligence” (PoI)

Bittensor’s PoI is **not** the mechanism that produces blocks (that job is done by ordinary Substrate / NPoS).

Instead, PoI is the *emissions oracle* that decides **who gets newly-minted TAO tokens** each 12-second block.

***

**1.1 Actors & jargon**

| Actor                | Bittensor name     | Main job                                                                                                                                                         |
| -------------------- | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Miner node**       | *miner neuron*     | Runs an ML model and answers prompts sent by validators.                                                                                                         |
| **Validator node**   | *validator neuron* | Samples prompts, queries miners, grades their answers, submits a weight vector wvw\_vwv​ to chain.                                                               |
| **Subtensor pallet** | on-chain logic     | Aggregates all validators’ weight vectors into a **weight matrix WWW** using **Yuma Consensus**, then pays miners/validators proportional to their final scores. |

Miners and validators exist inside **subnets** (one subnet ≈ one task/benchmark).

***

**1.2 A single 12-second PoI cycle**

```
1. Validator v draws a prompt x from its task pool
2. v asks (broadcasts) x to miners in its subnet
3. Each miner m returns y_m  (embedding, logits, text, …)
4. v computes a scalar utility u_m  (e.g. cosine similarity to target or ensemble)
5. Normalise u → weights w_v = softmax(u / τ)
6. v signs & submits w_v on-chain
7. Subtensor waits for all w_v, produces W = stack_v w_v
8. Yuma Consensus turns W into:
   • miner scores   S_m   (column sums after trust re-weighting)
   • validator alpha A_v  (how well v’s w_v predicted the final S)
9. Emission: TAO_m ∝ S_m,  TAO_v ∝ A_v
```

***

**1.3 Yuma Consensus in one sentence**

Take the raw weight matrix **W**, iteratively *down-weight columns from validators whose weights disagree with the aggregate*, until it converges.

This resists collusion and “weight-copying” attacks, because a validator only earns if its private scoring method predicts the honest majority.

***

**1.4 Sybil & liveness safeguards**

* **Registration cost** – to join a subnet a node must burn ≈ 200 TAO; this throttles spam.
* **Commit-reveal** – validators first **commit** a hash of their weight vector, then reveal it two blocks later; this stops last-second copy/paste of other validators’ weights.

***

### 2. Key properties of PoI

| Property                   | How PoI handles it                                                           | Security trade-off                                                                          |
| -------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| **Correctness of outputs** | *Subjective*: depends on validators’ scoring functions.                      | No cryptographic guarantee; if top validators collude, bad answers can still win.           |
| **Verifiability cost**     | Cheap (weight vectors are tiny).                                             | But honest users must *trust* validators’ evaluation code.                                  |
| **Chain security**         | Blocks secured by normal PoS; PoI **does not influence fork-choice**.        | An attacker who owns ≥ ⅔ staking power can still rewrite history, regardless of ML quality. |
| **Useful work**            | Positive: miners really run inference/train tasks chosen by subnet creators. | Yet nothing forces the task to be societally “useful”; quality is local to each subnet.     |
| **ASIC resistance**        | Depends on the task; easy subnets can see specialised rigs.                  | No global rotation schedule, so work can stagnate.                                          |

***

### 3. How our **rotating-LLM PoAI** differs

| Topic                      | Bittensor PoI                                              | Rotating-LLM PoAI (spec above)                                                   |
| -------------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------- |
| **Role in consensus**      | Just reward oracle; blocks = PoS.                          | **Secures the chain**: inference + hash-target acts as PoW.                      |
| **Proof type**             | Economic reputation (weights).                             | *Cryptographic*: zk-SNARK proves the forward pass + digest < target.             |
| **Objectivity of scoring** | Subjective, per-validator.                                 | Objective, deterministic (T = 0 decode on fixed batch).                          |
| **Sybil resistance**       | One-off burn + stake.                                      | Classical PoW difficulty TTT → compute-bound.                                    |
| **Model lifecycle**        | Any subnet designer picks task; can stay static for years. | **Global model rotation every ≈ 6 months** by DAO vote (e.g. Llama 3 → 3.1 → 4). |
| **Verification cost**      | O(#validators) tiny.                                       | Constant-time SNARK verification (< 10 ms).                                      |
| **End-user benefit**       | Need off-chain gateways to query miners.                   | On-chain LLMCall txs; stakers get *free* inference credits.                      |
| **Attack surface**         | Collusion or weight-copying by validators.                 | Classic 51 % compute attack, mitigated like Bitcoin.                             |

***

### 4. Bottom-line comparison

* **PoI (Bittensor)** turns *subjective* peer assessment into a token-emission ledger.\
  \&#xNAN;*Great for collaborative model training, but chain security still rests on ordinary PoS validators.*
* **PoAI (our design)** folds *objective* LLM inference into the **block-making itself**, giving Bitcoin-style security while recycling the electricity into publicly verifiable AI work.

So PoI is best viewed as a **reputation-weighted ML marketplace**, whereas PoAI is a **full consensus primitive** that *happens* to deliver a marketplace as a side-effect.


---

# 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/proof-of-ai-vs-proof-of-intelligence.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.