A secure rubber supply chain management system based on hyperledger fabric blockchain: a use case in Cambodia

Abstract

Conventional traceability systems in Cambodian agriculture, such as rubber, rice, and cassava supply chain management, often fail to provide timely data and fair market prices, leading to mistrust among stakeholders, exploitation by intermediaries, and hindering progress towards ethical sourcing and sustainable practices. This paper demonstrates the potential of integrating blockchain, IoT, the InterPlanetary File System (IPFS), and Differential Privacy (DP) techniques to empower Cambodian rubber farmers. By leveraging Hyperledger Fabric (HLF), the proposed system enhances transparency and facilitates fair pricing by forming decentralized rubber traceability from supplier to consumer. Integration with IPFS ensures secure and accessible data storage, while differential privacy techniques protect confidential data during information sharing. Our approach facilitates a model for other developing countries aiming to modernize agricultural distribution networks. Numerical results demonstrate that our system achieved the overall performance objectives, including transaction send rates, transaction throughput, and transaction latency. However, the results highlight a trade-off between privacy and performance in blockchain-based agricultural traceability systems. Specifically, while implementing differential privacy techniques enhances data confidentiality, it can slightly reduce system efficiency and scalability compared to configurations without privacy measures.

1 Introduction

Cambodia’s Natural Rubber (NR) sector began with small-scale cultivation in the early 1900s and saw industrialization begin in 1921 (Hang, 2009). By the 1970s, NR covered about 60,000 ha (ha). The sector expanded significantly to 436,682 ha across 22 provinces by 2018, with a production capacity of 220,000 tons projected to grow from 2019 to 2023. The majority of NR processing and exports consist of 78% Technically Specified Rubber (TSR) and 21% Ribbed Smoked Sheets (RSS), with the remainder being Concentrated Latex (CL)¹. The Cambodia Rubber Supply Chain Management (RSCM) sector involves 284 participants, including estate agencies, manufacturers, and cooperatives (Diepart et al., 2023). Despite the absence of a rubber futures market, Cambodia relies on market-reference-based pricing (MRB), which is influenced by international markets such as TOCOM, SICOM, and Shanghai. Cambodia’s NR export markets include Vietnam, Malaysia, China, Singapore, South Korea, and Europe.

In addition, agriculture, an important part of Cambodia’s economy, contributed 22% to the GDP in 2022 and employed 2.6 million people². This sector plays a critical role not only in economic output but also in supporting the livelihoods of a significant portion of the population, particularly in rural areas where farming is the primary source of income and employment. Despite its importance, Cambodia’s agriculture, including the rubber industry in this context, faces several challenges, such as labor issues, unstable markets, and insufficient traceability. These challenges hinder the sector’s growth potential and its ability to fully capitalize on international demand, especially in industries like rubber, where issues related to production quality and supply chain transparency are ongoing concerns. As a result, improving agricultural practices, enhancing market stability, and implementing better traceability systems could significantly contribute to the sustainable development of Cambodia’s agricultural sector.

2 Background

2.1 Supply chain management

Supply chain management (SCM) focuses on the strategic synchronization of product information and data movements across organizations, aiming to deliver products or services to consumers efficiently. This includes coordinating operations such as raw material purchasing, manufacturing planning, logistics, inventory management, and forecasting consumer demand. Effective SCM is essential for cost savings, market responsiveness, and consumer satisfaction (Kumar and Sahoo, 2025). Organizations must balance trade-offs, like cost reduction and maintaining sufficient supply to meet demand. The complexity of global supply chains necessitates advanced SCM practices utilizing technologies like blockchain, data analytics, AI, and IoT for real-time visibility and agility (Ivanov et al., 2019). Traditional SCM also emphasizes sustainability, reducing environmental impact, and ensuring transparency in purchasing processes, reflecting rising consumer awareness and regulatory demands.

2.1.1 Cambodia rubber value chain

In Cambodia’s rubber value chain, latex is processed into rubber using RSS or TSR methods. Smallholder farmers sell latex or coagulum based on factors like purchase price, processing unit proximity, and transportation availability. Numerous RSS processing facilities exist near smallholder farms, accessible within a day by motorcycle. Large landholders may sell directly to RSS facilities, exporting processed rubber to destinations such as Korea, Vietnam, China, India, and Malaysia (Diepart et al., 2023). TSR processing units also operate, sourcing latex and coagulum, with primary exports to Eastern Europe, Vietnam, China, Korea, Malaysia, and India. Smallholder farmers often coagulate latex on the farm and sell to local collectors, who transport it directly to Vietnam and Thailand, bypassing RSS or TSR processing. Supply chain management (SCM) focuses on the comprehensive synchronization of product information and data movements throughout an organization of businesses, including the primary objective of delivering products or services to the consumer or end user. Subsequently, it represents strategic coordination of operations such as raw material purchasing, manufacturing planning, logistics, inventory management, and forecasting consumer demand. Effective SCM is fundamental to achieving cost savings, increasing market responsiveness, and improving consumer endorsement (Kumar and Sahoo, 2025).

2.2 Blockchain technology

The concept of Blockchain (BC) has significantly changed our perception of reliability and cooperation in distributed applications (DApps). It is based on a shared, indestructible ledger made of cryptographically attributed components Firdaus et al. (2023a). Satoshi Nakamoto’s 2008 Bitcoin whitepaper mentioned this revolutionary invention (Nakamoto, 2024). In Figure 2, each record has a header with versioning, timestamps, and a Merkle root for data confidentiality, and an object containing transaction details. Blockchains achieve immutability through hash pointers, with each block referencing its predecessor for secure traceability. These ledgers operate on decentralized networks, relying on consensus mechanisms like Proof-of-Work (PoW) to validate updates (Cachin and Vukolić, 2017) and cryptography to protect data during transfer (Pappachan et al., 2024). This design fosters decentralization, immutability, traceability, collaborative maintenance, and customizable transparency (Pilkington, 2016). However, Bitcoin’s pioneering protocol exposes constraints in scalability and its scripting language’s adaptability for complex applications (Croman et al., 2016).

FIGURE 1

FIGURE 2

2.2.1 Blockchain platforms

2.2.2 Smart contract in hyperledger fabric

