1

An Empirical Analysis of ImplementingEnterprise Blockchain Protocols in Supply Chain

Anti-Counterfeiting and TraceabilityNeo C.K. Yiu, Member, IEEE

Department of Computer Science, University of Oxfordneo-chungkit.yiu@kellogg.ox.ac.uk

Abstract—A variety of innovative software solutions, addressing product anti-counterfeiting and record provenance of the wider supplychain industry, have been implemented. However, these solutions have been developed with centralized system architecture which couldbe susceptible to malicious modifications on states of product records and various potential security attacks leading to system failure anddowntime. Blockchain technology has been enabling decentralized trust with a network of distributed peer nodes to maintain consistentshared states via a decentralized consensus reached, with which an idea of developing decentralized and reliable solutions has beenbasing on. A Decentralized NFC-Enabled Anti-Counterfeiting System (dNAS) was therefore proposed and developed, decentralizing alegacy anti-counterfeiting system of supply chain industry utilizing enterprise blockchain protocols and enterprise consortium, to facilitatetrustworthy data provenance retrieval, verification and management, as well as strengthening capability of product anti-counterfeitingand traceability in supply chain industry. The adoption of enterprise blockchain protocols and implementations has been surging insupply chain industry given its advantages in scalability, governance and compatibility with existing supply chain systems and networks,but development and adoption of decentralized solutions could also impose additional implications to supply chain integrity, in terms ofsecurity, privacy and confidentiality. In this research, an empirical analysis performed against decentralized solutions, including dNAS,summarizes the effectiveness, limitations and future opportunities of developing decentralized solutions built around existing enterpriseblockchain protocols and implementations for supply chain anti-counterfeiting and traceability.

Index Terms—Blockchain, Enterprise Blockchain, Distributed Computing Methodologies, Decentralized Network Protocols, Anti-Counterfeiting, End-to-End Traceability, Product Authenticity, Supply Chain Integrity, Supply Chain Provenance, Decentralization,Internet-of-Things, dNAS.

F

1 INTRODUCTION

THe problem of counterfeit product trading has beenone of the major challenges the supply chain industry

has been facing, in an innovation-driven global economy.The situation has exacerbated with an exponential growthof counterfeits and pirated goods worldwide, for which ithas also plagued the companies with multinational supplychain networks for decades and on, according to an ana-lytical study – [1] published back in 2016, suggested thatthe volume of counterfeit trading has already surpassedas much as $509 billion representing 3.3% of world trade.Given the growing concern and worsening situation intrading activities of counterfeit products, there have beenanti-counterfeiting solutions developed and implemented insupply chain systems of different industries. The motivationand research objectives, which is based on analyses on ex-isting blockchain implementations in supply chain industry,such as the Decentralized NFC-Enabled Anti-CounterfeitingSystem, will be elaborated in this chapter.

• Neo C.K. Yiu was with Department of Computer Science, University ofOxford, Oxford, United Kingdom

Manuscript first submitted for preprint on Jan 31, 2021.

1.1 Existing Blockchain Implementations in SupplyChain Industry

Many of the existing implementations for product anti-counterfeiting in supply chain industry including NAS asdescribed in [2], utilizing wireless communication technolo-gies, wireless sensor networks or geospatial technologies,are built with centralized architecture relying on trustedservers, databases and applications, which are solely con-trolled and managed by manufacturers of different sec-tors, for coordinating and managing product authenticationwith participation contributed from different nodes alongthe supply chain of different industries. As elaborated in[3], given a variety of advantages, including prevention ofsingle-point failure, better resilience and availability, intro-duced via applying blockchain technology with a conceptof decentralized application, to have more secured andsophisticated supply chain systems, more and more decen-tralized solutions basing on a wide range of blockchainimplementations and protocols have been developed andimplemented in supply chain industry.

Blockchain innovations have also been implementedacross supply chain industry, and some are specifically withuse cases of decentralizing and improving product traceabil-ity and anti-counterfeiting aspects of the industry. [4] hasproposed a concept of blockchain system to enhance trans-

arX

iv:2

102.

0260

1v1

[cs

.CR

] 4

Feb

202

1

2

parency, traceability and process integrity of manufacturingsupply chains, while an Ethereum-based fully-decentralizedtraceability system for Agri-food supply chain managementnamed AgriBlockIoT was developed in [5]. Furthermore,a novel blockchain-based product ownership managementsystem, a blockchain-based anti-counterfeiting system cou-pled with chemical signature for additive manufacturingand ontology-driven blockchain design for supply chainprovenance, are also explained in [6], [7], [8] respectively.

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 solutions developed. Instead of developingblockchain implementations based on conceptual design,decentralizing legacy anti-counterfeiting systems with cen-tralized architecture already implemented in the industry,further with blockchain innovations integrated with, wouldbe a more pragmatic way to start with. As such, the Decen-tralized NFC-Enabled Anti-Counterfeiting System (dNAS)is developed, as depicted in [9], utilizing decentralizedblockchain network with enterprise blockchain protocolscompatible with the concept of enterprise consortium, pro-grammable smart contracts and a distributed file storagesystem to develop a secure and immutable scientific dataprovenance tracking and management platform, so as toprovide timely support to improve the snowballing situa-tion of product counterfeits in supply chain industry.

1.2 Research ObjectivesGiven dNAS has already been developed and imple-mented in supply chain industry for decentralizing anti-counterfeiting and traceability functions, with system modeldefinitions and system architecture based on a set of funda-mental system requirements defined and security analysesagainst its centralized counterpart, a main question of thisresearch should therefore be:

"Are decentralized anti-counterfeiting and traceability solu-tions, such as dNAS, which have already been developed andimplemented in supply chain industry, more effective and worthon combating the rampant counterfeiting attacks, compared withits centralized counterparts?"

In order to progress the research with a wide range ofanalyses performed against dNAS to identify future oppor-tunities of strengthening the capability of anti-counterfeitingand traceability with dNAS, the main question is thenaddressed through answering the following sub-questionsthroughout the research:

1) What are the possible approaches of the integrationmodel to such proposed decentralized solutions forwhich a user-friendly solution should be developedto help promote adoptions from node participants,end consumers and to supply chain industry as awhole?

2) How is the proposed decentralized prototype testedand validated with different settings, and against itscentralized counterparts qualitatively and quantita-tively?

3) What are the limitations, concerns and potentialfuture opportunities of dNAS?

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, viaa background on enterprise blockchain and existing enter-prise blockchain protocols applied in supply chain industry,a wide range of system analyses against the developeddNAS and a discussion of results so as to gain insightson what and how dNAS and other decentralized supplychain anti-counterfeiting and traceability solutions, basingon enterprise blockchain protocols and implementations,could further be improved.

2 BACKGROUND

In this chapter, following blockchain fundamentals andthe advantages brought by the blockchain technology andblockchain 2.0, where dNAS and many of the existing de-centralized solutions in supply chain industry are currentlydeveloped on, as explained in [3], the concept of enterpriseblockchain and existing enterprise blockchain protocols cur-rently applied in supply chain industry are also elaborated.

2.1 Enterprise Blockchain at the Core

The blockchain network can generally be categorized eitheras permission-less (public network) or permissioned net-work. The former is an open distributed ledger networksuch as [10], where any node can join the network andwhere any two peers can conduct transactions without anyauthentication performed by any central authority, whilethe latter is a controlled distributed ledger like [11] wherethe decision making and the validation process are kept toone organization or few organizations forming a consortiumwith or without the staking concept. In permissioned net-works, the consortium administrator or certificate authoritydetermines who can join the network as a validator node orlistener node. All nodes are authenticated in advance, andtheir identity is known to other nodes running on the samenetwork and in the same consortium, also known as peer-permissioning.

Permissioned blockchain implementations utilized byany organization or a group of organizations in the samesubset of industry forming a consortium are commonlyknown and classified as "enterprise blockchain". Differentindustries and service sectors have been implemented withinnovative solutions and system, such as enterprise resourceplanning, global positioning system and wireless tag com-munication system, in order to enhance the effectivenessand efficiency of service processing; however these innova-tions are not usually integrated and seamlessly connected toform a supply chain and value chain, which should supposeto facilitate the visibility of processed data across a supplychain or a specific industry.

Enterprise blockchain implementations are not fully de-centralized compared with decentralized solutions runningon public networks made available for wider audience tointeract with data exchange, and it is instead more focusedon building use cases to improve operational efficiency andeffectiveness for a group of organizations, a subset of in-dustry or even an entire supply chain of specific industries.Though it is not fully decentralized, it still come with the

3

