Skip to content
jax docs.

Eigen Trust

EigenTrust is a reputation algorithm originally designed for peer-to-peer networks to identify trustworthy peers and isolate malicious ones. In the context of decentralized storage with Blake3, this paradigm takes on specialized characteristics:

What Gets Shared in the Challenge-Proof Cycle

In this system, several critical pieces of information flow between peers:

1. Challenge Requests

When Peer A wants to verify that Peer B is actually storing a file, it sends a challenge request containing:

  • The content ID (derived from the file’s Blake3 root hash)
  • A specific chunk identifier or position within the file
  • A timestamp to prevent replay attacks
  • Potentially a nonce for additional security

2. Challenge Responses (Proofs)

When Peer B receives a challenge, it must respond with a proof containing:

  • The Blake3 hash of the requested chunk
  • A signature proving this response came from Peer B
  • The original challenge parameters (to prevent confusion attacks)

3. Trust Score Updates

After verification, peers update their local trust ledgers with:

  • The peer ID that was challenged
  • Whether the response was correct, incorrect, or missing
  • A timestamp of when this interaction occurred
  • A weight assigned to this particular challenge-response pair

4. Global Trust Propagation

Peers periodically share their local trust assessments:

  • Lists of peer IDs and their associated trust scores
  • Evidence backing these scores (successful and failed challenges)
  • Their own confidence level in these assessments

The Blake3 Underpinnings

Blake3’s Merkleized structure is integral to how this system functions:

Chunk-Level Verification

Because Blake3 processes files in 1KB chunks and builds a Merkle tree of these chunks, a peer can challenge another peer to provide the hash for any specific chunk. The challenged peer must:

  1. Read the specific chunk from storage
  2. Compute its Blake3 hash
  3. Return this hash as proof

Even for a large file (say 1GB), this means the challenged peer only needs to process a tiny fraction (1KB) to generate the proof, making the system highly efficient.

Sub-chunk Challenges for Enhanced Security

Some implementations might even challenge peers to provide hashes of sub-portions of chunks, further ensuring that storage peers can’t cheat by only storing the hashes rather than the actual data.

Practical Challenge Flow in the System

Here’s how challenges typically flow in the system:

  1. Challenge Issuance: Peer A selects a random chunk from a file that Peer B claims to store and sends a challenge requesting its Blake3 hash.

  2. Proof Generation: Peer B must locate the chunk in its storage, compute the Blake3 hash, and return it.

  3. Verification: Peer A compares the returned hash against the expected value from the file’s Merkle tree structure.

  4. Trust Update: Based on correctness and response time, Peer A updates its trust score for Peer B.

  5. Aggregation: Using EigenTrust principles, the network aggregates individual trust assessments into global reputation scores.

Trust Convergence Through EigenTrust

The power of the EigenTrust algorithm in this context is that it enables the network to converge on consistent trust values even when:

  • Some peers might be malicious
  • Network connectivity might be inconsistent
  • Peers only have partial views of the network

This occurs through an iterative matrix calculation where:

  1. Each peer maintains a vector of trust values for other peers
  2. Peers share these trust vectors
  3. Peers update their own vectors based on a weighted combination of others’ vectors
  4. Through multiple iterations, the trust values converge to a stable distribution

The elegant property of EigenTrust is that, given enough honest participants, all honest nodes will eventually arrive at approximately the same global trust values for each participant in the network.

Practical Applications in JAX

In the JAX system, this challenge-proof mechanism directly ties to economic incentives:

  1. Peers who consistently respond correctly to challenges develop high trust scores
  2. These trust scores determine the proportion of rewards from storage contracts
  3. The smart contracts distribute tokens based on these calculated trust percentages
  4. The system becomes self-regulating as peers are financially motivated to provide reliable storage

Through this mechanism, JAX creates a decentralized storage marketplace where reliability is automatically measured, trustworthiness is computationally determined, and rewards naturally flow to the peers providing the most valuable service to the network.