Smart contract (SC) are the core foundation behind Hyperledger Fabric’s efficiency and performance. In this permissioned blockchain architecture, SC operates as self-executing contracts, including agreed-upon business logic directly throughout the source code (Androulaki et al., 2018). Data preservation, in addition to an immutable record of state change transactions, provides remarkable transparency and automation to operations previously limited by complications, inefficiencies, and possible conflicts (Christidis and Devetsikiotis, 2016). In Hyperledger Fabric, SC is arranged into components known as Chain Code (CC) for administrative ease (Androulaki et al., 2018). These CCs, primarily created in Go but also support Node. js and Java, are run by network peers. This peer execution ensures that all authorized parties agree on transaction results before modifying the ledger state (Vukolić, 2016) as shown in Figure 3.

FIGURE 3

2.2.3 IPFS with hyperledger fabric

The InterPlanetary File System (IPFS) offers an attractive solution for blockchain technology’s data storage limitations. IPFS, a peer-to-peer (P2P) distributed file system, uses content-addressing to generate unique content identifiers (CIDs) through file hashing. By storing these CIDs on the blockchain instead of raw data, IPFS significantly reduces storage pressure and costs (Zheng Q. et al., 2018; Firdaus et al., 2023b). This relationship between IPFS and blockchain allows effective off-chain storage of significant or sensitive data. Sensitive information benefits from IPFS’s distributed nature, enhancing privacy, while the blockchain provides a tamper-proof record for references and metadata. Furthermore, IPFS incentivizes persistent data storage via Filecoin, its native asset, ensuring ongoing accessibility (Xu et al., 2018). Additionally, the content-addressable aspect of IPFS presents various benefits. Immutability is achieved by identifying content via a unique hash; any changes to the file’s contents generate a new CID. This improves version management, maintains verifiable data connections, and develops trust in data consistency. Therefore, integrating IPFS with blockchain systems allows decentralized data management, reducing dependency on centralized storage providers while offering a more secure and flexible structure.

2.3 Related works

Blockchain technology has shown significant potential in transforming agriculture and supply chain management by enhancing transparency, traceability, and operational efficiency. Several studies have explored its application across diverse agricultural domains and specific commodity supply chains like rubber. Blockchain has been widely applied in general agricultural supply chains to address issues such as food safety, fraud, and inefficiency. Tian (2016) introduced a blockchain-based food traceability system, enabling real-time monitoring of agricultural products, thus improving food safety. Kamilaris and Fonts, 2019 provided a comprehensive review of blockchain applications in agriculture, highlighting its role in improving supply chain transparency and combining it with IoT for efficient data collection and sharing. Similarly, Tripoli and Schmidhuber (2018) discussed blockchain’s role in agricultural trade by enabling farmers to access markets directly, reduce intermediaries. In sustainable agriculture, Dey and Shekhawat (2021) examined blockchain’s ability to track and verify sustainable farming practices, providing greater accountability to consumers and stakeholders. Using blockchain to manage smart farming systems with IoT integration has also been explored by Caro et al. (2018), who developed a system to automate crop monitoring and optimize supply chain workflows.

The rubber supply chain faces unique challenges, including ensuring product authenticity, addressing deforestation concerns, and promoting sustainable sourcing. Blockchain solutions have been proposed to improve transparency and mitigate these issues. For example, Yadav et al. (2024) developed a blockchain-enabled traceability framework for the natural rubber supply chain, allowing real-time monitoring of sourcing and production practices while ensuring adherence to sustainability standards. In a similar context, Cui and Gaur (2022) explored blockchain’s role in supporting smallholder farmers by integrating rubber price tracking and smart contracts to facilitate fair payments. Their study showed how blockchain reduces exploitation and promotes equitable profit sharing among stakeholders. Furthermore, Xiong et al. (2020) demonstrated how smart contracts can be applied in rubber trading to automate payment processes and ensure contract compliance, thus enhancing operational efficiency and reducing disputes.

3 Proposed framework

3.1 System overview

In this section, we present our proposed system to address the challenges faced by the rubber supply chain in Cambodia, including limited traceability, poor visibility, potential security risks, and concerns about sustainability. To overcome these issues, we leverage HLF’s flexibility and suitability for complex supply chains. Moreover, HLF is chosen for the rubber supply chain management system due to its unique advantages in scalability, performance, and privacy, which align with the requirements of the domain. Its permissioned architecture ensures that only authorized participants, such as producers, manufacturers, and distributors, can access and validate transactions, enhancing security and trust within the network. Fabric’s modular design supports channel partitioning and private data collections, allowing sensitive supply chain data to be shared securely among relevant stakeholders while maintaining privacy. Furthermore, its pluggable consensus mechanism is well-suited in the rubber industry. To securely store sensitive information such as rubber prices, origin details, and processing methods, we incorporate IPFS as an off-chain storage solution. In addition, IoT devices play a vital role in real-time monitoring, utilizing communication protocols like Bluetooth, WiFi, and the Internet to collect and transmit data. Protocols such as MQTT, HTTPS, and APIs integrate IoT devices with the blockchain and user interfaces, ensuring a seamless flow of data for effective supply chain management. To ensure secure data sharing, we employ differential privacy based on the Laplace mechanism, integrated into the smart contract, to protect sensitive information while maintaining data utility.

3.1.1 System entities

FIGURE 4

FIGURE 5

FIGURE 6

3.1.2 System architecture

3.2 Transaction flow

The proposed Hyperledger Fabric-based rubber supply chain management system in Cambodia incorporates a sophisticated architecture designed to enhance the integrity, efficiency, and transparency of the supply chain. It leverages IoT technology to collect essential data and employs blockchain technology for secure data processing and storage. By integrating these technologies, the system aims to address the traditional challenges of supply chain operations, such as limited traceability and potential security risks. The initial stage of the system architecture involves extensive data collection via IoT sensors strategically placed throughout the supply chain. These sensors gather critical real-time data, including temperature readings from storage facilities, humidity levels crucial for rubber preservation, and GPS tracking information to monitor logistical movements. This data is vital for proactive supply chain management, enabling immediate responses to potential issues, such as temperature fluctuations that could compromise product quality. To ensure secure and efficient data transmission, the system employs MQTT (Message Queuing Telemetry Transport), a lightweight machine-to-machine (M2M) connectivity protocol optimized for low-bandwidth environments. MQTT facilitates reliable communication between IoT devices and the central system, minimizing the risk of unauthorized access and data breaches. The collected data is securely processed and made available for further analysis and decision-making. Following data collection and processing, the system supports active stakeholder interaction through user-friendly mobile and web interfaces. These interfaces serve as the primary tools for data input and retrieval, enabling stakeholders to perform tasks such as entering shipment details, checking inventory levels, and monitoring supply chain operations in real time. Designed with accessibility in mind, these interfaces ensure that users of varying technical proficiency can effectively interact with the system.