blockchain characteristics, as elaborated in [3], and possiblya sovereign blockchain network for a group of organizationsin a specific subset of industry, preventing security threatswhich could be identified in centralized architecture, suchas single-point process, lower trust levels and sequentialsupply chain data exchanges amongst supply chain partici-pants. There are more advantages and industry perceptionstowards enterprise blockchain implementations which arewell explained in [12].

2.2 Related Work of Enterprise Blockchain ProtocolsWith the advancement of blockchain development in recentyears, there have been some existing blockchain innovationsdeveloped in different domains and in combination withother emerging technologies, such as IoT, NFC, artificialintelligence, machine learning and cloud computing, fordifferent purposes like forming digital business ecosystemsto propel towards Industry 4.0, as detailed in [13]. Giventhe advantages such as peer-permissioning, a more scal-able consensus algorithms and a capability of maintainingsovereign blockchain networks for specific business usecases with specific groups of organizations forming enter-prise consortia, these disruptive digital business ecosystemsare in all likelihood developed basing on open-source enter-prise blockchain protocols and implmentations, includingEthereum Proof-of-Authority network, Hyperledger Fabric,Consensys Quorum and Tendermint Core, as elaborated inthe following.

2.2.1 Hyperledger Fabric[11] is a permissioned blockchain framework implementa-

tion providing modular components designed for businessuse cases to build its own enterprise blockchain. It is oneof the Hyperledger projects hosted by The Linux Founda-tion. Hyperledger Fabric leverages container technology tohost smart contracts called "chaincode", comprised of theapplication logic of systems, available in a wide range ofprogramming languages. In Hyperledger Fabric, the nodesthat have access to the ledger are called "peers", and eachpeer belongs to some organizations. Adding transactions toFabric is literally a two-phase endorsement process as shown inFig. 1:

1) A client requests a transaction firstly approachesone or more endorsing peers with a transaction pro-posal and asks them to execute as well as endorsingthe proposal.

2) The endorsing peers then execute a smart contractto determine whether or not to endorse the trans-action based on an endorsement policy, and if so,endorsed transactions would then change the stateon the ledger. All endorsers must see an identicaltransaction proposal, or else it is rejected in theordering service.

The "logical validity" of transactions is determined in theendorsement phase. Once sufficiently enough endorsementsare obtained, the client would then send the endorsed trans-action to an ordering service, hosted by the leader node ofan organization, imposing a linear order on transactions andadding them to the ledger. The number of required endorse-ments for a transaction is determined by an endorsement

policy, which is set when the ledger is initialized. Roughlyspeaking, the ledger of the organization has only a singleendorsement policy applied to every transaction, and thereare also authentication and authorization policies appliedfor peer-permissioning. Sensitive data on the ledger shouldremain private from the chain of blocks, ordering service,and a subset of peers in a channel. Only evidence, such ashashes, need to be on the chain of blocks or sent to orderingservice, later distributed to every peer of the organization.

The consensus algorithm of Hyperledger Fabric is con-fined in the Crash Fault Tolerant (CFT) ordering service,aimed at fast finality, based on the RAFT consensus protocol,which follows a "leader and follower" model, where a leadernode is elected per organization or channel, and its decisionsare replicated by the followers. Such consensus algorithm isperceived to be more centralized than other consensus algo-rithms, amongst enterprise blockchain protocols, especiallywhen the number of nodes on the network is low.

2.2.2 Tendermint CoreTendermint Core is a blockchain application platform,developed based on [14] and [15], equivalent of aweb-server interaction, database, and supporting librariesfor blockchain applications written in any program-ming language allowing creation of business task-specificblockchains fulfilling any business needs. Tendermint Coreperforms Byzantine Fault Tolerant (BFT) State MachineReplication (SMR) for arbitrary deterministic and finitestate machines, functioning as a consensus engine for otherblockchain tools, such as Hyperledger Burrow – an alter-native implementation of Ethereum Virtual Machine (EVM)for the smart contracts, to be built on top of.

Given the application of leader-based BFT consensus al-gorithm on Tendermint, the scalability and performanceaspects of the consensus machine is greatly improved fromits counterparts of the traditional Proof-of-Work. It onlyrequires more than two-third nodes of the network to agreeon a state of the ledger before a consensus is reached basedon the BFT consensus.

Tendermint is a major building "block" of the wholeCosmos Network project, also known as the Internet ofBlockchains. They have implemented their decentralizedCosmos Hub on Tendermint to improve blockchain interop-erability. This Hub is where all the interoperable blockchainswould communicate with each other via the sidechains,also written in Tendermint, allowing transfer of digitalassets from one blockchain to another. It is designed tobe straightforward to integrate any ÐApp or blockchaininto the Internet of Blockchains in case those are also builtwith Tendermint or Cosmos-SDK, which is an extension ofTendermint with added stacking.

2.3 Contribution – System Analysis and Evaluation ofdNASThe idea of dNAS is all about provably honest of whichusers of the decentralized solution should be able to au-tomatically verify actions requested by server instances ofother nodes along the supply chain, whenever they wouldlike to and have the servers instances themselves checkingwith the instances of decentralized storage and decentral-ized network with validation results returned. dNAS aims

4

Fig. 1: Hyperledger Fabric Transaction Endorsement Workflow

at delivering a more secured and quality approach to verifythe authenticity and provenance of luxurious products, suchas bottled wine, with the use of peer-to-peer enterpriseblockchain protocols basing on a concept of enterpriseconsortium, and IPFS which has the potential to eliminateabsurd amount of costs for on-chain storage and providea much higher level of privacy, reliability and quality ofservice compared with the legacy NAS of centralized archi-tecture.

For entities to embrace this budding technology withconfidence, dNAS needs to be secured, reliable, flexiblewith integration models available, and its implementationdetails should be straightforward for supply chain nodesto adopt. Similarly, for consumers interacting with the userinterface of dNAS, it needs to be user-friendly and trans-parent. dNAS itself does offer a foundation to explore thestrengths and weaknesses of decentralised applications overtheir centralised counterparts, especially in supply chainindustry. The evaluation of the proposed dNAS against theresearch objectives, and in areas, such as the decentralizedwine record management, data and process integrity indNAS, system security, availability and integration, wouldalso uncover certain limitations and concerns of hostingand deploying ÐApps on different enterprise blockchainprotocols and implementations.

The research is aimed at investigating into the systemevaluation with various system testing and performancetesting activities performed against dNAS to determineif decentralized solutions applied in supply chain anti-counterfeiting and traceability are effective and useful asexpected. Discussion of results is also covered to providequalitative and quantitative system analysis, benchmark-ing different existing enterprise blockchain protocols to thenovel dNAS developed, with risks and limitations identifiedfor creating potential opportunities on future developmentand advancement of dNAS.

3 THE DECENTRALIZED NFC-ENABLED ANTI-COUNTERFEITING SYSTEM (DNAS)

dNAS is a decentralized and integrated system tailor-made for the wine industry. While capabilities such asend-to-end traceability, provenance and authenticity wereenabled in the legacy NAS, as described in [2], its anti-counterfeiting model was actually based on winemakerroles with their products moving downstream to their regis-tered supply chain participants and wine consumers untilthe retail points. The anti-counterfeiting model of dNASis actually based on the decentralized enterprise consor-tium consisting of multiple winemakers and supply chainparticipants, responsible for operating the web applicationand NFC-enabled mobile applications of the legacy NASon a dedicated and decentralized blockchain network, viaan integrated interface, with blockchain nodes assigned tothe consortium members, based on enterprise blockchainprotocols.

With the proposed system architecture of dNAS asdemonstrated in Fig. 2, it explains how exactly the legacyNAS could be re-engineered and running on the chosenenterprise blockchain protocols, and what exactly are thesystem components to be decentralized so as to enable corefunctionalities of the novel dNAS. Several major design de-cisions were also taken into account for the system architec-ture implemented as expected in terms of system scalability,security and privacy. The proposed system architecture ofdNAS can be explained in mainly three parts, namely (1)the decentralized blockchain network, (2) the blockchaininterface, and (3) the system components built in the legacyNAS.

Given the system model design with several designdecisions explained, the actual system implementation stepsof dNAS were also defined, including the proposed systemimplementation with the system operation protocols, spec-ified for detailing the system functionalities of the noveldNAS, on different wine record management process. The

5

Fig. 2: System Architecture Diagram of dNAS

system implementation is generally categorized into twophases, as demonstrated in [9], namely the initializationphase and the data processing phase, covering system im-plementations ranging from consortium formation, smartcontract deployment to 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 initializa-tion phase is consisted of consortium formation process andsmart contract deployment process. The data processing phaseincludes all the necessary system operations regarding thedecentralized wine record management along the supplychain, such as creation, validation and appending, involvingdifferent consortium members.

