Trusted Traceability Service: A Novel Approach to Securing Supply Chains

Abstract

Counterfeit products cause financial losses for both the manufacturer and the enduser; e.g., fake foods and medicines pose significant risks to the public’s health. Moreover, it is challenging to ensure trust in a product’s supply chain, preventing counterfeit goods from being distributed throughout the network. However, fake product detection methods are expensive and need to be more scalable, whereas a unified traceability system for packaged products is not available. Therefore, this research proposes a product traceability system, named Trusted Traceability Service (TTS), using Blockchain and Self-Sovereign Identity (SSI). The TTS can be incorporated across diverse industries because of its generic and manageable four-layer product packaging strategy. Blockchain-enabled SSI empowers distributed nodes, to verify them without a centralized client–server authorization architecture. Moreover, due to its distributed nature, the proposed TTS framework is scalable and robust, with the use of web3.0 distributed application development. The adoption of Fantom, a public blockchain infrastructure, allows the proposed system to handle thousands of successful transactions more cost-effectively than the Ethereum network. The deployment of the proposed framework in both public and private blockchain networks demonstrated its superiority in execution time and number of successful transactions.

1. Introduction

A supply chain is a complex network of organizations, activities, resources, and technologies that work together to produce, distribute, and deliver goods or services to end consumers [1]. It includes various stages, such as sourcing raw materials, manufacturing, transportation, storage, and retail. Effective supply chain management is critical for businesses, to ensure timely product delivery, reduce costs, and satisfy customer demands. However, the supply chain faces several challenges, including the risk of fake products entering the system. Counterfeit goods can infiltrate the supply chain through various channels, including unauthorized suppliers, gray markets, or illegal manufacturing processes [2]. These counterfeit items are deliberately made to resemble genuine products, misleading consumers and violating intellectual property rights [3]. The existence of counterfeit products in the supply chain damages consumer trust, harms brand reputation, and leads to financial losses for legitimate businesses.

The World Health Organization (WHO) highlights that in low- and middle-income countries, approximately one in ten medicines fail to meet quality standards or are counterfeit [4]. Similarly, Homeland Security stresses the negative impact that counterfeit products have on public safety [5]. Additionally, the semiconductor industry association estimates that counterfeit semiconductors cost US-based semiconductor companies over USD 7.5 million annually [6]. These losses are not confined to the semiconductor sector alone; the retail industry experienced global sales losses of nearly EUR 46.6 billion in 2020 due to counterfeit products, according to Statista [7]. Furthermore, a report from the Organization for Economic Co-operation and Development (OECD) indicated that the trade value of counterfeit goods surpassed USD 509 billion in 2016 and continues to grow [8]. These data underscore the significant risks posed by counterfeit goods in the supply chain, threatening the global economy. Consequently, there is an urgent need for a secure and transparent supply chain traceability system to maintain consumer trust and foster economic growth.

Earlier research on supply chain traceability has explored various sectors, including medicine, food, and more, utilizing technologies such as Blockchain, the Internet of Things (IoT), Quick Response (QR) codes, Radio Frequency Identification (RFID), and Near-Field Communication (NFC) [9,10,11,12,13]. However, these systems fail to incorporate essential authentication measures between supply chain entities. Such authentication is vital to ensure that end users can verify the legitimacy of the product’s manufacturer by tracing its journey from the retailer back to the manufacturer. Additionally, existing traceability systems are often tailored to specific industries, neglecting the need for a more integrated, cross-industry approach. This gap is particularly noticeable in the case of packaged products. Moreover, these systems generally lack comprehensive efficiency and security assessments.

This study introduces the Trusted Traceability Service (TTS), a secure, counterfeit-resistant supply chain framework built on blockchain-integrated Self-Sovereign Identity (SSI) to address the aforementioned problems. The proposed TTS framework effectively resolves the identified problems by enabling the verification of the identity and authenticity of all entities in the supply chain and their corresponding identity issuers. The TTS is designed to be scalable and more cost-effective compared to other smart-contract-enabled public blockchains. The underlying blockchain infrastructure for TTS is Fantom, which offers scalability and lower costs than other similar blockchains [14]. Fantom uses the Lachesis consensus mechanism, which is based on asynchronous Byzantine fault tolerance (aBFT)  [15], ensuring that all transactions are stored on the blockchain in a distributed and asynchronous manner. As a result, TTS avoids the scalability issues associated with the Ethereum network. Additionally, this study analyzes the system’s efficiency, security, and privacy concerns.

Consequently, the study investigates whether an SSI-based model can deliver reliable and decentralized traceability in supply chains and whether Fantom can outperform existing blockchain platforms in performance and cost. The key contributions of this paper are outlined below:

• Establishing a unified supply chain traceability mechanism for packaged products.
• Incorporating SSI for authentication between the involved supply chain entities in a blockchain-based decentralized environment.
• Analyzing the potential of the Fantom blockchain by comparing it with other smart-contract-based blockchain platforms.

2. Related Work

A trusted traceability service can identify, monitor, and track a product through the entire supply chain, from its manufacturing to its distribution. Product traceability is a challenge faced by nearly every industry. Numerous researchers have investigated product traceability in recent years, contributing valuable insights and advancements. This section provides a brief overview of their contributions, while also discussing the limitations and shortcomings of these efforts.