To enhance security, sensitive data such as personal information and logistical details are encrypted using SHA-256, a cryptographic hash function that provides robust data security. This encrypted data is stored off-chain on the InterPlanetary File System (IPFS), a peer-to-peer distributed file storage protocol. IPFS is ideal for handling large data volumes without compromising blockchain performance, as only metadata and hashes are stored on-chain. This approach reduces the blockchain’s load while ensuring data immutability and availability. Central to the transaction flow is the creation and management of on-chain transactions. Stakeholder actions, such as placing orders or updating shipment statuses, are captured as transactions within the Hyperledger Fabric network. These transactions are managed via APIs that interface with the Hyperledger Fabric SDK, providing a secure and standardized method for transaction handling. Upon initiation, transactions trigger chaincode (smart contracts) programmed with the business logic of supply chain operations. The chaincode validates the transactions against predefined rules and ensures compliance with operational standards and regulatory requirements.

For transaction validation and ledger updates, the system employs the RAFT consensus mechanism. In this mechanism, a leader node is elected to propose and manage transaction ordering. This leadership and consensus approach ensures the integrity and trustworthiness of the system, as all nodes must agree on transaction data before committing it to the ledger. Once consensus is achieved, the transactions are committed to the blockchain, maintaining a chronological and immutable record of supply chain activities. To keep all participants synchronized, the system includes notification and synchronization mechanisms. After a transaction is committed, relevant stakeholders are notified, and their respective ledgers are automatically updated to reflect the latest state. This ensures data integrity across the network and enhances the visibility and reliability of supply chain operations. Through this detailed architecture and workflow, the proposed system harnesses the combined strengths of IoT and Hyperledger Fabric to revolutionize rubber supply chain management in Cambodia. By addressing traditional challenges of transparency, efficiency, and security, the system provides a robust solution that modernizes and streamlines supply chain operations.

3.3 Consensus protocol

The RAFT consensus mechanism is implemented in our proposed system to manage the ordering of transactions within our network. Distributed nodes use a leader-based consensus mechanism known as RAFT, or the Reliable, Replicated, Redundant, and Fault-Tolerant protocol, to ensure data consistency throughout the network. All client requests are processed by a leader, who monitors the log replication procedure and provides the data committed to the replicated log before execution. A new leader is chosen when the current one collapses, reducing the time needed to achieve consistency and efficiently handle redundancy. RAFT is the most commonly utilized consensus mechanism in HLF implementations. It is very flexible and supports versions 2.0.0 and higher, which makes it suitable for our system, which is now running v2.5.0.

3.4 Secured data sharing protocol based on differential privacy using laplace algorithms

3.4.1 Vulnerable scenario in the HLF-based network

Figure 7 illustrates a possible vulnerable scenario in our proposed system for data exchange between the user, API, HLF, and the IPFS. This scenario describes a sequence of actions an attacker could employ to compromise system security. The initial vulnerability was identified at the API level, where the user enters sensitive information. The API is vulnerable to injection attacks, a type of manipulation in which an attacker injects malicious code into the system, resulting in unauthorized access or data tampering. This breach might compromise sensitive user information and allow the attacker to gain further capabilities within the network. Additionally, the adversarial assessment indicates that Hyperledger, regardless of its transaction transparency, is vulnerable to possible security breaches. The scenario exposes illegal data access, data manipulation, and metadata breaches. Each of these attack routes presents a critical risk to the system’s security. Unauthorized access could expose confidential transaction data; data tampering could alter transaction records, compromising the ledger’s reliability; and metadata compromise could reveal more details that could be used in future attacks or to cause current compromises (Islam et al., 2024). Furthermore, utilizing IPFS to query document information might offer an attack surface. However, rather than directly shown in the illustration, the metadata transmission could be intercepted or manipulated, resulting in a compromised retrieval of the information system.

FIGURE 7

3.4.2 Differential privacy (DP): a solution for the data sharing in HLF-based network

In our research, we propose leveraging Differential Privacy (DP) to enhance data security, privacy, and efficiency for rubber farmers. DP ensures that individual farmers’ data remains confidential while still allowing for meaningful data analysis. It achieves this by injecting noise into the data before sharing or processing it, preventing unauthorized parties from identifying specific individuals. DP enables stakeholders to analyze rubber production trends without exposing individual farmers’ private data (e.g., yield, pricing, and financial records). Moreover, DP helps mitigate various attacks, particularly membership inference attacks, which are crucial for securing financial forecasting. In this context, farmers’ financial records can be processed using DP techniques to generate market insights while safeguarding sensitive income data. Additionally, adaptive DP techniques can be applied, allowing farmers to control the level of privacy protection based on their preferences and data sensitivity.

FIGURE 8

This equation ensures that the output remains private according to the defined privacy parameter , providing mathematical security of privacy under specific assumptions about adversarial knowledge.

4 System implementation

In this part, we get into the essential prerequisites for successfully setting up the system as proposed. These prerequisites include the required hardware and software components, as well as the installation and configuration process. These factors are fundamental to assessing the performance of blockchain network implementations throughout the implementation phase and collecting relevant data such as transaction per second (TPS), transaction latency (TL), and transaction throughput (TT).

In the proposed system, the implementation environment is carefully chosen for optimal performance and compatibility. The system runs on Ubuntu 20.04.1 LTS 64-bit, ensuring security and reliability. It uses an Intel^® Core™ i7-7700 processor with 8 CPUs at 3.60 GHz and 8 GB of RAM, balancing high processing power with cost-effectiveness. The environment uses Minifab for Hyperledger Fabric 2.5 for up-to-date blockchain features and security. IPFS version 12 supports decentralized storage, enhancing data availability. Hyperledger Caliper 2.0 benchmarks blockchain performance, providing insights into transaction throughput and latency. Docker and Docker-compose (versions 25.0.3 and 1.29.2) facilitate containerization for scalable and isolated service execution. Go version 1.20.2 is chosen for efficient system-level programming. This configuration supports robust, scalable, and efficient blockchain application testing and deployment.