4 SYSTEM ANALYSES OF DNASSystem analyses are performed against system design de-cisions made during the development of dNAS, based onthe proposed system model and system architecture ofdNAS, ranging from the selection of enterprise blockchainprotocols, on-chain data storage to system integration mod-els selected for promoting adoptions of dNAS or anyother existing decentralized solutions in supply chain anti-counterfeiting and traceability.

4.1 Selection of Blockchain Network and ConsensusProtocol

There are a variety of enterprise blockchain protocols otherthan the Ethereum Proof-of-Authority blockchain imple-mentation, such as Hyperledger Fabric and TendermintCore, for which the development of dNAS could be basedon. Since trust is already achieved outside the blockchainnetwork, the concept of enterprise consortium is thereforeintroduced to implement a permissioned blockchain net-work for every consortium member of wine industry or

the wider supply chain industry, to run their blockchainnodes on a Proof-of-Authority (PoA) protocol to send andvalidate transactions, bypassing any intermediary actingon behalf of them. With the advent of the permissionednetwork based on the consortium with a concept of enter-prise blockchain, non-member accounts to access methodsof deployed smart contracts are then limited, based onthe role restrictions applied in the smart contract designpatterns. Peer-permissioning is also enabled under whichevery registered node must be explicitly allowed to join thenetwork, with trusted authorities applying accountabilitytowards the consortium formed for the wine industry. Itis therefore unnecessary to commit much computationalpower to support the trust in an enterprise consortium en-tirely, allowing the consensus mechanism for enterprise so-lutions to be selected, instead of any computation-extensiveconsensus algorithm applied in public blockchain networks.It will then in turn enhance scalability and performance ofthe chosen blockchain network with enterprise blockchainprotocols applied.

The process of achieving a non-disputable agreement,amongst the distributed nodes’ states, is called consensus.The popular options of consensus algorithm for any enter-prise blockchain solution are ranging from the aforemen-tioned PoA on Ethereum, the Crash Fault Tolerant (CFT)algorithm such as the Reliable, Replicated, Redundant, AndFault-Tolerant (RAFT) applied in Hyperledger Fabric orQuorum, to the Practical Byzantine Fault Tolerance (PBFT) likethe Istanbul Byzantine Fault Tolerant (IBFT) applied in Quo-rum Blockchain which is an enterprise blockchain platformforked from the open-source Go-Ethereum (Geth) clientof Ethereum with several protocol-level enhancements tosupport different business needs.

Proof-of-Authority Clique, RAFT and IBFT all offer ab-solute finality implying that a confirmed transaction cannotbe reverted or annulled in any case. Both RAFT and IBFT,which are permissioned voting-based, offer immediate fi-

6

nality, where no fork is ever allowed to happen. While thepermissoned lottery-based PoA Clique offers finality withinthe (N / 2) + 1 blocks because each of those blocks areprotected by a different signer sealing blocks based on thepublic key cryptography, thus forming a chain of digitalsignatures. It is therefore achieving proof of origin anddata immutability for every transaction, which cannot bebroken without majority of a network colluding together.The comparison of typical consensus algorithms is listed inFig. 3.

Fig. 3: Comparison of Consensus Algorithms

PoA Clique and PoA Aura both rely on a set of trustedauthorities utilizing a simplified messaging algorithm toachieve better performance than typical PBFT algorithms.There is only one round of messages exchanged among theauthorities in PoA, compared with three rounds in PBFT,namely the pre-vote, pre-commit and commit stages respec-tively to validate a transaction and sign a block once thereare signatures amounted to two-third of a validation group,comprised of a validation leader by vote and a group ofvalidators.

Therefore, better performance is one of the claims ofPoA when measured against other permissioned voting-based algorithms, such as PBFT. PoA network can tolerateup to N / 2 – 1 byzantine authority nodes. It could operatecorrectly when N / 2 + 1 authority nodes are honest. Multiplevalidator nodes are allowed to propose any block. Contraryto the PBFT, the design of PoA might sacrifice consistencyfor better availability so faster block committal but witheventual consistency guarantee once the forks get sorted outby the GHOST protocol. PoA produces blocks at a config-urable but fixed interval, regardless of whether there is anytransaction to include or not, and PoA Clique is an appropriatechoice for a network containing parties that do not trust eachother. For instance, with a network of 4 blockchain nodes, 3validator nodes and a node of consortium administrator, itwould be up to N – (N / 2 + 1) which is 1 validator node, forthis case, can propose a block for any given block interval.

PoA Clique or Aura is a more appropriate choice thanRAFT for the development of dNAS, given its decentralizedmechanism and signature-protected data immutability ofvalidated transaction. For instance, validator nodes on thePoA Clique network take turns to validate transactions andsign a block for which the block sealing process is lottery-based amongst the participating nodes of the network,instead of being executed by a specific leading validatornode. While for RAFT, the consensus model assumed theelected leader node always acts honestly and correctly withfollowers blindly replicate state transitions proposed by theleader node with no further validation. In HyperledgerFabric [11], the elected leader node controls the order oftransactions endorsed in the centralized ordering service ofa channel aiming at fast finality on blocks. Blocks minedin a Quorum RAFT consensus network are not protected

by signatures, as a result, blockchain data can be rewrittenrather easily by modifying historical data, such as trans-action inputs and recalculated block hash, transactions trieroot, etc. RAFT consensus does not mint new blocks un-less there are pending transactions. This would result insignificant storage savings, but trade-offs are difficulty andsecurity of the blockchain which could be lowered withoutany signature protection. The canonical chain is far simplerthan its counterparts of enterprise blockchain protocols.

4.2 On-chain Data StorageMany useful applications need to persist data to be benefi-cial for their end users, especially if someone is consideringmigrating their application from a centralized approach toa decentralised alternative. Given how unscalable and howexpensive it could be as it would cost absurd amount ofcosts in case dNAS was to build on the Ethereum mainnet, questions such as how, what and where the registerednodes’ persistent data is stored will need to be accountedand addressed carefully.

According to a standard wine record defined dNAS, asdemonstrated in Appendix A.1 with a corresponding datamodel defined in Appendix A.3, merely one industrial op-eration performed with the individual transactions loggedin the data schema, would already have the wine recorditself sized at 2,900 bytes. Given the size of the wine recordcalculated, should ones still look to process the whole winerecord on-chain and put whole chunks under the "data" fieldof every transaction, not to mention every additional supplychain process with its transaction data will at least add 806bytes to the wine record, and every additional unsuccessfulvalidation process will at least add 313 bytes to the winerecord?

Looking at the gas used per transaction involving thewhole 2900-byte wine record would suggest a very insight-ful idea on whether the whole wine record should beprocessed on-chain. Based on calculation steps detailed inAppendix A.4, total gas used per transaction and total costfor the 2900-byte wine record would be 1,820,000 and 0.1092ETH ($133.55 with ETH priced at $1,223) respectively. Giventhe fact that dNAS is running on enterprise blockchainprotocols and no gas cost is specified on any gas used in anytransaction, storing the full wine record will never be a good idearegardless of which enterprise blockchain protocol would beadopted, and regarding the performance of the blockchainnetwork and dNAS as a whole.

It is why IPFS - a distributed file storage is adopted anddeployed as a system component of dNAS connected to theblockchain service, processing a subset of a full wine record,as demonstrated in Appendix A.2, involved in any operationof the data processing phase, under which a standard 46-byte hash will be generated, regardless of size of the winerecord for storing the data in a decentralized and distributedfashion with the original wine record to be retrieved withthe generated content hash supplied to any local IPFS node.Instead of parsing a full wine record to the data field of anytransaction involved with the enterprise blockchain protocoladopted in dNAS, the IPFS content hash representing aversion of wine record is then stored and processed on-chain with corresponding methods of the deployed smartcontracts for any blockchain transaction.

7

A couple of mapping data structure defined in the de-ployed smart contacts are based on 32-byte hash represen-tation of the unique wine identifier as the key of mappingkey-value storage so as to log the important data, such asthe 32-byte hash representation of unique tag identifier, thewrite count (iteration) of every NFC tag, and the publicaddress of any registered node which could be recoveredfrom a respective signature passed in. With these types ofdata stored on-chain based on specific wine identifiers, on-chain states could therefore be included in any validationlogic whenever a NFC tag is scanned during any acceptingor buying process of specific wine products.

4.3 Proposed Hybrid System Integration Model withLegacy NASdNAS should set to provide a streamlined mechanism forregistered nodes of different roles in wine industry or thewider supply chain industry, to migrate their current cen-tralized architecture adopted in the legacy NAS to dNASwith certain degree of decentralization, as explained in [3]. Ahybrid approach should also be offered for potential nodesof winemaker role and supply chain participant role, whoare less concerned about trust issues of central architecture,to join the enterprise consortium of dNAS. The hybridapproach of dNAS is a starting point for newly joinedregistered nodes to enjoy benefits suggested in dNAS and ismore of an incremental way for any registered node in wineindustry to eventually adopt the fully decentralized anddistributed approach. The hybrid approach is therefore adoptedfor development of dNAS depicted in [9].

