Witness Chain
  • Introduction to Witness Chain
  • Infinity Watch
    • Proof of Location (Mainnet)
      • Introduction
      • Process flow
      • Architecture
      • Run a watchtower!
        • For Partner node runners
          • Running on Akash Cloud
          • Running on SuperNoderz
        • EigenLayer operators
          • Running a PoL Watchtower
          • Witness Chain AVS opt-in guide
        • At-home watchtowers
        • For DePIN/Validator Node provider
      • Demos
      • PoL Research
    • APIs
      • Campaign APIs
        • Key Terminologies
        • Authentication
        • Create Campaign
        • Edit campaign
        • Get Photo feed from campaign
        • Get Campaigns
      • Challenge APIs
        • Overview
        • Getting Started
  • Resources
    • Blogs
      • How Proof of Location Works
      • Redefining Geolocation Compliance: Witness Chain & Predicate
    • 🗞️Research
    • 🎙️Talks and Podcasts
    • 🤝Community
    • ⚖️Smart Contracts
    • File a bug
  • Archive
    • Introduction
    • Proof of Diligence Watchtower Protocol
      • How it works
      • Diligence Watchtower Roadmap
      • Watchtower Architecture
      • Chains watched
      • Smart Contracts
      • Quick Links
      • FAQs
    • For the node operators
      • Node requirements
      • Watchtower setup
        • [ARCHIVE] Mainnet Setup
          • L2 Archive Node Setup guide
        • Holesky Setup
          • L2 Archive Node Setup guide
        • Migration from archive to full node
      • Monitoring
    • Research
    • Keys Management
    • Proof of Bandwidth
      • Introduction
      • Architecture
      • For the node operators
        • Running a PoB Challenger Client
        • Running a PoB Prover Client
      • Demos
      • Research
    • 🤝Watchtower Protocol (Architecture v1)
      • đź—ĽHow it works
      • đź“…Watchtower Roadmap
      • 🏦Watchtower Architecture
      • đź”—Chains supported
Powered by GitBook
On this page
  • Parties Involved
  • Functional description
  • Challenge Request
  • Challenge Setup
  • Challenge Execution
  • Trust and Threat Model (current)
  • Challenge coordinator
  • Prover
  • Challengers
  1. Archive
  2. Proof of Bandwidth

Introduction

Introduction to Proof of Backhaul

Currently in Development

Proof of Backhaul is a decentralised speed-test which can be used by a “payer” to determine the backhaul capacity of a “prover” with the help of a pool of “challengers“ who send the challenge traffic to the prover. We are aspiring to build a protocol which is open (anyone can be a challenger) and trust-free (we need not trust any party). While we get there, the current version works under limited, explicitly stated trust assumptions.

Parties Involved

  1. Payer: A party who pays for the challenge and starts one

  2. Prover: The end-point whose backhaul capacity is being measured

  3. Blockchain full-node: Decentralised ledger for recording all the challenge requests and outcomes

  4. Challengers: A pool of servers which can send challenge traffic to the prover

  5. Challenge coordinator: Centralised services for (i) communication between the parties; (ii) computing challenge meta data; and (iii) interacting with the ledger

Functional description

A payer wants to verify that a prover has claimed bandwidth. It requests for a challenge to verify the bandwidth claimed by the prover.

Challenge Request

  1. A contract is initialised on-chain with public key of the payer, public key of the prover, and claimed capacity.

  2. The payer commits to the contract escrow tokens for the cost of the challenge (depending on the claimed capacity).

Challenge Setup

  1. Challenge coordinator reads the request from the chain and selects appropriate number of challengers from the pool of live challengers.

  2. The challenge coordinate informed the provers and the selected challengers about the challenge.

Challenge Execution

  1. Each challengers determines RTT to the prover.

  2. The challenge coordinator (CC) informs each challenger about where to send the challenge data and at what time.

  3. The challengers send the challenge data.

  4. The prover computes a response hash of all the data received and sends it as response to each challenger.

  5. Each challenger records the start time and the time at which the response hash is received.

  6. The prover sends signed verification data to each challenger, who in turn uses it to compute the transmission time (tt) and number of packets (np) received for its traffic.

  7. Challengers forward the response hash, verification data from prover (with prover signature), and its (tt, np) with its signature to the challenge coordinator.

  8. The challenge coordinator computes the bandwidth and post all the data (list of challengers and their response) on-chain.

  9. The PoB contract is terminated upon verification of the data and the tokens from the escrow are distributed to the challengers.

Trust and Threat Model (current)

Challenge coordinator

  1. Trust assumptions:

    1. The challenge coordinator is trusted to maintain a list of live challengers, handle load-balancing and scheduling for the challengers and randomly select a subset.

    2. The challenge coordinator is trusted to communicate between the parties and read/write to the ledger without censorship.

Prover

  1. Rational adversary: The prover can modify its response maliciously to try to inflate the measured capacity.

  2. Trust assumptions: The IP stack of the prover is trusted (in many cases this is controlled by the ISP of the prover). So the prover cannot spoof its IP, modify ICMP messages, etc..

Challengers

  1. Byzantine faults:

    1. Challengers can withhold the challenge traffic.

    2. Challengers can withhold the verification data in the final step. (What’s the solution for this? Should we allow the challenge coordinator to fetch the missing verification data (local hash for a challenger) from the prover if needed?)

  2. Rational adversary:

    1. Challengers can be bribed by the prover to inflate its measured capacity (rushing attack and information sharing attacks).

  3. Trust assumptions:

    1. Challengers will not in a DoS attack on their own or using informing an outside party about the challenge timing and details.

PreviousProof of BandwidthNextArchitecture

Last updated 1 year ago

Architecture

Details the Architecture of PoB

Demo Videos

Videos of the PoB product

API Documentation

How to use the Challenge Coordinator API

Setup your own PoB Client

How to setup your own PoB Client

Diagrammatic representation of a Challenge Execution