4.1 Ledger and chaincode initialization

In HLF, smart contracts are referred to as chaincode. Chaincode is the business logic that defines the rules for how transactions should be processed, validated, and stored on the blockchain. It runs on the peers in the network and is invoked by client applications to interact with the ledger. Ledger Initialization refers to setting up and initializing the ledger (the blockchain state) when the Hyperledger Fabric network starts or when a new chaincode is deployed. The ledger contains the blockchain data, including the state of the system and transaction history. When a chaincode is deployed, the ledger initialization occurs as part of the instantiation process. This initialization includes setting up necessary data structures, such as creating initial states or variables. The initialization also involves setting the initial values for the state that the chaincode manages. In this case, initialization involve setting up data for the first batch of rubber and defining initial records for stakeholders.

Algorithm 1 describes the implementation of the Initialize Ledger (InitLedger) smart contract algorithm on the HLF network. The algorithm accepts a single input, ctx, an instance of contractapi. TransactionContextInterface. This algorithm aims to initialize the ledger by calling the initCounter function, which maintains the counter’s initial state in the ledger. If the initialization is successful, the algorithm returns nil, indicating that the ledger was properly initialized. If an error occurs during the initialization procedure, the algorithm will output an error message for the type of error init counter:%s. This architecture guarantees that any errors during ledger startup are identified and reported.

4.2 Batch transaction

4.2.1 Growth batch transaction

A growth batch transaction refers to transactions that handle growing records, which involve the expansion of batch sizes over time. In the context of the rubber supply chain, this involves the growth in the amount of rubber collected from farmers, where the batch size increases due to ongoing collection over time. Algorithm 2 presented the outlines of the CreateBatch method within a Farmer SC tailored for blockchain applications. Initially, it fetches the transaction ID from the context and ifs if the provided batch ID is empty. An empty ID triggers a return of false along with an error message about the missing batch ID. If the ID is valid, it proceeds to fetch batch data from a transient state—not permanently recorded on the blockchain. Failure at this stage also results in a return of false due to the error encountered. Successful data retrieval leads to an attempt to deserialize the JSON-formatted string into a FarmerBatch object; a failure in deserialization returns false with the error. The next step involves uploading the batch data to the IPFS, a distributed file system, and storing the resulting IPFS hash. Any issues during this upload result in a return of false. Subsequently, the FarmerBatch object is updated with the IPFS hash and transaction ID, followed by an attempt to record this updated object in the blockchain’s state database using the batch ID as the key. If this operation fails, it results in a false return with an error. If all processes execute without errors, the function successfully concludes by returning true, signifying the successful creation of the batch. This method encapsulates typical blockchain operations involving data retrieval, validation, and storage, efficiently managing errors at each step to ensure data integrity and accuracy in batch recording.

4.2.2 Query grown batch transaction

This transaction refers to querying and retrieving information related to batches that have grown or evolved over time. In a supply chain, this involves querying the status or details of rubber batches that have accumulated over time due to increasing quantities or shipments. Algorithm 3 presented represents the operation of the QueryGrownBatchById function within a smart contract, used to retrieve and process a batch of data from a blockchain network. Initially, the function attempts to fetch the batch data from the blockchain’s state database using the ctx. GetStub(). GetState method. If an error occurs, such as the absence of data or a network issue, the function returns an error formatted to indicate a failure in data retrieval. Assuming successful data fetch, the next step involves deserializing the string format data into a FarmerBatch object for programmatic manipulation. If errors arise during this unmarshalling, such as from data corruption or incorrect formatting, the function returns an error that includes the specific batch ID and a detailed failure message. If unmarshalling is successful, the function returns the structured FarmerBatch object with a nil error, indicating successful execution.

4.3 IPFS integration

In this paper, we integrate IPFS with HLF to efficiently manage large file storage in the rubber supply chain. IPFS is used to store substantial files such as certification documents, batch records, and inspection reports, while HLF records only the metadata, including the IPFS hash, ensuring a lightweight and scalable blockchain network. The chaincode is implemented to interact with IPFS, allowing files to be uploaded and retrieved using the IPFS hash stored on the blockchain. This integration combines the immutability and transparency of HLF with the decentralized, efficient storage capabilities of IPFS, ensuring that critical data remains secure, transparent, and easily accessible. The approach improves the scalability of the supply chain system by offloading large data storage to IPFS while preserving the integrity and trust provided by the blockchain. The two most crucial steps in the integration of IPFS with file upload to IPFS and file retrieval from IPFS.

4.3.1 File upload to IPFS

The first critical step involves uploading files to the IPFS network. In this process, a file (such as a certification or inspection report) is added to the IPFS network using an IPFS client. When a file is uploaded, IPFS generates a unique IPFS hash (a content-addressable identifier). This hash serves as the reference for the file within the IPFS network. The chaincode in Hyperledger Fabric handles this process by interacting with the IPFS client to upload the file and subsequently stores the IPFS hash in the blockchain, associating the file with its metadata, such as file name, timestamp, and other relevant information.

Algorithm 4 for the UploadDataToIPFS function illustrates the process of uploading data to the IPFS. The procedure initiates by establishing a connection to an IPFS node using a specified IPFS Shell address (localhost:5001). The input data is then marshalled into JSON format to prepare it for IPFS, which handles raw bytes. If this conversion fails, an error message is promptly returned, indicating an issue with data marshaling. Once successfully converted, the JSON bytes are uploaded to IPFS by invoking the Add method on the shell instance with the marshalled bytes. If any error occurs during the upload, it returns an error message highlighting the problem with the IPFS upload process. Otherwise, the successful upload returns a unique hash(CID), provided by IPFS and stored in if PS Org. in the HFL network, which can be used to retrieve the uploaded data at any point, ensuring its persistent availability across the decentralized network.

4.3.2 Retrieve data from IPFS

