This document proposes a decentralized infrastructure for fair and trusted IoT data trading. It suggests using a blockchain and smart contracts to allow individual IoT data generators to directly trade their data streams, removing the need for a central trusted authority. Unilateral "message count cubes" would be reported by each participant to provide transparency and accountability. Smart contracts could then enforce settlements based on these reports in a way that is consistent, fair and removes central trust assumptions. Several challenges are noted including how to ensure fairness in the presence of malicious actors and improving scalability.

1. 1
Mind My Value:
A decentralised infrastructure
for fair and trusted IoT data trading
Paolo Missier
Shaimaa Bajoudah
{firstname.lastname}@ncl.ac.uk
School of Computing, Newcastle
University, UK
Angelo Capossele
Andrea Gaglione
Michele Nati
{firstname.lastname}@digitalcatapult.org.uk
Digital Catapult Centre
London, UK
IoT Conference
Linz, Austria
Oct. 24th, 2017

2. 2
Motivation: monetising our own IoT data streams
Focus on IoT data streams that carry information about people
• Wearables - Health care, Personal fitness, “quantified self”
• Smart home hubs / smart vehicles
Three questions:
• Business: Do these data streams have a value as digital assets?
• Technical: How do unlock the value / enable trading of such assets?
• Legal: Who is entitled to trade them?

3. 3
Primary and secondary IoT data markets
Working assumptions:
1. VAS (Value Added Services) that aggregate granular IoT data streams exist
2. They have both technical capabilities and business incentives
3. There will exist both primary and secondary markets for IoT data
Native
Value Added Services
Data Generators
- Personal / home / vehicle devices
Secondary
Value Added Services
Edge network
IoT data flows
VAS
VAS
VAS
VAS
VAS
Secondary markets
Primary market
P1
PN
…
P2
G1
Pi
……
…
Edge / Trusted zone
Network server /
Broker
Network infrastructure
C1
…
CN
Ci
…
Trusted zone
IoT data tracking
Pi
Tk
Nijk(W)
Nik(W)
Pi
Cj
Tk
Blockchain ecosystem
Interface
Subscriber app /
application server
(VAS)
…
GN
Gi

4. 4
Re-selling Scenario – Traffic For London
Tube stations gates
TFL
Primary marketOyster card
Data
User
Data
Taxi
company
Secondary markets
Targeted
Ads
Card + user
Data
TFL is a re-seller (do tube users get a cut of their extra profits?)

5. 5
Marketplace Scenario
“I am diabetic and I monitor my own fitness regime.
Can I trade my data for a better health insurance deal?”
Primary IoT data flows
Strava
Secondary markets
Primary VAS
Garmin server
Edge network
IoT data marketplace
Health
Insurance
Follow-your-runner
portal
“I am a (really good) runner.
How do Iicense my live data feed on the marketplace?”
IoT device owners may trade
data streams directly:

6. 6
A new type of data marketplace?
Goal:
To develop a blueprint for the next generation IoT data marketplaces and
demonstrate its technical feasibility
(Ideal) Requirements:
1. Dynamic and flexible. Enable un-anticipated business relationships
• Quickly establish and fulfil new primary–VAS contracts
2. Guaranteed compliance and fairness
3. Granular: Should allow individuals to gain value from their data
4. Decentralized: Governance rules are defined, but
• No central trusted authority is appointed to enforce those rules
5. “Big Data” challenges: high Volume, high Velocity, high Variety

7. 7
Initial scenario: brokered IoT traffic
Observable IoT data streams
- Simply count messages: <from, to, topic>
An IoT pub/sub setting (eg MQTT)

8. 8
Solution: broker-centric traffic metering
message count cubes
Only contain metadata
Example Topics:
- Heart rate
- Speed
- GPS trace
- Glucose level
- Gait
- Home water consumption
- Vehicle driving data
- …

9. 9
Settlement
At the end of each W:
Total fee owed by each cj to each pi computed by aggregating counts in the cube:
Unit cost
for topic k messagespi revenue after W:
if we assume:
- Complete and correct traffic metering
- A trusted authority to compute revenues
Problem solved?

10. 10
Marketplace with central trusted components
D
D
D
IoT data flows
VAS
VAS
Centralised Traffic Metering
Contract Compliance
Data Discovery
Service
Transaction settlement
Vocabulary /
Ontology
Negotiation and
Agreement
Service
Registration /
Identity Service
Dispute arbitration
msg count cubes
Observed
data flow
Contracts
DB
Participants
DB
Setup
Exec
Analyse
Low density
High density
(MQTT)
(Fees)

11. 11
Removing trust and de-centralising control
Can we remove the trust assumption and still fulfill these functions?
Trusted broker provides
• Accountability (accurate, complete counts)
• Dispute resolution
• Revenue distribution