Instead of conducting a complete architecture overhauland having every consortium member (registered nodesof wine consumer role are not part of the consortium asmentioned in the use-case analysis performed in [9]) hostingtheir own instance of dNAS, every registered node will gothrough use cases of registered node account managementdeveloped in AccountController of the app-backend service,to login and perform system operations on wine records,enabled by the dNAS instances hosted by the consortium,via a trustful governing authority which is the consortiumadministrator.

Having the consortium to host dNAS, it implies that ev-ery consortium member is assigned with all the distributedsystem components, including the blockchain service, keyvault service, blockchain node, IPFS node, etc. Every regis-tered node with access to the web application and mobileapplications would require partition logic patterns appliedto the database of app-backend service. In order to processand validate wine records properly, authentication logicpattern for user sessions of different applications, accesscontrol pattern to functionalities designed for different rolesof registered node, and authorization logic applied to theblockchain service and app-backend service, are requiredto implement. The blockchain node and IPFS node couldtherefore be connected whenever there is a request forany interaction with the blockchain network and the IPFSnetwork. Access to the node management suite and theblockchain explorer will need to be given to each consor-tium member to synchronize with the state and notify ofperformance on the blockchain node and IPFS node ownedby them.

By having the consortium administrator to bestow in-herent level of trust between consortium members, theregistered nodes could access to dNAS without much hassle.With the proposed hybrid approach, despite the fact thatregistered nodes would get benefits of decentralisation, suchas high availability and non-repudiation on the states storedon-chain, subsets of wine records stored in IPFS networkand decentralized operations of the consortium, it will stillbe susceptible to certain vulnerabilities from the given de-gree of centralization attributed by the concept of enterpriseconsortium. The app-backend service, blockchain serviceand every instance of the distributed system are actuallyhosted by the consortium, which is managed by the con-sortium administrator, scenarios such as service downtimeand failure on centralized system components of the app-backend service could still be applied. However, states ofwine records will still be conserved within the decentralizedsystem components of dNAS.

5 SYSTEM TESTING

A variety of software tests are in place to ensure functional-ities set out in different system components are functioningas expected, the system testing process of dNAS could bedivided into the functional testing and performance testing.

5.1 Functional Testing of dNASConcept of microservice containerization has made softwaretesting and deployment more straightforward in dNAS. Testscripts are developed to build the corresponding containers,based on the definition of docker-compose files, whichwould in turn build the respective Docker images specifiedin its Dockerfile. The test scripts will run the specific testservice of a running container, with individual test casesexecuted. The test process of dNAS is demonstrated in Fig. 4.

Fig. 4: Test Process of dNAS

Individual system components, such as the blockchainservice and smart contracts, are developed in individualrepositories maintained with versioning tool of source code.Automated testing strategy is also adopted with differenttypes of functional system tests, namely unit tests againstindividual functional definitions, static analysis on smartcontracts, and flow tests involving different functions per

8

specific operational logic, are also included. Integration testsare also covered between different system components, suchas blockchain service and app-backend service on its inte-gration involving endpoint invocations of the blockchainservice instance. Good test coverage of blockchain servicecould demonstrate the assurance on functions developedin different software components do define and executeas expected according to those operations explained in thesystem implementation of dNAS described in [9].

5.2 Performance Testing of dNASPerformance testing is also included for different sys-tem components of dNAS, such as the smart contracts,blockchain network and blockchain service, so as to examinewhether the proposed dNAS could fulfil the non-functionalrequirements set out in [3]. There are three key performancemetrics on dNAS, including averaged gas spent per individ-ual method of the deployed smart contracts, the averagedtransaction per second (TPS) the chosen enterprise blockchainprotocols could process, and the total computation timeneeded for different operations in data processing phase ofsystem implementation.

The average gas spent per method of the deployed smartcontracts defined in dNAS, is determined by a load testingof having 200 runs on every method. Deviation on every runper smart contract method is expected owing to the variableon the different states every method needed to process forevery run. It could further explain why averaged gas spent isa vital metric one should be taken into consideration, so asto better determine the values of initial block gas limit de-fined in the genesis file of the chosen enterprise blockchainprotocols adopted in dNAS, the minimum target of blockgas limit on future mined blocks as well as the options onhardware components running the blockchain nodes, suchas the Amazon EC2 instance types. The averaged gas spentof every smart contract method alongside the averagedgas spent of individual smart contract deployment processfor smart contracts, based on the version of the Soliditycompiler at 0.6.10, are listed in Fig. 5.

Fig. 5: Average Gas Spent Per Smart Contract Method andDeployment

On-chain methods of the deployed smart contracts arethose with state transitioned, such as the "createWineRecord"with the most gas spent amongst all on-chain methods,

averaged at 118,364. Given the targeted minimum block gaslimit was set at 12,500,000,000, it enables the possibility ofhaving multiple transactions related to different methods,validated and packed in the same block as long as the totalgas limit is not exceeding predefined block gas limit.

Given the fact that "createWineRecord" spent most aver-aged gas, which is averaged at 118,364, amongst all thesmart contract methods of dNAS as listed in Fig. 5, it is thepreferred smart contract method to determine an averagedtransaction per second (TPS), based on 10,000 5-secondblocks mined in a 4-node PoA Clique blockchain networkunder which each node is deployed with a "t2.2xlarge" ofAWS EC2 instance. Fig. 6 shows the distribution of transac-tions validated per block across a 10000-block duration.

Fig. 6: Distribution of Transaction Counts Over 10,000 Blockson dNAS Blockchain Network

According the results shown in Fig. 6, the peak and av-eraged number of transactions validated per 5-second blockare 3,933 and 3,759, and therefore the peak and averagedtransaction per second would then be 786.6 TPS and 751.8TPS respectively. There are in total of 38,565,382 transactionsvalidated across the first 10,000 blocks mined in the net-work. The results gathered, based on the preferred settingof the blockchain network developed for dNAS, show thatnon-functional requirements about system scalability set outin [3], of which these requirements requires dNAS shouldbe able to process one-million wine record without adverselyaffecting other operational parameters, and the blockchainnetwork developed as part of dNAS should be able toprocess at least 500 transactions per second, are fulfilled.

The experiment of determining the transaction per sec-ond over 10,000 blocks, for a 4-node network has furtherextended to examine how TPS could change with dif-ferent types of EVM nodes of Ethereum-based enterpriseblockchain protocols, deployed with a variety of choices onAWS EC2 instances with the metric listed in Fig. 7.

According to the comparison and reasoning on the pre-ferred enterprise blockchain protocol for dNAS included inthe analysis of consensus protocols covered in the chapterof system analysis on dNAS in this research, Go-EthereumClique network is of the best performance in terms of scal-ability, across different types of AWS EC2 instances, com-

9

Fig. 7: Transaction Per Second on Different Node TypesDeployed on Different types of EC2 Instances

pared to different enterprise blockchain protocols consistedof EVM nodes, such as those running on both Parity andQuorum.

Load testing activities are also performed to determinethe computation time required, with different batches ofrequest sending to different endpoints, related to data pro-cessing operations, provided in the blockchain service. Thecomputation time for different sets of load testing, appliedon a blockchain service instance of dNAS, is listed in Fig. 8.

Fig. 8: Computation time (in seconds) of Different Endpoints inBlockchain Service

The end-to-end load testing is also covered in differentend-to-end data processing operations performed, by aninstance of dNAS, such as the wine record creation andwine record appending operation, benchmarked with itscounterparts performed by the legacy NAS to examine whatdecentralization could mean to different data processingoperations of a supply chain application, in terms of thescalability as listed in Fig. 9. The wine record validationoperation of dNAS is not included since there is no suchoperation implemented in the legacy NAS.

Fig. 9: Computation time (in seconds) of End-To-End DataProcessing Operations Between dNAS and Legacy NAS

According to the results of 1,000 standard requests ofboth creation and appending operations sent to both dNASand the legacy NAS, as listed in Fig. 9, dNAS would roughlytake 34.08% and 36.14% longer, in terms of the computa-tion time, of creation and appending operation respectively,compared with these performed in the legacy NAS, giventhe decentralized processes and system components intro-duced in dNAS.

6 DISCUSSION OF RESEARCH RESULTS

With the system analyses and system testing of dNAS al-ready demonstrated and elaborated, it is important to eval-

uate, in different perspectives, if these aspects and dNASitself are consistent with what were set out in the researchobjectives, on whether dNAS and other decentralized solu-tions developed basing on enterprise blockchain protocols,and what the system requirements were set out in [3], withthe discussion of results according to the findings gatheredfrom a series of system testing activities and system analysesperformed against dNAS.