The second crucial step is retrieving files from IPFS when needed. To retrieve a file, the blockchain stores the IPFS hash (from the file uploaded earlier). When a user or system component requests the file, the blockchain query returns the IPFS hash, which can then be used to retrieve the file from the IPFS network. The chaincode interacts with the IPFS client again to access the file by its hash. This decentralized retrieval ensures that the file remains immutable and accessible without burdening the blockchain with large data storage.

Algorithm 5 The RetrieveDataFromIPFS function illustrate the process of retrieving data from the IPFS with a given hash number. Initially, the method creates a connection to an IPFS node by starting a new IPFS shell instance at localhost:5001. It then uses the Cat technique to extract the data stream corresponding with the hash supplied. If this retrieval fails, which might be due to an incorrect hash or network troubles, the function will instantly provide an error message. Considering that the data stream was successfully retrieved, the method reads all the data into a byte array, managing faults such as I/O difficulties by issuing an error if the read fails. After reading, the data stream is closed to free resources, which is enforced by a defer statement that ensures execution at the function’s end regardless of previous results. If all actions are successful, the method returns the byte array, allowing the caller to access the retrieved data.

4.4 Differential privacy for data sharing protection

The Algorithm 6 Query Grown Batch With Differential Privacy includes two primary functions for securely querying and processing rubber batch information while preserving privacy. The first procedure, QueryGrownBatchById, obtains a batch of data identified by batchId from a state ledger in the HLF network. Essentially, it converts data from a JSON string into a FarmerBatch model. If there are any issues in retrieving or decoding the data, it will immediately return the error. Additionally, it pulls related information from IPFS, ensuring the data is safe and verifiable. The following procedure, Differential Privacy, is designed to improve data privacy. This calculates noise injected into the data utilizing the Laplace approach, with a privacy budget set by epsilon and the query sensitivity Delta f. The disturbance, which is noise, is then injected into the data to guarantee privacy, which is a procedure for ensuring that the query’s result does not compromise the privacy of the individuals in the dataset. Our technique provides secure and confidential querying of sensitive rubber information while maintaining the information’s confidentiality and reliability.

4.5 HLF network setting

4.5.1 Starting fabric network and chaincode deployment

Initially, in our implementation, the primary tool for setting up and maintaining the Hyperledger Fabric network is the minifab up command, shown in Figure 9. This command generates the cryptographic certificates, downloads the required Docker images, and configures the peer and orderer nodes, effectively establishing the entire blockchain architecture. The cryptographic certificates, which are essential for identity management and secure communication, are automatically created, allowing the network to enforce permissioned access. Simultaneously, the required Docker images for the various components of the Fabric network, such as peer nodes and orderers, are fetched and prepared. This step ensures that the environment is consistent across different installations, as each component runs in an isolated container. The minifab up command then configures the peer and orderer nodes, which serve as the backbone of the Hyperledger Fabric network. Peer nodes are responsible for maintaining the blockchain ledger and executing chaincodes, while orderer nodes are tasked with organizing and validating transactions across the network. By automating the configuration of these nodes, the process avoids manual setup errors and ensures seamless communication between the nodes, which is critical for maintaining data consistency across the entire network. This process effectively establishes the entire blockchain architecture, enabling decentralized and secure transactions to take place. Furthermore, it guarantees that all nodes and chaincodes are correctly installed and functional, with the necessary dependencies resolved automatically.

FIGURE 9

4.5.2 Setting up channel

Figure 10 present minifab build -c rubbersupplychain command represents a step in establishing the blockchain network for our proposed system. By running this command, the system creates a new blockchain channel called “rubbersupplychain,” which is required for isolating and maintaining transaction data unique to our system. The tool utilizes a default specification file for setting several parameters, including the channel name, chaincode (Go), and initial chaincode parameters, which set the ledger’s starting state with specified assets. This approach consists of evaluating the included settings before constructing the channel, ensuring that the blockchain environment is appropriately customized to support the operations of our proposed system.

FIGURE 10

4.5.3 Set up organization configurations

Figure 11 presents the organization configuration in our HLF network; the architecture contains several Certificate Authorities (CAs) for each organization in the SC, from suppliers to consumers, illustrating a decentralized approach to authenticating and authorizing participants. Peers corresponding to each position validate transactions through nodes representing each supply chain stage. A single ‘orderer’ indicates a streamlined consensus process required for transaction ordering. All components have their logging level set to DEBUG, allowing complete monitoring and troubleshooting. The name “rubbersupplychain” refers to the network’s particular use of tracking the lifetime of rubber products to improve supply chain traceability and efficiency.

FIGURE 11

5 Performance evaluation and comparison analysis

This section presents a comprehensive analysis of the benchmark equations used in Hyperledger Caliper. These equations are crucial for evaluating the performance of the system under test.

5.1 Evaluation metrics

5.1.1 Success rate (SR)

The Success Rate (SR) is calculated using the equation:where represents the Success Rate (percentage), represents the number of Successful Transactions, and represents the Total number of Transactions (Successful + Failed). The Success Rate measures the percentage of transactions that were successfully completed within a test cycle.

5.1.2 Transaction and read latency (TL)

Transaction and Read Latency includes three key metrics:where represents the Average Transaction/Read Latency, represents the Latency of individual transaction , is the total number of transactions, is the Maximum Transaction/Read Latency, and is the Minimum Transaction/Read Latency. These metrics provide insights into the time taken for individual transactions to complete.

5.1.3 Transaction and read throughput (TT)

The Transaction and Read Throughput (TT) is calculated as:where represents the Transaction Throughput (transactions per second), represents the Total number of Transactions, and represents the Duration of the test cycle (seconds). Transaction and Read Throughput measures the rate at which transactions are processed by the system.

5.2 Performance evaluation

This section presents our evaluation of the proposed system performance, encompassing metrics such as transaction send rate, transaction throughput, minimum latency (s), average latency (s), and maximum latency (s). We compare these metrics in scenarios without differential privacy and with differential privacy implemented, where the provided value is set to 1 to provide a balance between privacy and data utility Krehbiel (2019); Dwork et al. (2019); Firdaus and Rhee (2023). In this sense, an epsilon of 1 allows for some level of data utility while still offering privacy protection.

5.2.1 Transaction send rate

