O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Mind My Value: A decentralised infrastructure for fair and trusted IoT data trading

278 visualizações

Publicada em

A paper talk given at the 7th IoT conference, Linz, Austria, Oct. 2017
paper: http://bibbase.org/network/publication/missier-bajoudah-capossele-gaglione-nati-mindmyvalueadecentralizedinfrastructureforfairandtrustediotdatatrading-2017

Next generation IoT data marketplace using blockchain technology

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Mind My Value: A decentralised infrastructure for fair and trusted IoT data trading

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20 Thank you Contact: Paolo Missier School of Computing Newcastle University, UK paolo.missier@ncl.ac.uk http://tinyurl.com/paolomissier

×