A literature review on supply chain risk management by Fan and Stevenson (2018) [16] revealed that 85% of the studies focused on work within a single country, while 52% of papers concentrated on a single industry or related industries. Additionally, 77% of the studies examined took the buyer’s perspective, with only five manuscripts considering the seller’s perspective. Furthermore, only 1% of the reviewed papers employed a mixed methodology, and just seven articles used secondary data. The review suggested that further empirical research is needed to explore the complex interrelationships within supply chains and how risk mitigation strategies can eliminate or create risks further upstream or downstream in supply chains and their partner networks.

A separate study by Eyaa et al. (2014) [17] noted that risk management involves mitigating identified risks and actively determining internal and external risk measures. However, opportunism has been highlighted in the supply chain literature, as situations where firms act in their own self-interest, potentially creating additional risks. Opportunism can manifest in various forms, such as product opportunism (misrepresentation of delivery capabilities, warranties, and product quality), information opportunism (deceptive communication to improve a firm’s image), financial opportunism (delayed payments or distorted prices for personal benefit), and governance opportunism (coercion and manipulation).

Nayyer et al. (2019) [18] further highlighted the risks of opportunism, particularly in the context of unqualified treatments and medicines, such as those found in the anti-malarial drug market. Their study in eight African countries, involving over 200,000 public and private sector outlets, found that only 24% of products were quality-controlled therapies. Patients’ exposure to substandard products can increase antimicrobial treatment resistance. Moreover, weaknesses in COVID-19 treatment policies, driven by individual national demands, have led to opportunities for abuse in the supply chains of essential medicines and equipment. For instance, 96% of overseas purchases of prescription Xanax were identified as counterfeit.

Various researchers have employed different technologies such as centralized databases, 2D barcodes, smartphones, NFC, IoT, QR codes, and RFID to facilitate product tracking [19,20,21,22]. However, a significant limitation of these approaches is their centralized structure, which relies on conventional databases. This centralized design makes them susceptible to data manipulation, as unauthorized modifications can go unnoticed, leading to incorrect information being entered into the system. Moreover, traditional tracking systems typically only enable product traceability at the consumer level, preventing other entities in the supply chain from detecting where counterfeit products might be circulating.

Investigators have increasingly turned to blockchain technology to overcome the traceability challenges of centralized systems. Blockchain is being explored for its decentralized, distributed, secure, transparent, and immutable properties, making it well suited for enhancing supply chain traceability [23,24,25]. For example, Madumidha et al. [26] proposed a theoretical framework for end-to-end traceability in agricultural food supply chains using blockchain and RFID tags. Similarly, Aniellio et al. [27] introduced a product tracking system incorporating blockchain and physically unclonable functions (PUF) to uniquely identify each product. Through the challenge–response mechanism of PUF, end users can verify the authenticity of a product. If the manufacturer is dishonest, the anti-counterfeiting measures will fail. Akhtar et al. [28] also suggested a medical supply chain traceability and counterfeit detection system, where each product is assigned a unique QR code that can be scanned to record traceability data.

To alleviate the blockchain load and address concerns related to confidential security, several researchers have designed innovative data storage models [29,30]. Sabah et al. [31] proposed a blockchain-based approach to detect counterfeit drugs in the pharmaceutical supply chain. Additionally, some investigators [32,33,34] have integrated the Interplanetary File System (IPFS) with blockchain to enable traceability in agricultural supply chains. Bumblauskas et al. [35] utilized IoT and blockchain technologies to track products in real time from the farm to the table. Coco et al. [36] introduced a model based on IPFS, RFID, and blockchain to ensure secure, visible, and auditable traceability in the Italian food product supply chain, allowing each supply chain entity to verify a product’s quality.

Hasan et al. [37] proposed a solution combining blockchain, IoT, and lightweight asymmetric cryptography (such as Elliptic Curve Cryptography) to protect supply chain transaction data from privacy breaches and ensure product traceability. Cocco et al. [38] presented a Self-Sovereign Identity (SSI), Blockchain, and IPFS-based approach for food supply chains to guarantee product quality. In contrast, Ehsan et al. [39], Rahman et al. [40], and Chatterjee et al. [41] suggested a blockchain-based agricultural product supply chain to ensure the integrity and transparency of the system.

Table 1. An overview of existing research on product traceability.

Study	Technologies				Analysis			Security Properties
	SSI	IPFS	Light Weight Blockchain	IoT	Scalability	Efficiency	Security	${\mathcal{S}}_{\mathbf{1}}$	${\mathcal{S}}_{\mathbf{2}}$	${\mathcal{S}}_{\mathbf{3}}$	${\mathcal{S}}_{\mathbf{4}}$	${\mathcal{S}}_{\mathbf{5}}$	${\mathcal{S}}_{\mathbf{6}}$
