In this section, the motivation of this research, and a list of research questions with the research methodology, are pinpointed and explained by going through the growing challenges of improving counterfeit product trading. The current solutions, which have already been implemented in the supply chain industry against the challenges, along with the ineffectiveness and inefficiency of current solutions against counterfeit product trading, are discussed to better address the need for more innovative and decentralized solutions, such as dNAS, which is proposed in this research alongside a set of research objectives.
1.1. The Existing Challenges in Supply Chain Anti-Counterfeiting
The problem of counterfeit product trading, such as luxurious goods or pharmaceutical products, has been one of the major challenges the supply chain industry has been facing in an innovation-driven global economy. The situation has been exacerbated by an exponential growth in counterfeit and pirated goods worldwide, which has also plagued companies which have multinational supply chain networks for decades and longer.
The analytical study—[1
], published by the Organization for Economic Cooperation and Development (OECD) and European Union Intellectual Property Office (EUIPO) in 2016 has further suggested that the volume of counterfeit product trading has been alarming, reaching as much as $
509 billion, representing 3.3% of world trade and 6.8% of imports from non-EU countries. Counterfeit trading activities not only infringe on trademarks and copyrights, and negatively impact on the sales and profits of industries, they also generate profits for organized crime at the expense of the affected companies and governments, as well as having broader adverse effects on the economy, public health, safety and security of the wider community.
In response to the growing concern, innovative, fully-functional, integrable and affordable product anti-counterfeiting solutions, utilizing cutting-edge technologies, have been widely and urgently demanded so as to ensure the provenance and traceability of genuine products throughout supply chain counterfeiting, and suggested solutions should be widely adopted regardless of the industry, the size of the company and its supply chain systems.
1.2. Current Alternative Resolutions of Product Anti-Counterfeiting
Given the growing concern and worsening situation in the trading activities of counterfeit products, anti-counterfeiting solutions have been developed and implemented in the supply chain systems of different industries, as listed and explained in [2
]. Wireless communication technologies, such as Radio-Frequency Identification (RFID) or near-field communication (NFC), which is a subset of RFID, powering the Internet-of-Things (IoT) are mostly the existing solutions with centralized architectures currently based on. The tags with wireless communication capabilities are packaged on the packets of goods or the product itself for purposes of identification, anti-counterfeiting and traceability.
One of the solutions to the growing concerns regarding product counterfeiting in supply chain systems, and specifically for the wine industry, was the NFC-enabled Anti-Counterfeiting System (NAS)
, as depicted in Appendix A.1
], developed and implemented back in 2014, which aimed at providing an innovative and fully functional alternative for supply chain anti-counterfeiting and traceability, based on near-field communication technology and cloud-based microservice architecture with centralized storage structure, hosted by any winemaker, to help improve the worsening situation of product counterfeiting, especially for the wine industry.
It has come to a point where, even though the implementation of NAS itself is already more secured than most of the typical supply chain systems, with original wine records being validated at any node along the supply chain, centralized architectures of NAS could still pose a risk in terms of data integrity, as any node, not only winemakers, along the supply chain have full control of wine records stored in their own database architectures. In case different nodes along the supply chain are untrusting of each other, there is still a possibility that duplicated wine records lead to an adverse situation where wine consumers can still purchase bottled wine counterfeits with fabricated wine records retrieved from NAS.
As explained by the research findings of security analyses performed in [2
], amongst NAS and other existing anti-counterfeiting alternatives with a centralized architecture, utilizing wireless tag communication technologies, there are three common counterfeit attacks in the existing centralized anti-counterfeiting and traceability solutions: (1) modification of product records stored in tags, such as fabricating product identifiers or metadata for any wine product, (2) cloning of tag metadata such as those genuine wine records to any counterfeit product tag, and (3) removal of legitimate tags from genuine wine products with reapplications to other counterfeit wine products.
The typical architecture of centralized supply chains creates several concerns, as discussed in [2
]. First, there is a tremendous processing burden on servers, since significant numbers of products are flooded through multiple supply chain nodes. Second, substantial storage is required to store authentication records for every single processed wine product. Third, with existing solutions based on a centralized architecture, traditional supply chains have the inherent problem of single-point failure, and so potential service downtime and data loss could be expected. The legacy of NAS relies on centralized authorities, such as winemakers, to combat counterfeit products which could, in all likelihood, result in single-point processing, storage, and failure
To overcome the concerns of software solutions which are developed with centralized architecture, Blockchain Technology (or other Distributed Ledger Technologies built with decentralized peer-to-peer networks) stands out as a potential framework to establish a modernized, decentralized, trustworthy, accountable, transparent, and secured supply chain innovation against counterfeiting attacks, compared to those built with a centralized architecture, with a comparison between the two detailed in Figure 1
. In this research, the aim is to develop and implement a novel prototype with a decentralized architecture, based on the legacy NAS, to reinforce the innovative idea of product anti-counterfeiting in a decentralized fashion, namely, the Decentralized NFC-based Anti-Counterfeiting System (dNAS)
1.3. Research Objectives
The open research questions, and the difficulties inherent in addressing them, should be detailed before actually diving into the system design of the proposed dNAS. It will then be followed by an outline of a preliminary design of the system model and an effective blockchain-based system architecture running on a cloud-production environment. Given the variety of advantages, such as the prevention of single-point failure, as well as the better resilience and availability of its being applied to the supply chain participants, that are brought by the blockchain technology and the concept of decentralized application, which lead to a more secured and sophisticated supply chain system against counterfeiting attacks, the main research question should be:
“How is it feasible to decentralize an anti-counterfeiting application, already developed and implemented in the supply chain industry, to better combat the rampant counterfeiting attacks?”
In order to progress the research with a prototype of decentralizing the aforementioned legacy NAS, the main question is then addressed by answering the following sub-questions throughout the research:
How are the chosen blockchain and its consensus protocol being implemented in the proposed dNAS?
How are the current operations of wine record management and product provenance verification reengineered to be a more decentralized, secured, autonomous and economical alternative?
How are wine record data being stored in the proposed decentralized and distributed storage architecture?
Given the main research question and the identified set of derived sub-questions, we aim to find an organized way of exploring them step-wise in this research. The best approach is to follow research techniques in computing, namely proof-by-demonstration and implementation-driven research techniques, under which a working prototype of dNAS will be introduced and validated with the idea of the decentralized supply chain solution, addressing the main research question and the derived sub-questions. It is important that, during development, the next best steps are always taken into account and ultimately offer a better analysis of the research questions with detailed documentation of the development of such an innovative and decentralized solution, using blockchain technology and other useful technical concepts, to improve the current situation of product counterfeits in the supply chain industry.
3. System Model Definition
dNAS is a decentralized and integrated system, tailor-made for the supply chain industry, and specifically the wine industry. While capabilities such as end-to-end traceability, provenance and authenticity were enabled in the legacy NAS, its anti-counterfeiting and traceability model was actually based on winemaker roles, with their products moving downstream to their registered supply chain participants and wine consumers until the purchase points. The anti-counterfeiting model of dNAS is actually based on a decentralized enterprise consortium consisting of multiple winemakers and supply chain participants, responsible for operating the web application and the NFC-enabled mobile applications of the legacy NAS with a dedicated blockchain network, via an integrated interface, with blockchain nodes assigned to every consortium member. This section will discuss the use-case analysis and proposed system architecture of dNAS.
3.1. System Requirements of dNAS
According to the potential opportunities and concerns of developing decentralized solutions for supply chain anti-counterfeiting and traceability, explained in the research discussion result of [2
], a fundamental set of system requirements for developing dNAS is defined.
There are, in total, 19 fundamental system requirements, as listed in [2
], to develop dNAS, with rationales ranging from data integrity, scalability, data privacy, improved authentication and authorization, ease of integration and consensus performance to state transparency, summarizing what the supply chain industry, and even the specific wine industry, expected from the innovative dNAS, with potential opportunities and concerns in the decentralization of the supply chain anti-counterfeiting and traceability, which are also addressed through the development and implementation of dNAS.
3.2. System Roles’ Definition
Before explaining the system architecture of dNAS based on the gathered system requirements, the constituent system roles and their corresponding use cases are clarified. In dNAS, the decentralized architecture and anti-counterfeiting mechanism are built around a concept of enterprise consortium consisting of winemakers and the supply chain participant nodes along the supply chain. Similar to those defined in the legacy NAS, there are four main system roles in the proposed system model of dNAS, depicted as follows.
The Winemaker Role: The winemaker is the manufacturer of wine products. The provided functions of winemakers include (1) creating new wine records with a set of wine pedigree data, supply chain data and transaction data, (2) proposing that their supply chain participants are added to or removed from the consortium, as well as their designated blockchain nodes to the blockchain network, (3) setting the quantity of wine products available to be sold, and (4) retrieving information regarding its supply chain participants so that the latest status of sales can be retrieved. The winemaker role can also inquire about any wine product their participants have been marketing to wine consumers, and verify whether specific wine products have been recalled or exchanged, or confirm if the current status of these wine products has been verified with public addresses provided by related wine consumers.
The Supply Chain Participant Role: The supply chain participants could have the role of wholesaler, retailer or reseller, and literally any supply chain node after winemakers and prior to wine consumers, along the supply chain. Participants can use functions of dNAS to encrypt wine record components using private keys, and wine consumers can, therefore, utilize the concept of asymmetric cryptography, which is applied to the system functions of its blockchain service, hosted by the consortium administrator. The participants’ public addresses are utilized to verify if the participant is who they claim to be. After performing each transfer operation, the participant will update the data fields of the transaction data and supply chain data, and the updated content hash is, therefore, pushed on-chain, and available for the registered nodes of winemaker role and supply chain participant role, to obtain the required data.
The Wine Consumer Role: The wine consumers are the end purchasers of wine products. The wine consumer can verify whether a specific supply chain participant is in a business relationship with another winemaker, and also verify whether the supply chain participant has an inventory of specific wine products. Wine consumers can prove that their identities are consistent with their public addresses, and obtain the individual transaction records and wine statuses of wine records via linking the corresponding blockchain nodes to a specific block explorer to review targeted blocks and transactions. As long as a wine product is transferred by a registered node of the wine-consumer role, the authenticity and end-to-end traceability will be assured and legitimate, even beyond any retailer point post-supply-chain.
The Consortium Administrator Role: A consortium consists of winemakers and supply-chain participants. The consortium administrator is elected through a democratic process involving every consortium member, who is assigned their own blockchain service instance with a designated blockchain node running on the blockchain network, which is managed by the consortium. The proposed dNAS would assume that there is only one administrator node elected for the enterprise consortium in this research, for ease of operation and presentation. The possible approach of having on-chain governance aspects to decentralize the enterprise consortium, or enhance the degree of dNAS decentralization as a whole, should be covered in future work on implementing dNAS.
3.3. Use Case Analysis of dNAS
Given the defined system roles of dNAS, a use case analysis based on these system roles was performed, as demonstrated in Appendix B.1
. dNAS is developed basing on a concept of enterprise consortium
, as depicted in Figure 2
, consisting of multiple registered nodes of the winemaker role, supply chain participant role and the consortium administrator, introduced to dNAS, unlike the legacy NAS on which the anti-counterfeiting system and mechanism are based solely on winemakers
Getting started with the blockchain system, as depicted in Figure 3
, there are use cases only accessible to the consortium administrator, such as the management of smart contracts, which are decentralized software design patterns and methods with access shared across different blockchain nodes running on the network, based on the authorization mechanism defined. The smart contract will need to be developed, deployed or even upgraded to the blockchain network if necessary. The consensus level is indeed the number of votes from consortium members, required for a consensus to be reached to confirm that a registered node will be added to or removed from the consortium. The consensus level can only be set by the consortium administrator if necessary, especially for a situation where the size of the consortium has changed, drastically affecting the degree of decentralization and fraction needed to reach a consensus. Other consortium members are able to propose the addition of a new node to, or removal an existing node from, the consortium, based on the public address of their designated blockchain node, which is stored in an on-chain registry. Every consortium member would be assigned with a blockchain node, and are therefore eligible to send and validate transactions of the blockchain network to help reach a consensus and state broadcasting.
Regarding the use cases of the database-operating web application, as listed in Figure 4
, any registered node of the winemaker role and supply chain participant role can obtain access to the functionalities provided by the web application to manage the inventory of wine products they hold, the list of collaborative supply-chain participants, and projects involving different wine products with different supply chain participants. A wine record, which could be created only
by registered nodes of the winemaker role, consists of four constituent data categories, such as wine pedigree data, transaction data, supply chain data and unsuccessful validation data.
Likewise, only registered nodes of the winemaker role could perform operations such as create, update and delete in the web application, while registered supply-chain participant nodes and registered wine-consumer nodes could only update the respective transaction data and supply chain data via ScanWINE mobile application at the point of wine acceptance or purchase, following a series of data validation steps, when scanning the NFC tags on wine products.
Like the legacy NAS, only registered nodes of the winemaker role could access the NFC-enabled tag-writing mobile application-TagWINE
, with use cases as listed in Figure 5
, and perform its functionalities, such as viewing wine records on the mobile application, recording required data fields of the wine record in NFC tags, and checking the history of the previous writing activities for those tags on the wine products they produced.
While, for the NFC-based tag-reading mobile application-ScanWINE
, with use cases as listed in Figure 6
, any registered nodes, including those of the wine-consumer role, is accessible to the functionalities, such as scanning NFC tags, which will also trigger the process of validating the provenance and authenticity of wine products by analysing the data stored in NFC tags, a unique identifier of scanned NFC tags and the identity of registered nodes.
In case such a validation process fails, the unsuccessful validation data of that wine record will be updated, and related winemakers and supply chain participants would be notified of the new status, shown on their database management web application. After going through a successful validation process, the wine record will be shown on the mobile application, with further options for wine consumers to buy, or supply chain participants to accept, the wine product, with physical wine products at their end. The transaction data and the supply chain data are, therefore, updated following the activities of purchasing or accepting wine products are confirmed.
The account management of registered nodes, with use cases listed in Figure 7
, is actually based on the design patterns developed in AccountController
of the app-backend service in legacy NAS, for which every node could go through registration steps and become registered nodes of either the winemaker role, supply-chain-participant role or wine-consumer role. The on-board process and registration steps of these aforementioned roles will be different depending on how each type of registered node could obtain access to different system components, including the database-operating web application, TagWINE
and the blockchain network, based on their roles and whether they are members of the enterprise consortium
. The AccountController
offers functionalities including validating the role of specific registered nodes, and voting to add or remove registered nodes of the enterprise consortium
4. The Decentralized NFC-Enabled Anti-Counterfeiting System-dNAS
Following the identified system model definition, a system architecture of dNAS is then designed accordingly, in order to answer the main research question of this research. With the proposed system architecture of dNAS as demonstrated in Appendix B.2
, how exactly the legacy NAS could be re-engineered and run on the chosen blockchain network of enterprise blockchain implementations, such as Ethereum Proof-of-Authority, is explained, as well as the system components that will be decentralized to enable core functionalities of the novel dNAS. The proposed system architecture of dNAS can largely be explained in three parts, namely (1) the decentralized blockchain network, (2) the blockchain interface, and (3) the system components built in the legacy NAS.
4.1. The Decentralized and Distributed Blockchain Network
The decentralized blockchain network, as demonstrated in Figure 8
, is developed based on Enterprise blockchain implementations such as the Quorum blockchain with a consensus algorithm of Istanbul Byzantine Fault Tolerant
(IBFT), and Ethereum blockchain network with a consensus algorithm of Proof-of-Authority
(PoA), in line with the concept of enterprise consortium, introduced in the system design and consisting of client nodes which could be either validator nodes (full node) involved in validating transactions and signing a new block in the blockchain, or the listener node (light node), which can only listen to blockchain states and perform non state-transitioned interactions with the smart contracts deployed to the network. Whether a validator node or listener node is assigned depends on the role of authorities in the enterprise consortium. For instance, the winemaker role would be assigned with a validator node of the blockchain network, while some of the supply-chain-participant nodes would be restricted to a listener node, depending on their involvement in the enterprise consortium.
The dNAS blockchain network could be built basing on enterprise blockchain implementations in the Quorum blockchain, Ethereum blockchain, Hyperledger Fabric or Tendermint. If the Proof-of-Authority blockchain network of dNAS is developed, it could be built basing on different Ethereum client implementations, such as Go-Ethereum, which could specifically be termed the Clique Proof-of-Authority network or Aura Proof-of-Authority network. If the blockchain network is developed with the Quorum blockchain, the Istanbul Byzantine Fault Tolerant network could be developed with Quorum client implementations, such as Go-Quorum. No matter which enterprise blockchain implementations the blockchain network of dNAS will be based on, it will consist of a set of client nodes managed by different authorities of the enterprise consortium, thus enabling the peer-permissioning functionalities, and so the network is functioned as a permissioned network, unlike public networks such as the Ethereum main net, which is an open network and does not emulate the concept of peer-permissioning, due to the fact that the proposed dNAS is developed for the supply chain industry, and specifically for the wine industry. When starting the client node, individual nodes are connected to each other, via specification of the node identifier of any client nodes already running on the network, so as to form a network.
Smart contracts are developed in solidity and deployed to the dNAS blockchain network by the consortium administrator, who is also hosting validator nodes on the network on behalf of consortium members. Whenever a transaction request approaches the blockchain network, the transaction-sending node will invoke methods defined in the smart contract accordingly, based on an application binary interface (ABI) specified in the data fields of a transaction to perform state-transitioned changes in smart contract storage as well as the states of the network, with transactions validated and a new block mined. The smart contracts can further be upgraded through the implementation of a smart contract upgradability pattern. The management of smart contracts with standard processes such as deployment or upgrade is handled by the contract deployment suite, which only blockchain nodes of the consortium administrator will have access to, and perform such operations on these smart contracts.
There are also network monitoring components, such as the blockchain explorer and node management suite, that can be deployed and connected to the blockchain nodes running on the network. The former is a user interface connecting blockchain nodes on the network for authorities to perform querying and viewing on validated transactions and mined blocks, including those at pending stage. The latter is a dashboard listing the different performance metrics of every blockchain node running on the network. The data collected from these network monitoring tools could further be augmented and integrated with any open-source data visualization tools, such as Kibana, with the enhanced monitoring capability of dNAS as a whole.
With the advent of the decentralized blockchain network integrated with system components of the legacy NAS via a tailor-made blockchain interface with other tools, the suggested architecture pattern can then provide a high-throughput and content-addressed block storage model to the architecture, which greatly improves the performance of the proposed dNAS. Similarly, regarding the advantages contributed by adopting Blockchain technology, it has been able to prevent single-point failure, and nodes along the supply chain do not essentially need to trust, but collaborate with, each other in the enterprise consortium.
4.2. The Blockchain Interface
Given that the decentralized blockchain network is regarded as a vital part of the proposed dNAS, a dedicated blockchain interface, as demonstrated in Figure 9
, which is essentially another microservice, will need to be designed and developed to help integrate the decentralized bits into system components of the legacy NAS. The blockchain service, acting as an interface between system components of the legacy NAS and the blockchain network, is developed basing on functionalities, offered by open-source Ethereum interface libraries such as Ethers.js
, aiming to interact with the designated blockchain node and, in turn, the blockchain network. API endpoints are also developed based on logic patterns in different controllers of the blockchain service.
The AppController of the app-backend service in the legacy NAS could invoke endpoints to perform different functionalities, such as pushing data on-chain, getting or validating data from the deployed smart contracts, executing peer-related operations, including votes to add or remove participating nodes, and validating the roles of registered nodes in the enterprise consortium. The blockchain network is also utilized as a controller of the enterprise consortium managing access control and the identities of registered nodes by implementing a concept of on-chain peer registry, and serving as a tamper-proof log of transaction events emitted back to the blockchain service.
With different helper functions developed in the blockchain service and functionalities enabled with open-source Ethereum interface libraries, the blockchain service instance can, therefore, direct its designated blockchain node to send transactions so as to perform different operations related to wine records and the peer registry. Sending transactions will require a signature produced with a private key of the node account. Therefore, a dedicated key-management module, such as the key vault service, will need to be in place to store key pairs related to any signing activities involved in any transaction processed by a specific node account, which is also linked with the blockchain service instance, and to providing a secured mechanism for any key pair to be retrieved whenever there is a transaction or a signing process.
Instead of storing the complete version of the wine record with all of its constituent metadata, such as transaction data, wine pedigree data and supply chain data, only the content hash of the wine record along with other payloads for data security and privacy should be stored in the data structure defined in the deployed smart contracts. A distributed data storage system, such as IPFS, is, therefore, introduced and migrated to the proposed dNAS, so that the dedicated and distributed IPFS node could be connected to an instance of the blockchain service whenever there is a request sent to the blockchain service to process. Storing wine records in such a distributed storage system provides a unique content hash which would then return to the blockchain service for further operations before being included in any transaction, and then be signed by dedicated node accounts and sent to the transaction pool of the blockchain network queuing to be processed for validation.
The content hash of a specific wine record is then retrieved from the smart contract whenever there is a validation process to be executed, and further used to retrieve wine record subsets from the distributed storage system off-chain, via the designated IPFS node. IPFS speaks of a permanent web, implying that any data published to the network should be available forever. The node management suite is also connected to IPFS nodes so as to have the same monitoring feature applied to every distributed IPFS node that is assigned to registered nodes of the enterprise consortium.
4.3. The Legacy NAS Components
According to system components of the legacy NAS, as demonstrated in Figure 10
, the applications provided to different registered nodes along the supply chain are the database-operating web application, TagWINE
—the NFC-enable tag-writing mobile application and ScanWINE
—the NFC-enabled tag-reading mobile application. The mobile applications are designed to interact with the NTAG 203
of NFC tag model.
The functionalities, enabled by those system components of the legacy NAS, substantiating the use cases described in the use case analysis, are actually based on logic patterns in AppController of the app-backend service. For instance, Create, Read, Update and Delete (CRUD) operations on wine records, performed on the database-operating web application, actually send a request to AppController, invoking respective methods related to such operations, and collaborate with different system components, such as the database system developed in Microsoft SQL, to reflect states transitioned back to the web application. Another example could be using ScanWINE to scan NFC tags, and validate the provenance and authenticity of wine products, by validating and comparing respective states of specific wine records stored in the NFC tags, the off-chain database system connected with AppController, distributed IPFS storage, and the on-chain data storage of smart contract deployed to the dNAS blockchain network via the integration between the app-backend service and the blockchain service.
Regarding the components of the app-backend service, a database system is integrated with AppController to store states and versions of wine records, and AccountController processes the account management of registered nodes with states and user sessions stored in the database. The phonegap-nfc module is integrated with AppController to enable ScanWINE and TagWINE mobile applications with the functionalities of any NFC-related interaction, with the specific NFC tags packaged on wine products. Further logic patterns are developed and included in AppController for integration with the decentralized bits of the dNAS via the blockchain interface by invoking related API endpoints of the proposed blockchain service to perform functionalities, such as pushing data to the blockchain and validating on-chain data of specific wine records with transaction events returned to the app-backend service.
NTAG 203 Ferrite was the selected type of NFC tag for development of the legacy NAS, given its universal compatibility with most of the NFC-enabled devices and its resistance against metallic interference, for which the NTAG 203 Ferrite Tag can change the magnetic flux path to avoid interference to the NFC tag, with a high surface resistance and effectiveness in preventing resonance and suppressing coupling from the metallic interference, as NFC tags are likely to be attached to foil packaging materials surrounding wine bottlenecks. However, the NTAG 203 chip is already out of production and has been replaced by those of the NTAG21x series, such as NTAG 213 or NTAG 216, given their increased memory storage and security functions, including a password lock and scan counter. NTAG 216 Ferrite is, therefore, the selected type of NFC tag for the development of dNAS, owing to its extensive configuration with 7-byte UIDs and 888-byte memory capacity, for more flexibility in terms of the data stored in each NFC tag representing every unique wine product.
6. Developing the dNAS Prototype
Given the elaborated system architecture of dNAS, and the system implementation with the operational steps explained, the working prototype of dNAS is developed. The development process of dNAS followed the standard Agile software development methodology, involving software project management tools, software development environments, and configurations utilizing modern concepts, such as containerized applications, service-oriented architecture, source version control, and cloud environment deployment. The tools and concepts applied to the development process of the individual components in dNAS, such as the blockchain network and smart contracts, are also explained.
According to the system architecture of dNAS, decentralized system components of dNAS actually consist of a blockchain network, smart contracts, an IPFS network and a blockchain service. This section includes the implementation details and the design concepts of the individual decentralized system components of dNAS.
6.1. The dNAS Blockchain Network
The Ethereum developer community has developed many different client implementations, such as Go-Ethereum PoA Clique, Parity PoA Aura and Pantheon PoA, with options on consensus protocols provided, as well as other enterprise blockchain implementations, such as Quorum, Hyperledger Fabric and Tendermint, which are available for the development of a permissioned network. There are indeed benefits to having multiple Ethereum clients, such as (1) improved resilience to the network enabled by faster issue detection and correction—with more people interpreting the protocol specification, there is a greater chance of these errors being uncovered and detected—and (2) enhanced security—if there is an attack factor or bug in any of the Ethereum implementations, this means the network is usually working fine, as there is a wider diversity of clients available. Go-Ethereum nodes currently form the majority of the Ethereum network, including different implementations with different consensus algorithms, and a dNAS blockchain network is developed basing on the Go-Ethereum PoA implementation.
The network implementation started by creating Ethereum accounts for each of the blockchain nodes with a key pair, and its key-store file was generated during the process. The secret key could be decrypted if required, such as for signing transactions, with the specified password. Ethereum accounts are created and assigned to validator nodes, acting as consortium members, to be included in dNAS blockchain network.
The genesis file essentially defines the genesis block, also known as the first block of any blockchain network. There is some significant information set in the genesis file for starting the network; for instance, the “chainId” specifies the chain those validator nodes are connected to, the “period” specifies a block time for which a block is mined, regardless of the existence of transactions in the specified time interval, and the public addresses of Ethereum accounts generated are also under “extraData” to specify that these accounts are going to run as validator nodes when the network starts, with their public addresses also listed under “alloc” so they are allocated funds in gwei once the network is started. The genesis file is then initiated by every validator node that will be run on the same dNAS blockchain network.
A “geth” data folder, consisting of “chaindata”, “lightchaindata”, “node states” and “transaction RLP (Recursive Length Prefix)”, will then be created under each of the validator nodes after being initialized with the specified genesis file. The folder will serve as a local copy of global states, block states of specific chain and individual transaction states, transited in line with the progress of the dNAS blockchain network. The gas limit of the genesis block is also set in the genesis file for the network to begin. However, the gas limit of the block-to-mined is determined by the gas used in its parent block, which is dynamic and not static in nature, according to one set for the genesis block, specified as “gasLimit” in the genesis file. The mechanism set out in the Go-Ethereum implementation aims to increase the gasLimit if “parentGasUsed > parentGasLimit * (2/3)”; otherwise, it is lowered and the amount increased/decreased is determined by how far away it can be from “parentGasLimit * (2/3) parentGasUsed”.
The individual validator nodes are also ready to form a network with the specified Ethereum node identifiers. During the start-up process of a blockchain node, the gas price is set to zero, as it is not considered in any blockchain processes performed in dNAS. The APIs of remote procedure calls
(RPC) are also available via RPC calls by specifying the internet protocol address of the running node or an internal process call
(IPC) file under the “geth
” data folder created for each of the running nodes, to consortium members and the consortium administrator, for any customized node operation. The node operations could propose the addition of new nodes to dNAS blockchain network via the following sample method, invoked by any blockchain node running on the network, as follows:
With the number of such proposals amounting to more than N / 2 + 1, where N is the number of running nodes, the proposed public address, representing a proposed node, is then added and run as part of the dNAS blockchain network. The blockchain node could further be attached to any open-source blockchain explorer, such as BlockScout, with the “ETHEREUM_JSONPRC_HTTP_URL” specified based on the provider URL of the blockchain node.
6.2. The Decentralized Functional Smart Contracts
Smart contracts, hosting functional methods, have the core functional code to become fully decentralized and delegated to all the trusted authorities of the consortium and its blockchain network. Every blockchain node on the dNAS blockchain network must agree on the current state of the smart contract storage. This should be done in accordance with the smart contract mechanism and workflows, such as the source code compiled with the Solidity compiler and run by the Ethereum Virtual Machine of every blockchain node of the network, as described in Figure 14
The smart contract source code, deployed to the blockchain network, is implemented in Solidity, with the Truffle framework as its development environment and automated testing library. There are typically three smart contracts developed in dNAS, so as to cover every operation defined in the initialization phase and data process phase, namely (1) the “WineDataContract” for wine data operations, (2) the “PeerRegistryContract” for the consortium registry management, and (3) the “Proxy” which enables a proxy pattern for the purpose of smart contract upgradability.
In order to perform those operations defined under the data processing phase, the design patterns of mapping storage are defined in smart contracts, with individual data types also specified, such as the “WineDataHash”, which is the content hash (Content ID) obtained from any IPFS process representing a specific wine record subset mapped to a unique wine identifier, which could also be further mapped per different write counts as “iteration”. Similar design patterns of mapping storage could be found to apply to the public key of the previous processing node, which is also a registered node of dNAS along the supply chain, and to identifiers of different tags and devices. The “currentImplementation” and “initializeCounter” are in place according to the proxy pattern, which is used to check if a contract address has already been initialized previously.
Events are also defined in the “WineDataContract”, and will be emitted when the on-chain process of the wine record creation or appending is completed. The events emitted in either of the operations are then captured by the event listener defined in the blockchain service. The creation process will include both the public address and hashed device identifier creating the wine record in its event, while the appending process will include both previous and current public addresses of the wine record.
Proceeding with the definition of individual methods, according to the wine record creation process, a specified wine identifier is checked and to validate if any records for the identifier have already been logged on-chain with the “require
” statement. The individual variables mapped to the wine identifier are then updated with parameters, including a content hash obtained from IPFS node (WineDataHash
), the public address, tag identifier and device identifier, of the request payload. The on-chain wine record creation process in Algorithm 1, is completed by incrementing the write count so that it matches the counterpart stored in the NFC tag, with the creation process also being emitted.
|Algorithm 1: Creating On-chain Wine Record Entry|
In case a wine record is stored on-chain for a specific wine identifier with the corresponding physical wine product moved downstream to specific supply chain participants, the wine record must be validated with the wine record validation processes previously detailed. The on-chain validation of a specific wine record could be categorized into two parts, applied to both the wine record hash and the signature, which are also stored in the NFC tag. For the former, Algorithm 2 is a straightforward comparison between the content hash of a specific wine record subset stored in the IPFS network, and its counterpart, stored on-chain. It proves that the content of the wine record was not altered along the supply chain to the point where validation takes place.
The latter is used to validate the signature, with the sample on-chain method demonstrated in Algorithm 3, which was produced by the previous processing node with its private key on data such as the wine identifier, tag identifier and the device identifier, stored in physical NFC tags. The idea of validation on the signature is to recover the public key of the signature on-chain and to validate if the recovered public address is consistent with its counterpart stored under the specific wine identifier on-chain.
|Algorithm 2: Validating the Wine Record (IPFS hash)|
|Algorithm 3: On-chain Signature Validation|
Due to the fact that both the tag identifier and device identifier are retrieved from the on-chain mapping storage, with the wine identifier as a key, during the on-chain validation process, both tag identifier and device identifier are also validated to ensure they are consistent with the version of the wine record stored in the off-chain database, the IPFS network and in the physical NFC tag as the constituents to produce the signature. Both methods of validation can confirm if a specific wine identifier has already been stored on-chain to make sure the specific wine record of the wine identifier has been created. Adding the prefix makes the calculated signature, with the keccak256 hash function, recognisable as an Ethereum-specific signature.
Once the validation steps are completed successfully, the registered nodes are provided with options to accept a wine product, and when the wine product is accepted, its wine record will be updated with new transaction data and the supply chain data appended. The method, named “appendWineRecord”, is also defined in the smart contract for the on-chain appending process by updating the mapping variables accordingly.
6.3. Design Patterns of Smart Contract Upgradability
Deployed smart contracts are the shared functional code in the dNAS blockchain network and available for its designated blockchain nodes to perform the different operations requested. Just like any other software code, smart contracts are expected to be upgraded to offer new functionalities, fix software bugs, etc. The most straightforward way to update the smart contract is to deploy another smart contract and update each of the individual blockchain service instances of dNAS with the new address of the upgraded smart contract. However, this would require a new contract address to be specified for every restarting blockchain service instance, and there are multiple blockchain service instances, each owned by individual consortium members. The contract storage will also be lost and needs to perform a state migration with which every state-transitioned operation is performed again in order to sustain on-chain states aligned with the previous version of the smart contract.
Given the above drawbacks of any traditional mechanism of upgrading the deployed smart contract, the proxy upgradability pattern offers a common ground regardless of the rounds of upgrades with the same proxy contract; nevertheless, it will definitely increase trust in the consortium administrator’s ability to perform a smart contract upgrade for the consortium. The proxy contract uses the “delegatecall
” function of EVM assembly code, as demonstrated in Figure 15
, pointing to the contract address of WineDataContract v1
, as described in Figure 16
, alongside the “msg.sender
”, which is also embedded, and initiated by the consortium administrator instead of the proxy contract itself.
The upgrade process is initiated and performed by the consortium administrator, according to the “upgradeTo
” method defined in the proxy contract. The only thing that the proxy contract needed to operate is to point to a contract address of the upgraded smart contract, which is the WineDataContract v2
, as described in Figure 17
6.4. The Blockchain Interface
The blockchain service is built as an interface between the app-backend service and the blockchain network, with other service logic related to the key vault service and IPFS nodes embedded into it, when performing different system implementation operations. Given the functionalities of the open-source Ethereum interface libraries, such as Ethers.js or Web3.js, the blockchain service instance is able to invoke methods of the deployed smart contracts, and to interact with its local blockchain node with an instantiated object of “ethers” or “web3”, and the contract address specified via injecting environment variables when bringing up the service. Other environment variables represent information, such as the address of its IPFS local node, as well as both the role_id and secret_id of the key vault service for key management purposes.
The individual routers further link to their respective controllers. The controllers would utilize respective helper functions if some processes are repeated in the same controller functions, such as the process of obtaining a dedicated IPFS instance and an instance of key vault service. Some helper functions would also invoke the methods of the deployed smart contracts, as shown in Figure 18
, demonstrating how the requests from an app-backend service could flow through the blockchain service, with related functions invoked at different levels.
The developed smart contract source codes, such as those of WineDataContract, PeerRegistryContract and Proxy, after being compiled as JSON objects with the Truffle framework, are injected in the blockchain service for further object instantiations and operations.
6.5. The Decentralized Peer-to-Peer Data Storage with InterPlanetary File System (IPFS)
As it is too costly, and therefore not sensible, to store a full version of wine record on-chain, an alternative persistent data source is required, and the IPFS decentralized peer-to-peer data storage is an obvious choice for deployment in dNAS, under which an immutable and permanent content hash would be obtained from the IPFS network. The IPFS hash of a wine record subset would be stored on-chain under its respective wine identifier, and could be referred to whenever there is a request for further operations, such as wine record validation across different blockchain service instances. From the security perspective, wine record subsets could not be altered or tampered with before being passed to the dNAS blockchain network and the IPFS network, given the fact that every content hash of a specific wine record subset obtained from the IPFS network will be changed if any of the contents of the wine record subset have been updated, which would further lead to an inconsistency with its counterpart stored on-chain when a wine record validation process is performed.
The IPFS functionalities in the blockchain service instance are enabled by “js-ipfs”. Before performing further IPFS operations, the IPFS node instance needs to be created in the blockchain service instance. During the wine record creation operation, in which changes are applied to the wine record subsets, the content hash is generated. The generated content hash have multi-hash format and base-58 encoding, under which the unique multi-hash allows the exclusivity of the generated content hash when the updated wine record subsets are added to the IPFS network. Once the IPFS node instance is generated, the wine record subsets are pushed to the IPFS network, with both “path” and “content” specified in the “addDataIPFS” function. The generated content hash of IPFS is then pushed and stored on-chain.
IPFS content hash is retrieved from the on-chain storage during the wine record validation operation, and the retrieved content hash is further sent to the IPFS node to obtain the represented wine record subset from the IPFS network. When looking up wine record subsets in the IPFS network, the network utilizes the distributed hash table (DHT), looking for respective IPFS nodes storing the specified wine record subset behind a content hash. The more times a wine record subset is retrieved from the IPFS network, the more copies of that record exist in the network, as the copy will reside in some IPFS nodes of the network, and IPFS nodes with the retrieved data will also act as hosts, accelerating the look-up process from the distributed hash table for other IPFS nodes looking up the same set of wine record subsets.
Object pinning of retrieved data could also be applied to ensure the data is always available on a local IPFS node, if the retrieved data needs to be available for further operations; however, as the retrieved wine record subset is only required for the specific wine record validation operation, the cache of the local node should be freed-up periodically if the data are retrieved with the normal “cat” method. IPFS nodes could also be added to or removed from a private IPFS network, like the one set used for dNAS, under which only IPFS nodes owned by any of consortium members and the consortium administrator are part of the private IPFS network according to the node management mechanism described in system implementation. Any message regarding the addition of data to, or retrieval of date from, the IPFS private network is shared only across the network. IPFS nodes on the private network could manage a list of IPFS nodes they have been communicating with, which are also owned by other consortium members of dNAS for IPFS node management.
6.6. The Key Management Module–Key Vault Service
It is important to know that blockchain transactions could only be sent from an account of a blockchain node, owned by any consortium member, with a valid digital signature produced by a private account key, such as the digital signature generated during the data-processing operation. Given how important the key management of Ethereum is to the security model of dNAS, it is vital to keep the private key of any account involved in dNAS safe, with a well-defined key management process and selection of key management modules. The key vault service deployed in dNAS could prevent any malicious player from compromising wine record components to negatively impact the data and processing integrity of the entire dNAS solution, though data stored on-chain is already hashed to obfuscate.
The key vault service of dNAS is developed basing on the open-source Vault by HashiCorp, which could further be remodelled with AWS Secrets Manager or Akeyless Vault depending on the system requirements, so as to offer functionalities to manage and control access to the secrets of different Ethereum nodes and accounts, respectively, owned by any consortium member, and to manage secrets and contract addresses returned after every smart contract deployment process. Identities need to be verified before a specific blockchain service instance can access and interact with a key vault service instance of dNAS. There are two authentication methods for every distributed key vault service instance, used by any individual consortium member—token-based and approle-based—as defined in “VaultAuthMethod”.
The former is based on a unique access token generated by any vault service instance for a specific blockchain service, which is also owned by the consortium member. The access token generated is limited by the authentication leases, implying that reauthentication is needed after a given lease period to continue accessing the key vault service. The latter is about a set of policies and login constraints, such as the RoleID and SecretID generated, regarding the specific key vault service instance, which must be met to receive a token with those policies and access the key vault service. The distributed blockchain service instance could access the distributed key vault service instance by specifying the “VaultAuthMethod” with necessary metadata, such as the URL of a deployed vault service instance, or the API version or both the role identifier and secret identifier, depending on the authentication method specified, through environment variables, when bringing up the instance of distributed key vault service.
Once the key vault service is instantiated with a given blockchain service instance, both owned by a specific consortium member, the secrets of an Ethereum node and account owned by the same consortium member are then ready to be created and stored in the same key vault service instance with a given “VAULT_PREFIX_KEY” and memberID. According to the smart contract deployment process, the consortium administrator is the only role that is permitted to develop, deploy and upgrade deployed smart contracts, as depicted in the use-case analysis of dNAS. The contract address of both individual smart contracts and the corresponding proxy contract alongside the public address of the contract owner, which is the consortium administrator for this case, could use a similar design pattern to store the metadata as “SCDeploymentSecret” with the corresponding proxy address as a key to the secrets stored.
7. Overall Evaluation
dNAS demonstrated that any state transition on a wine record along the supply chain could only be validated and completed automatically if, (1) the involved registered nodes and its distributed nodes, such as blockchain nodes and the IPFS nodes, are cryptographically authenticated, (2) the related wine record and the transactions for specific process are cryptographically verified, and (3) the consensus of such state transition is reached with the related transactions packed in a mined block, by blockchain nodes owned by other consortium members. The immutable states of transactions in different blocks are also available on the network and can be accessed via different tools developed in dNAS, such as the blockchain explorer. The wine record verification and product provenance abilities of dNAS were confirmed to be strengthened and benefited with decentralization, under which no more single-point failure and control were found in the proposed dNAS. The resiliency and availability of the validated wine records, with the history of transitioned states, are also enhanced with the persistent volume on the states of blockchain and the related transactions, alongside the wine record data stored in dNAS.
Though dNAS was found to be less scalable than its centralized counterparts, as we expected, the advantages brought by decentralization have enabled different nodes along the supply chain of wine industry to work collaboratively with wine records flowing downstream, with state transitions validated automatically in a decentralized and immutable fashion. dNAS proved to function not only as a verification service, but also as a notary service, providing a proof-of-existence for wine records owned by different supply-chain participants. Further qualitative analysis on dNAS as a whole was also performed, with limitations and risks identified to further improve different aspects, such as the system security, partial decentralization and scalability of dNAS.
In accordance with the research objective, it is confirmed that it is feasible to decentralize an anti-counterfeiting application of the supply chain industry to better improve the situation of counterfeiting attacks in the wine industry, and even the supply chain industry as a whole. With the flexibility of the architecture of decentralized system components, the decentralized solutions and operations proposed in dNAS are indeed industry-agnostic, and should be available for any industry with supply chain systems looking to combat product counterfeit.
With the current challenges in the anti-counterfeiting of the supply chain industry, the research was performed based on an implementation-driven research technique, with the main question and individual sub-questions listed in the research objectives and addressed in sections describing the system design, system implementation and the actual development steps detailed in this research. A proposed solution, namely the decentralized NFC-enabled anti-counterfeiting System (dNAS), is therefore developed as an autonomous and decentralized application for supply-chain anti-counterfeiting and traceability, especially for the wine industry, providing a way for registered nodes of the supply chain to verify the legitimacy of wine products, with cryptographically validated wine records. dNAS appears to strengthen the anti-counterfeiting and traceability capacities for the 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), which this research aimed to decentralize.
The literature analyses of this research cover current alternative resolutions to product anti-counterfeiting, and existing blockchain implementations applied in different industries. The idea of decentralized application was also explained and applied to the development of dNAS as this research’s contribution to explaining why ÐApp could exhibit properties, such as its zero downtime, immutability and resistance to collusion. The proposed system model design and system architecture of dNAS were implemented basing on a set of system requirements, defined according to the findings of a security analysis performed against the legacy NAS. How dNAS is actually implemented is explained via system implementation procedures, categorized into two main phases, namely the initialization phase, including those operations related to consortium registry management and smart contract deployments, and the data processing phase, including the wine record creation and validation operations of dNAS. The technical details of system development, design patterns applied to different system components and the system execution of the dNAS working prototype, were also covered and elaborated.
The developed prototype of dNAS provided a clear demonstration of how a legacy supply-chain anti-counterfeiting and traceability system, for the wine industry in this case, could be decentralized and reengineered from its centralized architecture, which was once hosted and maintained by intermediaries. dNAS is built around the idea of enterprise consortium with registered nodes along the supply chain of the wine industry, balancing the degree of decentralization, scalability, security and the privacy of the proposed solution, with the concept of enterprise blockchain chosen as the preferred development model of the blockchain network, as well as the availability of shared smart contracts with the ability to be upgraded, with versions shared amongst the consortium members. The future directions of this research are also defined, including the evaluation of dNAS with system-testing procedures, such as automated-testing and performance-testing on different system components of dNAS, and the discussion the results of these system-testing activities and a qualitative system analysis of the prototype dNAS. More details on the limitations of, and future opportunities for, dNAS, including the development of a fully distributed model of dNAS, the introduction of possible security and privacy-preserving features, and the concept of product ownership, are discussed and explained in the separate research of [22