Decentralizing Supply Chain Anti-Counterfeiting Systems Using Blockchain Technology
11 Decentralizing Supply Chain Anti-CounterfeitingSystems Using Blockchain Technology
Neo C.K. Yiu,
Member, IEEEDepartment of Computer Science, University of [email protected]
Abstract —An interesting research problem in supply chain industry is evaluating and determining provenance of physical goods –demonstrating authenticity of luxury goods such as bottled wine. Yet, there has been a few innovative software solutions addressingproduct anti-counterfeiting and record provenance of today’s goods that are produced and transported in complex, inter-organizational,and often internationally spanning supply chain networks. However, these supply chain systems and networks have been built andimplemented with centralized system architecture, relying on centralized authorities or any form of intermediaries, and leading to issuessuch as single-point processing, storage and failure, which could be susceptible to malicious modifications of product records or variouspotential attacks to system components by dishonest participant nodes traversing along the supply chain. Blockchain technologyhas evolved from being merely a decentralized, distributed and immutable ledger of cryptocurrency transactions to a programmableinteractive environment for building decentralized and reliable applications addressing different use cases and existing problems in theworld. In this research, the Decentralized NFC-enabled Anti-counterfeiting System (dNAS) is proposed and developed, decentralizing alegacy anti-counterfeiting system of supply chain industry using Blockchain technology, to facilitate trustworthy data provenance retrieval,verification and management, as well as strengthening capability of product anti-counterfeiting in wine industry with capacity to furtherextend to supply chain industry as a whole. The proposed dNAS utilizes decentralized blockchain network on a consensus protocolcompatible with the concept of enterprise consortium, programmable smart contracts and a distributed file storage system to develop asecure and immutable scientific data provenance tracking and management platform on which provenance records, providing compellingproperties on data integrity of luxurious goods, are recorded, verified and validated automatically.
Index Terms —Blockchain, Anti-counterfeiting, Smart contracts, Product Authenticity, End-to-End Traceability, Supply Chain Integrity,Supply Chain Provenance, Decentralization, Enterprise Blockchain, NFC-enabled Anti-counterfeiting System, Near-field Communica-tion, Internet-of-Things, dNAS. (cid:70)
NTRODUCTION I N this chapter, the motivation of this research and a listof research questions with the research methodology arepinpointed and explained by going through the growingchallenges of improving counterfeit product trading. Thecurrent solutions which have already been implementedin supply chain industry against the challenges, with theineffectiveness and inefficiency of current solutions againstcounterfeit product trading also discussed to better addressthe need of more innovative and decentralized solutions,such as dNAS, proposed in this research with a set ofresearch objectives declared. The problem of counterfeit product trading, such as luxuri-ous goods or pharmaceutical products, has been one of themajor challenges the supply chain industry has been facing,in an innovation-driven global economy. The situation hasexacerbated with an exponential growth of counterfeits andpirated goods worldwide, for which it has also plaguedcompanies with multinational supply chain networks fordecades and on. • Neo C.K. Yiu was with Department of Computer Science, University ofOxford, Oxford, United KingdomManuscript first submitted for preprint on Jan 31, 2021.
The analytical study – [1], published by OECD (Orga-nization for Economic Cooperation and Development) andEUIPO (European Union Intellectual Property Office) in2016 has further suggested that the volume of counterfeitproduct trading, which has been alarming, and alreadyamounted to as much as $509 billion representing ofworld trade and 6.8% of imports from non-EU countries.In response to the growing concern, innovative,fully-functional, integrable and affordable product anti-counterfeiting solutions, utilizing the cutting-edge technolo-gies, have been widely and urgently demanded so as toensure provenance and traceability of genuine productsthroughout supply chain counterfeiting, and suggested so-lutions should be widely adopted regardless of industries,size of companies and its supply chain systems.
Given the growing concern and worsening situation intrading activities of counterfeit products, there have beenanti-counterfeiting solutions developed and implementedin the supply chain systems of different industries as listedand explained in [2]. Wireless communication technologies,such as
RFID (Radio-frequency Identification) or
NFC (Near-field communication which is a subset of RFID), powering a r X i v : . [ c s . C Y ] F e b the Internet of Things (IoT) are mostly those existing anti-counterfeiting and traceability solutions with centralizedarchitectures currently based on, via packaging the tags onpackets of goods or products itself for identification andanti-counterfeiting purpose.One of the solutions to answer the growing concernson product counterfeiting along supply chain systems ofsupply chain industry and specifically for the wine industry,was the
NFC-enabled Anti-Counterfeiting System (NAS) as de-picted in
Appendix A.1 . [3] was developed and implementedback in 2014, aiming at providing an innovative and fullyfunctional alternative for supply chain anti-counterfeitingand traceability, based on Near-field communication tech-nology and cloud-based microservice architecture with cen-tralized storage structure, solely hosted by any winemaker,to help improve the worsening situation of product coun-terfeiting especially for the wine industry.It has come to a point that even though the implemen-tation of NAS itself is already more secured than mostof the typical supply chain systems, with original winerecords being validated at any node along the supply chain,centralized architectures of NAS could still pose a risk indata integrity and product authenticity as any node, notonly winemakers, along the supply chain have full control ofwine records stored in their own database architectures. Incase different nodes along the supply chain are untrusting toeach other, there could still be possibilities that wine recordsbeing duplicated adversely leading to a situation that wineconsumers can still purchase bottled wine counterfeits withfabricated wine records retrieved from NAS.As explained with research findings of security analysesperformed in [2], amongst NAS and other existing anti-counterfeiting alternatives with centralized architecture, uti-lizing wireless tag communication technologies, there arethree common counterfeit attacks in the existing centralizedanti-counterfeiting and traceability solutions: (1) modifica-tion of product records stored in tags, such as fabricatingproduct identifiers or metadata of any wine product, (2)cloning of tag metadata such as those genuine wine recordsto any counterfeit product tag, and (3) removal of legitimatetags from genuine wine products with reapplications toother counterfeit wine products.The typical architecture of centralized supply chainscreates several concerns as discussed in [2]. First, there isa tremendous processing burden on servers, since signif-icant numbers of products flooded through multiple sup-ply chain nodes. Second, substantial storage is required tostore authentication records for every single processed wineproduct. Third, with existing solutions basing on centralizedarchitecture, traditional supply chains inherently have theproblem of single-point failure and so potential servicedowntime and data loss could be expected. The legacy NASrelies on a centralized authority, such as winemakers, tocombat counterfeit products which could in all likelihoodresult in single-point processing, storage, and failure .To overcome such issues, Blockchain Technology (orother Distributed Ledger Technologies built with decentral-ized networks) stands out as a potential framework to estab-lish a modernized, decentralized, trustworthy, accountable,transparent, and secured supply chain innovation againstcounterfeiting attacks, compared with those built with cen- tralized architecture, with comparison between two as de-tailed in
Fig. 1 . In this research, it is aimed to develop andimplement a novel prototype with a decentralized architec-ture, based on the legacy NAS, to reinforce the innovativeidea of product anti-counterfeiting in a decentralized fash-ion, namely the
Decentralized NFC-based Anti-CounterfeitingSystem (dNAS) .Fig. 1:
Comparison of Decentralized and CentralizedArchitecture
Open research questions and difficulties inherent in address-ing them should first be detailed before actually divinginto system design of the proposed dNAS. It will then befollowed by outlining a preliminary design of system modeland an effective blockchain-based system architecture run-ning on cloud production environment. Given a variety ofadvantages, such as prevention of single-point failure, betterresilience and availability of being applied amongst supplychain participants, brought by the blockchain technologyand the concept of decentralized application, to have amore secured and sophisticated supply chain system againstcounterfeiting attacks, the main question of the researchshould therefore be: "How is it feasible to decentralize an anti-counterfeitingapplication already developed and implemented in supply chainindustry to better combat the rampant counterfeiting attacks?"
In order to progress the research with a prototype ofdecentralizing the aforementioned legacy NAS, the mainquestion is then addressed through answering the followingsub-questions throughout the research:1) How are the chosen blockchain and its consensusprotocol being implemented in the proposed dNAS?2) How are the current operations of wine recordmanagement and product provenance verificationreengineered to be a more decentralized, secured,autonomous and economical alternative?3) How is wine record data being stored in the pro-posed decentralized and distributed storage archi-tecture?Given the main research question and a set of the derivedsub-questions identified, it is common to follow an organ-ised way of exploring them step-wise in this research. Thebest approach is to follow research techniques applied to the field of computer science namely proof-by-demonstration and implementation-driven research technique, depicted in [4], [5]respectively, under which a working prototype of dNAS willbe introduced and validated with the idea of decentralizedsupply chain solution addressing the main research questionand the derived sub-questions. It is important that duringdevelopment, the next best steps are always taken intoaccount and ultimately offer a better analysis of researchquestions with detailed documentation of developing suchinnovative and decentralized solution, using blockchaintechnology and other useful technical concepts, to improvethe exacerbating situation of product counterfeits in supplychain industry.
ACKGROUND
In this chapter, following the advantages brought by theblockchain technology, a variety of current blockchain im-plementations applied to different categories of supplychain industries are also mentioned with reasons on why theproposed dNAS could be a novel and feasible innovation toimprove the product counterfeiting, as a primary motive fordeveloping and implementing dNAS. The idea of develop-ing decentralized applications, acting as a contribution ofthis research for which the development of dNAS is basedon, will further be elaborated.
With the advancement of blockchain development in recentyears, there have been some existing blockchain innova-tions developed in different domains and in combinationwith other emerging technologies for different purposes. Ablockchain-based digital certificate system and blockchain-enabled system for personal data protection were proposedin [6], [7] respectively. [8], [9] have also given an overviewof blockchain-based applications developed in different do-mains where a variety of examples of blockchain systemsand use cases are built, could be found in healthcare domainas depicted in [10], [11] for decentralized health record man-agement and storage, and energy domain [12] for electric e-mobility, grid management and Peer-to-Peer energy trading.Blockchain technology has also been utilized to integratewith other technologies, such as
Internet-of-Things (IoT) and
Artificial Intelligence (AI), on use cases, such as [13], [14] onenabling interoperability of IoT device in a decentralizedenvironment with
Fog computing come into play as theorchestrating layer, [15] on blockchain-based access controllayer to the IoT data storage, and [16] on decentralized AIapplications for enhanced data security, improved trust onrobotic decisions, decentralized intelligence.Blockchain innovations have also been implementedacross the supply chain industry, and further for the use caseof improving product traceability and anti-counterfeitingaspects of the industry. [17] has proposed a concept ofblockchain system to enhance transparency, traceability andprocess integrity of manufacturing supply chains, whilean Ethereum-based fully-decentralized traceability systemfor the Agri-food supply chain management named Agri-BlockIoT was developed in [18]. Furthermore, a novelblockchain-based product ownership management sys-tem, a blockchain-based anti-counterfeiting system coupled with chemical signatures for additive manufacturing andontology-driven blockchain design for supply chain prove-nance, are also detailed in [19], [20], [21] respectively.However, the aforementioned blockchain implementa-tions tend to support the findings only with conceptualdesigns on how blockchain technology could be utilizedfor achieving better provenance, traceability and processintegrity, but few have really been practically implementedwith insightful evaluations on the prototypes and strategiesregarding the actual implementation and integration in anycategory of supply chain industry. The issues such as systemavailability, system integration model, security consider-ations, data integrity with the actual decentralized datamanagement operations and system functionalities beyondretailer points, are remained to be addressed.Some implementations are conceptualized and de-veloped based on computation-extensive permission-lessblockchain networks and consensus algorithms, aiming atfull decentralization over scalability and stability of suchdecentralized systems developed. Instead of developingblockchain implementations based on conceptual design,decentralizing a legacy anti-counterfeiting system alreadyimplemented in the supply chain industry, further withblockchain innovations integrated with, would be a morepragmatic way to start with so as to provide timely support toimprove the snowballing situation of product counterfeitsof supply chain industry, with the novel dNAS developedand implemented.
The research is to investigate into the development of decen-tralised applications (ÐApp) utilizing available frameworksof Enterprise Blockchain, enabling distributed applicationsto function with unprecedented versatility defined in smartcontracts, with a distributed file storage system, such as
InterPlanetary File System (IPFS) and
Swarm suggested in[22] and [23] respectively, on how it could bring advantagesover the legacy solutions in supply chain anti-counterfeitingand traceability. The idea is all about provably honest ofwhich users of the decentralized application should be ableto automatically verify the actions requested by the serverinstances of other nodes along the supply chain, wheneverthey would like to have the server instances themselveschecking with instances of decentralized storage and decen-tralized network with validation results returned.dNAS aims at delivering a more secured and quality ap-proach to verify the authenticity and provenance of luxuri-ous products such as bottled wine, with the use of a peer-to-peer Blockchain Network of Blockchain 2.0 implementationsas explained in [2], basing on the concept of enterprise con-sortium, and a peer-to-peer distributed file storage system,such as IPFS, which has the potential to eliminate absurdamount of costs for on-chain storage and provide enhancedprivacy, reliability and quality of service compared with thelegacy NAS with centralized architecture.Contrary to existing conceptual blockchain implementa-tions applied in different industries, this research is aboutdecentralizing a legacy anti-counterfeiting solution alreadyimplemented in supply chain industry, to improve product counterfeits for the industry.
Practicality in terms of thesystem implementation, integration model, data integrity,system scalability and stability, is what this research willbe after. The proposed prototype depicted in this researachnot only stands as a working ÐApps prototype, but alsodefines a framework and practice for different nodes alongthe supply chain to integrate the low-cost, real-time andimmutable blockchain technology into their daily supplychain workflows.For entities to embrace this budding technology withconfidence, dNAS needs to be secured, reliable, flexible withintegration models available, and its implementation detailsshould be straightforward for the registered supply chainnodes to adopt. Similarly, for consumers interacting withthe user interface of dNAS, it needs to be user-friendly andtransparent. dNAS itself does offer a foundation to explorestrengths and weaknesses of decentralised applications overtheir centralised counterparts, especially in supply chainindustry. The evaluation of the proposed dNAS against thepredefined research objectives, and in areas, such as thedecentralized wine record management, data and processintegrity in dNAS, system security, availability and integra-tion, would also uncover certain limitations and concernsof hosting and deploying ÐApps on Enterprise Blockchainor with other Blockchain technologies and frameworks. Theproposed dNAS could further be improved with potentialfuture work inspired from the findings on limitations andconcerns raised in the system evaluation process of dNAS.
YSTEM M ODEL D EFINITION dNAS is a decentralized and integrated system tailor-madefor supply chain industry and specifically the wine in-dustry. While capabilities, such as end-to-end traceability,provenance and authenticity were enabled in the legacyNAS, its anti-counterfeiting and traceability model wasactually based on winemaker roles with their productsmoving downstream to their registered supply chain par-ticipants and wine consumers until the purchase points.The anti-counterfeiting model of dNAS is actually based ona decentralized enterprise consortium consisting of multiplewinemakers and supply chain participants, responsible foroperating the web application and the NFC-enabled mobileapplications of the legacy NAS with a dedicated blockchainnetwork, via an integrated interface, with blockchain nodesassigned to every consortium member. This chapter will gothrough the use-case analysis, proposed system architectureof dNAS and design decisions made for the development ofdNAS.
According to the potential opportunities and concerns ofdeveloping decentralized solutions for supply chain anti-counterfeiting and traceability, explained in the researchdiscussion result of [2], a fundamental set of system require-ments for developing dNAS is therefore defined.There are in total 19 fundamental system requirements,as listed in [2], to develop dNAS, with rationales rangingfrom data integrity, scalability, data privacy, improved au-thentication and authorization, ease of integration, consen-sus performance to state transparency, summarizing what supply chain industry and even the specific wine industryexpected from the innovative dNAS with potential oppor-tunities and concerns of decentralizing supply chain anti-counterfeiting and traceability, also addressed through thedevelopment and implementation of dNAS.
Before getting more detailed into the system architectureof dNAS based on the system requirements gathered asdiscussed, the constituent system roles and their use casesare needed to be clarified. In dNAS, the decentralized ar-chitecture and anti-counterfeiting mechanism are buildingaround an enterprise consortium consisted of winemakersand its supply chain participant nodes along the supplychain. Similar to those defined in the legacy NAS, there aremainly FOUR system roles in the proposed system model ofdNAS depicted as follows:
The Winemaker Role : The winemaker is the manufacturerof wine products. The provided functions of winemakersinclude creating new wine records with a set of wine pedi-gree data, supply chain data and transaction data, proposingits supply chain participants to be added to or removedfrom the consortium as well as its blockchain node to theblockchain network, setting quantity of wine products couldbe sold, and retrieving information on its supply chainparticipants so that the latest sales status can be retrieved.The winemaker role is also possible to inquire about wineproducts that the participants marketed to its wine con-sumers and verify whether specific wine products have yetbeen recalled, exchanged and confirmed if the current statusof these wine products has yet been verified with publicaddresses provided by wine consumers.
The Supply Chain Participant Role : The supply chainparticipants could be with a role of wholesaler, retaileror reseller, and so literally any supply chain node afterwinemakers and prior to wine consumers. Participants canuse functions of dNAS to encrypt wine record componentswith its private keys, and wine consumers can thereforeutilize asymmetric cryptographic concepts applied to sys-tem functions in its blockchain service instance hosted bythe consortium administrator, with participants’ public ad-dresses to verify if the participant is what it claims to be.After each transfer operation, the participant updates thedata fields of transaction data and supply chain data, andso the updated content hash is pushed on-chain availablefor those registered nodes of winemaker role and supplychain participant role to obtain the data required.
The Wine Consumer Role : The wine consumers are endpurchasers of wine products. The wine consumer can verifywhether a supply chain participant has a sales relationshipwith another winemaker of wine products, and also verifywhether the supply chain participant’s inventory has notyet been sold out. Wine consumers can prove that theiridentities are consistent with their public addresses, andobtain individual transaction records and wine status inwine records via linking the dedicated blockchain nodes toa specific block explorer for reviewing targeted blocks andtransactions. As long as a wine product is transferred bya registered node of wine consumer role, the authenticityand end-to-end traceability are still assured and legit evenbeyond any retailer point post supply chain.
The Consortium Administrator Role : A consortium is con-sisted of winemakers and supply chain participants. Theconsortium administrator is elected through a democraticprocess involved every consortium member who is assignedwith their own blockchain service instance with a desig-nated blockchain node running on the blockchain networkmanaged by the consortium. The proposed dNAS wouldassume there is only one administrator nodes elected forthe enterprise consortium to get started in this research for theease of operations and presentations. The possible approachof having on-chain governance aspects to decentralize theenterprise consortium, or to enhance degree of decentraliza-tion on dNAS as a whole, should be covered in future workof implementing dNAS.
Given the system roles of dNAS defined, a use case analysisbased on these system roles was performed as demonstratedin
Appendix B.1 . dNAS is developed based on a conceptof enterprise consortium , as depicted in
Fig. 2 , consisted ofmultiple registered nodes of winemaker role, supply chainparticipant role and the consortium administrator, intro-duced to dNAS, unlike the legacy NAS of which the anti-counterfeiting system and mechanism are based solely onwinemakers . Fig. 2:
Enterprise Consortium of dNAS
Getting started with the blockchain system, as depictedin
Fig. 3 , there are use cases only accessible for the con-sortium administrator, such as management of smart con-tracts, which are decentralized software design patternsand methods with access shared across different blockchainnodes running on the network, based on the authorizationmechanism defined. The smart contract will need to bedeveloped, deployed or even upgraded to the blockchainnetwork if necessary. The consensus level is indeed thenumber of votes from consortium members, required for aconsensus reached to confirm a registered node to be addedto or removed from the consortium. The consensus level canonly be set by the consortium administrator if necessary,especially for a situation when the size of the consortiumchanged drastically affecting degree of decentralization and fraction to reach consensus. For other consortium members,they are able to propose to add a new node to or removean existing node from the consortium, based on the publicaddress of their designated blockchain node, stored in anon-chain registry. Every consortium member would be as-signed with a blockchain node and is therefore eligible tosend and validate transactions of the blockchain network tohelp reach consensus and state broadcasting.Fig. 3:
Use Cases of dNAS Blockchain System
Regarding the use cases of the database-operating webapplication, as listed in
Fig. 4 , any registered node of wine-maker role and supply chain participant role can get accessto the functionalities provided by the web application tomanage, the inventory of wine products they hold, thelist of collaborative supply chain participants, and projectsthey might work on involving different wine products withdifferent supply chain participants. A wine record, whichcould be created only by registered nodes of winemakerrole, is consisted of four constituent data categories suchas wine pedigree data, transaction data, supply chain dataand unsuccessful validation data. Likewise, only registerednodes of winemaker role could perform operations suchas create, update and delete in the web application, whileregistered supply chain participant nodes and registeredwine consumer nodes could only update the respectivetransaction data and supply chain data via
ScanWINE mo-bile application at the point of wine accepting or purchasingfollowing a series of data validation steps, when scanningagainst the NFC tags on wine products.Like the legacy NAS, only registered nodes of wine-maker role could access to the NFC-enabled tag-writingmobile application -
TagWINE with use cases as listed in
Fig. 5 , and perform its functionalities such as viewing winerecords on the mobile application, writing required datafields of the wine record to NFC tags and checking thehistory of previous writing activities of those tags on thewine products they produced.While for the NFC-based tag-reading mobile application-
ScanWINE , with use cases as listed in
Fig. 6 , any registerednodes, including those of wine consumer role, is accessibleto the functionalities, such as scanning NFC tags, whichwill also trigger the process of validating provenance andauthenticity of wine products by analysing the data storedin NFC tags, unique identifier of scanned NFC tags and
Fig. 4:
Use Cases of Database Web Application
Fig. 5:
Use Case of Tag-Writing App - TagWINE identity of registered nodes with its registered device scan-ning the NFC tags. In case such validation process is failed,the unsuccessful validation data of that wine record will beupdated and so both related winemaker and supply chainparticipants would be notified of the new status showedat their database management web application. After goingthrough a successful validation process, the wine recordwill be shown on the mobile application with further op-tions given, for wine consumers, to buy or, for supplychain participants, to accept the wine product with thesephysical wine products at their end. The transaction dataand the supply chain data are therefore updated followingthe activities of purchasing or accepting wine products areconfirmed.Regarding the account management of registered nodeswith use cases listed in
Fig. 7 , it is actually based on thedesign patterns developed in
AccountController of the app-backend service in legacy NAS, for which every node couldgo through registration steps and become registered nodes Fig. 6:
Use Case of Tag-Reading App - ScanWINE of either winemaker role, supply chain participant role orwine consumer role. The on-boarding process and registra-tion steps of these aforementioned roles will be differentdepending on how each type of registered node could getthe access to different system components, including thedatabase web application,
TagWINE , ScanWINE and theblockchain network, based on their roles and whether theyare members of the enterprise consortium . The
AccountCon-troller offers functionalities including validating the role ofspecific registered nodes, voting to add or remove registerednodes of the enterprise consortium .Fig. 7:
Use Case of Registered Node Management HE D ECENTRALIZED
NFC-E
NABLED A NTI -C OUNTERFEITING S YSTEM - D NAS
Following the identified system model definition, a systemarchitecture of dNAS is then designed accordingly, in or-der to answer the main research question of this research.
With the proposed system architecture of dNAS as demon-strated in
Appendix B.2 , it explains how exactly the legacyNAS could be re-engineered and running on the chosenblockchain network of enterprise blockchain implementa-tions, such as Ethereum Proof-of-Authority, what exactly arethe system components to be decentralized so as to enablecore functionalities of the novel dNAS. The proposed systemarchitecture of dNAS can be explained in mainly three parts,namely (1) the decentralized blockchain network, (2) theblockchain interface, and (3) the system components builtin the legacy NAS.
The decentralized blockchain network, as demonstrated in
Fig. 8 , is developed based on Enterprise blockchain impl-mentations such as Quorum blockchain with an consensusalgorithm of
Istanbul Byzantine Fault Tolerant (IBFT) andEthereum blockchain network with an consensus algorithmof
Proof-of-Authority (PoA), in line with the concept of en-terprise consortium, introduced in the system design andconsisted of client nodes which could either be validatornodes (full node) involving in validating transactions andsigning new block in the blockchain, or listener node (lightnode) which could only listen to blockchain states andperform non state-transitioned interactions with smart con-tracts deployed to the network. Whether a validator nodeor listener node is assigned will be depending on the roleof authorities in the enterprise consortium. For instance,winemaker role would be assigned with a validator nodeof the blockchain network, while some of the supply chainparticipant nodes would only be restricted to a listener nodedepending on its involvement in the enterprise consortium.Fig. 8:
The dNAS Blockchain Network
The dNAS blockchain network could be built based onenterprise blockchain implementations amongst Quorumblockchain, Ethereum blockchain, Hyperledger Fabric or Tendermint. In case the
Proof-of-Authority blockchain net-work of dNAS is developed, it could be built based ondifferent Ethereum client implementations, such as Go-Ethereum, which could specifically termed as Clique Proof-of-Authority network or Aura Proof-of-Authority network.While in case the blockchain network is developed withQuorum blockchain, the
Istanbul Byzantine Fault Tolerant network could be developed with Quorum client imple-mentations, such as Go-Quorum. No matter which enter-prise blockchain implementations the blockchain networkof dNAS could develop on, it consists of a set of clientnodes managed by different authorities of the enterpriseconsortium, and thus enabling the peer-permissioning func-tionalities and so the network is functioned as a permis-sioned network, unlike public networks such as Ethereummain net which is an open network and not emulatedthe concept of peer-permissioning, due to the fact that theproposed dNAS is developed for supply chain industry andspecifically for the wine industry. When starting client node,individual nodes are connected to each other, via specifyingthe node identifier of any client nodes already running onthe network, so as to form a network.Smart contracts are developed in Solidity and deployedto the dNAS blockchain network by the consortium ad-ministrator who is also hosting validator nodes on thenetwork on behalf of consortium members. Whenever thereis a transaction request coming to the blockchain network,the transaction-sending node will invoke methods definedin the smart contract accordingly based on an applicationbinary interface (ABI) specified in data fields of a transactionto perform state-transitioned changes on smart contractstorage as well as states of the network with transactionsvalidated and new block mined. The smart contracts can fur-ther be upgraded with the implementation of smart contractupgradability pattern. The management of smart contractswith standard processes such as deployment or upgradeis handled by the contract deployment suite for whichonly blockchain nodes of the consortium administrator willhave access to and perform such operations on these smartcontracts.There are also network monitoring components, suchas the blockchain explorer and node management suite, tobe deployed and connected to blockchain nodes runningon the network. The former is a user interface connectingblockchain nodes on the network for authorities to per-form querying and viewing on validated transactions andmined blocks including those are at pending stage. Thelatter is a dashboard listing different performance metricsof every blockchain node running on the network. Thedata collected from these network monitoring tools couldfurther be augmented and integrated with any open-sourcedata visualization tools, such as Kibana, with enhancedmonitoring capability of dNAS as a whole.With the advent of the decentralized blockchain networkintegrated with system components of the legacy NAS viaa tailor-made blockchain interface with other tools, thesuggested architecture pattern can then provide a highthroughput and content-addressed block storage model tothe architecture that greatly improves the performance ofthe proposed dNAS. Similarly, regarding the advantagescontributed by adopting Blockchain technology, it has been able to prevent single-point failure, and nodes along thesupply chain do not essentially need to trust but collaboratewith each other in the enterprise consortium.
Given the decentralized blockchain network is regarded asa vital part of the proposed dNAS, a dedicated blockchaininterface as demonstrated in
Fig. 9 , which is essentially an-other microservice, will need to be designed and developedto help integrate the decentralized bits to system compo-nents of the legacy NAS. The blockchain service, actingas an interface between system components of the legacyNAS and the blockchain network, is developed based onfunctionalities, offered by open-source Ethereum interfacelibraries such as
Ethers.js and web3.js , aiming to interact withthe designated blockchain node and in turn the blockchainnetwork. API endpoints are also developed basing on logicpatterns in different controllers of the blockchain service.Fig. 9:
The Proposed Blockchain Interface of dNAS
The
AppController of app-backend service in the legacyNAS could invoke endpoints to perform different func-tionalities, such as pushing data on-chain, getting or vali-dating data from the deployed smart contracts, executingpeer-related operations including voting to add or removeparticipating nodes, and validate roles of registered nodesin the enterprise consortium. The blockchain network isalso utilized as a controller of the enterprise consortiummanaging access control, identities of registered nodes byimplementing a concept of on-chain peer registry and serv-ing as a tamper-proof log of transaction events emitted backto the blockchain service.With different helper functions developed in theblockchain service and functionalities enabled with open-source Ethereum interface libraries, the blockchain serviceinstance can therefore direct its designated blockchain node,to send transactions so as to perform different operationsrelated to wine records and the peer registry. Sending trans-actions will require a signature produced with a private key of the node account. Therefore, a dedicated key manage-ment module such as the key vault service, will need to bein place to store key pairs related in any signing activitiesinvolved in any transaction processed by a specific nodeaccount, which is also linked with the blockchain serviceinstance, and to provide a secured mechanism for any keypair to be retrieved whenever there is a transaction or asigning process to be handled.Instead of storing the complete version of wine recordwith all of its constituent metadata such as transaction data,wine pedigree data and supply chain data, only the contenthash of the wine record along with other payloads for datasecurity and privacy should be stored in the data structuredefined in the deployed smart contracts. Distributed datastorage system, such as IPFS, is therefore introduced andmigrated to the proposed dNAS, so that the dedicated anddistributed IPFS node could be connected to an instance ofthe blockchain service whenever there is a request sendingto the blockchain service to process. Storing wine records, insuch a distributed storage system, provides a unique contenthash which would then return to the blockchain service forfurther operations before being included in any transactionwhich would then be signed by dedicated node accountsand sent to the transaction pool of the blockchain networkqueuing to be processed for validation.The content hash of specific wine record is then retrievedfrom the smart contract whenever there is a validationprocess to be executed and be further used to retrieve winerecord subsets from the distributed storage system off-chain,via the designated IPFS node. IPFS speaks about an ideaof a permanent web, implying any data published to thenetwork should be available forever. The node managementsuite is also connected to IPFS nodes so as to have the samemonitoring feature applied to every distributed IPFS nodeassigned to registered nodes of the enterprise consortium.
According to system components of the legacy NAS asdemonstrated in
Fig. 10 , the applications provided to differ-ent registered nodes along the supply chain are namely thedatabase-operating web application,
TagWINE – the NFC-enable tag-writing mobile application, and
ScanWINE – theNFC-enabled tag-reading mobile application. The mobileapplications are designed to interact with the
NTAG 203 ofNFC tag model.The functionalities, enabled by those system componentsof the legacy NAS, substantiating the use cases described inthe use case analysis, are actually based on logic patternsin
AppController of the app-backend service. For instance,
CRUD (Create, Read, Update and Delete) operations onwine records, performed on the database operation webapplication, actually send request to
AppController invokingrespective methods related to such operations, and collabo-rate with different system components, such as the databasesystem developed in Microsoft SQL, to reflect states transi-tioned back to the web application. Another example couldbe using
ScanWINE to scan a NFC tags, and validate prove-nance and authenticity of wine products, by validating andcomparing respective states of specific wine records storedin the NFC tags, the off-chain database system connected
Fig. 10:
The System Components of Legacy NAS with
AppController , distributed IPFS storage, and the on-chain data storage of smart contract deployed to dNASblockchain network via the integration between the app-backend service and the blockchain service.Regarding components of the app-backend service, adatabase system is integrated with
AppController to storestates and versions of wine records, and
AccountController is to process account management of registered nodes withstates and user sessions also stored in the database. The phonegap-nfc module is integrated with
AppController toenable
ScanWINE and
TagWINE mobile applications withfunctionalities of any NFC-related interaction, with the spe-cific NFC tags packaged on wine products. Further logicpatterns are developed and included in
AppController tointegrate with the decentralized bits of the dNAS via theblockchain interface by invoking related API endpoints ofthe proposed blockchain service to perform functionalities,such as pushing data to the blockchain and validating on-chain data of specific wine records with transaction eventsreturned to the app-backend service.
NTAG 203 Ferrite was the selected type of NFC tag whendeveloping the legacy NAS, given its universal compatibil-ity to most of the NFC-enabled devices and its resistanceagainst metallic interference for which the
NTAG 203 FerriteTag can change the magnetic flux path to avoid interferenceto the NFC tag, with high surface resistance and effective-ness in preventing resonance and suppressing coupling,from the metallic interference as NFC tags are likely tobe attached to foil packaging materials surrounding winebottlenecks. However,
NTAG 203 chip has already been outof production and replaced by those of
NTAG21x series,such as
NTAG 213 or NTAG 216 , simply given the increasedmemory storage and security functions including passwordlock and scan counter.
NTAG 216 Ferrite is therefore theselected type of NFC tag for the development of dNASowing to its extensive configuration with and for more flexibility in terms of datastored in each NFC tag representing for every unique wineproduct.
YSTEM I MPLEMENTATION
Given the system model design and system architectureexplained, the actual system implementation steps of dNAS are expected. This chapter includes the proposed systemimplementation with system operation protocols, specifiedfor detailing system functionalities of the novel dNAS, ondifferent wine record management process. The systemimplementation is categorized into two phases, namelyinitialization phase and data processing phase, coveringsystem implementations, such as consortium formation anddecentralized wine record management on dNAS.
The initialization phase includes all the necessary systemimplementation steps needed to be in place before dNAScan be fully functional for wine record management whenwine products moving along the supply chain. The initial-ization phase is consisted of consortium formation processeswith only the sample on-boarding process of new node toenterprise consortium covered in this research.
After registering for an account to access system compo-nents and applications of dNAS hosted by the consortium,such as the database operation web application, and bothNFC-enabled mobile applications according to its systemrole defined, the registered node would then be assignedwith the access to every dNAS system component. In orderto become a consortium member, an on-boarding operationis needed to execute with a blockchain node instance as-signed, which is hosted by the consortium. As detailed inthe use case analysis, only registered nodes of winemakerrole and supply chain participant role will be assigned witha blockchain node, an IPFS node and key pairs shared andkept in their own instance of key vault service. While regis-tered nodes of wine consumer role utilize shared instancesof these distributed system components hosted by the con-sortium, for data processing operations, such as the winerecord validation and appending process. Wine consumerswill consequently need to use
ScanWINE mobile applicationto validate a bottled wine with wine record returned, beforepurchasing the wine product with transaction and supplychain data updated in dNAS. The suggested protocol ofadding the new node to the consortium is described in
Fig. 11 .To have a newly registered node added to the consor-tium, a democratic voting process is performed amongstthe current consortium members. It is assumed that suchoperation is kicked in after a new node is granted accessto dNAS as a registered node, approved by the consortiumadministrator, and assigned the newly registered node ofdNAS with an instance of distributed components, includ-ing a blockchain node and an IPFS node. With the
URL of the blockchain node instance specified, the blockchainservice sends querying request to reach to the " getPeers "method (not limited by role restriction and so it could beaccessed even if the blockchain node is a light node of theblockchain network) of the deployed smart contract to geta full list of peer details of existing consortium members.The blockchain service instance of the proposed node theninvokes the propose-to-add endpoint of blockchain serviceinstance owned by every consortium member.Once the votes of adding such proposed node to theconsortium, have amounted to a half of the consortium’s Fig. 11:
Adding New Registered Nodes to Enterprise Consortium size in term of the number of participating members, twoconsequences would then happen; (1) the peer details of theproposed node will be added to the on-chain registry ofconsortium members which is in turn a white list of the con-sortium member so as to enable role restriction on accessingmethods of the deployed smart contract for wine recordmanagement, and (2) once the process of such on-chainoperation is completed, an event of adding the new node tothe on-chain registry will then be emitted and broadcast tothe blockchain service instance of the consortium adminis-trator based on the event listener enabled in the blockchainservice, which would in turn initialize a proposal on theblockchain network of adding the blockchain node of suchproposed node to be part of the blockchain network, aswell as sending requests to the counterpart of every existingconsortium member to agree on the proposal via their ownblockchain nodes running on the same blockchain networkwhen it has reached the number amounted to
N / 2 + 1 incase a Proof-of-Authority blockchain network is chosen tobe implemented in dNAS.There is also a so-called bootstrap stage applied to the on-boarding process, of which a specific starting number, suchas 5, of registered node proposed to join the consortiumare not required to go through such democratic votingprocess. Instead, the proposed nodes will be added to theon-chain registry of peer details directly by the consortiumadministrator, as well as having their blockchain nodesto be added and run on the network, so as to guaranteethere is always enough number of blockchain node runningon the blockchain network and enough headcounts of theconsortium to make democratic decisions. It is also assumedthat the voting mechanism of electing a consortium admin-istrator will not be covered in this research and would beexplained as a potential limitation of dNAS to develop on-chain governance steps described in future work of dNAS.Similar to the operation of adding registered node, thereis also an operation of removing registered node from the consortium which is not covered in the research given theirsimilarity.
The data processing phase includes all the necessary systemoperations regarding the decentralized wine record manage-ment along the supply chain, such as creation, validationand appending, involving different consortium members,with only the wine record creation process and wine recordvalidation process covered in this research necessarily.
Once a registered node of winemaker role is added tothe consortium with its blockchain node being part of theblockchain network, the wine record creation process willbe started after the physical bottled wine is produced,packaged and ready to be shipped at the winemaker point,given the fact that the wine record creation process couldonly be performed by registered nodes of winemaker role,such as the one performed by the Registered Node A, asdescribed in
Fig. 12 .The wine record creation process starts with having theapp-backend service, as described in the proposed dNASsystem architecture of the Registered Node A, firstly senta request to its blockchain service instance, by invoking theendpoint of " /peer/validate ", to confirm if the Registered NodeA is indeed a part of the consortium based on the on-chainvalidation with its public key, stored in its own instance ofkey vault service, against the version stored in the on-chainregistry. Once it is assured that such requesting node is partof the consortium, its app-backend service instance wouldthen be notified and commencing the off-chain creationprocess of a wine record, including the processes of creatingthe actual wine record and storing the full wine record tothe database of app-backend service.Invoking an endpoint of signing operations in theblockchain service would produce and return a signature on Fig. 12:
The Wine Record Creation Process a byte-array of the wine identifier, tag identifier and deviceidentifier involved in the process. In order to write therequired data to an NFC tag, Register Node A will thenutilize the NFC-enabled TagWINE mobile application forwhich only registered nodes of winemaker role could haveaccess to according to the use cases analysis, to write thewine identifier, signature and the value of write counter tothe tag itself. The " wine_status " and " supply_chain_data " arethen updated for which the former will have its updateddata fields with latest values, while new entries would becreated for the latter whenever there is new activity ofany interaction with the tag. The protection mode, with thepassword predefined randomly and automatically injectedby the app-backend service, is also applied to NTAG 216Ferrite NFC tag once the tag-writing process is completed.After completing all the required processes of the off-chain creation operation, the on-chain creation process ofa wine record is initiated. The app-backend service willinvoke the create endpoint of the blockchain service, withthe subset version of the wine record, instead of the fullwine record, as the payload of the API call, and perform op-erations required on both IPFS network and the blockchainnetwork. Once such wine record subset is uploaded to theIPFS network via a designated IPFS node, a based on
SHA256 hash algorithm is then returned to theblockchain service. The content hash of IPFS alongside thepublic address of the registered node and the unique identi-fiers of the wine product, tag and device are all included inthe payload when invoking the " create_wine_record " methodof a deployed smart contract with transactions sent to theblockchain network. The state of the on-chain storage of all these payloadfields are updated when the transaction is validated andpackaged in the block. The new block is mined by one ofthe blockchain nodes running on the network, with therespective block number, transaction hash and the eventof " create_wine_record " is being emitted on-chain and re-turned to the blockchain service. Both blockchain numberand transaction hash are then returned to the app-backendservice, updated to supply chain data and transaction dataof the full wine record stored in the dedicated databaseof app-backend service. The corresponding physical bottledwine product is therefore ready to be shipped downstreamto the next participant nodes along the supply chain, whichis already registered with dNAS to become a part of theenterprise consortium.
Once a wine record is created off-chain and on-chain by theregistered node of a winemaker role with the tag-writingprocess completed, those bottled wine products are thenshipped to the next node along the supply chain. Assumedthe next node along the supply chain is a registered node ofdNAS as well as a member of the consortium, such as theRegistered Node B described in
Fig. 13 , the correspondingwine record of an incoming wine product would then bebrought into a validation process performed on its winerecord before the wine product itself could be accepted orpurchased, via the NFC-enabled
ScanWINE mobile applica-tion.The registered nodes of supply chain participant roleand wine consumer role will then scan the NFC tagswith
ScanWINE to update the state of that wine record. Fig. 13:
The Wine Record Validation ProcessScanWINE is the only entry point for registered nodes ofboth roles to transit the state of a wine record, unlike theregistered nodes of winemaker role which could utilize thedatabase-operating web application to create and managewine records. Such wine record validation process is a three-layered validation process , namely against (1) the data storedin the database of app-backend service, (2) the on-chainstorage, and (3) the updated wine record subset stored onthe IPFS network.When a registered node logged into
ScanWINE on itsdevice and scan the NFC tag of an incoming bottled wineproduct, it will automatically get through the passwordprotection applied to the NFC tag as the static passwordis always injected during the tag-reading process. Datawritten to the tag, mentioned in the creation process, willthen return to
ScanWINE after which it could invoke themethod of validating the wine record based on the dataretrieved from the NFC tag. Off-chain validation processagainst the wine record will then take place to comparethe retrieved tag data and those stored in the dedicateddatabase of a shared instance of app-backend service. Anerror, either classified as (1) modification attack in casethe wine identifier and the signature are inconsistent withtheir counterparts stored in the database, (2) reapplicationattack in case either of the " write_counter " or " read_counter " isdifferent from that of the wine record stored in the database,or (3) cloning attack in case an inconsistent tag identifieris found, would be returned to the app-backend serviceand consequently updated the " unsuccessful_validation_data "of the corresponding wine record, with an error message shown on the user interface of
ScanWINE application.The on-chain validation processes of that wine recordwill therefore be initiated, provided that the off-chain onecompleted successfully. The app-backend service will senda request to the blockchain service via its " validate " endpointwhich will further invoke the " validate_wine_record " methodof the deployed smart contract, named " wine_data_contract ",with " tag_data " as the payload. The public address of thelast registered node handling the wine product, which wasinvolved in producing the signature from " tag_data ", is thenrecovered on-chain with the identifiers of both the wineproduct and corresponding tag of " tag_data " also supplied.The recovered public address is then validated against itscounterpart stored on-chain under the same wine identifierin a dedicated mapping storage on the smart contract.Similar to the errors returned during the off-chain vali-dation process, an error, either classified as (1) modificationattack in case both wine identifier of the payload andrecovered public address could not be found or matchedon-chain, (2) reapplication attack in case either of the " write_-counter " or " read_counter " is inconsistent with its counter-parts stored on-chain, or (3) cloning attack in case an incon-sistent tag identifier is found on-chain, would be returnedto the app-backend service and updated the respective " un-successful_validation_data " of a corresponding wine record,with an error message shown on the user interface of
ScanWINE application. Once the on-chain validation processis successful, the result and latest "
IPFS_hash " of the specificwine identifier is then returned to the blockchain service,and the latest version of the wine record subset stored in theIPFS network could then be retrieved with the "
IPFS_hash " specified via its IPFS node. The wine record subset retrievedfrom IPFS network is then compared with its counterpartstored in the database interacted with the app-backendservice. The validation result is then returned to the app-backend service and the user interface of ScanWINE .With a successful validation on the wine record, theoverview page of the corresponding wine record is thenbrought up on the user interface of
ScanWINE with winepedigree data, wine status data and some transaction datafields, such as the unique transaction hash with a corre-sponding block number with which the registered nodecan query and confirm the latest block and transactionrelated to this wine product on a blockchain explorer con-nected to the blockchain network. The " read_count " of thetag is incremented after every tag-reading process and soits counterparts stored on-chain and off-chain will also beincremented during every validation operation. The faultyand counterfeited wine product, with an error of any classi-fied attack logged in the " unsuccessful_validation_data " of itswine record, should therefore be rejected and returned to itswinemakers or the previously registered nodes of the wineproducts for further operations.
EVELOPING THE D
NAS P
ROTOTYPE
Given the system architecture of dNAS elaborated and thesystem implementation with operational steps explained,the working prototype of dNAS is therefore developed. Thedevelopment process of dNAS has followed the standardAgile software development methodology involving soft-ware project management tools, software development en-vironments, and configurations utilizing modern concepts,such as containerized applications, service-oriented archi-tecture, source version control, cloud environment deploy-ment, etc. Tools and concepts applied to the developmentprocess of the individual components in dNAS, such as theblockchain network and smart contracts, are also explained.According to the system architecture of dNAS, decen-tralized system components of dNAS are actually consistedof a blockchain network, smart contracts, an IPFS networkand a blockchain service. This chapter includes the imple-mentation details and the design concepts of individualdecentralized system components of dNAS.
The Ethereum developer community has developed manydifferent client implementations, such as Go-Ethereum PoAClique, Parity PoA Aura and Pantheon PoA, of its optionson consensus protocols provided, not to mention thereare more enterprise blockchain implementations, such asQuorum, Hyperledger and Tendermint, available for thedevelopment of permissioned network for this purpose.There are indeed benefits of having multiple Ethereumclients available which are (1) improved resilience to thenetwork enabled by a faster issue detection and correction –more people interpreting the protocol specification the morechance of these errors to be uncovered and detected, and (2)enhanced security – if there is an attack factor or bug in anyof the Ethereum implementations, it means the network isusually working fine as there is a bigger diversity of clients available.
Go-Ethereum nodes are currently the majority ofthe Ethereum network including different implementationswith different consensus algorithms, and dNAS blockchainnetwork is therefore developed based on the Go-EthereumPoA implementation.The network implementation started by creatingEthereum accounts for each of the blockchain nodes with akey pair and its key-store file generated during the process.The secret key could be decrypted if required, such assigning transactions, with the password specified. Ethereumaccounts are created and assigned to validator nodes, actingas consortium members, intended to be included in dNASblockchain network.The genesis file is essentially the recipe of definingthe genesis block, also known as the first block of anyblockchain network. There is some significant informationset in the genesis file for starting the network; for instance,the " chainId " specifies the chain those validator nodes areconnected to, the " period " specifies a block time for which ablock is mined regardless an existence of transactions in thetime interval specified, and public addresses of Ethereumaccounts generated are also put under " extraData " to specifythese accounts are going to run as validator nodes whenthe network started, with their public addresses also listedunder " alloc " in order to be allocated fund in gwei oncethe network is started. The genesis file is then initiated byevery validator node intended to run on the same dNASblockchain network.A " geth " data folder, consisted of " chaindata ", " lightchain-data ", " node states " and " transaction RLP (Recursive LengthPrefix) ", will then be created under each of the validatornodes after being initialized with the genesis file specified.The folder will serve as a local copy of global states, blockstates of specific chain and individual transaction statestransited in line with the progress of dNAS blockchainnetwork. The gas limit of the genesis block is also set in thegenesis file for the network to get started. However, the gaslimit of the block-to-mined is determined by the gas usedin its parent block, which is dynamic and not static in nature according to the one set for the genesis block, specified as" gasLimit " in the genesis file. The mechanism set out in Go-Ethereum implementation is to increase the gasLimit if " par-entGasUsed > parentGasLimit * (2/3) ", otherwise lower it andthe amount increased/decreased is determined by how faraway it could be from " parentGasLimit * (2/3) parentGasUsed ".The individual validator nodes are also ready to bestarted up to form a network with Ethereum node iden-tifiers specified. During a start-up process of a blockchainnode, the gas price is set to zero as it is not considered inany blockchain processes performed in dNAS. The APIs of remote procedure calls (RPC) are also available via RPC callsby specifying the internet protocol address of the runningnode or an internal process call (IPC) file under the " geth " datafolder created for each of the running nodes, to consortiummembers and consortium administrator for any customizednode operation. The node operations could be proposingto add new nodes to dNAS blockchain network with theprocess via the following sample method, invoked by anyblockchain node running on the network, as follows: clique.propose ( public _ address, true ) With the number of such proposal amounted to be morethan
N / 2 + 1 , where N is the number of running node,the proposed public address representing a proposed nodeis then added and run as part of dNAS blockchain net-work. The blockchain node could further be attached to anyopen-source blockchain explorer, such as
BlockScout , withthe "
ETHEREUM_JSONPRC_HTTP_URL " specified basedon the provider URL of the blockchain node.
Smart contracts, hosting functional methods, have thecore functional code become fully decentralized and dele-gated to all the trusted authorities of the consortium andits blockchain network. Every blockchain node on dNASblockchain network must agree on a current state of thesmart contract storage. According to the smart contractmechanism and workflows, such as the source code com-piled with Solidity compiler and run by the EVM of everyblockchain node of the network, as described in
Fig. 14 . TheFig. 14:
The Workflow of Ethereum Smart Contract Source smart contract source code, deployed to the blockchain net-work, is implemented in Solidity with the Truffle frameworkas its development environment and automated testinglibrary. There are typically three smart contracts developedin dNAS, so as to cover every operation defined in theinitialization phase and data process phase, namely (1) the"
WineDataContract " for wine data operations, (2) the "
Peer-RegistryContract " for the consortium registry management,and (3) the "
Proxy " which enables a proxy pattern for thepurpose of smart contract upgradability.In order to perform those operations defined under thedata process phase, design patterns of mapping storage aredefined in smart contracts with individual data types alsospecified, such as the "
WineDataHash " is indeed the contenthash (
Content ID ) obtained from any IPFS process represent-ing a specific wine record subset mapped to a unique wineidentifier which could also be further mapped per differentwrite count as " iteration ". Similar design patterns of mappingstorage could be found applying to the public key of theprevious processing node, which is also a registered node ofdNAS along the supply chain, and applying to identifiers ofdifferent tags and devices. The " currentImplementation " and" initializeCounter " are in place according to the proxy pattern, which are for checking if a contract address has already beeninitialized previously.Events are also defined in the "
WineDataContract " andthey will be emitted when on-chain process of the winerecord creation or appending is completed. The events emit-ted in either of the operation are then captured by the eventlistener defined in blockchain service. The creation processwill include both the public address and hashed deviceidentifier creating the wine record in its event, while theappending process will include both previous and currentpublic address of the wine record.Moving on with the definition of individual methods,according to the wine record creation process, a specifiedwine identifier is checked and validated if there is any winerecord of such wine identifier has already been logged on-chain previously with the " require " statement. The individualvariables mapped to the wine identifier are then updatedwith parameters including a content hash obtained fromIPFS node (
WineDataHash ), the public address, tag identifierand device identifier, of the request payload. The on-chainwine record creation process in
Algorithm 1 , is completedby incrementing the write count so as to be matching itscounterpart stored in the NFC tag, with an event of thecreation process also emitted.
Algorithm 1:
Creating On-chain Wine RecordEntry
Input : wineId, wineDataHash, newPublicAddress,tagId, deviceId
Output:
Boolean result of create operation if MapWriteCount(wineId)==0 then
M apP ubAddr ( wineId ) ← newP ublicAddress ; M apDataHash ( wineId ) ← wineDataHash ; M apT agId ( wineId ) ← tagId ; M apDeviceId ( wineId ) ← deviceId ; M apW riteCount ( wineId )+ = 1 ;emit event ;return true ; else return ( err, errM essage ) ;In case there is a wine record stored on-chain for aspecific wine identifier with the corresponding physicalwine product moved downstream to specific supply chainparticipants, the wine record is required to be validated,with the wine record validation processes previously de-tailed. Regarding the on-chain validation of a specific winerecord, it could be categorized into two parts, applied toboth wine record hash and the signature passed in whichare also stored in the NFC tag. For the former, Algorithm 2 is a straightforward comparison between the content hashof a specific wine record subset stored in the IPFS network,and its counterpart stored on-chain. It proves the content ofthe wine record was not altered along the supply chain tothe point of validation takes place.The latter is to validate the signature, with the sampleon-chain method demonstrated in
Algorithm 3 , which wasproduced by the previous processing node with its privatekey on the data such as the wine identifier, tag identifier and Algorithm 2:
Validating the Wine Record (IPFShash)
Input : wineId, wineDataHash
Output:
Boolean result of validation if MapWriteCount(wineId)!=0 then return
M apDataHash ( wineId ) == wineDataHash ; else return ( err, errM essage ) ;the device identifier, stored in physical NFC tags. The ideaof validation on the signature is to recover the public key ofthe signature on-chain and to validate if the public addressrecovered is consistent with its counterpart stored under thespecific wine identifier on-chain.Due to the fact that both tag identifier and deviceidentifier are also retrieved from the on-chain mappingstorage with the wine identifier as a key, during the on-chain validation process, both tag identifier and deviceidentifier are also validated to ensure they are consistentwith the version of the wine record, stored in the off-chaindatabase, the IPFS network and in the physical NFC tag asthe constituents to produce the signature. Both methods forvalidation can confirm if there has already been an entry ofa specific wine identifier stored on-chain to make sure thespecific wine record of the wine identifier has already beencreated on-chain. Adding the prefix makes the calculatedsignature, with the keccak256 hash function, recognisable asan Ethereum-specific signature . Algorithm 3:
On-chain Signature Validation
Input : wineId, v, r, s
Output:
Boolean result of validation if MapWriteCount(wineId)!=0 then pref ix ← (cid:48) Ethereumsignaturepref ix (cid:48) ; encodedW ineData ← encode ( wineId, T agId w , DeviceId w ) ; hashedW ineData ← hash ( pref ix, encodedW ineData ) ;return recover ( hashedW ineData, v, r, s ) == M apP ubAddr ( wineId ) ; else return ( err, errM essage ) ;Once the validation steps completed successfully, theregistered nodes are provided with options to accept awine product and in case the wine product is accepted,its wine record will be updated with new transaction dataand supply chain data appended. The method named " ap-pendWineRecord " is also defined in the smart contract forthe on-chain appending process by updating the mappingvariables accordingly. Deployed smart contracts are the shared functional codein the dNAS blockchain network and available for itsdesignated blockchain nodes to invoke so as to perform different operations requested. Just like any other softwarecode, smart contracts are expected to be upgraded foroffering new functionalities, fixing software bugs, etc. Ifthe consortium administrator was to upgrade a deployedsmart contract, the most straightforward way is to deployanother smart contract and update each of the individualblockchain service instances of dNAS with a new addressof the upgraded smart contract. However, this would re-quire a new contract address specified for every blockchainservice instance to restart, not to mention there are multi-ple blockchain service instances each owned by individualconsortium members. The contract storage will also be lostand needed to have the stored states from every state-transitioned operation, performed on the smart contract ofthe previous version, migrated to the new version of thesmart contract in order to sustain on-chain states.Fig. 15:
EVM Assembly Code with delegatecall
Given the above drawbacks of any traditional mecha-nism of upgrading the deployed smart contract, the proxyupgradability pattern offers a common ground regardless ofrounds of upgrades with the same proxy contract; neverthe-less, it will definitely add a lot of trust to the consortium ad-ministrator to perform a smart contract upgrade for the con-sortium. The proxy contract uses the " delegatecall " functionof EVM assembly code, as demonstrated in
Fig. 15 , pointingto the contract address of
WineDataContract v1 , as describedin
Fig. 16 , alongside the " msg.sender " also embedded, whichis initiated by the consortium administrator instead of theproxy contract itself.Fig. 16:
Proxy Pattern Before Smart Contract Upgrade
The upgrade process is initiated and performed bythe consortium administrator, according to the " upgradeTo "method defined in the proxy contract. The only thing thatthe proxy contract needed to operate is to point to a con- tract address of the upgraded smart contract, which is the WineDataContract v2 as described in
Fig. 17 .Fig. 17:
Proxy Pattern After Smart Contract Upgrade
The blockchain service is built as an interface between theapp-backend service and the blockchain network with otherservice logic related to the key vault service and IPFS nodesembedded into it, when performing different operationsof system implementation. Given the functionalities of theopen-source Ethereum interface libraries, such as
Ethers.js or Web3.js , the blockchain service instance is able to invokemethods of the deployed smart contracts, and to interactwith its local blockchain node with an object of " ethers " or" web3 " instantiated and contract address specified via inject-ing environment variables when bringing up the service.Other environment variables represent information, such asthe address of its IPFS local node as well as both role_id and secret_id of the key vault service for key managementpurpose.The individual routers further link to their respectivecontrollers. The controllers would utilize respective helperfunctions if some processes are repeated in the same con-troller functions, such as the process of getting its dedicatedIPFS instance and instance of key vault service. Some helperfunctions would also invoke methods of the deployed smartcontracts as shown in the
Fig. 18 demonstrating how therequests from app-backend service could flow through theblockchain service with related functions invoked at differ-ent level.The developed smart contract source code, such as thoseof
WineDataContract , PeerRegistryContract and
Proxy , afterbeing compiled as JSON objects, with the Truffle framework,are injected in the blockchain service for further objectinstantiations and operations.
As it is too costly and therefore not sensible to store a fullversion of wine record on-chain. An alternative persistentdata source is therefore required, and the IPFS decentralizedpeer-to-peer data storage is an obvious choice to be de-ployed in dNAS, under which an immutable and permanent Fig. 18:
Functional Request Flow of Blockchain Service content hash would be obtained from the IPFS network.The IPFS hash of a wine record subset would be storedon-chain under its respective wine identifier, and couldbe referred whenever there is a request for further oper-ations, such as the wine record validation across differentblockchain service instances. In the perspective of security,wine record subsets could not be altered or tampered beforebeing passed to the dNAS blockchain network and the IPFSnetwork, given the fact that every content hash of specificwine record subset, obtained from the IPFS network, will bechanged if any of the content of the wine record subset hasbeen updated, which would further lead to an inconsistencywith its counterpart stored on-chain when a wine recordvalidation process is performed.The IPFS functionalities in the blockchain service in-stance are enabled by " js-ipfs ". Before performing furtherIPFS operations, the IPFS node instance is needed to becreated in the blockchain service instance. During the winerecord creation operation, of which changes are applied tothe wine record subsets, the content hash is generated. Thecontent hash generated is with multi-hash format and base-58 encoding under which the unique multi-hash allows the exclusivity of a content hash generated, when the updatedwine record subsets are added to the IPFS network. Oncethe IPFS node instance is generated, the wine record subsetsare pushed to the IPFS network with both " path " and " con-tent " specified in the " addDataIPFS " function. The generatedcontent hash of IPFS is then pushed and stored on-chain.IPFS content hash is retrieved, from the on-chain stor-age, during the wine record validation operation, and theretrieved content hash is further sent to the IPFS node to getthe wine record subset represented, from the IPFS network.When looking up wine record subsets in the IPFS network,the network indeed utilizes the distributed hash table (DHT)looking for respective IPFS nodes storing the specified winerecord subset behind a content hash. The more times ofa wine record subset is retrieved from the IPFS network, the more copies that record existed in the network as thecopy will reside on some IPFS nodes of the network, not tomention IPFS nodes with the retrieved data will also act ashosts, accelerating the lookup process from the distributedhash table, for other IPFS nodes looking up the same set ofwine record subsets. Object pinning of retrieved data could also be applied toensure the data is always available on a local IPFS node, ifthe retrieved data is needed to be available for more furtheroperations; however, as the retrieved wine record subsetis only required for the specific wine record validationoperation and so the cache of the local node should be freedup periodically if the data is retrieved with the normal " cat "method. IPFS nodes could also be added to or removed froma private IPFS network like the one set for dNAS, under whichonly IPFS nodes owned by any of consortium members andthe consortium administrator are part of the private IPFSnetwork according to the node management mechanism de-scribed in system implementation. Any message regardingthe activities of data addition to or retrieval from the IPFSprivate network is shared only across the network. IPFSnodes on the private network could manage a list of IPFSnodes they have been communicating with, which are alsoowned by other consortium members of dNAS for
IPFS nodemanagement . It is important to know that blockchain transactions couldonly be sent from an account of a blockchain node, ownedby any consortium member, with a valid digital signatureproduced with private key of the account, such as the digitalsignature generated during the data processing operation.Given how important the key management of Ethereumaccounts to the security model of dNAS, it is therefore vitalto keep the private key of any account, involved in dNAS,safe, with a well-defined key management process andselection of key management modules. With the key vaultservice deployed in dNAS, it could prevent any maliciousplayer from compromising wine record components to neg-atively impact the data and process integrity of entire dNASsolution, though data stored on-chain is already hashed toobfuscate.The key vault service of dNAS is developed based onthe open-source
Vault by HashiCorp , which could furtherbe remodelled with
AWS Secrets Manager or Akeyless Vault depending on system requirements, so as to offer function-alities to manage and control access to the secrets of differentEthereum nodes and its accounts respectively, owned by anyconsortium member, and to manage secrets and contractaddresses returned after every smart contract deploymentprocess. Identities are needed to be verified before a spe-cific blockchain service instance could access and interactwith a key vault service instance of dNAS. There are twoauthentication methods available for every distributed keyvault services instance, used by any individual consortiummember, such as token-based and approle-based , as defined in"
VaultAuthMethod ".The former is based on a unique access token generatedby any vault service instance for specific blockchain service,which is also owned by the consortium member. The ac-cess token generated is limited by the authentication leases implying that reauthentication is needed after a given leaseperiod so as to continue accessing the key vault service. Thelatter is about a set of policies and login constraints, such asthe
RoleID and
SecretID generated, regarding the specific keyvault service instance, which must be met to receive a tokenwith those policies set so as to access the key vault service.The distributed blockchain service instance could accessto the distributed key vault service instance by specifyingthe "
VaultAuthMethod " with necessary metadata, such as theURL of a deployed vault service instance, the API versionor both role identifier and secret identifier depending onthe authentication method specified, through environmentvariables when bringing up the instance of distributed keyvault service.Once the key vault service is instantiated with a givenblockchain service instance, both owned by a specific con-sortium member, the secrets of an Ethereum node andaccount owned by the same consortium member are thenready to be created and stored in the same key vaultservice instance with a given "
VAULT_PREFIX_KEY " and memberID . According to the smart contract deployment pro-cess, consortium administrator is the only role permitted todevelop, deploy and upgrade deployed smart contracts, asdepicted in use case analysis of dNAS. The contract addressof both individual smart contracts and the correspondingproxy contract alongside the public address of the contractowner, which is the consortium administrator for this case,could use a similar design pattern to store the metadata as"
SCDeploymentSecret " with the corresponding proxy addressas a key to the secrets stored.
ONCLUSION
With the current challenges on anti-counterfeiting of sup-ply chain industry, the research was performed basingon an implementation-driven research technique with themain question and individual sub-questions listed in theresearch objectives addressed of this research. A proposedsolution, namely the Decentralized NFC-enabled Anti-counterfeiting System (dNAS), is therefore developed tobe an autonomous and decentralized application for sup-ply chain anti-counterfeiting and traceability especially forthe wine industry, providing a way for registered nodesto verify the legitimacy of wine products with its winerecords cryptographically validated. dNAS is appeared tostrengthen the capacity in anti-counterfeiting and traceabil-ity for wine industry and the wider supply chain industry,while minimising the involvement of centralized parties,such as winemakers of the centralized NFC-enabled anti-counterfeiting system (NAS) for which this research isaimed to decentralize.The literature analyses of this research cover currentalternative resolutions of product anti-counterfeiting, andexisting blockchain implementations applied in differentindustry. The idea of decentralized application was alsoexplained and applied to the development of dNAS as acontribution of this research to explain why ÐApp couldexhibit properties, such as zero downtime, immutability andresistance to collusion. The proposed system model designand system architecture of dNAS were implemented basedon a set of system requirement defined according to the findings of security analysis performed against the legacyNAS. How dNAS is actually implemented, is explained withsystem implementation procedures categorized mainly intotwo phases, namely the initialization phase including thoseoperations related to consortium registry management andsmart contract deployments, and the data processing phase including wine record creation and validation operations ofdNAS. The technical details of system development, designpatterns applied to different system components and thesystem execution of dNAS working prototype were alsocovered and elaborated.It appeared that the developed prototype of dNAS wasa solid example demonstrating how a legacy supply chainanti-counterfeiting and traceability system, for wine indus-try in this case, could be decentralized and reengineeredfrom its centralized architecture which was once hostedand maintained merely by intermediaries. dNAS is builtaround the idea of enterprise consortium with registerednodes along the supply chain of wine industry, balanc-ing the degree of decentralization, scalability, security andthe privacy of the proposed solution, with the concept ofenterprise blockchain chosen appropriately as a preferreddevelopment model of the blockchain network as well asavailability of shared smart contracts with capability to beupgraded with versions shared amongst the consortiummembers. dNAS will be evaluated with system testingprocedures, such as automated testing and performancetesting on different system components of dNAS, and thediscussion of result from these system testing activities andqualitative system analysis on the prototype of dNAS, willbe included in a separate research with limitation, concernsand future opportunities of dNAS also identified. R EFERENCES [1] OECD and EUIPO,
Trade in Counterfeit and Pirated Goods – MappingThe Economic Impact . OECD Publishing, 2019.[2] N. C. K. Yiu, “Toward blockchain-enabled supply chain anti-counterfeiting and traceability,” arXiv preprint arXiv:2102.00459 ,2020.[3] N. C. K. Yiu, “An nfc-enabled anti-counterfeiting system for wineindustry,” arXiv preprint arXiv:1601.06372 , pp. 1046–1051, IEEE,2018.[7] G. Zyskind, O. Nathan, et al. , “Decentralizing privacy: Usingblockchain to protect personal data,” in , pp. 180–184, IEEE, 2015.[8] F. Casino, T. K. Dasaklis, and C. Patsakis, “A systematic literaturereview of blockchain-based applications: current status, classifica-tion and open issues,”
Telematics and Informatics , vol. 36, pp. 55–81,2019.[9] J. Al-Jaroodi and N. Mohamed, “Blockchain in industries: A sur-vey,”
IEEE Access , vol. 7, pp. 36500–36515, 2019.[10] S. Khezr, M. Moniruzzaman, A. Yassine, and R. Benlamri,“Blockchain technology in healthcare: A comprehensive reviewand directions for future research,”
Applied sciences , vol. 9, no. 9,p. 1736, 2019. [11] G. Drosatos and E. Kaldoudi, “Blockchain applications in thebiomedical domain: a scoping review,”
Computational and struc-tural biotechnology journal , vol. 17, pp. 229–240, 2019.[12] M. Andoni, V. Robu, D. Flynn, S. Abram, D. Geach, D. Jenkins,P. McCallum, and A. Peacock, “Blockchain technology in the en-ergy sector: A systematic review of challenges and opportunities,”
Renewable and Sustainable Energy Reviews , vol. 100, pp. 143–174,2019.[13] A. Reyna, C. Martín, J. Chen, E. Soler, and M. Díaz, “On blockchainand its integration with iot. challenges and opportunities,”
Futuregeneration computer systems , vol. 88, pp. 173–190, 2018.[14] W. Viriyasitavat, L. Da Xu, Z. Bi, and A. Sapsomboon, “Newblockchain-based architecture for service interoperations in inter-net of things,”
IEEE Transactions on Computational Social Systems ,vol. 6, no. 4, pp. 739–748, 2019.[15] H. Shafagh, L. Burkhalter, A. Hithnawi, and S. Duquennoy,“Towards blockchain-based auditable storage and sharing of iotdata,” in
Proceedings of the 2017 on Cloud Computing Security Work-shop , pp. 45–50, 2017.[16] K. Salah, M. H. U. Rehman, N. Nizamuddin, and A. Al-Fuqaha,“Blockchain for ai: Review and open research challenges,”
IEEEAccess , vol. 7, pp. 10127–10149, 2019.[17] S. A. Abeyratne and R. P. Monfared, “Blockchain ready manufac-turing supply chain using distributed ledger,”
International Journalof Research in Engineering and Technology , vol. 5, no. 9, pp. 1–10,2016.[18] M. P. Caro, M. S. Ali, M. Vecchio, and R. Giaffreda, “Blockchain-based traceability in agri-food supply chain management: A prac-tical implementation,” in , pp. 1–4, IEEE, 2018.[19] K. Toyoda, P. T. Mathiopoulos, I. Sasase, and T. Ohtsuki, “A novelblockchain-based product ownership management system (poms)for anti-counterfeits in the post supply chain,”
IEEE access , vol. 5,pp. 17465–17477, 2017.[20] Z. C. Kennedy, D. E. Stephenson, J. F. Christ, T. R. Pope, B. W. Arey,C. A. Barrett, and M. G. Warner, “Enhanced anti-counterfeitingmeasures for additive manufacturing: coupling lanthanide nano-material chemical signatures with blockchain technology,”
Journalof Materials Chemistry C , vol. 5, no. 37, pp. 9570–9578, 2017.[21] H. M. Kim and M. Laskowski, “Toward an ontology-drivenblockchain design for supply-chain provenance,”
Intelligent Sys-tems in Accounting, Finance and Management , vol. 25, no. 1, pp. 18–27, 2018.[22] J. Benet, “Ipfs-content addressed, versioned, p2p file system,” arXiv preprint arXiv:1407.3561 , 2014.[23] V. Trón, “The book of swarm: storage and communication infras-tructure for self-sovereign digital society back-end stack for thedecentralised web,”
Ethereum.org , 2020.
Mr. Neo C.K. Yiu IEEE is a computer scientistand software architect specialized in developingdecentralized and distributed software solutionsfor industries. Neo is currently the Lead Soft-ware Architect of Blockchain and CryptographyDevelopment at De Beers Group on their end-to-end traceability projects across different valuechains with the Tracr™ initiative. Formerly actingas the Director of Technology Development atOxford Blockchain Society, Neo is currently aboard member of the global blockchain advisoryboard at EC-Council. Neo received his MSc in Computer Science fromUniversity of Oxford and BEng in Logistics Engineering and GlobalSupply Chain Management from The University of Hong Kong. A PPENDIX AB ACKGROUND
A.1 The Overview of the Legacy NAS (NFC-enabledAnti-Counterfeiting System)
NAS with centralised data architectures which are predomi-nantly based on the typical and familiar cloud-based client-server architecture style is demonstrated in
Fig. 19 .The whole NAS solution is consisted of FIVE maincomponents, which are (1) the back-end system with theweb-based database management user interface for winedata management performed by winemakers, for whichmanagement of data columns of specific wine productswhich are in their custody can be performed by wine-makers, (2) an NFC-enabled mobile application,
ScanWINE ,for tag-reading purpose of wine products at retailer pointsfor wine consumers or supply chain participants of thesupply chain before accepting a wine product, (3) anotherNFC-enabled mobile application,
TagWINE , performing tag-writing purpose for wine products at wine-bottling stage bywinemakers, (4) the NFC tags packaged on the bottleneckfor those purposes and actions, and (5) any NFC-enabledsmartphones or tablets of supply chain participants andwine consumers along the supply chain.There are FOUR major categories of data to be processedalong the supply chain with NAS, namely the (1) nodaltransaction history data, (2) supply chain data, (3) winepedigree data which is processed with its dedicated con-trollers based on their predefined schema and data models,and (4) unsuccessful validation data returned from anyunsuccessful validation at the stage of accepting wine prod-ucts. As the wine products being processed and handledby different nodes along the supply chain with the dataupdated by scanning the NFC tags of the wine productusing the tag-reading
ScanWINE with the state of winerecord to be updated accordingly to the database. Thesecategories of data are updated along the supply chain untilthe point of purchase at which wine consumers use the tag-reading
ScanWINE to scan the NFC tags and retrieve thedata such as wine pedigree data and transaction data forreal-time validations to determine if the wine product iscounterfeit or not.A unique identifier is assigned to each wine productand is written into the NFC tag. Such tag-attached wineproducts are then shipped from winemakers to differentnodes along the supply chain. During the transportationprocess of the wine products along the supply chain, eachinvolved node could interact with the NFC tags and add theaforementioned four categories of data into the NFC tagsrespectively. In this way, the next node can check whetheror not the wine products have already passed through thelegitimate supply chain. If any inconsistency is found at anynode, such wine products may be considered as counterfeitsand should be returned to winemakers. However, once thewine product reached post-purchase stage and circulatedin any customer-to-customer markets, its authenticity is nolonger guaranteed, as anyone who has an NFC reader couldinterfere and clone tags’ data. Therefore, it is importantto develop anti-counterfeiting and traceability systems thatcould work even when the data of the tag is cloned inthe post-purchase supply chain with the security attacks detected and prevented on any potential adversary statetransition took place. A PPENDIX BS YSTEM M ODEL D EFINITION
B.1 Use Case Analysis Diagram of dNAS
The Use Case Analysis Diagram of dNAS is depicted in
Fig. 20 . B.2 System Architecture Diagram of dNAS
The Full System Architecture Diagram of dNAS is depictedin
Fig. 21 . Fig. 19:
The System Architecture of Legacy NAS (Source: Neo Y.) Fig. 20:
Use Case Analysis Diagram of dNAS