[19]	-	-	-	-	-	-	-	-	-	✓	-	-	✓
[21]	-	-	-	-	-	-	-	-	-	✓	-	-	✓
[22]	-	-	-	-	-	-	-	-	-	✓	-	-	✓
[13,26]	-	-	-	✓	-	-	-	-	-	✓	-	-	✓
[27]	-	-	-	-	-	-	-	-	-	✓	-	-	✓
[32]	-	✓	-	-	-	-	-	-	-	✓	-	-	✓
[24]	-	-	-	✓	-	-	-	-	-	✓	-	-	✓
[10,12,20]	-	-	-	-	-	-	-	-	-	✓	-	-	✓
[23,30,35]	-	-	-	-	-	-	-	-	-	✓	-	-	✓
[9,25]	-	-	-	-	-	-	-	-	-	✓	-	-	✓
[29]	-	-	-	✓	✓	-	-	-	-	✓	-	-	✓
[33,34,36]	-	✓	-	-	-	-	-	-	-	✓	-	-	✓
[38]	✓	-	-	-	-	-	-	✓	✓	✓	-	-	✓
[31]	-	-	✓	✓	✓	-	-	-	-	✓	-	-	✓
[37]	-	-	✓	✓	✓	✓	✓	-	✓	✓	✓	-	-
[39,40]	-	-	-	-	-	-	-	-	-	✓	-	-	✓
[41]	-	-	-	-	-	-	-	-	-	✓	-	-	✓
This study	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓

Here, ${\mathcal{S}}_{\mathbf{1}}$: authenticity of identity issuer and holder; ${\mathcal{S}}_{\mathbf{2}}$: authenticity of interaction; ${\mathcal{S}}_{\mathbf{3}}$: availability; ${\mathcal{S}}_{\mathbf{4}}$: confidentiality; ${\mathcal{S}}_{\mathbf{5}}$: data integrity; ${\mathcal{S}}_{\mathbf{6}}$: traceability; ✓ : “supports or secure”; -: “unsupported or insecure”.

provides an overview of the latest techniques for product traceability, summarizing the associated research studies. These techniques mainly leverage blockchain, IoT, databases, and IPFS to enable traceability within supply chains. However, none of these studies could identify the specific entities involved in the supply chain nor provide details on the scanning process within their proposed systems. Additionally, their systems are vulnerable to attacks, where an adversary could replicate the QR code. In contrast, the proposed framework addresses all these limitations by incorporating a fully decentralized authentication mechanism for the entities involved in the supply chain, ensuring enhanced traceability and security.

Self-Sovereign Identity (SSI) was chosen for its ability to enable decentralized, user-controlled identity verification, which is crucial for trust and traceability across distributed supply chain actors. Unlike centralized models, SSI allows entities to issue and verify credentials without relying on a central authority. Its relevance to cross-border and multi-party systems is supported by the European Blockchain Services Infrastructure (EBSI) [42] and recent research advocating its use in supply chain ecosystems [43].

3. Preliminaries

This section describes the technologies related to the proposed framework, such as blockchain, self-sovereign identity (SSI), and others. The notations used in this paper for describing the proposed system are given in

Table 2. Notations.

Notation	Description	Notation	Description
$GA$	governance authority	$DS$	distributor
$MF$	manufacturer	$RT$	retailer
$PK$	public key	$SK$	private key
$EU$	end-user	$LG$	local government
$hash$	hash function	$VC$	verifiable credential

.

3.1. Fantom Blockchain and Consensus Protocol

Fantom is a high-performance, scalable, and secure blockchain platform that aims to provide a decentralized infrastructure for next-generation applications [44]. The platform is also designed to be fully compatible with existing smart contract platforms like Ethereum, making it easy for developers to build and deploy decentralized applications. It uses a unique consensus mechanism called "Lachesis" that allows for fast and efficient confirmation of transactions. The Lachesis protocol employs a Directed Acyclic Graph (DAG) algorithm to provide realistic Byzantine fault tolerance. DAG is the reason why the Fantom Blockchain achieves its speed [45].

3.2. Self Sovereign Identity

Self-sovereign identity (SSI) is a framework that empowers individuals or organizations with full control over their digital identities and personal information, allowing them to manage their accounts independently. SSI comprises seven key components [46]. They are described below:

• Verifiable credentials are digital documents that contain claims or assertions about an individual’s identity, attributes, or other relevant information.
• The trust triangle is a concept used in the context of SSI systems to establish trust between different entities involved in identity verification and authentication processes. The triangle comprises three key components: the issuer, the holder, and the verifier. Figure 1 shows an overview of the trust triangle.
• Digital wallets, also known as e-wallets or mobile wallets, are software applications or platforms that allow individuals to store, manage, and use their financial assets and payment information digitally.
• Digital agents, also known as autonomous agents or intelligent agents, are software programs or systems that are designed to perform tasks or make decisions on behalf of individuals or organizations.
• Decentralized identifiers $DID$s are unique identifiers that are globally unique and resolvable across different networks and platforms. They serve as the foundation for establishing and managing decentralized digital identities.
• Blockchains are shared databases protected by cryptography. They can provide a reliable foundation for public keys and $DID$s. They are not vulnerable to attack or having a single point of failure.
• Governance frameworks are issued by governance authorities. They provide a set of rules, principles, and mechanisms that govern an SSI ecosystem’s operation, management, and decision-making processes.

3.3. Decentralized Key Management System (DKMS)

The decentralized key management system (DKMS) is a cryptographic approach that enables the use of verifiable credentials in a decentralized manner. Unlike traditional Public Key Infrastructure (PKI) systems that rely on centralized authorities, the DKMS utilizes a new identity concept called Decentralized Identifiers, $DID$ [46]. A $DID$ is generated cryptographically and stored on a distributed ledger, eliminating the risk of a single point of failure. It consists of three components: the $DID$ URI scheme identifier, the $DID$ method identifier, and the $DID$ method-specific identifier. Figure 2 shows an example of a $DID$.

3.4. Database Clustering

