1. LinkChains:
Decentralised
Trustworthy Linked
Data
Allan Third & John Domingue (@johndmk)
Knowledge Media Institute
The Open University, UK
kmi.open.ac.uk
blockchain.open.ac.uk

2. Background and
Blockchains

3. Handling Sensitive Linked
Data
• Need to ensure that Linked Data Set is
unchanged
• E.g.
– Healthcare
– Education
– Finance
– Scholarly publications

4. Cryptographic Hash Function
https://en.wikipedia.org/wiki/Cryptographic_hash_function

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. Peer to Peer Network
http://www.terndrup.net/2015/10/27/Building-a-P2P-Peer-Client-with-Node-js/
Add everyone has a complete copy of the data
Who Next?

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. Ethereum Blockchain Platform
Sources: Ethereum Development Tutorial

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. Interplanetary File System
(IPFS)
• Content-addressed distributed storage
(CADS)
• Files identified by hash of contents
• Shared across BitTorrent-based network

11. Exploring the DL/LD Decentralisation/Trust
Space

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. Dimensions of decentralisation
for Linked Data
• Decentralised
– Data storage
– Querying
– Verification
• Other criteria
– Storage costs
– Query costs
– Level of integrity guarantee

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. Base case
• Centralised storage & querying
• No verification
Query = Linked Data Fragments

16. Linked Data Fragments
Ruben Verborgh’s
Linked Data Fragments

17. CADS

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. CADS + Distributed Ledger

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. Base case + DL Verifier
• Centralised storage & querying
• Verify query results with copy of original data on
blockchain

22. Base case + DL Backend
• Semi-decentralised queries - any node can be a
query frontend
• Decentralised data verified directly from blockchain

23. Linked Data Fragments
Ruben Verborgh’s
Linked Data Fragments

24. Base case + DL Backend

25. “Pure” Distributed Ledger
• Decentralised storage & querying
• Data comes directly from blockchain

26. Summary

27. Implementation
• Fully implemented:
– Base case with
• Blockchain verifier
• Blockchain backend
– ”Pure” distributed ledger
• In progress
– IPFS-based approaches

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. 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. blockchain.open.ac.uk