Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

LinkChains: Decentralised Trustworthy Linked Data

We describe our exploration of the space of combined Linked Data, blockchains and IPFS to enable trust over linked data sets.

  • Be the first to comment

  • Be the first to like this

LinkChains: Decentralised Trustworthy Linked Data

  1. 1. LinkChains: Decentralised Trustworthy Linked Data Allan Third & John Domingue (@johndmk) Knowledge Media Institute The Open University, UK
  2. 2. Background and Blockchains
  3. 3. Handling Sensitive Linked Data • Need to ensure that Linked Data Set is unchanged • E.g. – Healthcare – Education – Finance – Scholarly publications
  4. 4. Cryptographic Hash Function
  5. 5. Blockchain is a Linked List A blockchain can be thought of as a linked list of transactions that is built with hash pointers instead of pointers Source: Bitcoin and Cryptocurrency Technologies - Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, Steven Goldfeder
  6. 6. Peer to Peer Network Add everyone has a complete copy of the data Who Next?
  7. 7. Proof of Work • Hard to outpace the entire rest of the network… a 51% attack could do it, but otherwise it is like buying thousands of lottery tickets – doesn’t help you that much! Source: Marc Eisenstadt ‘What is the genius behind Bitcoin’
  8. 8. Ethereum Blockchain Platform Sources: Ethereum Development Tutorial
  9. 9. Ethereum Virtual Machine Sources: Ethereum Development Tutorial The Ethereum Virtual Machine can be thought of as a large decentralized computer containing millions of objects, called "accounts", which have the ability to maintain an internal database, execute code and talk to each other. There are 2 types of Accounts: Externally owned account (EOA): an account controlled by a private key that has the ability to send ether and messages from it. ‘Smart’ Contract: an account that has its own code, and is controlled by code. Any user can trigger an action by sending a transaction from an EOA, setting Ethereum's wheels in motion. If the destination of the transaction is another EOA, then the transaction may transfer some ether but otherwise does nothing However, if the destination is a ‘Smart’ Contract, then the contract in turn activates, and automatically runs its code.
  10. 10. Interplanetary File System (IPFS) • Content-addressed distributed storage (CADS) • Files identified by hash of contents • Shared across BitTorrent-based network
  11. 11. Exploring the DL/LD Decentralisation/Trust Space
  12. 12. Decentralised Linked Data on Distributed Ledgers • Guarantees of immutability – Data cannot be changed once published • Integrity of valuable data – Financial – Medical – Political/politically-sensitive • e.g., climate science data – Academic Publishing
  13. 13. Dimensions of decentralisation for Linked Data • Decentralised – Data storage – Querying – Verification • Other criteria – Storage costs – Query costs – Level of integrity guarantee
  14. 14. Decentralising LOD storage & querying • Identified 5 approaches – CADS – CADS + distributed ledger – Standard LOD + distributed ledger verifier – Standard LOD + distributed ledger backend – “Pure” distributed ledger • Compared with base case of standard LOD – SPARQL/Linked Data Fragments querying
  15. 15. Base case • Centralised storage & querying • No verification Query = Linked Data Fragments
  16. 16. Linked Data Fragments Ruben Verborgh’s Linked Data Fragments
  17. 17. CADS
  18. 18. CADS • Data decentralised (copy-on-demand) • Queries centralised • Verification – Centralised (central source of IPFS hash) – Weak (need to trust source of IPFS hash) – Need to re-compute hash over entire data set – No timestamping
  19. 19. CADS + Distributed Ledger
  20. 20. CADS + DL (2) • Data decentralised – But copy-on-demand • Queries centralised • Verification – Decentralised (blockchain source of IPFS hash) – Strong (IPFS hash immutable, signable) – Need to re-compute hash over entire data set – Timestamping
  21. 21. Base case + DL Verifier • Centralised storage & querying • Verify query results with copy of original data on blockchain
  22. 22. Base case + DL Backend • Semi-decentralised queries - any node can be a query frontend • Decentralised data verified directly from blockchain
  23. 23. Linked Data Fragments Ruben Verborgh’s Linked Data Fragments
  24. 24. Base case + DL Backend
  25. 25. “Pure” Distributed Ledger • Decentralised storage & querying • Data comes directly from blockchain
  26. 26. Summary
  27. 27. Implementation • Fully implemented: – Base case with • Blockchain verifier • Blockchain backend – ”Pure” distributed ledger • In progress – IPFS-based approaches
  28. 28. Issues • Performance – Cap on data per-block – Speed of Ethereum • Cost – Experiments on (free) private chain so far • Metadata – How do we tell clients the verification status/provenance of query results in SPARQL/Linked Data Fragments queries?
  29. 29. Future Work • Performance analysis and improvements • Cost analysis • Extension (in progress) of Linked Data Fragments server – Extensible query result metadata • Extension of LDF client – Display verification status of results to user
  30. 30.