A database cluster consists of multiple interconnected computer nodes, each running a database server, working together as a single database, such as an IPFS [47]. It addresses the limitations of a single server by enabling distributed and parallel query execution. The cluster provides advantages such as data redundancy, scalability, high availability, and automation. All servers store the same data, ensuring redundancy and availability. Load balancing enables scalability, while regulations and automation streamline processes and reduce manual effort.

4. System Model

4.1. System Overview

This study proposes a Trusted Traceability Service architecture for supply chains. This is a blockchain-based product traceability system that proves a product’s authenticity by providing the supply chain’s traceability information. Entities involved in this proposed system are the Governance Authority ($GA$), Local Government ($LG$), Manufacturer ($MF$), Distributor ($DS$), Retailer ($RT$), and End User ($EU$). The roles of the participants are as follows.

• Governance Authority $GA$: Provide verifiable credentials ($VC$) to Manufacturer $MF$ and Local Government ($LG$). $GA$ is the root of trust.
• Local Government $LG$: Provide a trade license as a verifiable credential $VC$ to Distributor $DS$ and Retailer $RT$.
• Manufacturer $MF$: Provide verifiable credentials $VC$ to Distributor $DS$ after verification and sell product pallets to the $DS$.
• Distributor $DS$: Provide verifiable credentials $VC$ to Retailer $RT$ after verification. Purchase pallets from the $MF$ and sell cases to the $RT$.
• Retailer $RT$: Purchase cases from the D and sell unit products to the End User $EU$
• End User $EU$: Purchase the unit product from the Retailer $RT$ after checking its authenticity.

In TTS’s, the Governance Authority $GA$ is the root of all trust. The $GA$ provides verifiable credentials $VC$ to the Manufacturer $MF$ and Local Government $LG$. The $LG$ delivers $VC$ to the Distributor $DS$ and Retailer $RT$ upon satisfying the verification process. Now, the $DS$ needs to show proof of the $VC$ issued by the $LG$ to the $MF$ in order to buy the product pallet from $MF$. Similarly, the $MF$ verifies itself to the $DS$ by sending the proof of $VC$ issued by the $GA$. The $MF$ provides the $VC$ to the $DS$ after a successful verification and interactions. Similarly, the $RT$ buys cases from the $DS$ and receives a $VC$. Here, the $RT$ also asks for proof of the $VC$, which has been issued by the $MF$ to the $DS$. The governance framework and trust triangle are shown in Figure 3. All $DID$s and public keys ($PK$) are stored in the blockchain. This process is discussed in detail in Section 5.

In the proposed system, the $MF$ produces the product pallets based on four levels of packaging. They are Primary packaging (Unit Product U), Secondary packaging (Box B), Tertiary packaging (Case C), and Pallet (P). Figure 4 shows the four-level packaging of medicines. The primary packaging represents the unit product. The box is called secondary packaging. Tertiary packaging represents the Case. Combinations of many cases are termed a Pallet. At first, the $MF$ sells pallets to the $DS$. Now, the $DS$ sells cases to the $RT$. Lastly, the $EU$ buys unit products from the $RT$. Each packaging level has a unique QR code attached to it. The content of the QR codes is stored off-chain. In this system, off-chain represents a clustered database or an IPFS instead of a single server database. The reason for using an IPFS is to eliminate centralized databases and the possibility of a single point of failure.

At each step of the supply chain, QR codes are scanned and the identity of the seller is verified. The verification of the participants is based on SSI using a $DID$, the $DID$ document, and verifiable credentials. When the $MF$ sells pallets to the $DS$ or the $DS$ sells cases to the $RT$, a new block is added each time with the transaction details in IPFS. The hash of the transactions is added to the blockchain. In both cases, the DID related to the product QR code is used, so that anybody can check the transactions related to that specific product. Moreover, the $EU$ can verify the $MF$ by scanning the QR code before purchasing the unit product and observing all traceability information and product details. This process is discussed in detail in Section 5. Figure 5 shows a simple overview of the product traceability mechanism.

4.2. Threat Model

In the TTS, all parties are semi-honest adversaries (A) and do not trust each other, except for the Global Authority ($GA$). These adversaries follow the protocol honestly but also want to access the private data of other participants. These adversaries act as middlemen or eavesdroppers and may dominate the shared channels. They might also initiate identity fraud attacks, passive attacks, or active attacks.

4.3. Security Goals

The TTS satisfies the following supply chain protection conditions. The Global Authority ($GA$) is trusted by all parties. Any adversary A, whether an insider, outsider, or middleman within the TTS, will fail to infer any private or sensitive data after initiating attacks such as identity fraud, impersonation, forwarding secrecy attacks, or replay attacks. Furthermore, adversaries A cannot succeed in launching either passive or active attacks.

5. Model Construction

This section explains the detailed model construction and security analysis of the TTS.

5.1. Establishing SSI for TTS

All participants in the system aim to establish secure connections with each other based on Self-Sovereign Identity ($SSI$). This section demonstrates the $SSI$-based connection between the Manufacturer ($MF$) and the Distributor ($DS$). The process outlined here applies universally to all entities. Both the $MF$ and $DS$ have $SSI$ mobile wallet applications, and their respective edge agent ($EA$) software sets up their cloud agents ($CA$). The $EA$ functions are performed on local devices at the network’s edge, where they are managed by the identity holder, while the $CA$ operates at the cloud edge, hosted by any cloud service provider or platform.