In Figure 12 evaluating the impact of differential privacy on transaction send rates, the analysis presents a comparative performance between systems configuration with and without differential privacy measures. The result encapsulates transaction send rates across increasing transaction volumes, ranging from 50 to 300 transactions. The plot reveals a consistent increase in TPS for both conditions. However, the system without differential privacy starts at a lower rate of 84.0 TPS but surpasses the with-privacy system around the 200 transaction mark, eventually reaching a peak of 139.3 TPS at 300 transactions. This suggests that without using differential privacy may initially impose overhead, it potentially offers higher scalability and efficiency as transaction volumes increase.

FIGURE 12

5.2.2 Transaction throughput

The illustration of a performance comparison between transaction systems configuration with and without differential privacy is present in Figure 13, focusing on throughput measured in transactions per second (TPS). Both configurations demonstrate a trend of increasing throughput as the number of transactions increases from 50 to 300. However, the system non-employing differential privacy shows a notable improvement in performance beyond the 100 transaction mark, achieving higher throughput rates from 107.9 to 137.3 TPS. In contrast, the system with differential privacy exhibits a more gradual increase in throughput, plateauing at 117.2 TPS. This suggests that without differential privacy, despite its initial lower performance, may enhance throughput efficiency under higher transaction loads, possibly due to optimized handling of the system at scale.

FIGURE 13

5.2.3 Transaction latency

Transaction latency can impact the performance of a rubber supply chain management system by increasing transaction confirmation times, delaying real-time data updates, and slowing the integration of IoT device data. High latency can affect the efficiency of consensus protocols, causing delays in block propagation and reducing system throughput. As the network grows, latency issues may become more pronounced, impacting scalability. In Hyperledger Fabric, every transaction needs to be endorsed by the appropriate nodes, validated by the ordering service, and then committed to the ledger. High network latency can delay the communication between nodes, leading to longer transaction confirmation times. For a rubber supply chain, this delay could result in slower processing of transactions, such as updates to rubber traceability records, shipment confirmations, or payment processing, potentially reducing the responsiveness of the system. Figure 14 presents results on minimum latency in seconds and offers a foundational view of how differential privacy influences system performance at the lower latency bounds. Both system’s configurations exhibit relatively low and stable latencies as transaction volumes increase from 50 to 300. The system without differential privacy maintains a minimum latency within a tight range of 0.10–0.13 s, indicating consistent performance. In contrast, the system with differential privacy begins at an even lower latency of 0.07 s but shows slightly more variability, peaking at 0.15 s at the 250 transaction mark. This observation highlights the minimal impact of differential privacy on the lower latency bounds, setting the stage for a deeper exploration of latency impacts at average and maximum levels.

FIGURE 14

However, when we consider the average latency in Figure 15, the plot summarizes the latency (in seconds) for transaction systems configuration operating with and without differential privacy across different transaction volumes. Both curves indicate a balanced increase in latency as transaction volumes rise. The system without differential privacy starts at a latency of 0.29 s and raises to 1.46 s. On the other hand, the system with differential privacy initiates at a slightly higher latency of 0.34 s and concludes at 1.49 s, indicating a marginal increase in delay due to privacy-preserving mechanisms. This effectively illustrates the balance between maintaining privacy and managing average latency in transaction processing systems configuration, indicating how differential privacy slightly increases latency but potentially enhances privacy.

FIGURE 15

Finally, Figure 16, which contrasts the maximum delay in seconds, allows comprehending how different system configurations with and without differential privacy affect performance. The differential privacy system indicates a strong start with a lower maximum latency of 2.07 s, peaking at 2.94 s and maintaining a continuous increase compared to the non-private system, which starts at 2.18 s and rises more sharply to 3.53 s. This indicates that differential privacy implementations might be more resilient in managing latency spikes under increasing transaction loads, potentially offering better performance stability; therefore, while minimum and average latencies provide a transparent view of consistent performance, the maximum latency underscores the stability of differential privacy in handling peak transaction demands, infusing confidence in the system’s performance capabilities.

FIGURE 16

5.3 Research comparison and remarks

5.3.1 Comparison

The comparative analysis Table 2 provides a structured comparison between the capabilities of our proposed system and three other notable studies within the realm of transaction systems across various industries. Our framework, detailed in the table, stands out, particularly in terms of Accessibility, Data Security, and Traceability, where it matches or surpasses the cited works. Unlike the research by Ref. #1 (Molyvann, 2023) and Ref. #2 (Bruckman et al., 2018), which show limitations in data security and transparency, our system ensures both robust security and full traceability, aligning with Ref. #3 (Pradana et al., 2020) emphasis on blockchain benefits.

A noteworthy aspect of the table is the universal sustainability and fair prices feature across all compared studies, except where specific works have particular deficiencies. For instance, only our framework and the one developed by Ref. #1 (Molyvann, 2023) promotes more equitable pricing strategies. This feature is critical in markets like rubber and rice, where price volatility can significantly impact producers. Additionally, our work incorporates Cost Reduction and Transparency, which are not uniformly addressed in other studies, especially highlighted by their absence in Ref. #2 (Bruckman et al., 2018) approach to bioenergy. On the other hand, the primary use cases and platforms highlight the variety and adaptability of transaction systems to different sectors. Our framework is built on HLF-based, which contrasts with Ref. #3 (Pradana et al., 2020) use of ETH-based, suggesting an adapted approach to meeting specific industry needs, such as the rubber supply chain, compared to the other studies focus on rice, bio-energy, and coffee. This differentiation emphasizes our framework’s flexibility and enhances its applicability to a broader range of scenarios where such technologies can provide significant economic and operational benefits.

In the case of the rubber supply chain, Ref. #4 Buadit et al. (2023) emphasizes enhancing economic and environmental performance using green productivity (GP) and value chain analysis. It identifies resource inefficiencies and proposes clean technology (CT) solutions to optimize fertilizer use, water recycling, and energy efficiency, ultimately improving sustainability and competitiveness. The work from Ref. #5 Yadav et al. (2024) focuses on blockchain adoption in manufacturing and aims to overcome barriers such as high investment costs and a lack of digital skills to improve supply chain transparency and sustainability. While this study is centered on manufacturing, our work applies blockchain in an agricultural context, incorporating additional privacy protection using Differential Privacy. In contrast, Ref. #6 Hsieh et al. (2024) focuses on the circular economy (CE) in the rubber recycling industry, with an emphasis on remanufacturing and recycling rubber to improve resource efficiency and reduce pollution. Although our study also targets the rubber industry, our approach centers on traceability, market fairness, and data privacy, leveraging blockchain and IoT to create a decentralized system for farmers, whereas Ref. #6 Hsieh et al. (2024) is more focused on remanufacturing and resource conservation.