6.1 The Scalable Decentralized Wine Record Manage-ment

It is expected that decentralized systems are generally lessscalable than its centralized counterparts owing to the factthat consensus is needed for every state changed on thedata. dNAS is also appeared to be less scalable than thelegacy NAS in different operations, such as wine recordcreation and appending for which the computation timeof both with dNAS are 34.08% (250.98 seconds per 1,000requests of wine record creation to be processed) and 36.14%(232.29 seconds per 1,000 requests of wine record appendingto be processed) more than those operations performed withthe centralized legacy NAS. Given the extra decentralizedprocesses, which involve blockchain service, IPFS network,key vault service of dNAS, from the point of invokingendpoints of blockchain service all the way to the blockchainnetwork, the one-third extra computation time required onlyfor these decentralized processes, does look reasonably swiftif comparing with benefits brought by decentralization, suchas the strengthened data integrity and improved system se-curity with distributed instances enabling individual nodesalong the supply chain collaborating to combat productcounterfeits.

The fact is that computation time of decentralized on-chain processes is always a surplus to the computationtime taken for off-chain processes performed in centralizedsystem components inherited from the legacy NAS, suchas the app-backend service. In other words, the one-thirdextra computation time, of dNAS compared with the legacyNAS, is contributed only by the decentralized processes,which is of better performance, given the fact that the samewine records are processed on-chain in a distributed anddecentralized way. The blockchain service of dNAS is able tohandle an average of 6.47 requests per second (154.64 secondsper 1,000 requests) for wine record creation operation, andan average of 6.88 requests per second (145.33 seconds per1,000 requests) for wine appending operation, while theblockchain service can also handle 9.79 requests of winerecord validation process per second (102.19 seconds per 1,000requests) involving the three-layered validation steps (vali-dating an IPFS hash of wine records on-chain, validatingwine record subsets stored on IPFS network, and validatingwine record subsets retrieved against its counterpart storedin the off-chain database of the app-backend service).

There are two reasons contributed to such a good per-formance on decentralized system components, which are(1) the selection of the enterprise blockchain protocol, forthis case the EVM-based consensus protocol such as thePoA Clique, targeted on good scalability to get started forthe blockchain network of dNAS, and (2) the optimizedon-chain data storage. The former refers to the selection

10

of permissioned Proof-of-Authority implementation on Go-Ethereum as the preferred consensus algorithm for theenterprise blockchain implementation, instead of a publicpermission-less Ethereum network with more focus on thedecentralization over scalability, for the blockchain networkunder which the network throughput outdid the 500 TPSset in non-functional requirements, further to 786.6 TPSwith blockchain node hosted with t2.2xlarge of AWS EC2instance. The enterprise Proof-of-Authority protocol is alsoproved to be the most scalable option amongst the availableenterprise blockchain consensus protocols explained in thisresearch, based on the setting of dNAS, amongst networkswith EVM-based blockchain nodes such as the Quorumand Parity Aura. The latter refers to the design decisionmade that only IPFS content hash representing specific winerecord subset is stored on-chain for specific wine identifier,instead of the full version of wine record which wouldin all likelihood spend 3,060,000 of gas amount, based onthe calculation performed in Appendix A.1, for every state-transitioned transaction on the wine record. The averagedgas amount spent for transactions of wine record creationand appending in the setting of dNAS, are merely 118,364and 114,129 respectively, according to Fig. 5, which couldfurther be lowered with more optimization mechanismsapplied to methods of the smart contracts. The relatively lowgas spent on methods of the smart contracts implies that lesscomputation time and gas spent is required per transactionand so more transactions could be packed into a minedblocked as long as the sum of gas spent of transactions to bepacked is less than the predefined block gas limit.

Another layer of Merkle proof mechanism, in addition tothe one already adopted on the blockchain node regardingtransaction states, on the off-chain storage of wine recordswas once considered. Nonetheless, given the IPFS mecha-nism is not only to obtain a root hash for a wine record,which is indeed adding another layer of security to thesystem and to data integrity of the wine record, the IPFSapproach is therefore preferred in dNAS. The scalability ofdNAS as a whole could be further enhanced with multi-threaded processes introduced to individual system com-ponents, such as the app-backend service and blockchainservice. More optimized gas spent for individual methodsof the deployed smart contracts with more transactionsincluded in a mined block, and other options of non-EVMpermissioned consensus algorithms of enterprise blockchainprotocols targeted on high scalability, such as the leader-basedHyperledger Fabric, could also enhance the scalability ofdNAS.

6.2 Improved Data Integrity

The three-layered data storage and validation on wine recordsacross the off-chain database of the app-backend service,IPFS network and the blockchain network, have provedthat data integrity on wine records processed is enhancedunder the setting of dNAS. Except the wine record creationoperation, any wine record to be processed is requiredundergoing off-chain validation processes against the fullversion of wine records, stored in the database dedicated tothe app-backend service, and on-chain validation processesagainst wine record subsets stored on the IPFS network

and other data stored on-chain, such as the content hashof IPFS, the write count and the public address related tospecific wine identifier, before any operation, such as thewine record appending operation with state transitions onwine records could be executed. New entry of supply chaindata and transaction data, with data fields like transactionhash and block number, are then created and added towine records in database with the content hash of IPFSalso updated as the version of wine record subset has beenupdated.

The on-chain and off-chain validation processes de-scribed in the wine record validation operation, presentedin the system implementation of dNAS, were in place toensure data integrity and to prevent any attempted attacks,such as the cloning attack on NFC tags, modification attacksin case the wine identifier and the signature stored in NFCtags are inconsistent with that stored in the database or on-chain storage, and reapplication attacks in case the readcount and write count are inconsistent to its counterpartsstored off-chain and on-chain respectively. With a certaindegree of decentralization attained with both IPFS networkand blockchain network, data integrity of processed winerecords is further improved, owing to the fact that any statechange on a specific wine record with its transaction willnow need to be validated with consensus reached on thenetwork. The immutability of transaction states related tostate transitions of specific wine record operations wouldmean that any state change processed on the network couldbe referred and queried in any connected block explorer,based on individual transaction hashes and block numbersspecified.

6.3 Strengthened Security Considerations

Given the security considerations deployed to different val-idation processes of the wine record validation operation toimprove data integrity, and according to the result from thethreat analysis performed on the legacy NAS, as detailedin [3], which in turn transformed into system requirementsfor the development of dNAS, a variety of security attacksexisted in the legacy NAS have no longer been found indNAS or error is thrown if those attacks are detected beforea state transition could be completed on a specific winerecord. The security model on data integrity of dNAS is alsoproved to be able to function beyond the retailer points,as long as post-purchase wine consumers of consumer-to-consumer market are also registered as registered nodes ofdNAS.

There are also various security considerations deployedto different system components of dNAS; for instance, pass-word protection was applied to any tag-reading and tag-writing process on NFC tags given this newly supportedfeature on the selected model of NFC tags - NTAG 216Ferrite. Some validation processes, as described in the winerecord validation operation described in [9], also involvesignatures and signing processes. The distributed key vaultservice instance, assigned to every consortium memberalongside its blockchain service instance, is also includedto dNAS as a key management module to store and managekey secrets, such as secrets of Ethereum wallet for spe-cific consortium member. Regarding security considerations

11

applied to the deployed smart contracts, as described inthe working prototype of dNAS detailed in [9], multiple"require" statements are developed and included in differentmethods to prevent potential attacks, such as reapplicationattacks in which the on-chain write count and its coun-terpart off-chain do not match. Design patterns with role-restriction concept of the smart contract, in the form of "mod-ifier", is also introduced, so as to enable access authorizationto different methods of the deployed smart contracts.

6.4 High Availability of System FunctionalitiesEnsuring high-level operational performance of differentsystem components to maintain system functionalities ondifferent wine record operations is key to the system imple-mentation of dNAS. With the focus of system security anddata integrity on wine record now applied to decentralizedsystem components of dNAS, availability of states stored anddecentralized system components, such as the blockchainservice, blockchain nodes and the IPFS nodes, becomes moresignificant to the overall availability of system functionali-ties.

Given the decentralized nature of dNAS, availability andresilience on the data and states, stored on the blockchainnetwork and IPFS network, are assured and even be en-hanced with increasing number of consortium memberswith their assigned nodes running on both blockchain net-work and IPFS network, owing to the fact that each node ofthese networks keeps the copy of the states stored in the per-sistent volume dedicated to the distributed nodes. The avail-ability of the blockchain network would also be enhancedwith more consortium members with their blockchain nodesrunning on the blockchain network in which the availabilitycould be preserved as long as there is at least a blockchainnode running on the network.