The $MF$ holds a verifiable credential ($V{C}_{MF}$) issued by the Governance Authority ($GA$), and the $DS$ holds a $V{C}_{DS}$ issued by the Local Government ($LG$). Both the $MF$ and $LG$ possess a $VC$ issued by the $GA$. All of these protocols are defined and managed by the $GA$, which publishes the governance framework that all participants adhere to. The $GA$ is considered a trusted entity by all participants in the system.

In this scenario, the $MF$ intends to sell its product, a Pallet, to the $DS$. To facilitate this transaction, the $MF$ and $DS$ verify each other’s identity and establish a secure connection, as they have no prior trust relationships. The $MF$ only accepts the $VC$ (identity credentials) issued by the $LG$ for verifying the $DS$, while the $MF$ authenticates itself to the $DS$ using the $VC$ issued by the $GA$. Additionally, the $LG$ is automatically authenticated, as its $VC$ is issued by the $GA$. The entire authentication process is outlined below and visually represented in Figure 6.

Initially, the edge agent ($E{A}_{MF}$) of the Manufacturer ($MF$) instructs the wallet to generate a new public/private key pair, denoted as $P{K}_{MF}$ and $S{K}_{MF}$, as well as a peer identifier ($DI{D}_{MF}$) derived from the key pair. The $DID$ serves as a unique pseudonymous label that establishes the $MF$’s relationship with the Distributor ($DS$) in a private, peer-to-peer manner. The $MF$ stores the $DI{D}_{MF}$, $P{K}_{MF}$, and $S{K}_{MF}$ in the wallet.

$MF$ scans a Quick Response ($QR$) code to verify its credentials. This requests proof of the verifiable credential ($VC$) from the Governance Authority ($GA$).

The $E{A}_{MF}$ seeks authorization from the $MF$ to create the proof. Once the $MF$ has consented, the $E{A}_{MF}$ creates the proof ($P{R}_{MF}$).

Next, the $E{A}_{MF}$ assembles a message ($M_1$), which contains the $MF$’s private service endpoint ($L_{C{A}_{MF}}$), $P{K}_{MF}$, $P{R}_{MF}$, and $DI{D}_{MF}$. The $E{A}_{MF}$ then generates a $QR$ code from the message $M_1$, and computes a hash value $H_1\leftarrow h\left(M_1\right)$. The blockchain records both the $DI{D}_{MF}$ and $H_1$.

Following this, the $E{A}_{MF}$ sends the $QR$ code to the $MF$’s cloud agent ($C{A}_{MF}$), instructing it to prepare for handling messages related to $P{K}_{MF}$. The $C{A}_{MF}$ subsequently transmits the $QR$ code to the $DS$ as part of the connection and verification request. These requests are sent over unsecured channels, and since the data in the $QR$ code are not sensitive, they do not demand strict security measures.

The Distributor ($DS$), intending to purchase Pallets from the Manufacturer ($MF$), scans the $QR$ code. Using its mobile/edge wallet software ($E{A}_{DS}$), it receives the message $M_1^{\prime }$. The $E{A}_{DS}$ retrieves $H_1$, $DI{D}_{GA}$, and $P{K}_{GA}$ from the blockchain. It then generates $H_1^{\prime }\leftarrow h\left(M_1^{\prime }\right)$ and compares $H_1^{\prime }$ with $H_1$. If they match, $E{A}_{DS}$ extracts $L_{C{A}_{MF}}$, $P{K}_{MF}$, $P{R}_{MF}$, and $DI{D}_{MF}$ from $M_1^{\prime }$ and stores them. The $E{A}_{DS}$ verifies the proof $P{R}_{MF}$ using $DI{D}_{GA}$ and $P{K}_{GA}$. The proof verification follows the Non-Interactive Zero-Knowledge Proof.

Next, the $E{A}_{DS}$ triggers the wallet to create a new key pair, $P{K}_{DS}$ and $S{K}_{DS}$, along with a peer identifier $DI{D}_{DS}$ derived from them, storing all elements in the wallet. To obtain proof of its verifiable credential, the $DS$ scans a $QR$ code linked to the Local Government ($LG$). Before generating the proof, the $E{A}_{DS}$ requests consent from $DS$. Once permission is granted, $E{A}_{DS}$ produces the proof $P{R}_{DS}$.

Subsequently, the $E{A}_{DS}$ assembles the message $M_2$, which includes the $DS$’s private service endpoint ($L_{C{A}_{DS}}$), $P{K}_{DS}$, $P{R}_{DS}$, and $DI{D}_{DS}$. The $E{A}_{DS}$ generates $H_2\leftarrow h\left(M_2\right)$ and encrypts the message $M_2$ using $P{K}_{MF}$, producing $\left[\left[M_2\right]\right]\leftarrow enc(M_2,P{K}_{MF})$. The blockchain stores both $DI{D}_{DS}$ and $H_2$. The $E{A}_{DS}$ forwards the encrypted message $\left[\left[M_2\right]\right]$ to the $DS$’s cloud agent ($C{A}_{DS}$), which then sends the encrypted message to the $L_{C{A}_{MF}}$.

