## 4 The Decentralized NFC-Enabled Anti-Counterfeiting System-dNAS
### 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 _Ethere.js_ and _web3.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  
Figure 9: The Proposed Blockchain Interface of dNAS.  
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.