5.3.2 Remarks and findings

6 Conclusion

In this paper, we propose a conceptual framework that integrates blockchain technology, including Hyperledger Fabric, IPFS for data storage, and differential privacy for data-sharing protection, to transform the operational landscape of the Cambodian rubber supply chain. This framework addresses critical challenges such as data integrity, traceability, and trust in agricultural distribution while laying the foundation for real-world implementation. These technologies offer a secure and immutable system that ensures transaction security and fair pricing for farmers. By addressing issues such as corruption and fraud, this approach promotes sustainable practices in the Cambodian rubber sector, ultimately improving livelihoods, supporting economic stability, and encouraging environmentally friendly manufacturing practices. Future research should explore the application of IoT sensors and consider larger datasets and more extensive transaction throughput to better assess real-world scalability. Additionally, a cost-benefit analysis is required to evaluate implementation complexity, computational overhead, and privacy guarantees in relation to system performance and scalability. Further studies should also investigate the impact of different values on both privacy and data utility, providing a more comprehensive understanding of how influences specific applications. To strengthen the framework, several critical aspects beyond the scope of this paper should be considered in future work. These include long-term maintenance costs, energy consumption implications, and strategies for managing system obsolescence and upgrades. Conducting stress testing under adverse conditions and user acceptance testing are also important, along with developing a detailed roadmap for system adoption that includes training requirements for stakeholders and ensuring regulatory compliance. Integrating blockchain with advanced technologies such as artificial intelligence (AI) and machine learning (ML) could unlock further opportunities to predict demand, monitor environmental impact, and optimize supply chain operations. These enhancements pave the way for a more efficient, sustainable, and accountable agricultural supply chain in Cambodia, benefiting all stakeholders.

References

• 1

  AndroulakiE.BargerA.BortnikovV.CachinC.ChristidisK.De CaroA.et al (2018). “Hyperledger fabric: a distributed operating system for permissioned blockchains,” in Proceedings of the thirteenth EuroSys conference, 1–15.

  • Google Scholar

• 2

  AntonopoulosA. M.WoodG. (2018). Mastering ethereum: building smart contracts and dapps. O’reilly Media.

  • Google Scholar

• 3

  BelchiorR.VasconcelosA.GuerreiroS.CorreiaM. (2021). A survey on blockchain interoperability: past, present, and future trends. ACM Comput. Surv. (CSUR)54, 1–41. 10.1145/3471140

  • CrossRef
  • Google Scholar

• 4

  BruckmanV. J.HaruthaithanasanM.MillerR. O.TeradaT.BrennerA.-K.KraxnerF.et al (2018). Sustainable forest bioenergy development strategies in indochina: collaborative effort to establish regional policies. Forests9, 223. 10.3390/f9040223

  • CrossRef
  • Google Scholar

• 5

  BuaditT.UssawarujikulchaiA.SuchivaK.PapongS.RattanapanC. (2023). Green productivity and value chain analysis to enhance sustainability throughout the passenger car tire supply chain in Thailand. J. Open Innovation Technol. Mark. Complex.9, 100108. 10.1016/j.joitmc.2023.100108

  • CrossRef
  • Google Scholar

• 6

  ButerinV.et al (2014). A next-generation smart contract and decentralized application platform. white Pap.3, 2–1.

  • Google Scholar

• 7

  CachinC.VukolićM. (2017). Blockchain consensus protocols in the wild. arXiv preprint arXiv:1707.01873

  • Google Scholar

• 8

  CaroM. P.AliM. S.VecchioM.GiaffredaR. (2018). “Blockchain-based traceability in agri-food supply chain management: a practical implementation,” in 2018 IoT vertical and topical summit on agriculture-tuscany (IOT tuscany) (IEEE), 1–4.

  • Google Scholar

• 9

  ChristidisK.DevetsikiotisM. (2016). Blockchains and smart contracts for the internet of things. IEEE access4, 2292–2303. 10.1109/access.2016.2566339

  • CrossRef
  • Google Scholar

• 10

  CromanK.DeckerC.EyalI.GencerA. E.JuelsA.KosbaA.et al (2016). “On scaling decentralized blockchains: (a position paper),” in International conference on financial cryptography and data security (Springer), 106–125.

  • Google Scholar

• 11

  CuiY.GaurV. (2022). “Supply chain transparency using blockchain: benefits, challenges, and examples,” in Global logistics and supply chain strategies for the 2020s: vital skills for the next generation (Springer), 307–326.

  • Google Scholar

• 12

  DeyK.ShekhawatU. (2021). Blockchain for sustainable e-agriculture: literature review, architecture for data management, and implications. J. Clean. Prod.316, 128254. 10.1016/j.jclepro.2021.128254

  • CrossRef
  • Google Scholar

• 13

  DiepartJ.-C.KongR.KouP.WoodsK.De Alban TJ. D.JamaludinJ. (2023). Cambodian smallholder rubber sector, 2000 to 2021: trajectories of change

  • Google Scholar

• 14

  DworkC.KohliN.MulliganD. (2019). Differential privacy in practice: expose your epsilons. J. Priv. Confidentiality9. 10.29012/jpc.689

  • CrossRef
  • Google Scholar

• 15

  FirdausM.RheeK.-H. (2023). “Towards trustworthy collaborative healthcare data sharing,” in 2023 IEEE international conference on bioinformatics and biomedicine (BIBM) (IEEE), 4059–4064.

  • Google Scholar

• 16

  FirdausM.LarasatiH. T.RheeK.-H. (2023a). A blockchain-assisted distributed edge intelligence for privacy-preserving vehicular networks. Comput. Mater. and Continua76, 2959–2978. 10.32604/cmc.2023.039487

  • CrossRef
  • Google Scholar

• 17

  FirdausM.NohS.QianZ.LarasatiH. T.RheeK.-H. (2023b). Personalized federated learning for heterogeneous data: a distributed edge clustering approach. Math. Biosci. Eng.20, 10725–10740. 10.3934/mbe.2023475

  • Pubmed Abstract
  • CrossRef
  • Google Scholar