The Manufacturer’s cloud agent ($C{A}_{MF}$) obtains the encrypted message and transmits it to the edge agent ($E{A}_{MF}$) of the $MF$. The $E{A}_{MF}$ decrypts the message using $S{K}_{MF}$ and constructs $M_2^{\prime }$. It retrieves $H_2$, $DI{D}_{LG}$, and $P{K}_{LG}$ from the blockchain. The $E{A}_{MF}$ generates $H_2^{\prime }\leftarrow h\left(M_2^{\prime }\right)$ and compares $H_2^{\prime }$ with $H_2$. If they match, the $E{A}_{MF}$ extracts $L_{C{A}_{DS}}$, $P{K}_{DS}$, $P{R}_{DS}$, and $DI{D}_{DS}$ from $M_2^{\prime }$ and stores them. The $E{A}_{MF}$ then verifies the proof $P{R}_{DS}$ using $DI{D}_{LG}$ and $P{K}_{LG}$.

The proof verification follows the zero-knowledge proof (ZKP) algorithm. Once verified, both $E{A}_{MF}$ and $E{A}_{DS}$ notify the $MF$ and $DS$ that a secure, cryptographic communication channel has been established between them, ensuring privacy. A key advantage for the $MF$ is that the $E{A}_{MF}$ can refresh its keys and service endpoint as needed. As a result, the $MF$ can access messages through its updated service endpoint or the new public key shared by $DS$. This ensures that insecure connection details are replaced with secure, eavesdropper-resistant information.

After the connection is successfully verified, the $MF$ issues a verifiable credential ($VC$) to the $DS$, officially recognizing the $DS$ as an authorized distributor for the $MF$. Similarly, the $DS$ will proceed to verify, connect, and issue a $VC$ to the Retailer ($RT$).

5.2. Establishing TTS

This section provides a detailed explanation of the traceability process from the Manufacturer ($MF$) to the End User ($EU$). The system introduced primarily manages two types of registries: verification registries and sell registries. The verification registry stores the decentralized identifiers ($DID$) of the $MF$, $DS$, and $RT$, whereas the sell registry stores the product IDs, the $DID$s of both the seller and the buyer, along with a timestamp that records the time of the sale.

During the production phase, the $MF$ generates a distinct QR code for each pallet, case inside the pallet, box inside the case, and individual product inside the box. The generation process is based on the number of pallets ($n_P$), cases ($n_C$) within each pallet, boxes ($n_B$) inside each case, the number of units ($n_U$) inside each box, and the unit product details ($UD$). The QR code generation process is outlined in Algorithm 1. Here, h represents a hash function. The QR codes include the IDs for the pallet, case, box, and unit product, respectively.

These IDs are stored off-chain in four separate relational tables, which enable the identification of unit product IDs based on the IDs of the boxes, cases, and pallets. The unit product details ($UD$) are stored off-chain and are linked to the pallet ID ($i{d}_P$).

$MF$ sells the pallets to the $DS$. $MF$ first selects the sell option, scans the Pallet QR code $Q{R}_P$, and selects the appropriate $DS$. This scanning process indicates that the pallet has been issued by the $MF$ to the $DS$. Algorithm 2 shows the pallet selling process. After the scanning of the $Q{R}_P$ by the $MF$, the system retrieves the $V{C}_{MF}$ and its issuer $DID$. As the seller claims to be a $MF$, the system compares the retrieved $DID$ with the $DI{D}_{GA}$. If it matches, then the $P{K}_{GA}$ is retrieved from the blockchain. The $V{C}_{MF}$ is verified using the $P{K}_{GA}$. After successful verification of the $V{C}_{MF}$, the $i{d}_P$, $DI{D}_{MF}$, $DI{D}_{DS}$, and the current timestamp $ts$ are stored in the sell registry. In addition, the $DI{D}_{MF}$ is checked against all unit products of the pallet in the verified registry. Note that, Algorithm 2 is applicable for all buying and selling transactions. In the case of the $DS$ and $RT$, only the issuing of the $VC$ will change.

Algorithm 1: QR code generation by $MF$

Algorithm 2: Pallet issuing by $MF$

After receiving the Pallet, the $DS$ selects the verify option and scans the $Q{R}_P$. Algorithm 3 depicts the verification process of pallets by the $DS$. Note that this verification process is the same for both the $DS$ and $RT$. After scanning to see if the $Q{R}_P$ is found in the seller_registry, the seller and buyer $DID$s are retrieved, which are $DI{D}_{MF}$ and $DI{D}_{DS}$. The entry in the seller_registry ensures that the product has been issued from the verified $MF$. From the $DID$s, the name of the $MF$ and $DS$ are returned. By this process, the $DS$ is reassured that the pallet has been issued correctly.

Algorithm 3: Pallet issuing verification by $DS$

The product authentication by the EU is described in Algorithm 4. Before buying a unit product, the EU scans the QR_U. If the id_U is not found in the seller registry, this means the product has not been sold yet. After that, the DID_MF is retrieved from the verified registry and the MF name is returned. If the EU wants to buy the unit product, the RT scans the QR_U, which confirms the sale. The EU scans the QR_U again. Now the id_U can be found in the seller registry and the timestamp retrieved. The id_P of the id_U can be found in the relational table. id_P helps in obtaining the UD. From the verified registry DID_MF, the DID_DS and DID_RT are retrieved, and using these DID_s, the names of the MF, DS, and RT are also retrieved. The UD, timestamp, and names of the MF, DS, and RT are returned.

Algorithm 4: Product verification by $EU$

5.3. Security Analysis

The security analysis of the proposed system and its corresponding propositions and proof are discussed here.