12. 12
Approach
1) Accountability: Each participant is responsible for reporting their own counts of
messages sent / received
2) Transparency: Reports become part of blockchain transactions
Unilateral count cubes:
- Provided by each participant
- Partial – reflect a participant’s point of view
Count of messages sent by pi about tk
Provider cube:
Subscriber cube:
Count of messages received by cj from pi about tk

13. 13
Consistency and settlement with unilateral cubes
Cubes collected at the end of W:
Consistency constraint:
For each tk, for each subscriber cj to tk:
Number of messages sent by pi = number of messages received by cj from pi
But:
• Producers have an incentive to over-report the data they send
• VAS have an incentive to under-report the data they receive
Thus for some combination of pi, cj, tk we may expect:

14. 14
Blockchain + smart contracts
1. Associate identity to marketplace participants
2. Agree on contract specification
3. Settlement of contractual disputes given unilaterally generated traffic reports
“A blockchain is a globally shared, transactional database”
Smart contracts (Ethereum blockchain)
Smart contract is a term used to describe computer
program code that is capable of facilitating, executing, and
enforcing the negotiation or performance of an agreement
(i.e. contract) using blockchain technology.
Contract logic triggered by data input  the batches of (unilateral) cubes

15. 15
Removing central trust: approach
broker-controlled “message count cubes”  each participant unilaterally reports data sent / received
D
D
D
IoT data flows
VAS
VAS
Contract Compliance
Data Discovery
Service
Vocabulary /
Ontology
Negotiation and
Agreement
Service
Registration /
Identity Service
Settlement /
Reputation Management
Setup
Exec
Analyse
D
D
D
IoT data flows
VAS
VAS
Contract Compliance
Data Discovery
Service
Vocabulary /
Ontology
Negotiation and
Agreement
Service
Registration /
Identity Service
Settlement /
Reputation Management
Setup
Exec
Analyse
- Identities
- Contracts
- Unilateral
traffic reports
Sm
art
C
ontract
Sm
art
C
ontract
Sm
art
C
ontract
Sm
art
C
ontract
Unilateral cubes
cubep cubes

16. 16
Evaluation
Where should cubes data live?
- Off chain: cubes remain natively located within participants’ trusted zones
- Oraclize (Ethereum-specfic mechanism)
- Adds to cost of Smart Contract execution
- guarantees the authenticity and integrity of the retrieved data.
- Oraclize requires a query fee: 0.01$ to 0.04$
- On chain: transactions embed the cubes in the blockchain
- No cost but adds to transaction size
Execution cost of cube
settlement operations
How much does it cost to run the settlement smart contract?

17. 17
Evaluation
Overhead: (cost of contract execution) x (settlement rate)
- cost of contract execution  cube size)  #PROD X #CONS x #TOPICS
(possibly compressed)
1
10
100
1000
10000
0 5 10 15 20 25
Datatransferrate
Cube settlement operations
0.0000010
0.0000038
0.0000153
0.0000610
0.0002441
0.0009766
0.0039063
0.0156250
0.0625000
0.2500000
Dataprice[ETH]
Impact of overhead on unit cost for varying settlement rate and data transfer rate

18. 18
Evaluation
Cost per message for varying data volume, settlement rate, gas price
0.0000002
0.0000010
0.0000038
0.0000153
0.0000610
0.0002441
0.0009766
0.0039063
200 400 600 800 1000 1200 1400 1600 1800 2000
0.00006
0.00024
0.00098
0.00391
0.01563
0.06250
0.25000
1.00000
Cubesettlementcost[ETH]
Cubesettlementcost[USD]
Data transfer rate
1 settlement at low gas price
5 settlements at low gas price
1 settlement at avg gas price
5 settlements at avg gas price
off-chain data
(retrieved using Oraclize with
additional cost overhead)
Estimated data prices
0.0000002
0.0000010
0.0000038
0.0000153
0.0000610
0.0002441
0.0009766
0.0039063
200 400 600 800 1000 1200 1400 1600 1800 2000
0.00006
0.00024
0.00098
0.00391
0.01563
0.06250
0.25000
1.00000
Cubesettlementcost[ETH]
Cubesettlementcost[USD]
Data transfer rate
1 settlement at low gas price
5 settlements at low gas price
1 settlement at avg gas price
5 settlements at avg gas price
on-chain data

19. 19
Open challenges
Fairness in the presence of malicious behaviour
 reputation model:
based on history of disagreements on past transactions
What’s in a trading agreement?
• From atomic data trading (single message) to complex SLA
Think “follow-your-runner”
System challenges:
• Evolving Smart Contract technology: Ethereum vs Hyperledger
• Public vs permissioned blockchains
• Scalability

20. 20
Thank you
Contact:
Paolo Missier
School of Computing
Newcastle University, UK
paolo.missier@ncl.ac.uk
http://tinyurl.com/paolomissier