• 18

  HangS. C. (2009). Export competitiveness of the cambodian rubber sector relative to other greater mekong subregion suppliers: a simple descriptive analysis. ARTNeT Gt. Mekong Subregion (GMS) Initiat. Discuss. Pap. Ser. , 5.

  • Google Scholar

• 19

  HsiehH.-H.YaoK.-C.WangC.-H.ChenC.-H.HuangS.-H. (2024). Using a circular economy and supply chain as a framework for remanufactured products in the rubber recycling industry. Sustainability16, 2824. 10.3390/su16072824

  • CrossRef
  • Google Scholar

• 20

  IslamM.RehmaniM. H.ChenJ. (2024). Differentially private enhanced permissioned blockchain for private data sharing in industrial iot. Inf. Sci.658, 119997. 10.1016/j.ins.2023.119997

  • CrossRef
  • Google Scholar

• 21

  IvanovD.DolguiA.SokolovB. (2019). The impact of digital technology and industry 4.0 on the ripple effect and supply chain risk analytics. Int. J. Prod. Res.57, 829–846. 10.1080/00207543.2018.1488086

  • CrossRef
  • Google Scholar

• 22

  KamilarisA.FontsA.Prenafeta-BoldύF. X. (2019). The rise of blockchain technology in agriculture and food supply chains. Trends food Sci. and Technol.91, 640–652. 10.1016/j.tifs.2019.07.034

  • CrossRef
  • Google Scholar

• 23

  KrehbielS. (2019). “Choosing epsilon for privacy as a service,” in Proceedings on privacy enhancing technologies.

  • Google Scholar

• 24

  KumarR.SahooS. K. (2025). A bibliometric analysis of agro-based industries: trends and challenges in supply chain management. Decis. Mak. Adv.3, 200–215. 10.31181/dma31202568

  • CrossRef
  • Google Scholar

• 25

  MolyvannB. (2023). Contract-based agriculture production: a case study of organic rice production in Cambodia.

  • Google Scholar

• 26

  NakamotoS. (2024). Bitcoin: a peer-to-peer electronic cash system. Available online at: www.bitcoin.org.

  • Google Scholar

• 27

  OngaroD.OusterhoutJ. (2014). “In search of an understandable consensus algorithm,” in 2014 USENIX annual technical conference (USENIX ATC 14), 305–319.

  • Google Scholar

• 28

  PappachanP.RahamanM.SreerakuvandanaS.BansalS.AryaV. (2024). “Beyond current cryptography: exploring new frontiers,” in Innovations in modern cryptography (IGI global), 1–30.

  • Google Scholar

• 29

  PilkingtonM. (2016). “Blockchain technology: principles and applications,” in Research handbook on digital transformations (Edward Elgar Publishing), 225–253.

  • Google Scholar

• 30

  PradanaI. G. M. T.DjatnaT.HermadiI. (2020). “Blockchain modeling for traceability information system in supply chain of coffee agroindustry,” in 2020 international conference on advanced computer science and information systems (ICACSIS) (IEEE), 217–224.

  • Google Scholar

• 31

  ShalabyS.AbdellatifA. A.Al-AliA.MohamedA.ErbadA.GuizaniM. (2020). “Performance evaluation of hyperledger fabric,” in 2020 IEEE international conference on informatics, IoT, and enabling technologies (ICIoT) (IEEE), 608–613.

  • Google Scholar

• 32

  SousaJ.BessaniA.VukolicM. (2018). “A byzantine fault-tolerant ordering service for the hyperledger fabric blockchain platform,” in 2018 48th annual IEEE/IFIP international conference on dependable systems and networks (DSN) (IEEE), 51–58.

  • Google Scholar

• 33

  TianF. (2016). “An agri-food supply chain traceability system for China based on rfid and blockchain technology,” in 2016 13th international conference on service systems and service management (ICSSSM) (IEEE), 1–6.

  • Google Scholar

• 34

  TripoliM.SchmidhuberJ. (2018). Emerging opportunities for the application of blockchain in the agri-food industry

  • Google Scholar

• 35

  VukolićM. (2016). “The quest for scalable blockchain fabric: proof-of-work vs. bft replication,” in Open problems in network security: IFIP WG 11.4 international workshop, iNetSec 2015, Zurich, Switzerland, october 29, 2015, revised selected papers (Springer), 112–125.

  • Google Scholar

• 36

  WoodG.et al (2014). “Ethereum: a secure decentralised generalised transaction ledger,” in Ethereum project yellow paper 151, 1–32.

  • Google Scholar

• 37

  XiongH.DalhausT.WangP.HuangJ. (2020). Blockchain technology for agriculture: applications and rationale. Front. Blockchain3, 7. 10.3389/fbloc.2020.00007

  • CrossRef
  • Google Scholar

• 38

  XuR.ChenY.BlaschE.ChenG. (2018). Blendcac: a smart contract enabled decentralized capability-based access control mechanism for the iot. Computers7, 39. 10.3390/computers7030039

  • CrossRef
  • Google Scholar

• 39

  YadavA.SachdevaA.GargR. K.QureshiK. M.MewadaB. G.Al-QahtaniM. M.et al (2024). Challenges of blockchain adoption for manufacturing supply chain to achieve sustainability: a case of rubber industry. Heliyon10, e39448. 10.1016/j.heliyon.2024.e39448

  • Pubmed Abstract
  • CrossRef
  • Google Scholar

• 40

  ZhengZ.XieS.DaiH.ChenX.WangH. (2017). “An overview of blockchain technology: architecture, consensus, and future trends,” in 2017 IEEE international congress on big data (BigData congress) (Ieee), 557–564.

  • Google Scholar

• 41

  ZhengP.ZhengZ.LuoX.ChenX.LiuX. (2018a). “A detailed and real-time performance monitoring framework for blockchain systems,” in Proceedings of the 40th international conference on software engineering: software engineering in practice, 134–143.

  • Google Scholar

• 42

  ZhengQ.LiY.ChenP.DongX. (2018b). “An innovative ipfs-based storage model for blockchain,” in 2018 IEEE/WIC/ACM international conference on web intelligence (WI) (IEEE), 704–708.

  • Google Scholar