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

Miner executes its assigned model shard.
Result is returned to the orchestrator agent.
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.

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

399.7

Loading Time

7999.6

2.7

21.6

83.4

Inference Time

3732

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.