The persistent volume storage, assigned to each node in-stance running on the blockchain network of dNAS to storethe blockchain states and the individual chain data, is alsoproved to be contributed to a faster synchronization anddata recovery on states to new blockchain nodes connectedto the network as part of the on-boarding process of theconsortium. It is due to the fact that failed blockchain nodescan now synchronize from where it left instead of synchro-nizing from the start – the first block. This will then assure theavailability of blockchain nodes and the blockchain networkas a whole, as failed blockchain nodes could be reconnectedto synchronize and process transactions sent to the networkimmediately.

The smart contract upgradeability with the proxy patternis demonstrated to enhance the availability of the blockchainservice, for which it does not need to be brought downthe individual blockchain service instances every time asmart contract is upgraded with a new contract address. Theavailability of data stored on-chain will also be preservedwith such pattern adopted to upgrade smart contracts withchanges on the constituent functional methods. Though theoff-chain database and the app-backend service itself are notmade distributed under the chosen hybrid approach, theavailability will further be enhanced with the fully decen-tralized approach under which every consortium memberwill be hosting their own instance of literally every systemcomponent in dNAS.

6.5 Manageable System Integration Model

Regarding the integration between system components oflegacy NAS, such as app-backend service, and decentralizedsystem components including the blockchain network, thesystem architecture proposed for dNAS has made it ratherstraightforward for which the data model of wine recordsoriginally defined in the legacy NAS is updated with newdata fields, such as "transcation_hash" and "blockchain_num-ber" under "transaction_data" according to the sample datamodel of wine record applied to dNAS as listed in Ap-pendix A.1. With the new data model of wine record, theapp-backend service inherited from the legacy NAS canintegrate with decentralized system components of dNASby including decentralized processes in original wine recordoperations via predefined functions of invoking the end-points of blockchain service.

The hybrid approach of system integration model wasapplied to dNAS under which instances dNAS system com-ponents, including the blockchain nodes, IPFS nodes anddistributed key vault service, are hosted by consortium andassigned to individual consortium member with secret keysowned by the consortium member and stored in the keyvault. The hybrid approach has demonstrated to provideanother layer of indirection, allowing consortium membersto safely manage their own keys, the backup of the winerecords in case anything unexpected goes wrong with theblockchain network, IPFS network or any system compo-nents of dNAS, the consortium could still be able to act asa fail-over and manage requests from consortium members.It is understood that not every consortium member wouldpossess the in-house technical capacity to maintain its owninstance of dNAS. Such approach of system integrationmodel is proved to be appropriate to help promote theadoption from different nodes along the supply chain ofwine industry and for different stakeholders of the industryto collaborate for good to help improve the worseningsituation of product counterfeits, with process integrity alsoconserved.

7 LIMITATIONS AND CONCERNS

With dNAS is developed and evaluated with a variety ofsystem tests and analysis, limitations and concerns acrossdifferent system components of dNAS are also identified.

7.1 Degree of Decentralization

Though dNAS is proposed and developed to decentral-ize the legacy NAS using blockchain technology, dNAS isindeed built around enterprise blockchain protocols anda concept of enterprise consortium consisted of registerednodes along the supply chain. Every consortium member isassigned with a blockchain node running on the blockchainnetwork implemented with enterprise blockchain protocolssuch as PoA or IBFT as the chosen consensus algorithm.Due to the fact that dNAS is developed with the proposedhybrid approach, every instance of dNAS with any systemrole alongside their distributed nodes of the blockchain net-work and the IPFS network, are hosted with the enterpriseconsortium maintained and operated by the consortiumadministrator.

12

The decentralized model of dNAS is substantiated withits blockchain network and IPFS network. Implementationswith both networks do provide certain degree of decen-tralization when it comes to transactions being validatedand packed in a block on-chain with the correspondingmethods of the deployed smart contracts invoked as wellas proposing state changes on the consortium registry andthe blockchain network. However, decentralization aroundsmart contract management and deployment, managementof dNAS instances and management of the distributed net-work protocols, is limited as these are solely handled by theconsortium administrator of dNAS.

7.2 Scalability Concerns

Scalability can somehow contradict with decentralization,according to the results of performance testing, for whichdNAS generally takes longer computation time for a sameset of operations performed by the legacy NAS. It is under-standable dNAS is less scalable than the legacy NAS, giventhe advantages of decentralization applied to dNAS withconsensus reached for every state change made to a winerecord. There are concerns and limitations on scalabilityidentified in dNAS.

dNAS provides three layers to store the representationsof a wine record or a full version of the wine record itselfas depicted in Fig. 10. When the number and size of winerecords growing with more wine products circulating inthe supply chain, longer computation time is definitelyexpected for wine record operations with more computationresources spent on the data processing on wine recordsstored in the database app-backend service.

Fig. 10: Data Storage of dNAS

Despite the averaged gas spent of every method and thedeployment of the smart contracts are far lower than theblock gas limit predefined, the averaged gas spent of smartcontracts could still be optimized with lower gas spent.It implies that there are less logical steps needed and somore scalable for a transaction to be executed, validatedand packed in a block with same computation resourcesassigned to the blockchain nodes. Repeated and similardesign pattern should be minimized and reused in the smart

contract development, so as to optimize the averaged gasspent per method.

The blockchain will grow bigger when time goes on withmore transactions validated and packed in a block mined,not to mention a new block will be created every 5 secondsfor the blockchain network, configured and developed indNAS. It could take fairly long period of time for a newblockchain node, assigned to the new consortium member,to synchronize with other blockchain nodes to get to thelatest global states of the blockchain network. The longsynchronization time would hinder the user experience fornew consortium members using dNAS when the size ofblockchain is too bulk. The requests to the app-backendservice and the blockchain service itself are currently han-dled sequentially for which a new request will be processedonly if the previous one is completed or properly handled.The single-threaded handling of these services, involved inany end-to-end wine record operations, would hinder thescalability of dNAS as a whole.

7.3 Potential Security Vulnerabilities

dNAS is believed to have protection deployed over cloningattacks, modifications and reapplication attacks, to winerecords and its NFC tags. There are specific security vulner-abilities also identified across different constituent systemcomponents of dNAS. Every registered node of the enter-prise consortium developed in dNAS, is normally assignedwith blockchain node and an account, such as Ethereumaccount if EVN-based enterprise blockchain protocols areapplied, of which a key pair is handed over to a registerednode for storage and management, with their own instanceof key vault service. Though a security authentication layerhas already been added on top of the key vault servicewhenever the corresponding blockchain service instance,owned by the same registered node, retrieves the key pair.The "Signer", based on the key pair, is instantiated to validateand send transactions with the local blockchain node via achosen blockchain client protocol. The same secret privatekey is also retrieved and signed on the identifiers of wineproducts, devices and NFC tags, whenever there is a state ofthe wine record requires to be transitioned with a signatureproduced, stored on the corresponding NFC tag and on-chain. The same key pair is retrieved and used over andover again without a concept of key rotation, and it ispossible that the key pair could be compromised and hencethe aforementioned attacks could still be made possible to createvulnerabilities and threats to dNAS.

Following the compromised key secrets, distributeddenial-of-service (DDoS) could also be made possible, withthe presence of extremely high gas limit. As long as theblockchain node is hosted with enough computation re-source, it is possible to spam the blockchain network withhuge amount of transactions to be processed. The denial-of-service could also be performed by any malicious registerednode though they are part of the consortium, wine industryand the wider supply chain industry. While for wine recordsubsets, in JSON format, stored on IPFS network with thecontent hash obtained, anyone can interpret and retrievethe wine record subsets if the content hash is supplied. Thewine record subset stored on IPFS is not encrypted because

13

the wine record subset is in all likelihood not sensitiveand only open to consortium members. With their IPFSnodes running on a private network, encryption on winerecord subsets would ensure the security and access ondata itself to be shared to related supply chain participants.The publicity of the smart contract source code could alsocause security vulnerabilities. Unlike the source code ofdifferent system components in the legacy NAS which hasthe option to have its code base open-sourced or completelyprivatised, smart contract code of dNAS is always easilyaccessible by the nodes running on the blockchain network,and so malicious consortium members running blockchainnodes could look for human induced vulnerabilities if anymethod of the deployed smart contracts is not implementedcorrectly.

7.4 Privacy ConcernAs discussed in the potential security vulnerability, the lackof key rotation mechanism in dNAS would also mean thatthe same public address is possible to be mapped to anactual registered node. The system role identifier couldfurther be mapped to the true identity of the representa-tive organization, by other registered nodes who are alsoconsortium members. Although public addresses stored on-chain are already obfuscated with hash functions applied,events will be emitted when methods of the deployed smartcontracts are executed, whenever there are new transactionson wine record operations related to the same public ad-dresses. The events are later received by the event listener ofevery blockchain service instance. With more events emittedwith the same public address, it is more likely a specificpublic address could be mapped to an actual registerednode, and so its transaction volume could still be derivedby other consortium members which could potentially beits competitors.