Proposition 1 

(Security of $TTS$). The protocol of the $TTS$ is safeguarded against attacks by A and guarantees the security properties ($\mathcal{S}1$ to $\mathcal{S}6$) outlined in Table 1.

Proof 

(Proof of Proposition 1). The $TTS$ involves six entities: $GA$, $LG$, $MF$, $DS$, $RT$, and $EU$. All of these entities are semi-honest adversaries, meaning they try to learn private data from the others but still follow the protocol. Each adversary also starts different types of attacks. This means the protocol involves these six entities, each with a unique view of how they can learn from the others. In the $TTS$ protocol, the $VC$ of the $MF$ and $LG$ can only be seen by the $GA$. The $VC$ of the $DS$ and $RT$ can only be viewed by the $LG$. The $EU$ can only buy products and check the product history dashboard. Therefore, the $GA$, $LG$, and $EU$ are not considered adversaries. The main adversaries in the $TTS$ protocol are the $MF$, $DS$, and $RT$. These entities follow the same processes and actions. The perspective of the $MF$ on the parameters of the other entities is as follows:

$$vie{w}_{MF}^{TTS}=\left({[L_{CA},DID,PR,PK]}_{DS}\right)$$

Here, $MF$ can verify D by checking $P{R}_{DS}$. There are no other data available to the $MF$ that could help infer additional private information.

Next, the perspective of an individual $DS$ on the parameters of the other entities is as follows:

$$vie{w}_{DS}^{TTS}=\left({[L_{CA},DID,PR,PK]}_{MF},QR\right)$$

The $DS$ can authenticate the $MF$ by verifying $P{R}_{MF}$. There are no other data available to the $DS$ that could help infer additional private information.

The perspective of an outsider adversary A, who is not part of the $TTS$ but aims to infer data, is as follows:

$$vie{w}_A^{TTS}=\left({DID}_{MF,DS,RI}\right)$$

Outsider adversaries are only able to view information that is publicly available. None of this information is sufficient to infer any private information of the $TTS$ participants. The A cannot even initiate any kind of hacking attacks, because the $TTS$ is a decentralized system. Therefore, even if A can infer the encrypted data, it will not be of any use, and privacy will prevail. □

6. Experiment and Result Evaluation

In this section, the test environment description is outlined, and the performance of the proposed model is evaluated.

6.1. Testbed

The machine used for testing the Fantom blockchain was powered by an Intel Core i9 processor (Intel Corporation, Santa Clara, CA, USA), which featured a base clock speed of 2.3 GHz and was equipped with 8 cores. Additionally, the processor was capable of boosting its clock speed up to 4.8 GHz, providing enhanced performance during testing. The system used for testing the Fantom blockchain was equipped with 16 GB of 2666 MHz DDR4 RAM, providing seamless performance during blockchain operations. It also included a 2.6 GHz AMD Radeon Pro 5300M graphics card with 4 GB of GDDR6 memory, ensuring efficient handling of graphical tasks. This powerful configuration was designed to deliver optimal performance and support throughout the testing of the Fantom blockchain.

6.2. Evaluation Metrics

This section presents the key metrics utilized to measure the performance of the proposed system, including the execution time ($et$), average latency ($al$), average verification time ($vt$), and average throughput ($at$).

6.3. Execution Time ($et$)

This refers to the total duration, measured in seconds, required for the system to process and finalize all transactions. It is calculated as the sum of the time differences between the start and end of each transaction. The formula for execution time is given in Equation (1), where n represents the total number of transactions, and $t_1$ and $t_2$ are the deployment time and the end time of the transaction, respectively.

$$et=\sum _{i=1}^n(t_2-t_1)$$

(1)

6.4. Average Latency ($al$)

This is calculated as the mean of the time differences between $t_2$ and $t_1$ for a set of transactions, reflecting how long it takes for a transaction to be processed. This is represented by Equation (2), where the sum is divided by the total transaction count n.

$$al={\displaystyle \frac{{\sum }_{i=1}^n(t_2-t_1)}{n}}$$

(2)

6.5. Average Throughput ($at$)

This determines the average rate of successful transactions processed each second during the execution phase. It is calculated using the formula in Equation (3), where N represents the total number of successful transactions, and $T_1$ and $T_2$ are the start and end times of each transaction.

$$at={\displaystyle \frac{\frac{N}{{\sum }_{i=1}^N(T_2-T_1)}}{N}}$$

(3)

6.6. Result Evaluation

This section provides an assessment of the proposed system’s performance. The evaluation was based on three metrics: average latency, execution time, and average throughput. A comparative performance analysis of Fantom, Ethereum 2.0, Ethereum, and Hyperledger Fabric is depicted in Figure 7.

Figure 7a illustrates the performance variation based on the time consumption of four distinct blockchain platforms: Ethereum, Ethereum 2.0, Fantom, and Hyperledger Fabric. The x-axis shows the transaction count, ranging between 1 and 1000, whereas the y-axis indicates the total time taken for different transaction groups in seconds. The plot is displayed using a linear scale. From Figure 7a, it is clear that the execution time increased with the number of transactions. Ethereum 2.0 demonstrated the slowest performance, struggling to complete up to 980 transactions, while Ethereum performed similarly, but at a slightly faster rate. The figure shows that Fantom processed transactions faster than the others. This time difference increased with more transactions.

