Validation, Reputation, and Miner Lifecycle

Running AI inference across untrusted, decentralized networks introduces major challenges in correctness, fault tolerance, and trust minimization. Nesa addresses these challenges through:

• Optimistic validation

• Reputation-based scoring

• Tiered miner routing

• Trial gating for new miners

• Timeout and recovery protocols

---

Inference Validation

Nesa adopts optimistic execution, where inference results are assumed valid unless later proven incorrect. This approach minimizes latency and avoids the need for synchronous consensus.

Execution Pipeline

1. Miner executes its assigned model shard.

2. Result is returned to the orchestrator agent.

3. The agent validates results by checking:

   • Tensor structure and output shape

   • Response latency

   • Miner’s historical reputation

Additional Validation for High-Risk Queries

• Shadow miner reruns

• Redundant execution

• zkDPS or cryptographic proofs

---

Trial Runs for New Miners

Before a miner can join the live query pool, it must pass a trial inference:

• A dummy task with a known output is dispatched.

• The miner’s response is validated.

Outcomes:

• If correct: miner is marked as “warm” with baseline reputation initialized.

• If incorrect: miner is delayed (cooldown) and flagged for review.

---

Miner Reputation Scoring

Nesa employs two scoring mechanisms depending on the system architecture.

Top-Down Scoring (Orchestrator Assignment)

Miner reputation is updated for each inference task as:

$$R' = R \cdot \text{Pen}^M \cdot \text{Rew}^{1 - M}$$

Where:

• $R$: current reputation

• $R'$: updated reputation

• $\text{Pen} = 0.8$: penalty multiplier

• $\text{Rew} = 1.01$: reward multiplier

• $M \in \{0, 1\}$: error flag (1 = mistake, 0 = correct)

This creates exponential divergence: consistently reliable miners grow reputation faster, while unreliable miners fall behind.

Simulation of miner reputation under incremental penalty and reward mechanisms. Left: with reward factor 1.01, good miners gradually separate from poor performers.

Simulation of miner reputation under incremental penalty and reward mechanisms. Right: with higher reward factor 1.05, exponential divergence accelerates, enabling rapid recovery for consistently correct miners.

---

Bottom-Up Scoring (Bidding Architecture)

In peer-to-peer or bidding-based systems, performance is also factored in:

$$R' = \alpha \cdot R \cdot \text{Pen}^M \cdot \text{Rew}^{1 - M} + \beta \cdot (w_S S + w_F F + w_B B + w_I I)$$

Where:

• $R$: current reputation

• $R'$: updated reputation

• $\alpha$, $\beta$: weighting factors (accuracy vs performance)

• $S$: single-token inference throughput (token/s)

• $F$: forward pass performance

• $B$: backward pass performance

• $I$: network speed or latency responsiveness

• $w_S, w_F, w_B, w_I$: normalized weights

All performance metrics are normalized:

$$x \leftarrow \frac{x - x_{\text{min}}}{x_{\text{max}} - x_{\text{min}}}$$

Design note: High rewards with few mistakes can cause exponential growth in scores, overshadowing hardware performance. Penalty/reward factors must be tuned to balance fairness.

---

Empirical Observations

Latency Statistics (500K inference requests)

Metric	Max	Min	Median	Std Dev
Response Time	272254	3	24	399.7
Loading Time	7999.6	2.7	21.6	83.4
Inference Time	3732	0	0.36	38.0

Correlation Tests (100k requests)

• Strong correlation: loading-only time ↔ total response time

• Weak correlation: inference time ↔ model size

The figures below — empirical distributions of miner performance metrics. left: response speed shows a zero-inflated Poisson-like distribution. middle: loading time distribution is heavily right-skewed. right: inference time distribution, also skewed, highlights variability across miners.

Correlation analysis across 100k inference requests. Left: loading-only time correlates strongly with total response time (R² ≈ 0.87). Right: inference time shows weak correlation with model size (R² < 0.1), even under polynomial fits.

Correlation analysis across 100k inference requests. Left: loading-only time correlates strongly with total response time (R² ≈ 0.87). Right: inference time shows weak correlation with model size (R² < 0.1), even under polynomial fits.

---

Tiered Miner Pools

Miners are dynamically categorized:

• Tier 1: High-reputation miners with hot models and fast responses

• Tier 2: Reliable fallback miners for medium-stakes tasks

• Tier 3: New or recovering miners, restricted to low-stakes tasks

Routing prioritizes Tier 1 for critical workloads.

---

Failure Handling and Penalization

If a miner disconnects, times out, or returns invalid results:

Miner-side:

• Reputation penalized

• Node may be throttled or blacklisted

Agent-side:

• Job republished to fallback swarm

• Shard timeout: 2–5 seconds

• Global timeout: 10–15 seconds

User-facing:

• UI shows fallback in progress

• If unresolved:

  • Return partial result (if safe)

  • Retry on new path

  • Final error if all alternatives fail

---

Timeout and Retry Logic

Level	Timeout (Seconds)
Shard-level	2–5
End-to-End API	10–15

Missed deadlines trigger automatic rerouting and structured error reporting.

---

Summary

Nesa ensures decentralized inference remains trustworthy, low-latency, and production-ready through:

• Optimistic validation with fallback for riskier queries

• Dual reputation scoring strategies

• Tiered pools for prioritization

• Penalties for untrustworthy miners

• Trial gating for onboarding

• Timeout safeguards for responsiveness