The proposed data structure of the wine record, asdemonstrated in Appendix A.1, will be shared across the sup-ply chain to nodes that are related to the transfer of specificwine products. It is suggested in dNAS that new entry ofsupply chain data will be added to a wine record wheneverthere is a successful state-transitioned transfer operationperformed with both device data and GPS location data ofthe tag-interacting process in presence. Similarly, these datafields, with privacy details, will also be logged in the winerecord for every unsuccessful validation process. In additionto the public address, these data fields could directly relateto physical entities and cause privacy concern if there isno privacy-preserving technology in place to process thesesensitive data fields. If the corresponding NFC tags are notdeactivated properly when the respective wine products areconsumed, it could possibly lead to a privacy threat basedon any non-encrypted or non-obfuscated data fields of winerecords stored in NFC tags. Privacy-preserving technologiesare required with use cases based on the chosen mechanismto be included in any future upgrade of dNAS regarding theprivacy concerns.

8 FUTURE OPPORTUNITIES OF DNASAccording to the limitations and concerns identified fromthe system analyses and a series of system test activities

against, a variety of future opportunities on strengtheningcapability in supply chain anti-counterfeiting and traceabil-ity are also suggested and elaborated in this chapter.

8.1 Production Readiness of dNASWith distributed instances of decentralized system com-ponents and key management hosted and managed byindividual consortium member, dNAS should be developedinto a production ready state. The on-boarding process willhave to be streamlined so as to integrate with the legacydata pipelines already adopted by the registered nodes inthe industry, especially integrating with their enterpriseresource planning (ERP) systems to enable automation aswell as encouraging user adoption throughout the wineindustry and its related supply chain participants.

Continuous integration and continuous deliverypipeline should also be implemented for deployment effortsto different environment clusters for major releases witha production ready state of dNAS to promote adoptionsamongst major targeted audience or across a specific supplychain network of wine industry. More analysis on metrics,such as energy consumption, memory utilization and costson hosting instances, for every wine record operation,should also be performed so as to determine the optimaltechnical stack for a production version of dNAS.

8.2 Fully Distributed ApproachOwing to the fact that dNAS is developed to decentralize thelegacy NAS and the proposed hybrid approach of systemintegration model was introduced and applied to dNAS.The next logical step would be looking to take the incre-mental effort to fully decentralize the prototype of dNAS, inwhich every registered node which is also the consortiummember, to host their own instance of dNAS as well asthe distributed nodes running on the blockchain networkand the IPFS network. The fully decentralized approach isabout having every consortium member to host their owninstance of dNAS. In other words, consortium members arenow responsible for key management of their blockchainnodes, any system process involved with signatures, and theinteraction between distributed nodes with its designatedblockchain service instance. Such approach would requirein-house technical capacity of the participating consortiummembers, to maintain their own dNAS instance.

With the advent of distributed dNAS architecture inwhich every consortium member hosts their own instance ofevery dNAS system components (registered nodes of wineconsumer role would still have to login so as to use theapplications and services hosted by the consortium as theyare still not part of the consortium), a peer-to-peer controller,such as PeerDiscoveryController, will need to be implementedfor each instance. Different instances of the AppControllercould therefore synchronize with each other on the states ofspecific wine product whenever there are operations, suchas transfer of wine products or sharing of wine record data,performed along the supply chain.

8.3 Adoption of a More Decentralized EnterpriseBlockchain ProtocolThe fully distributed approach could also imply that op-erations of the enterprise consortium could be more de-

14

Fig. 11: The Proposed Fully Decentralized Architecture for dNAS

centralized by having more consortium administrators viaon-chain governance amongst all the consortium members.The consortium will need to maintain the versioning of in-dividual dNAS components so that every distributed dNASinstance is running with the latest versions of system com-ponents. Having such trustful role of consortium adminis-trator completely removed could be an option applied inthis approach. Without the consortium administrator, everymember in the consortium could perform any operationwith their own deployed smart contracts with functional-ities shared with other consortium members in differenttrade groups. It would also imply that every change onthe versioning of system components in dNAS will needto go through another set of on-chain governance processes,such as voting process, across the enterprise consortium toreach consensus on different fronts such as the version ofsmart contracts, version of wine record data model, etc. Theconcept of a fully distributed approach which should beincluded in future work of dNAS, is demonstrated in Fig. 11.

Before progressing dNAS to the production-ready state,the limitations and concerns detailed should be addressed.On-chain governance mechanism should be introduced onelecting the consortium administrators and the number ofconsortium administrators should also be increased to en-hance the degree of decentralization within the consortiumand the system implementation as a whole. Other consen-sus algorithms with a more decentralized way of electingvalidation leaders validating the transactions per validation

group on the blockchain network, could be considered forpossible adoption, such as the "IBFT" applied to ConsensysQuorum.

Though the leader-based consensus algorithm for ablockchain network running with EVM nodes would beroughly 22% less scalable compared to Proof-of-Authorityprotocols, for the case of dNAS as evaluated in the systemanalyses covered in this research. Other mechanisms ofimproving the scalability could also be introduced, suchas having reusable patterns applied to methods of thedeployed smart contract and applying the batched pat-tern operation in the smart contract for which more state-transitioned operations could be included in a transactionand its corresponding block.

8.4 Upgraded Security Features of dNASKey rotation functionalities should be introduced to dNASto improve the security aspect on key secrets and dNAS asa whole. The key rotation and key signing could furtherbe implemented with privacy-preserving technique, suchas the stealth address [16], ring signature scheme [17],multi-signature [18], or zero-knowledge proof [19], for moreadvanced wine record validation concept without a need ofsignature stored in NFC tags, to improve the privacy modelof dNAS. Another layer of network security could be takeninto account; for instance, a virtual private network (VPN)could be implemented on top of every communicationand interaction channel between instances and consortium

15

members in dNAS. A more secured signing process couldbe performed in trusted execution environment, such as IntelSGX for secured computations.

8.5 Digital Asset Development on dNAS

The concept of ownership on digital assets with which anon-chain digital twin is created and coupled with productrecords could be introduced where the notion regardingthe proof of ownership could be in place for every transferoperation took place on dNAS. The digital assets could beachieved with the tokenization of on-chain properties re-lated to specific wine records, which could further facilitatethe concept of on-chain operations related to digital assetscreated with functionalities, such as proof of ownershipand transfer of ownership, enabled. The concept of digitalasset ownership not only strengthens supply chain anti-counterfeiting and traceability of decentralized solutionsimplemented in supply chain industry, but also opens upmore integration opportunities in fields, such as decen-tralized finance (DeFi) and decentralized e-commerce andexchange platform, for different service sectors in supplychain industry.

9 CONCLUSION

It is concluded that dNAS is a solid example demonstratinghow a legacy supply chain anti-counterfeiting and trace-ability system, for wine industry in this case or for thewider supply chain industry, could be decentralized andreengineered from its centralized architecture which wasonce hosted and maintained merely by intermediaries orin this case - the winemakers. dNAS is built with enter-prise blockchain protocols and around an idea of enterpriseconsortium consisted of registered nodes along the supplychain of wine industry, balancing degree of decentralization,scalability, security and privacy aspects of such decentral-ized solution for improved supply chain anti-counterfeitingand traceability, with EVM-based enterprise blockchain pro-tocols, such as PoA and Quorum, chosen appropriatelywith the preferred consensus algorithms, such as PoA andIBFT, of the blockchain network as well as availability ofshared smart contracts with a capability to be upgradedwith versions shared amongst consortium members. Thehybrid approach of system integration model adopted indNAS has also proved to be appropriate to help promotethe adoption from different roles of wine industry, and fordifferent stakeholders of the industry to collaborate for goodto help improve the situation of product counterfeits.

dNAS demonstrated that any state transition on a winerecord along the supply chain could be validated and com-pleted automatically, only if, (1) the involved registerednodes and its distributed nodes, such as blockchain nodesand the IPFS nodes, are cryptographically authenticated,(2) the related wine record and the transactions for specificprocess are cryptographically verified, and (3) the consensusof such state transition is reached with the related transac-tions packed in a mined block, by blockchain nodes ownedby other consortium members. The immutable states oftransactions in different blocks are also available on the

network and able to be accessed via different tools devel-oped in dNAS, such as the blockchain explorer. The capabil-ities demonstrated in wine record verification and productprovenance with dNAS have confirmed to be strengthenedand benefited from a degree of decentralization, underwhich no more single-point failure and control to be foundin dNAS. The resiliency and availability of validated winerecords with the history of transitioned states are also en-hanced with the persistent volume on states of blockchainand transaction, alongside the wine record data stored indNAS.