In Figure 7b,c, we examine the impact of varying transaction volumes on the performance of the blockchain platforms, focusing on the latency and throughput. Both figures feature the number of transactions on the x-axis, which ranges from a single transaction to 1000 transactions. Figure 7b provides a visual representation of the average latency in seconds for each transaction set, illustrating how the response times changed as the number of transactions increased. Meanwhile, Figure 7c highlights the average throughput, measured in transactions per second (tps), for each corresponding set of transactions, offering insights into how efficiently the blockchain platforms could process a higher transaction load. The analysis reveals that Fantom achieved the lowest latency and the highest throughput when compared to Hyperledger Fabric, Ethereum, and Ethereum 2.0. This performance comparison demonstrates that Fantom outperformed the other blockchain platforms in terms of speed and efficiency.

In conclusion, the proposed system showcased remarkable improvements in performance across several key metrics, including speed, cost-efficiency, scalability, and security, when deployed on the Fantom blockchain platform. This exceptional performance is primarily attributed to Fantom’s innovative use of the Directed-Acyclic-Graph-based consensus mechanism known as Lachesis, which enables asynchronous Byzantine Fault Tolerance. Unlike traditional blockchain platforms such as Ethereum, Ethereum 2.0, and Hyperledger Fabric, which rely on more conventional consensus models, Lachesis allows for faster transaction processing, greater scalability, and enhanced fault tolerance, ultimately leading to a more robust and efficient system. These advantages make the proposed system on Fantom a compelling alternative for decentralized applications requiring high throughput and low latency.

Figure 8 illustrates the evaluation of the proposed system by assessing the average verification performance as the number of transactions varied across four distinct blockchain platforms, as mentioned above. On the x-axis, the graph depicts the number of transactions, which spans from 1 to 1000. The y-axis indicates the mean time for verification, representing the duration required to authenticate all credentials, including the verifiable credentials of entities within a supply chain. The data clearly show that Fantom consistently exhibited significantly lower average verification times compared to the other blockchain platforms, such as Ethereum, Hyperledger Fabric, and Ethereum 2.0. Notably, Ethereum and Ethereum 2.0 demonstrated an identical verification performance across all transaction sets. This suggests that the verification performance of these two platforms is nearly indistinguishable. In conclusion, the proposed system, built on the Fantom blockchain, consistently delivered superior verification speed, making it a more efficient solution than Ethereum, Hyperledger Fabric, and Ethereum 2.0 for handling supply chain credential verification.

Table 3. Comparison of TTS with previous studies.

Studies	${\mathcal{X}}_1$	${\mathcal{X}}_2$	${\mathcal{X}}_3$	${\mathcal{X}}_4$	${\mathcal{X}}_5$	${\mathcal{X}}_6$	${\mathcal{X}}_7$
[19]	0	-	-	-	5+	No	No
[23]	1	-	-	-	5+	No	No
[37]	2	238.8	2	0.004	5+	Yes	No
[29]	1	-	23	0.2	5+	No	No
TTS	4	100	1	0.07	5	Yes	Yes

Here, ${\mathcal{X}}_1$: number of blockchain technologies used; ${\mathcal{X}}_2$: $et$; ${\mathcal{X}}_3$: $al$; ${\mathcal{X}}_4$: $at$; ${\mathcal{X}}_5$: human interaction needed for the ecosystem and traceability; ${\mathcal{X}}_6$: an ideal system for supply chain traceability for all kinds of products; ${\mathcal{X}}_7$: SSI utilizations; -: represents the system does not support this parameter.

shows a comparative analysis of the TTS with previous studies. The comparison is performed based on the number of blockchain technologies utilized, $wt$, $al$, $at$, human interaction needed, whether the technology is ideal for all kinds of product supply chains or not, and whether SSI is used or not. Most of the supply chain the studies did not cover blockchain, and even if some of them utilized blockchain, they did not cover a proper analysis, such as $et$, $al$, and $at$. It is clear from the Table 3 that the proposed TTS outperformed all previous studies in terms of $et$, $al$, and $at$. To support the validity of our performance results, each experiment was conducted five times under identical conditions. We report the outcome as the mean ± standard deviation, to reflect the variability across repeated trials. For instance, the TTS implementation on the Fantom network achieved a consistent throughput of 0.008 ± 0.0003 transactions per second and a verification latency of 1.2 ± 0.15 s for 1000 transactions. This statistical framing reinforces our evaluation’s reliability and the system’s stability across repeated executions.

7. Conclusions

This study introduced a comprehensive supply chain network designed for reliable product traceability, ensuring efficient tracking of products from the manufacturer to the end consumer. The use of the Fantom public blockchain network provides a faster, more cost-effective, and secure solution for managing supply chain processes. Additionally, the DKMS (Decentralized Key Management Service) enhances the authentication process, ensuring a more reliable and distributed Self-Sovereign Identity (SSI) system for each entity within the supply chain. The system was tested on various public and private networks. The findings indicate that Fantom led the pack in verification and transaction performance. Compared to Ethereum and Hyperledger Fabric, Fantom offered faster verification and transaction processing, enhancing its viability for supply chain traceability.

Future work will focus on deploying IoT devices at the network’s edge, to enhance data collection and processing. These devices will integrate onboard machine learning and image analysis to improve decision-making. This advancement aims to achieve full automation of the supply chain system, increasing efficiency and accuracy. Further studies will also explore demand forecasting for improved supply chain management.