## 4 The Decentralized NFC-Enabled Anti-Counterfeiting System-dNAS
### 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  
Figure 7: Use Case of Registered Node Management. 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.