Though dNAS is found to be less scalable than itscentralized counterparts as we could expect, the advan-tage introduced by the concept of decentralization haveenabled different nodes along the supply chain of wineindustry to work collaboratively with wine records flow-ing downstream seamlessly with state transitions validatedautomatically in a decentralized and immutable fashion.dNAS is proved to be not only a verification service but alsoa notary service, providing a proof of existence for winerecords owned by different supply chain participants. Allsystem requirements defined in dNAS were fulfilled withthe claimed functionalities confirmed with both functionaltesting and performance testing. Further qualitative analysison dNAS as a whole was also performed with limitationsand risks identified so as to support rationale of futureopportunities on further improving different aspects, suchas system security, degree of decentralization and scalabilityof dNAS.

As we set out in the research objective, it is confirmedthat decentralized solutions, including dNAS, of supplychain anti-counterfeiting and traceability, are more effectiveand worth than its centralized counterparts of supply chainindustry to better improve the situation of counterfeitingattacks in wine industry and even in supply chain industryas a whole. With flexibility on the architecture of decentral-ized system components and the suggested data structuredefined in design decisions made during the system designand development steps, the decentralized solutions andoperations proposed in dNAS are indeed industry-agnosticand should be available for any service sectors looking tocombat product counterfeit in a wider supply chain indus-try.

16

REFERENCES

[1] OECD and EUIPO, Trade in Counterfeit and Pirated Goods – MappingThe Economic Impact. OECD Publishing, 2019.

[2] N. C. K. Yiu, “An nfc-enabled anti-counterfeiting system for wineindustry,” arXiv preprint arXiv:1601.06372, 2014.

[3] N. C. K. Yiu, “Toward blockchain-enabled supply chain anti-counterfeiting and traceability,” arXiv preprint arXiv:2102.00459,2020.

[4] 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.

[5] 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 2018 IoT Vertical and Topical Summit onAgriculture-Tuscany (IOT Tuscany), pp. 1–4, IEEE, 2018.

[6] 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.

[7] 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.

[8] 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.

[9] N. C. K. Yiu, “Decentralizing supply chain anti-counterfeitingsystems using blockchain technology,” arXiv preprintarXiv:2102.01456, 2020.

[10] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,”tech. rep., Manubot, 2008.

[11] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis,A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich,et al., “Hyperledger fabric: a distributed operating system forpermissioned blockchains,” in Proceedings of the thirteenth EuroSysconference, pp. 1–15, 2018.

[12] A. Karamchandani, S. K. Srivastava, and R. K. Srivastava,“Perception-based model for analyzing the impact of enterpriseblockchain adoption on scm in the indian service industry,” Inter-national Journal of Information Management, vol. 52, p. 102019, 2020.

[13] I. M. Cavalcante, E. M. Frazzon, F. A. Forcellini, and D. Ivanov, “Asupervised machine learning approach to data-driven simulationof resilient supplier selection in digital manufacturing,” Interna-tional Journal of Information Management, vol. 49, pp. 86–97, 2019.

[14] J. Kwon, “Tendermint: Consensus without mining,” Draft v. 0.6,fall, vol. 1, no. 11, 2014.

[15] E. Buchman, Tendermint: Byzantine fault tolerance in the age ofblockchains. PhD thesis, 2016.

[16] N. T. Courtois and R. Mercer, “Stealth address and key man-agement techniques in blockchain systems.,” ICISSP, vol. 2017,pp. 559–566, 2017.

[17] S. Noether, “Ring signature confidential transactions for monero.,”IACR Cryptol. ePrint Arch., vol. 2015, p. 1098, 2015.

[18] L. Harn, “Group-oriented (t, n) threshold digital signature schemeand digital multisignature,” IEE Proceedings-Computers and DigitalTechniques, vol. 141, no. 5, pp. 307–313, 1994.

[19] C. Rackoff and D. R. Simon, “Non-interactive zero-knowledgeproof of knowledge and chosen ciphertext attack,” in AnnualInternational Cryptology Conference, pp. 433–444, Springer, 1991.

[20] G. Wood et al., “Ethereum: A secure decentralised generalisedtransaction ledger,” Ethereum project yellow paper, vol. 151, no. 2014,pp. 1–32, 2014.

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 advisory

board 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.

17

APPENDIX ADATA MODEL DEFINITION OF DNASA.1 Sample Data Model of Wine RecordThe Sample Data Model of Wine Record defined in dNAS isdemonstrated in Fig. 12.

A.2 Sample Data Components of Wine Record SubsetStored On IPFSThe Sample Data Components of Wine Record Subset StoredOn IPFS defined in dNAS is demonstrated in Fig. 13.

A.3 Data Model Definition of dNASWith only minimal changes applied to the data model ofwine record, defined in the legacy NAS, data categoriessuch as wine status, supply chain data, transaction dataand unsuccessful validation data were updated with moredata fields so as to integrate with the decentralized aspectsof dNAS alongside strengthened anti-counterfeiting mecha-nism enabled.

The sample of the proposed data model of wine recordsapplied to dNAS is demonstrated in Appendix A.1. Forinstance, a wine product with "c11d44f4-3024-4fe6-a237-d236720867dc" as "wine_id" has gone through supply chainprocesses including the first step – production of the wineproduct which in turn with a wine record created, withindividual "supply_chain_id" and "scan_device_id" of a regis-tered node. In order to have the latest "wine_status", both"supply_chain_data" and "transaction_data" are needed to beupdated with data fields such as "transaction_hash" and"block_number" of validated transactions for specific supplychain operations. As every supply chain operation shouldinvolve the operations on NFC tags packaged with individ-ual wine products, data fields such as "tag_id", "tag_read_-count" and "timestamp" are logged under "supply_chain_data".The "wine_status" captures every latest data field, such as"latest_supply_chain_id" signalling which supply chain nodethe wine product is physically located at currently, "latest_-tag_id" as the NFC tag identifier could be updated onlyby winemakers if necessary, after returns of related wineproducts, and "tag_read_count" showing number of times aspecific NFC tag has been read throughout every operationprocess performed.

There is also another subset in the proposed schemaof wine records, which is critical to dNAS, namely "unsuc-cessful_validation_data" of which any unsuccessful validationoperation when scanning the NFC tag at different nodesalong the supply chain would be logged, with a "rejection_id"in UUID and a reason of rejection given. It will also give in-formation such as where and when a specific operation wascarried out, which supply chain participant using which ofits device to perform such scanning and validating activities,and which NFC tag of a given wine product was attemptedto scan.

The "wine_pedigree_data" gives product details about aspecific wine product. Only registered nodes of winemakerrole could make changes to the "wine_pedigree_data" and"project" using the database operation web-app as men-tioned in the use case analysis. All data fields under "sup-ply_chain_data", "transaction_data" and "unsuccessful_valida-tion_data" could only be updated whenever tag-writing or

tag-reading operations are performed on NFC tags alongthe supply chain via the NFC-enabled ScanWINE mobileapplication and so there is no direct CRUD operation onthese data fields at any point of an operation performed inany system component of dNAS.

A.4 Calculation of Gas and Total Cost on the SampleFull Version of Wine RecordA "word" in any EVM-based protocol, such as Ethereummain net, is 32 bytes, implying that so as to store 2,900 bytesit would mean storing roughly 91 words’ worth of data.Assuming all these words were set to non-zero from zero,and according to the Ethereum yellow paper as explainedin [20]:

• Gsset 20000 Paid for an SSTORE operation when thestorage value is set to non-zero from zero.

• Gsreset 5000 Paid for an SSTORE operation when thestorage value’s zeroness remains unchanged.

This would suggest calling for an SSTORE operation 91times, at 20,000 gas each (the cost to allocate and store anon-zero value). The total gas used to store 2900-byte size ofdata would be:

total_gas_used = Gsset ∗ number_of_32− byte_word

= 20, 000 ∗ 91

= 1, 820, 000

Each transaction involved a full wine record processedon-chain would mean a whopping amount of 1,820,000gas used and the cost per transaction, according to theaverage gas price listed on the Ethereum gas station(https://ethgasstation.info/), which is currently at 60 Gwei,every transaction involved the whole wine record couldcost:

total_cost = total_gas_used ∗ average_gas_price

= 1820000 ∗ 60/109

= 0.1092ETH

= $133.55(ETH_price = $1, 223))

It would cost a whopping $133.55 to only process asample wine record on-chain and about 333 seconds and34 blocks for a transaction to be confirmed, on the main netof Ethereum.

18

Fig. 12: Sample Data Model of Wine Record

Fig. 13: Sample Data Components of Wine Record Subset StoredOn IPFS