We showcase our approach to verify off-chained information using Linked Data, Smart Contracts, and RDF graph hashes stored on a Distributed Ledger. In this demo, we present our implementation and a use case from the supply chain domain

Braun, Christoph

Käfer, Tobias

English

KITopen

Verifying the Integrity of Information along aSupply Chain using Linked Data and SmartContractsChristoph Braun and Tobias KäferInstitute AIFB, Karlsruhe Institute of Technology (KIT), Germanyuvdsl@student.kit.edu, tobias.kaefer@kit.eduAbstract. We showcase our approach to verify off-chained informationusing Linked Data, Smart Contracts, and RDF graph hashes stored ona Distributed Ledger. In this demo, we present our implementation anda use case from the supply chain domain.1 IntroductionCopyright ©2019 for this paper by its authors. Use permitted under Creative Commons LicenseAttribution 4.0 International (CC BY 4.0).Today’s supply chain networks face the challenge of delivering goods and ser-vices not only efficiently but also transparently to the customer. Transparencygains importance especially in the food sector: Society demands more transpar-ently provided information on products and their transportation [1]. Customersexpect to find verifiable information on where food comes from and how it wastreated.Distributed Ledger Technologies (DLTs) are cryptography-based append-only databases, which are maintained on distributed nodes that need to findconsensus on the state of the ledger. DLTs are designed to provide a high degreeof data transparency and immutability, and gained quite some attention in recentyears. However, when using DLT, issues of data sovereignty and privacy arise, asall nodes in a Distributed Ledger network store a copy of the whole ledger. Thismakes storing data on a ledger expensive. By “off-chaining” data [3], the dataitself is stored in a database outside the ledger and only hashes are stored onthe ledger as a reference. Thus, data sovereignty and privacy can be establishedlocally and the ledger is kept at a smaller size.The distributed ledger provides a uniform way of accessing and storing dataon all nodes. For accessing and storing off-chained data, a uniform standardwould be desired as well. For that, Linked Data offers a light-weight standard-based way to publish data in a decentralised fashion, where access control can beeasily implemented. Hence, we ask: Can we combine the verification capabilitiesof the distributed ledger with Linked Data management?In this demo, we present an implementation for our paper [2], where weaddress this question. The approach from our paper consists of four parts, ofwhich an implementation of 2 and 4 are the contributions of this paper:2 Christoph Braun and Tobias Käfer1. We use Linked Data, i. e. RDF and HTTP to decentrally store data off-chain.We build an item’s trail of ownership, its so-called “Linked Pedigree”, in theform of RDF graphs, described using the OntoPedigree ontology [5].2. We implement a link-traversal based querying approach for verifying dataon a Linked Pedigree off-chain.3. We hash the RDF graph using the approach of [4] to connect the off-chaineddata with the distributed ledger.4. We implement a Smart Contract to store RDF graph hashes in a DistributedLedger based on Ethereum. The stored hashes are then used to verify theircorresponding Linked Data.The paper is structured as follows: First, we give a short overview on relatedwork (Section 2). Next, we present an application showcase (Section 3) of afisher, a trucker and a supermarket forming a supply chain to deliver a fish,i. e. a supply chain item, to an end-consumer. By this example, we show howtransparent and verifiable information is generated and exchanged during thelife cycle of a supply chain item. Last, we conclude (Section 4).A website presenting a walk-through of the “LD-chain client”, the CLI clientimplementation developed by us, and further explanation can be found online1,2.2 Related WorkIn the intersection of supply chain and distributed ledger, IBM has launchedtwo of the most renowned initiatives: TradeLens for global freight companies andFoodTrust for agricultural goods. Both approaches are based on Hyperledger andhave similar operational characteristics: They solely rely on cryptographic accessright management to ensure data privacy on the ledger. All nodes that are part ofthe distributed ledger hold a full copy of the ledger, where all data is stored. Byincluding document filings, supply chain events, authority approval status andmore in the ledger, scalablity may become an issue. Similarly, provenance.org,offering track & trace and certification of consumer goods, stores all data on adistributed ledger.In the intersection of semantic technologies and distributed ledgers, differentontologies have been published to describe a distributed ledger, e. g. GraphChain [6],BLONDiE3, and EthOn4. Our approach uses parts of EthOn. Moreover, off-chaining data has so far not been the subject of papers in the Linked Data andDistributed Ledgers workshop series (LD-DL)5.In the intersection of semantic technologies and supply chain, the concept ofa Linked Pedigree [5] has been proposed to track & trace a supply chain item.A Linked Pedigree consists of RDF graphs that describe an item’s history of1 http://people.aifb.kit.edu/co1683/2019/ld-chain/semantics-demo/2 https://github.com/uvdsl/LinkedData-Logistics3 https://github.com/hedugaro/Blondie4 http://ethon.consensys.net/5 Browse with http://events.linkeddata.org/ldow-lddl/ as entry point.Verifying the Integrity of SCM Information using Linked Data and DLT 3ownership as Linked Data. For using the thus described data, a communicationprotocol is also presented in the paper. Verification is not part of the LinkedPedigree approach. In this demo, we show an implementation that adds hashingand distributed ledger technology for verification to the Linked Pedigree concept.3 Application ShowcaseTo showcase our approach, we extend the motivating example from our paper [2].We present a walk-through of this three step example of a simple supply chain:Item Creation: A fisherman creates an item, i. e. some fish.Item Handover: The fish is handed over between supply chain partners, e. g.from the fisherman to a trucker to a local supermarket to the consumer.Item Verification: At the store, the consumer verifies information about thefish as a decision-making support for the purchase. Verification could alsobe performed during each handover.We first introduce the architectural setup of our demonstration. Subsequently,we present a technical walk-through of our example.3.1 ArchitectureIn our application showcase, we use the architecture depicted in Figure 1. Eachof the three businesses, i. e. the fisher, the trucker and the supermarket, hasthe same setup in terms of software: A Linked Data server, e. g. a LDP6 im-plementation, an Ethereum blockchain node, and the LD-chain client developedby us. The Ethereum blockchain node acts as a participant in the distributedledger to perform data storage and computation. The LD-chain client providesa command-line interface. The end-consumer only requires an instance of theLD-chain client connected to any Ethereum node in the private network andwith access to the network’s Linked Data.Ethereum nodeEthereum nodeEthereum nodeFisher Trucker SupermarketEthereum private networkRDF storeRDF storeRDF storeLinked DataLD-chain clientLD-chain clientLD-chain clientLD-chain clientConsumerFig. 1. The architecture we use for our demo.6 https://www.w3.org/TR/ldp/4 Christoph Braun and Tobias Käfer3.2 Example Walk-throughThe showcase depicts how transparent and verifiable information is generatedand exchanged during the life cycle of a supply chain item. During the firsttwo steps, i. e. item creation and item handover, the item’s physical history isdescribed and published as Linked Data. In the third step, i. e. item verification,we only cover the verification of the published data.Item Creation: Initialising the Linked Pedigree. A visitor to our boothwould first take the role of the fisherman and create a supply chain item bycatching a fish (made of plastic). Information on the item and the catchingprocess, e. g. fishing ground and time, is recorded in form of an RDF graph andpublished via HTTP. Thus, the initial part of the Linked Pedigree on the fish isformed.Item Handover: Storing an RDF graph hash. The fisher meets up withthe trucker to hand over the item. Information on the imminent item handoveris included in the initial Linked Pedigree part.Still in the role of the fisher, the visitor uses the LD-chain client to storethe hash of the updated Linked Pedigree part via the Smart Contract. For that,he/she enters the URI whose content to hash. In addition, the visitor needs tospecify the next owner’s Ethereum wallet address. As a result, a transaction forstoring the hash and transferring the digital ownership to the trucker is issued tothe Ethereum node. The transaction is pending until a miner successfully minesa block that includes this transaction.During the process, console logs are displayed about what is happening. TheRDF content of the dereferenced URI can be viewed, hashing logs indicate thegenerated hash value, and query logs show if the submitted Linked Pedigree partis to be appended to an existing one or registered as a new initial one. Whenthe transaction is mined, the transaction cost as well as the action performed,i. e. registering or appending, is displayed to the visitor.Item Handover: Approving an RDF graph hash. Now, the visitor takesthe role of the trucker. Before accepting the item, the visitor has to reviewthe content of the proposed Linked Pedigree part, especially information on theimminent handover. If everything is fine, the visitor uses the LD-chain client toapprove the hash of the Linked Pedigree part. For that, he/she enters the URIto approve, i. e. the URI of the fisherman’s part. A transaction to approve thespecified URI is issued. After successful mining, the associated cost is displayed.Again, console logs are displayed to the visitor during the process aboutcontent, hash and verification of the input URI. When the transaction is mined,the visitor in the role of the trucker accepts to receive the physical item fromthe fisher.Now the visitor can create the next Linked Pedigree part that references theinitial part by its URI. Continuing the iterative example, he/she can store thenew part’s hash and propose the item to his/her next role, i. e. the supermarket.Verifying the Integrity of SCM Information using Linked Data and DLT 5Item Verification: Checking a Linked Pedigree. Skipping forward in theiterative example: The supermarket has already approved the trucker’s LinkedPedigree part. The received item is now to be purchased by the end-consumer.Taking the familiar role of the end-consumer, the visitor wants to ascertainif the fish’s information has not (maliciously) been tampered with, e. g. a retro-spective adjustment to the cooling information was made. To this end, the visitoruses the LD-chain client to verify the integrity of the fish’s Linked Pedigree. Forthat, he/she enters the URI of the last known Linked Pedigree part that is pro-vided by the supermarket. A table shows verification information of each URIdereferenced during the backwards traversal of the Linked Pedigree. This way,the customer can check the information trail on the fish until the beginning, i. e.the catchment.Again, logs about the verification of the iteratively dereferenced URIs aredisplayed. This verification can be performed analogously at any point in thesupply chain by any participant, starting at different points in the traversal.4 Summary and ConclusionWe presented an implementation to verify the integrity of information along asupply chain using Linked Data and Smart Contracts. Linked Data is used tostore data off the chain, and a Smart Contract manages hashes on the ledger. Weshowed an application to verify information along an exemplary supply chain upto the end-consumer.We see wide application possibilities in decentrally organised logistics net-works where on-premise data storage and access control is desired.Bibliography1. Arnot, C: Transparency Is No Longer Optional: How Food Companies Can Re-store Trust, (2015). https://www.forbes.com/sites/gmoanswers/2015/11/30/transparency-no-longer-optional/ (visited on 01/30/2019). Online2. Braun, C and Käfer, T: Verifying the Integrity of Hyperlinked Information usingLinked Data and Smart Contracts. In: Proceedings of Semantics 2019 (2019). Ac-cepted3. Eberhardt, J and Tai, S: On or Off the Blockchain? Insights on Off-Chaining Com-putation and Data. In: Proceedings of the 6th European Conference on Service-Oriented and Cloud Computing (ESOCC) (2017)4. Hogan, A: Skolemising Blank Nodes while Preserving Isomorphism. In: Proceedingsof the 24th International Conference on World Wide Web (WWW) (2015)5. Solanki, M and Brewster, C: Consuming Linked data in Supply Chains: Enablingdata visibility via Linked Pedigrees. In: Proceedings of the 4th International Work-shop on Consuming Linked (COLD) at the 12th International Semantic Web Con-ference (ISWC) (2013)6. Sopek, M, Gradzki, P, Kosowski, W, Kuzinski, D, Trójczak, R, and Trypuz, R:GraphChain: A Distributed Database with Explicit Semantics and Chained RDFGraphs. In: Proceedings of the 3rd Workshop on Linked Data & Distributed Ledgers(LD-DL) at the Web Conference (29th WWW) (2018)

Verifying the integrity of information along a supply chain using linked data and smart contracts

https://publikationen.bibliothek.kit.edu/1000100178/49127046

Verifying the integrity of information along a supply chain using linked data and smart contracts

Abstract

Similar works

Full text

Available Versions

KITopen