Skip to main content
SearchLogin or Signup

Fair Service Payments in Decentralized Networks

Published onOct 05, 2019
Fair Service Payments in Decentralized Networks

Yondon Fu is from Livepeer


How should we think about ensuring QOS for users? Generally: routing requests to providers to ensure minimum quality.

Setting: a service requestor wants to pay for a service; a service provider wants to be paid in exchange for [computational?] service. Requestors don’t want to pay for poor quality of service, providers want to be paid for work.
Goal: Allow requestors to define QoS prefs, w/o opaque trusted centralized service, w/o relying on legal recourse in case of an SLA breach.

1.Ensure providers are paid appropriately for service: robust to resource-exhaustion attacks.
2.Ensure requestor gets a minimum QoS for their payment not dependent on the provider.


One option: measure actual computational cost, charge proportional.
Ex: gas in Ethereum. Challenges: Attacks on metering possible; see EIP 150.

Ex: Livepeer. Outsource streaming service provision to ‘orchestrator’ nodes. Shift to a local metering model: each orchestrator can implement its own, update how it prices UOM based on realtime benchmarks.
We need to meter both encoding and decoding. An atacker could stuff 1000 frames into a 2sec input to make decoding hard.

Another option: QoS via micropayments, redundancies and failovers:

Requestors need to be protected from failure or QoS degradation of providers. What about weighted selection? Instad of selecting 1 provider, we select N; make switching easy and low friction, by breaking up computation into tiny chunks, sending a micropayment with each, similar to interledger packetized payments. Make the value at risk small, so an SLA breach leads to rerouting, losing the value in exchange from learning to demote that router in future selections.

Paths to explore

minimize cost, ok w latency: fail over to another provider.
minimize latency, ok w cost: have N tunable providers, redundantly processing, use the first response. Reduce the size of computation and value in each transaction to allow switching [cost: at least Nx?]

Open problems

alternate metering models: WASM computation model

Provider selection algorithms: combine sybil resistance mechanisms (stake) and performance measurement to ‘score’ providers for selection. General framework?

Opt-in untrusted, transparent, third-party matching srevices for selection.


No comments here