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
Payer: A party who pays for the challenge and starts one
Prover: The end-point whose backhaul capacity is being measured
Blockchain full-node: Decentralised ledger for recording all the challenge requests and outcomes
Challengers: A pool of servers which can send challenge traffic to the prover
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
A contract is initialised on-chain with public key of the payer, public key of the prover, and claimed capacity.
The payer commits to the contract escrow tokens for the cost of the challenge (depending on the claimed capacity).
Challenge Setup
Challenge coordinator reads the request from the chain and selects appropriate number of challengers from the pool of live challengers.
The challenge coordinate informed the provers and the selected challengers about the challenge.
Challenge Execution
Each challengers determines RTT to the prover.
The challenge coordinator (CC) informs each challenger about where to send the challenge data and at what time.
The challengers send the challenge data.
The prover computes a response hash of all the data received and sends it as response to each challenger.
Each challenger records the start time and the time at which the response hash is received.
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.
Challengers forward the response hash, verification data from prover (with prover signature), and its (tt, np) with its signature to the challenge coordinator.
The challenge coordinator computes the bandwidth and post all the data (list of challengers and their response) on-chain.
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
Trust assumptions:
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.
The challenge coordinator is trusted to communicate between the parties and read/write to the ledger without censorship.
Prover
Rational adversary: The prover can modify its response maliciously to try to inflate the measured capacity.
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
Byzantine faults:
Challengers can withhold the challenge traffic.
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?)
Rational adversary:
Challengers can be bribed by the prover to inflate its measured capacity (rushing attack and information sharing attacks).
Trust assumptions:
Challengers will not in a DoS attack on their own or using informing an outside party about the challenge timing and details.
Last updated
