RiceChain-Plus: an enhanced framework for blockchain-based rice supply chain systems-ensuring security, privacy, and efficiency

Privacy and security

Maintaining data privacy and security is a significant problem in blockchain-based agricultural systems. Several studies use cryptographic methods to improve data security:

• Multi-Party Encryption: Xu et al. (2022) introduced a grain and oil food traceability system that integrates blockchain technology with multi-party hybrid encryption to ensure data security. The system, however functional, encountered scalability challenges and reliance on human data entry (Duan, Pang & Lin, 2023; Md Nasir et al., 2024).

• Blockchain and Asymmetric Cryptography: Shivendra et al. (2021) examined the use of blockchain and asymmetric cryptography to improve traceability in food and agricultural supply chains. Notwithstanding progress, challenges regarding data integrity and verification continued (Arfin et al., 2024).

• Consortium Blockchain Models: Saranya & Maheswari (2023) introduced a PoTx-based consortium blockchain model for agricultural traceability. Notwithstanding enhanced efficiency, vulnerabilities like DDoS attacks and energy inefficiencies remained (Yakubu et al., 2022).

RiceChain-Plus Contribution: RiceChain-Plus ensures safe data validation and keeps private data safe by combining Zero-Knowledge Proofs (ZKP) and cryptographic hashing (SHA-256). These procedures address issues pertaining to privacy violations and enhance overall system robustness.

Scalability

The scalability constraints of blockchain often impede its use in high-volume agricultural supply networks.

• Consensus Mechanisms: Yakubu et al. (2022) and Khanna et al. (2022) established a rice supply chain system using Ethereum’s Proof of Authority (PoA) consensus, enhancing scalability but encountering issues pertaining to decentralisation (Farooq et al., 2024).

• Cross-Chain Solutions: Peng et al. (2022b) developed a Multi-Blockchain Rice Refined Supervision Model (MBRRSM) that incorporates multi-party encryption and the Supervision Proof of Peers (SPOP) consensus mechanism. Nevertheless, it demonstrated lowered scalability and throughput (Han & Fang, 2024; Md Nasir et al., 2024).

RiceChain-Plus Contribution: Utilising a lightweight proof-of-authority consensus method and fog nodes for gathering data, RiceChain-Plus addresses scaling challenges by minimising computational overhead and facilitating quick transaction validation.

Energy consumption

Excessive energy usage continues to be an important roadblock to the deployment of blockchain technology in agricultural supply chains.

• Integration of IoT and Blockchain: Saranya & Maheswari (2023) used IoT devices with a hybrid blockchain architecture using Proof of Transaction (PoTx) consensus to improve efficiency. Nonetheless, energy consumption and vulnerability to DDoS attacks were significant drawbacks (Altaf et al., 2022; Yakubu et al., 2023).

• Hydroponic Vegetable Supply Chains: Suroso, Rifai & Hasanah (2021) developed a blockchain-based system for hydroponic vegetable supply chains that integrates IoT devices. Although effective in improving traceability, it encountered increased energy consumption (Rahman, Ooi & Lee, 2025).

RiceChain-Plus Contribution: RiceChain-Plus reduces energy consumption by implementing fog nodes and optimising cryptographic processes, making it a sustainable option for agricultural supply chains.

Data integrity and storage optimisation

Ensuring data integrity and optimising storage are essential for sustaining reliable and efficient systems.

• IPFS Integration: Wang et al. (2021) and Yao & Zhang (2022) used the InterPlanetary File System (IPFS) to mitigate storage challenges and enhance data retrieval efficiency. Despite their effectiveness, these systems encountered substantial installation expenses and susceptibility to collisions (Zhang, Jia & Chen, 2024).

• Merkle Trees: Cryptographic constructs such as Merkle Trees were used to ensure data privacy and integrity. Nonetheless, difficulties such as collision attacks continued to exist (Bosona & Gebresenbet, 2023).

RiceChain-Plus Contribution: Using SHA-256 cryptographic hashing and the assurance of data immutability, RiceChain-Plus upholds data integrity. The private blockchain design minimises overhead storage and improves data security.

Advanced integration with machine learning

The integration of machine learning with blockchain presents innovative methods for anomaly detection and data integrity (Cherbal et al., 2024; Li et al., 2022).

• Three-Tier Systems: Zhang et al. (2023) integrated blockchain technology with machine learning models, such as isolation forests and random forests, to improve data dependability. The system, albeit successful, had challenges generalising to new data and was susceptible to false data injection attacks (Salama & Eassa, 2024).

• Cross-Chain Data Management: Peng et al. (2022a) proposed a cross-chain methodology using unsupervised machine learning approaches to enhance data interchange. Notwithstanding progress, latency and energy consumption continued to pose issues (Li et al., 2024).

RiceChain-Plus Contribution: RiceChain-Plus mainly focusses on blockchain and cryptography methods. However, in the future, improvements could include machine learning models to make finding anomalies and validating data easier, which would help fix problems with current systems.

In conclusion, despite notable progress in agricultural traceability with blockchain in previous research, concerns like privacy, scalability, energy consumption, and data integrity remain unresolved. These problems are fixed in RiceChain-Plus by using fog nodes, cryptographic hashing, zero-knowledge proofs, and a streamlined proof of authority consensus process. These advances render it a resilient solution tailored to the specific requirements of the rice supply chain. Table 1 provides a summary of the relevant studies, classified by the approach used, the objectives sought, and the limitations faced. To implement a practical blockchain solution addressing the challenges highlighted in the literature, we developed a network model tailored to the rice supply chain, as discussed in the following section.

Fog nodes serving as intermediaries

Fog nodes in RiceChain-Plus, denoted as CHs, serve as intermediaries between sensor devices and the blockchain network, significantly improving efficiency. Besides aggregating data, fog nodes provide essential cryptographic functions to guarantee secure interaction and data integrity:

• SHA-256 Hashing: Sensor device data is hashed using the SHA-256 cryptographic method prior to transmission to the blockchain. This guarantees data integrity by allowing stakeholders to confirm that the data has remained unaltered throughout transmission or storage.

• Zero-Knowledge Proofs (ZKP): Fog nodes use ZKP to verify data integrity while preserving confidential information. The sensory data on product quality is validated for accuracy while maintaining confidentiality, hence assuring privacy and security across the network.

• Mutual Authentication: Mechanisms for mutual authentication are used between the devices in the system to avert impersonation and unauthorised access. Nonces and timestamps are used in the authentication process to prevent replay attacks and maintain session freshness.

These cryptographic procedures, together with data compression techniques, reduce transmission costs, improve security, and ensure secure transfer to the blockchain. The decentralised architecture of fog nodes decreases latency and prevents bottlenecks, particularly in resource-constrained settings.

Stakeholder-specific communication

Each CH, representing a stakeholder, is allocated a distinct Ethereum account (EA) for secure communication within the network. Transactions are digitally verified by the CHs using their private keys, hence assuring authenticity and non-repudiation. The central node, known as the admin or gateway node, functions as the principal aggregator, authenticator, and mining node. The admin node does the following functions:

• Transaction Management: The admin verifies transactions submitted by CHs, ensuring that only approved parties can interact with the blockchain.

• Block Addition: The admin node incorporates confirmed transactions into the blockchain ledger via the Proof of Authority (PoA) consensus process.

• Key Management: The admin allocates shared cryptographic keys to CHs at the initial registration stage to enable secure communication.

Smart contracts and blockchain operations

Smart contracts are integrated into the blockchain to automate transaction processing and allow stakeholders to monitor and track developments using mobile apps. These contracts implement stakeholder-specific regulations, including access control policies grounded on Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC), to dynamically manage permissions.

Data saved on the blockchain is session-specific, indicating its removal post-product expiry to alleviate computational burden and facilitate further on-chain transactions. Data is encrypted and structured according to stakeholder-specific regulations to preserve privacy and reduce redundancy. Only authorised individuals are permitted to decipher and access pertinent information, hence preserving the secrecy of sensitive documents.

Sensory nodes in the rice supply chain network

Sensory nodes are essential in maintaining the quality and efficiency of the value chain, from seed cultivation to consumption (Firdaus, Rahmadika & Rhee, 2021; Nguyen & Mohammadi, 2023; Vijayan et al., 2021). These nodes, deployed at various stages, collect critical data to optimize processes and ensure the quality of the product. They gather information at various stages of the process, such as monitoring environmental factors, seed status, and stock control in the seed supply domain. Sensory nodes in the farmland stage enhance growth characteristics and productivity by transmitting data to the FLCH. Sensory nodes in grain elevators preserve and maintain rice quality by transmitting data to the GECH for analysis. Sensory nodes in grain processing plants regulate quality, productivity, and safety, with the GPCH receiving the information. Sensory nodes in grain distribution domain monitor storage and transportation conditions, transmitting data to the GDCH. Sensory nodes in the retail domain evaluate the safety and quality of rice for consumers by transmitting information to the GRCH. Sensory nodes in the consumer domain ensure the safety and quality of rice, using sensors for temperature, humidity, gas, light, weight, vibration, pests, microbial, and optical detection. Strategically deploying these sensory nodes across the entire rice supply chain will maintain quality, safety, and efficiency at every level.

Adversary model

In the context of the RiceChain-Plus framework, the adversary model comprises various potential threats that aim to compromise the security, privacy, and efficiency of the blockchain-based rice supply chain system. The key types of adversaries considered in this model include:

• i. External Adversaries:

  • a.

    Eavesdroppers: These adversaries aim to intercept communication between the stakeholders in the supply chain. They might try to capture data such as sensor readings, transaction details, or personal information.

  • b.

    Attackers on Network Nodes: These adversaries attempt to compromise network nodes such as the cluster heads (CHs) or the gateway ( $G$). They might aim to manipulate the data, perform denial-of-service (DoS) attacks, or gain unauthorized access to sensitive information.

• ii. Internal Adversaries:

  • a.

    Malicious Insiders: These adversaries include compromised or malicious stakeholders within the supply chain, such as a dishonest farmer or processor. They might aim to tamper with the data, forge transactions, or disrupt the supply chain processes.

  • b.

    Compromised Devices: Sensory devices or cluster heads that are compromised could send false data, leading to incorrect information being recorded in the blockchain.

Security and privacy requirements

1. Confidentiality: Encrypts sensitive data during transmission and storage.

2. Integrity: Uses robust hashing algorithms for data verification.

3. Authentication: Employs mutual authentication mechanisms for accessing sensitive data.

4. Authorization: Defines clear access control policies restricting stakeholder permissions.

5. Non-repudiation: Records transactions in an immutable ledger.

6. Replay Attack Prevention: Uses timestamp-based checks and nonce mechanisms to prevent replay attacks.

7. Scalability: Design the system to handle growing transactions and stakeholders efficiently.

8. Privacy: Implements privacy-preserving techniques for sensitive information verification.

9. Anonymizes stakeholders’ private data and shares only necessary information among supply chain participants.

First security level: initialization and mutual authentication of stakeholders and their associated devices

This level provides detailed processes involved in the protocols used to validate stakeholders and their associated devices in the proposed framework.

Registration phase

Stage 0: The admin $\mathcal{G}$ register all stakeholders’ cluster heads $CH=\left\{C{H}_1,C{H}_2,C{H}_3,\dots C{H}_i\right\}$ and the corresponding mobile device Identifications $D=\left\{{\mathcal{d}}_1,{\mathcal{d}}_2,{\mathcal{d}}_3,\dots {\mathcal{d}}_i\right\}$. Each CH and the admin $\mathcal{G}$ are identified by their unique Ethereum address (EA).

Stage 1: Each CH generates a private key and a corresponding public key using elliptic curve cryptography parameters. Using its private key and the admin’s public key, each CH computes it secretes key $C{H}_{skey}$ using Elliptic Curve Diffie-Hellman (ECDH) algorithm.

Using this secrete key, the admin’s Ethereum address ${\mathcal{G}}_{EA}$, and its Ethereum address $C{H}_{EA}$, the CH generates, and stores shared secrete keys with $\mathcal{G}$ as follow:

(1) $${\mathcal{G}}_{skey}=h\left({\mathcal{G}}_{EA}\parallel C{H}_{skey}\right)$$

(2) $$\mathrm{C}{\mathrm{H}}_{share}=h\left(C{H}_{EA}\parallel C{H}_{skey}\right)$$

The computed keys are securely stored in a Hardware Security Module (HSM) to prevent unauthorized access.

Stage 2: Each CH $C{H}_i$ then chooses an identification $S_{id}$ to each sensor node $\mathcal{S}{n}_i$ in its cluster and store it.

Stage 3: Each CH shares ${\mathcal{G}}_{skey}$, $C{H}_{share}$, and $S_{id}$ with $\mathcal{G}$.

Given that the sensing data provided by all sensor nodes in the model are only for consumption of the registered users (stakeholders) in the supply chain network, each stakeholder will need to register its mobile device with which it will access these data when released. The process is outlined in the following stages.

Stage 4: The stakeholder selects a unique identification $S{H}_{id}$ and a strong password $S{H}_{psw}$ for their mobile device. The device generates a random number ${\mathcal{r}}_1$, selects its corresponding mobile device ID ${\mathcal{d}}_i\in D$ and computes the encapsulated password hash:

(3) $$E_{psw}=h\left({\mathcal{r}}_1\oplus S{H}_{psw}\oplus {\mathcal{d}}_i\right)$$

Then, $E_{psw}$ and $S{H}_{id}$ are shared with the $\mathcal{G}$.

Stage 5: Upon receiving $E_{psw}$ and $S{H}_{id}$, $\mathcal{G}$ generate another random number ${\mathcal{r}}_2$ and then compute the following values at the timestamp $T_1$:

(4) $${\phi }_1=h\left(E_{psw}\parallel T_1\right)$$

(5) $${\phi }_2=h\left(E_{psw}\parallel {\mathcal{G}}_{EA}\right)$$

(6) $${\phi }_3=h\left({\phi }_1\parallel {\mathcal{r}}_2\parallel {\mathcal{G}}_{EA}\right)\oplus h\left(E_{psw}\parallel T_1\right)$$

$\mathcal{G}$ stores these values ( ${\phi }_1$, ${\phi }_2$, ${\phi }_3$, ${\mathcal{r}}_2$, $T_1$) in its memory and then share them with the mobile device.

Stage 6: The mobile device stores these values and computes its encapsulated identification ( $E_{id}$) as follow:

(7) $$E_{id}=h\left(S{H}_{psw}\parallel S{H}_{id}\right)\oplus {\mathcal{r}}_1$$

The mobile device then stores the value ( $E_{id}$) in its memory. The summary of the registration phase is provided in Fig. 2.

User device login phase

Stage 1: The stakeholder enters $S{H}_{id}$ and $S{H}_{psw}$ into the mobile device with.

Stage 2: The user then selects the cluster head Ethereum address ( $C{H}_{EA}$) of the cluster from which the requesting data is and then enters the address of the admin ${\mathcal{G}}_{EA}$.

Stage 3: With reception of these information, the mobile device then computes the following values:

(8) $${\mathcal{r}}_1^{\ast }=E_{id}\oplus h\left(S{H}_{psw}\parallel S{H}_{id}\right)$$

(9) $$E_{psw}^{\ast }=h\left({\mathcal{r}}_1^{\ast }\oplus S{H}_{psw}\oplus {\mathcal{d}}_i\right)$$

(10) $${\phi }_2^{\ast }=h\left(E_{psw}^{\ast }\parallel {\mathcal{G}}_{EA}\right)$$

Stage 4: The device then checks if ${\phi }_2^{\ast }$ and ${\phi }_2$ are equal. If the result is true, then the $S{H}_{id}$ and $S{H}_{psw}$ of the stakeholder user are verified and then it moves to the next stage. Else, the session is terminated.

Stage 5: In this stage, the mobile device generates a random number ${\mathcal{r}}_3$ and then compute the following values at timestamp $T_2$.

(11) $${\beta }_1={\phi }_3\oplus h(E_{psw}\parallel T_1)$$

(12) $${\beta }_2=h\left(T_2\parallel {\mathcal{r}}_3\parallel {\beta }_1\parallel {\mathcal{G}}_{EA}\right)$$

(13) $${\beta }_3=\left({\mathcal{r}}_3\parallel T_2\right)\oplus {\beta }_1$$

The mobile device then submits the values ( $C{H}_{EA},{\beta }_2$, ${\beta }_3$) to the $\mathcal{G}$. The summary of the user device login phase is provided in Fig. 3.

Mutual authentication phase

The mutual authentication as a key important protocol in this work, was selected for its capacity to thwart impersonation and replay attacks by validating the identities of both parties via the use of nonces and timestamps. The following are the stages involved in this work.

1. Steps Executed by the Admin Gateway ( $\mathcal{G}$)

• i.

  $\mathcal{G}$ receives ${\beta }_2$, ${\beta }_3$ and computes the following at timestamp $T_3$: (14) $${\beta }_1^{\ast }={\phi }_3\oplus h(E_{psw}\parallel T_1)$$ (15) $${\beta }_1^{\ast }={\beta }_3\oplus \left({\mathcal{r}}_3\parallel T_2\right)$$

• ii.

  $\mathcal{G}$ checks if $T_3-T_2<\theta$. If true, the session continues; otherwise, it terminates.

• iii.

  $\mathcal{G}$ computes: (16) $${\beta }_2^{\ast }=h\left({\mathcal{r}}_3\parallel T_2\parallel {\beta }_1^{\ast }\parallel {\mathcal{G}}_{EA}\right)$$

• iv.

  If ${\beta }_2^{\ast }={\beta }_2$, the mobile device is verified. Otherwise, the session terminates.

• v.

  $\mathcal{G}$ generates a random number ${\mathcal{r}}_4$ and computes: (17) $${\gamma }_1=h\left(C{H}_{EA}\parallel {\phi }_1\parallel C{H}_{share}\parallel {\mathcal{r}}_4\parallel T_3\right)$$ (18) $${\gamma }_2=\left({\mathcal{r}}_3\parallel T_3\parallel {\mathcal{r}}_4\right)\oplus C{H}_{share}$$ (19) $${\gamma }_3={\phi }_1\oplus h(C{H}_{EA}\parallel h\left({\mathcal{r}}_4\right){\mathcal{r}}_3)$$

• vi.

  $\mathcal{G}$ stores and transmits ${\gamma }_1$, ${\gamma }_2$, ${\gamma }_3$ to the cluster head (CH).

• vii.

  Upon receiving $\omega$, ${\rho }_1$, ${\rho }_2$ from CH, $\mathcal{G}$ performs the following at timestamp $T_5$: (20) $$\mathrm{C}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{u}\mathrm{t}\mathrm{e}\mathrm{s}\left(\parallel {\mathcal{r}}_5\parallel T_4\right)={\rho }_2\oplus {\mathcal{r}}_4$$ $$\mathrm{V}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{f}\mathrm{i}\mathrm{e}\mathrm{s}\mathrm{i}\mathrm{f}{T}_5-T_4<\theta .\mathrm{I}\mathrm{f}\mathrm{f}\mathrm{a}\mathrm{l}\mathrm{s}\mathrm{e},\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{s}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{i}\mathrm{n}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{s}.$$ (21) $$\mathrm{C}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{u}\mathrm{t}\mathrm{e}\mathrm{s}{\rho }_1^{\ast }=h\left(T_4\parallel {\mathcal{r}}_5\parallel C{H}_{EA}\parallel C{H}_{share}\parallel T_3\parallel \omega \right),$$ $$\mathrm{I}\mathrm{f}{\rho }_1={\rho }_1^{\ast },\mathrm{C}\mathrm{H}\mathrm{i}\mathrm{s}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{f}\mathrm{i}\mathrm{e}\mathrm{d}.\mathrm{O}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e},\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{s}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{i}\mathrm{n}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{s}.$$

• viii.

  $\mathcal{G}$ computes: (22) $${\sigma }_1=h\left(\omega \parallel {\phi }_1\parallel {\mathcal{r}}_4\parallel T_5\parallel {\gamma }_1\right)$$ (23) $${\sigma }_2=h\left({\mathcal{r}}_5\parallel {\mathcal{r}}_4\parallel T_5\right)\oplus {\mathcal{r}}_3$$

• ix.

  $\mathcal{G}$ shares ${\gamma }_1$, ${\sigma }_1$, and ${\sigma }_2$ with the user device.

2. Steps Executed by the Cluster Head (CH)

• i.

  CH receives ${\gamma }_1,{\gamma }_2,{\gamma }_3$ and computes the following at timestamp $T_4$: (24) $$\left({\mathcal{r}}_3\parallel {\mathcal{r}}_4\parallel T_3\right)={\gamma }_2\oplus C{H}_{share}$$

• ii.

  CH checks if $T_4-T_3<\theta$. If true, the session continues; otherwise, it terminates.

• iii.

  CH computes: (25) $${\phi }_1^{\ast }={\gamma }_3\oplus h(C{H}_{EA}\parallel {\mathcal{r}}_4\parallel {\mathcal{r}}_3)$$ (26) $${\gamma }_1^{\ast }=h\left(C{H}_{EA}\parallel {\phi }_1^{\ast }\parallel C{H}_{share}\parallel {\mathcal{r}}_4\parallel T_3\right)$$

• iv.

  If ${\gamma }_1={\gamma }_1^{\ast }$, the values are verified. Otherwise, the session terminates.

• v.

  CH generates a random number ${\mathcal{r}}_5$ and computes: $$\omega =h\left({\phi }_1^{\ast }\parallel {\mathcal{r}}_3\parallel {\mathcal{r}}_4\parallel {\mathcal{r}}_5\right),$$ (27) $${\rho }_1=h\left(T_4\parallel {\mathcal{r}}_5\parallel C{H}_{EA}\parallel C{H}_{share}\parallel T_3\parallel \omega \right),$$ $${\rho }_2=h\left({\mathcal{r}}_5\parallel T_4\right)\oplus {\mathcal{r}}_4$$

• vi.

  CH transmits $\omega$, ${\rho }_1$, ${\rho }_2$ to the $\mathcal{G}$.

3. Steps Executed by the User Device

• i.

  The user device receives ${\gamma }_1$, ${\sigma }_1$, and ${\sigma }_2$ at timestamp $T_6$ and computes: (28) $$\left({\mathcal{r}}_5\parallel {\mathcal{r}}_4\parallel T_5\right)={\sigma }_2\oplus {\mathcal{r}}_3$$

• ii.

  It checks if $T_6-T_5<\theta$. If true, the session continues; otherwise, it terminates.

• iii.

  The user device computes: (29) $${\sigma }_1^{\ast }=h\left(\omega \parallel {\phi }_1\parallel {\mathcal{r}}_4\parallel T_5\parallel {\gamma }_1\right)$$

• iv.

  If ${\sigma }_1={\sigma }_1^{\ast }$, $\mathcal{G}$ and CH are verified. Otherwise, the session terminates.

The summary of the mutual authentication phase is provided in Fig. 4. All cryptographic key exchanges and authentication sessions are securely logged on the blockchain for accountability and auditability.

User password replacement phase

The user password replacement phase ensures secure updates of passwords for stakeholders’ devices. The following are the stages involved in this phase:

Stage 1: On the reception of the logging details ${\beta }_2$, ${\beta }_3$, the

Stage 1: The user enters $S{H}_{id}$ and $S{H}_{psw}$ and requests to replace the password.

Stage 2: The user selects a new password $S{H}_{psw}^{\ast }$

Stage 3: The mobile device then computes the following values:

(30) $${\mathcal{r}}_1^{\ast }=E_{id}\oplus h\left(S{H}_{psw}\parallel S{H}_{id}\right)$$

(31) $$E_{psw}^{\ast }=h\left({\mathcal{r}}_1^{\ast }\oplus S{H}_{psw}\oplus {\mathcal{d}}_i\right)$$

(32) $$E_{psw}^{\ast }=h\left({\mathcal{r}}_1\oplus S{H}_{psw}^{\ast }\oplus {\mathcal{d}}_i\right)$$

Stage 4: The device sends $E_{psw}^{\ast }$ and the request for password replacement to $\mathcal{G}$.

Stage 5: $\mathcal{G}$ computes:

(33) $${\phi }_2^{\ast }=h\left(E_{psw}^{\ast }\parallel {\mathcal{G}}_{EA}\right)$$

(34) $${\phi }_1^{\ast }=h\left(E_{psw}^{\ast }\parallel T_1\right)$$

(35) $${\phi }_3^{\ast }=h\left({\phi }_1^{\ast }\parallel {\mathcal{r}}_2\parallel {\mathcal{G}}_{EA}\right)\oplus h\left(E_{psw}^{\ast }\parallel T_1\right)$$

These values ( ${\phi }_2^{\ast }$, ${\phi }_1^{\ast }$, ${\phi }_3^{\ast }$) are shared with the mobile device.

Stage 6: The mobile device stores these values. With this, the old password is replaced successfully.

The summary of the user password replacement phase is provided in Fig. 5.

Following mutual authentication between stakeholders and related devices, the framework advances to a second layer of security controlling data access authorisation and the protection of sensitive information. This layer guarantees that private information is never leaked and that only authorised persons can access certain resources.

Second security level: security considerations during interactions among stakeholders in the framework

The RiceChain-Plus framework has been designed to address the critical security and privacy requirements of a blockchain-based rice supply chain system. This section demonstrates how the proposed system achieves Authorization and Privacy requirements during several interactions.

Summary of the proposed model

In summary, the RiceChain-Plus framework secures transaction flows using a two-level security model that ensures robust authentication, authorization, and privacy preservation across the rice supply chain. Below is the transaction flow summary:

• (1)

  Authenticate User & Device: Secure login with hashed credentials, nonces, and timestamps.

• (2)

  Mutual Authentication: Both user and system entities verify each other to ensure trust.

• (3)

  Access Control: RBAC and ABAC determine what data or functions the user can access.

• (4)

  Data Privacy Verification: ZKPs ensure sensitive data is validated without exposure.

• (5)

  Transaction Execution: Verified transactions are recorded on the blockchain for immutability and traceability.

To encapsulate the flow of interactions in the proposed framework, Algorithm 1 and Fig. 6 offer a procedural overview of the RiceChain-Plus integration pipeline.

Mitigation strategies for internal threats

The RiceChain-Plus architecture utilises strong methods to protect against internal threats, including malicious insiders (e.g., dishonest stakeholders like farmers or processors) and compromised devices (e.g., infiltrated sensor nodes or cluster heads). These countermeasures guarantee data integrity, message authenticity, and comprehensive resistance against threats, including replay attacks.

• (a)

  Safeguarding Against Malicious Insiders

• Malicious insiders may seek to manipulate data, fabricate transactions, or interfere with the supply chain. RiceChain-Plus mitigates these vulnerabilities by using cryptographic hash methods, ensuring blockchain immutability, and implementing defences against replay attacks:

  • i.

    Ensuring Data Integrity using Hashing:

    • •

      The architecture uses real-time validation at fog nodes to ensure data legitimacy, with each packet passing cryptographic integrity tests before being sent to the blockchain.

    • •

      Sensor nodes have distinct IDs and session-specific nonces, ensuring data from authorized devices is permitted, thus preventing tampering or erroneous data during data gathering.

    • •

      All interactions, transactions, or data blocks are hashed using the SHA-256 cryptographic hash algorithm, guaranteeing that any alteration to the data produces a unique hash result.

    • •

      For instance, the framework calculates a hash $h\left(M\right)=SHA256\left(M\right)$ for a transaction that includes sensitive data (e.g., rice quality measurements). The hash value is recorded on the blockchain in conjunction with the transaction data.

    • •

      During verification, the incoming data is rehashed, and the computed hash is compared to the stored hash. Any discrepancy signifies manipulation, resulting in the failure of the integrity check and obstructing malicious insiders from modifying data undetected.

  • ii.

    Irreversibility of Transactions:

    • •

      Once a transaction is inscribed in the blockchain, it becomes immutable, rendering it hard for malicious insiders to alter or erase data without notice.

    • •

      This guarantees responsibility for all parties, since any effort to falsify or alter previous data is impracticable.

  • iii.

    Protection Against Replay Attacks:

    • •

      Replay attacks include the interception of authentic data and its subsequent malicious retransmission to get unauthorised access or perpetrate fraud. RiceChain-Plus safeguards against such attempts using timestamps and nonces:

      • •

        Timestamp: Each transaction includes a timestamp (e.g., $T_1$) to guarantee data validity within a designated period. Upon receipt of a message, the system verifies the current time ( $T_2$) and computes the difference $T_2-T_1$. If this surpasses the maximum permissible delay (θ), the session is ended, and the message is designated as stale. This inhibits adversaries from retransmitting obsolete communications or transactions.

      • •

        Nonces: Randomly generated numbers for each session or transaction guarantee uniqueness. A nonce that has been previously used is never allowed again, rendering the reuse of intercepted transactions in a replay attack infeasible.

    • •

      In the process of mutual authentication, the mobile device produces a session identification ${\beta }_2$ using a random nonce $r_3$. The admin gateway $\mathcal{G}$ checks both $r_3$ and the timestamp $T_2$. Upon detection of a duplicate nonce or an expired timestamp, the session is terminated, therefore thwarting replay attempts.

  • iv. Mitigation of Fabricated Communications:

    • •

      Mutual authentication systems prevent malicious insiders from producing legitimate communications to impersonate another party. To generate a counterfeit message { ${\mathcal{d}}_i$, ${\beta }_2$, ${\beta }_3$}, the insider must calculate the following parameters: $${\beta }_2=h\left(T_2\parallel {\mathcal{r}}_3\parallel {\beta }_1\parallel {\mathcal{G}}_{EA}\right)$$

      $${\beta }_3=\left({\mathcal{r}}_3\parallel T_2\right)\oplus {\beta }_1.$$

    • •

      Nonetheless, in the absence of access to ${\beta }_1$, contingent upon private credentials like $S{H}_{psw}$ (stakeholder password) and ${\mathcal{r}}_1$ (random number), the insider is unable to generate correct values. These credentials are safeguarded by one-way hash algorithms and cannot be inferred or replicated within polynomial time.

• (b)

  Protection Against Compromised Devices

• Infiltrated sensor nodes or cluster heads may transmit erroneous data to interrupt the supply chain or alter blockchain records. RiceChain-Plus alleviates this threat by means of:

  • i. Validation of Data Authenticity:

    • •

      Authentication of each device’s communication occurs prior to the recording of its data on the blockchain. For example, communications across sensor nodes contain cryptographic hashes ${\phi }_1,{\phi }_1,{\beta }_1$, and session-specific random numbers ${\mathcal{r}}_3,{\mathcal{r}}_4$, which are authenticated by the cluster head or administrative gateway $\mathcal{G}$.

    • •

      Should any parameter fail validation, the data is discarded, therefore preventing exploited devices from introducing erroneous information.

  • ii. Tamper Resistance using Mutual Authentication:

    • •

      Mutual authentication guarantees that only permitted devices may engage in the protocol. For a compromised cluster head to successfully fabricate a legitimate message, it must fulfil the following criteria: $${\beta }_2=h\left(T_2\parallel {\mathcal{r}}_3\parallel {\beta }_1\parallel {\mathcal{G}}_{EA}\right)$$ $${\beta }_3=\left({\mathcal{r}}_3\parallel T_2\right)\oplus {\beta }_1.$$

    • •

      In the absence of session-specific parameters such as ${\beta }_1$, ${\mathcal{r}}_3,$ and ${\mathcal{r}}_4,$ the compromised device is incapable of producing authentic messages.

  • iii. Resistance to Replay Attacks:

    • •

      Replay attack mitigation strategies are also applicable to compromised devices. Timestamps and nonces guarantee that intercepted legitimate data cannot be repurposed to fabricate new transactions. Any attempt to retransmit previous communications is identified and denied by the verification procedure.

  • iv. Integrity of Recorded Data:

  • Despite a compromised device transmitting erroneous data, the verification procedure guarantees the preservation of data integrity. Only data that passes integrity tests is kept on the blockchain. Efforts to alter current records will be unsuccessful because of blockchain immutability.

The RiceChain-Plus architecture offers extensive safeguards against internal threats by guaranteeing data integrity, message authenticity, avoidance of replay attacks, and stringent device validation. The system efficiently eliminates data tampering, transaction forgery, and supply chain disruptions by using cryptographic hashes, timestamps, nonces, mutual authentication, and the immutability of blockchain technology. These procedures guarantee the dependability and safety of the supply chain, even against internal challenges.

Resilience against external adversaries

The proposed framework exhibits significant resistance against external attackers targeting related devices, including sensor nodes and gateway nodes. This resilience is achieved by strong cryptographic techniques and the secure management of protocol parameters, as shown below:

Defence Against Adversarial Communication Eavesdropping: The architecture presupposes that an adversary could intercept communications during the execution of the protocol. An adversary can attempt to formulate a legitimate message for $\mathcal{G}$ after capturing the parameters ${\rho }_1$ and ${\rho }_2$, where:

$${\rho }_1=h\left(T_4\parallel {\mathcal{r}}_5\parallel C{H}_{EA}\parallel C{H}_{share}\parallel T_3\parallel \omega \right),$$

$${\rho }_2=h\left({\mathcal{r}}_5\parallel T_4\right)\oplus {\mathcal{r}}_4$$

Nevertheless, the adversary is unable to produce a legitimate message without access to the secret values $\omega$ and ${\mathcal{r}}_5$, which are safeguarded by a one-way hash function. The irreversible characteristic of the hash function guarantees that these values cannot be rebuilt from captured data. Consequently, the adversary is unable to extract significant information or generate authentic messages, hence guaranteeing the protocol’s resilience against side-channel attacks aimed at sensor nodes.

Validation of Gateway Node Authenticity: The system guarantees that sensor nodes and user devices can authenticate the gateway node’s legitimacy in two principal attack scenarios:

• 1.

  Intercepted Communication Between $\mathcal{G}$ and Sensor Node:

• Should an adversary intercept the communication { $C{H}_{EA}$, ${\gamma }_1$, ${\gamma }_2$, ${\gamma }_3$} over the public channel, they may attempt to impersonate the gateway. Nonetheless:

  • •

    ${\gamma }_1$, ${\gamma }_2$, ${\gamma }_3$ are contingent upon the random integer ${\mathcal{r}}_4$, which is secured by the one-way hash algorithm $h()$. The irreversible characteristic of $h()$ inhibits an adversary from deriving ${\mathcal{r}}_4$.

  • •

    $\mathrm{C}{\mathrm{H}}_{share}$ is a cryptographic parameter that cannot be deduced in polynomial time because of its robust security.

  • Collectively, these procedures guarantee that the gateway node remains unimpersonated.

• 2.

  Intercepted Communication Between $\mathcal{G}$ and User Device:

• If an adversary intercepts the message { ${\gamma }_1$, ${\sigma }_1$, ${\sigma }_2$}, they may attempt to impersonate the gateway. Nonetheless:

  • •

    In the absence of ${\phi }_1$ and ${\mathcal{r}}_4$, the adversary is unable to calculate ${\sigma }_1$ or ${\sigma }_2$.

  • •

    The irreversibility of the one-way hash function guarantees that ${\phi }_1$ and ${\mathcal{r}}_4$ cannot be rebuilt from intercepted data.

• Thus, when the user device identifies an incorrect message, it ends the connection, thus mitigating gateway simulation attacks.

The proposed system utilises cryptographic primitives, including one-way hash functions and secure key exchange, to provide strong protection against external threats aimed at sensor and gateway nodes. These techniques protect communication, inhibit unauthorised access, and obstruct impersonation attempts, preserving the integrity and security of the supply chain network.

Proof of correctness for mutual authentication and key exchange phase

To verify the accuracy of the proposed mutual authentication protocol, we use the Burrows-Abadi-Needham (BAN) logic, a recognised framework for assessing the security attributes of authentication and key exchange protocols. The analysis confirms that the protocol attains the requisite security attributes, including mutual authentication, key freshness, and key validity. The following sections analyse the mutual authentication and key exchange phase of the proposed model using BAN logic to ensure it conforms to the desired security properties.

Key Concepts in BAN Logic

• (1)

  Beliefs: What principals (e.g., admin $\mathcal{G}$ and cluster head CH) believe to be true.

• (2)

  Freshness: A statement or a key is fresh if it has not been used before.

• (3)

  Jurisdiction: A principal can be trusted to say something about another principal.

• (4)

  Nonce: A random number used only once within a protocol run.

BAN Logic Notations

• $P|\equiv X$: Principal $P$ believes $X$.

• $P⊲X$: Principal $P$ sees $X$.

• $P|\sim X:$ Principal $P$ said $X$.

• $P|\Rightarrow X$: Principal $P$ has jurisdiction over $X$.

• $\mathrm{\#}\left(X\right):X$ is fresh.

Protocol Elements

• Principals: $\mathcal{G}$ and CH.

• Shared Keys: ${\mathcal{G}}_{skey}$ (shared key between $\mathcal{G}$ and CH), $C{H}_{share}$ (key derived by CH).

• Timestamps: $T_3,T_4,T_5,$ representing specific steps in the protocol.

• Random Numbers: $r_3,r_4,r_5,$ these ensures freshness of each session.

Initial Assumptions

• (1)

  $\mathcal{G}|\equiv \mathrm{\#}\left({\mathcal{r}}_4\right)$: $\mathcal{G}$ believes ${\mathcal{r}}_4$ is fresh.

• (2)

  $\mathcal{G}|\equiv {\mathcal{G}}_{skey}$: $\mathcal{G}$ believes ${\mathcal{G}}_{skey}$ is a good, shared key.

• (3)

  $\mathcal{G}|\equiv {\mathcal{G}}_{skey}\Rightarrow \left\{\mathrm{C}\mathrm{H}|\equiv {\mathcal{G}}_{skey}\right\}$: $\mathcal{G}$ trusts $CH$ to know ${\mathcal{G}}_{skey}$.

Protocol Messages and Translations

• Message 1: $\mathcal{G}\to CH:{\gamma }_1$, ${\gamma }_2$, ${\gamma }_3$

  • •

    $\mathcal{G}|\equiv$ $\mathrm{\#}\left(T_3\right)$: $\mathcal{G}$ believes $T_3$ is fresh.

  • •

    $\mathcal{G}|\equiv$ $\mathrm{\#}\left(r_4\right)$: $\mathcal{G}$ believes $r_4$ is fresh.

  • •

    $CH⊲{\gamma }_1$, ${\gamma }_2$, ${\gamma }_3$: $CH$ sees ${\gamma }_1$, ${\gamma }_2$, ${\gamma }_3$.

  • •

    From ${\gamma }_1=h\left(C{H}_{EA}\parallel {\phi }_1\parallel C{H}_{share}\parallel {\mathcal{r}}_4\parallel T_3\right)$:

    • •

      $CH|\equiv$ $\mathrm{\#}\left(T_3\right)$: CH believes $T_3$ is fresh.

    • •

      $CH|\equiv$ $\mathrm{\#}\left(r_4\right)$: CH believes $r_4$ is fresh.

  • •

    $CH|\equiv$ $\mathcal{G}|\equiv {\mathcal{G}}_{skey}\Rightarrow \{CH|\equiv {\mathcal{G}}_{skey}\}:CH$ believes $\mathcal{G}$.

  • •

    $CH|\equiv$ ${\mathcal{G}}_{skey}:CH$ believes the shared key ${\mathcal{G}}_{skey}$ is valid.

• Message 2: $CH\to \mathcal{G}:\omega ,{\rho }_1,{\rho }_2$

  • •

    $CH\mid \equiv \mathrm{\#}\left(T_4\right)$: $CH$ believes $T_4$ is fresh.

  • •

    $CH\mid \equiv \mathrm{\#}\left(r_5\right)$: $CH$ believes $r_5$ is fresh.

  • •

    $\mathcal{G}⊲\omega ,{\rho }_1,{\rho }_2$: $\mathcal{G}$ sees $\omega ,{\rho }_1,{\rho }_2$.

  • •

    From ${\rho }_1=h\left(T_4\parallel {\mathcal{r}}_5\parallel C{H}_{EA}\parallel C{H}_{share}\parallel T_3\parallel \omega \right)$:

    • •

      $\mathcal{G}|\equiv$ $\mathrm{\#}\left(T_4\right)$: $\mathcal{G}$ believes $4$ is fresh.

    • •

      $\mathcal{G}|\equiv$ $\mathrm{\#}\left(r_5\right)$: $\mathcal{G}$ believes $r_5$ is fresh.

  • •

    $\mathcal{G}|\equiv CH|\equiv {\mathcal{G}}_{skey}\Rightarrow \left\{\mathcal{G}\equiv {\mathcal{G}}_{skey}\right\}$: $\mathcal{G}$ believes $CH$ trust $\mathcal{G}$.

  • •

    $\mathcal{G}|\equiv {\mathcal{G}}_{skey}$: $\mathcal{G}$ believes the shared key ${\mathcal{G}}_{skey}$ is valid.

Goals Achieved

• (1)

  $\mathcal{G}|\equiv CH|\equiv {\mathcal{G}}_{skey}$: $\mathcal{G}$ believes $CH$ trust the shared key ${\mathcal{G}}_{skey}$.

• (2)

  $CH|\equiv \mathcal{G}|\equiv {\mathcal{G}}_{skey}$: CH believes $\mathcal{G}$ trust the shared key ${\mathcal{G}}_{skey}$.

The proposed mutual authentication and key exchange procedure adheres to the security attributes mandated by BAN logic. The analysis guarantees mutual authentication between the admin $\mathcal{G}$ and the cluster head $CH$, as well as the confidence in the established shared key ${\mathcal{G}}_{skey}$. The system ensures key freshness, safeguards against replay attacks, and facilitates secure mutual authentication. This formal proof of correctness confirms the resilience of the authentication step against prevalent threats in supply chain systems. To complement the security analysis, we conducted a detailed performance evaluation of the RiceChain-Plus framework under simulated network conditions, as described in the next section.

Simulation setup

The simulation was conducted using computers with Intel Core i7-6700 CPUs at 3.40 GHz, implementing the RiceChain-Plus model in Solidity and interacting with the Ethereum Virtual Machine (EVM) via Python modules like Web3.py. The simulation used the Metamask Ethereum wallet, the Rinkeby testnet, and a Proof-of-Authority (PoA) consensus method, ensuring uniform and unbiased testing conditions. Each scenario involved 100 transaction interactions between stakeholders over 100 min, allowing for activities like mutual authentication. This is based on accepted benchmarking approaches for assessing blockchain-based supply chains. This method offers statistically notable analysis of system performance. Although further extensive testing is expected for future work, the present findings satisfactorily support the efficiency of the system.

The simulation generated comprehensive data, enabling rigorous monitoring and validation of the RiceChain-Plus smart contract. The smart contract’s security was assessed using the Oyente tool, achieving 68% coverage of the EVM code and confirming the absence of common security flaws. Table 4 presents the smart contract vulnerability analysis for RiceChain-Plus, demonstrating its resilience against common blockchain attacks. The framework effectively mitigates risks such as reentrancy, integer overflows, and unauthorized access through well-defined security measures. The inclusion of role-based access control, nonces, and timestamp validation ensures robust protection against malicious exploits.

RiceChain-Plus has a cluster-based design in which each cluster head (CH) gathers and authenticates data prior to transmitting it to the blockchain. The model has not yet been implemented in a practical environment, but its design incorporates IoT devices with optimised resource allocation for enhanced energy efficiency. The frequency of data collection is continuously regulated according to network circumstances and stakeholder interactions to optimise real-time monitoring and computational efficiency. The measured transaction execution time in our simulations is around 44.5 ms, consistent with industry benchmarks for blockchain-based agricultural monitoring systems.

In the simulation, each cluster head device was represented by a unique Ethereum account to mimic real-world scenarios. The computational cost of each device was compared to the gas usage using MetaMask, and the validity of the simulated gateway (admin) device was verified with a separate Ethereum account. The study tested all models based on a sequence of transactions, ensuring that accounts were adequately funded to avoid interruptions.

We must acknowledge that this study does not cover the potential consequences of a cluster head device running out of funds, which could be considered a limitation. Nevertheless, all accounts were funded throughout the system design to ensure uninterrupted functioning, thereby eliminating the possibility of devices running out of funds.

Basic performance evaluations

The performance of RiceChain-Plus was assessed using several key criteria, including average execution costs, energy consumption, throughput, execution time, and transaction time. The results of these evaluations are detailed in the sections that follow.

Execution costs

This section compares the execution costs, specifically gas consumption, of the RiceChain-Plus model against four benchmark blockchain models: MBRRSM (2022), KRanTi (2024), PoTx (2023), and RiceChain (2022). RiceChain-Plus demonstrated the lowest and most consistent gas usage, ranging from approximately 43,860 to 45,407 gas units, indicating its high efficiency in transaction processing as depicted in Fig. 7. This efficiency is attributed to improvements in the consensus method, data management, and cryptographic approaches.

In contrast, the MBRRSM model had the highest gas consumption, suggesting it requires more computational resources due to complex or less optimized procedures. KRanTi showed moderate gas usage (46,800 to 48,277 gas units), affected by storage overheads and less optimal consensus mechanisms. PoTx had competitive gas consumption (42,800 to 44,205 gas units) due to its focus on optimizing transaction verification, but it still fell short of RiceChain-Plus’s efficiency. RiceChain (2022) was efficient, with gas usage slightly higher than RiceChain-Plus, ranging from 43,800 to 45,277 gas units.

Overall, RiceChain-Plus consistently showed the lowest execution costs, confirming its superior efficiency and optimization, making it a cost-effective and viable solution for blockchain-based agricultural supply chains. The other models displayed higher and more variable gas consumption, indicating less efficient processes. This analysis underscores RiceChain-Plus’s position as an efficient and practical choice for real-world applications.

Energy consumption

RiceChain-Plus demonstrates superior energy efficiency of 9.38828E−05 J averagely compared to benchmark models MBRRSM (2022), KRanTi (2024), PoTx (2023), and RiceChain (2022) which have average energy consumption of 0.000112504, 9.99106E−05, 0.00009973 and 0.000101697 J respectively. This efficiency is consistently observed across various interactions, as depicted in the Fig. 8. The RiceChain-Plus model consumes significantly less energy, highlighting its effectiveness in energy utilization.

The reduced energy consumption of RiceChain-Plus is largely attributed to its use of the PoA consensus mechanism, which is more energy-efficient than the Proof of Work (PoW) or Proof of Stake (PoS) mechanisms employed by the other models. Additionally, RiceChain-Plus leverages optimized SHA-256 hashing algorithms, which reduce computational overhead and minimize energy usage. This technological approach not only enhances energy efficiency but also speeds up transaction processing, contributing to the overall efficacy of the system.

The efficiency of RiceChain-Plus positively impacts its scalability and practical application, especially in agricultural supply chains where cost-efficiency and scalability are crucial. The model can handle a larger number of interactions without a significant increase in energy consumption, making it a cost-effective solution as the network grows. Although RiceChain-Plus has a slightly higher average execution cost compared to RiceChain (2022), its superior energy efficiency makes it the preferred option for managing agricultural supply chains.

Throughput analysis

RiceChain-Plus consistently outperforms benchmark models in throughput, maintaining an average throughput of 0.071201 transactions per second, as illustrated in Fig. 9. The minimal variation between its highest value (0.071205493 at Interaction 2) and lowest value (0.071197653 at Interaction 100) indicates stable performance. In comparison, MBRRSM shows an average throughput of 0.064835, peaking at 0.065831238 during Interaction 3 and dipping to 0.063303417 at Interaction 100. KRanTi averages 0.064384, with a high of 0.064882949 at Interaction 2 and a low of 0.06247292 at Interaction 100. PoTx records an average throughput of 0.065127, reaching 0.066376943 at Interaction 3 and falling to 0.063787976 at Interaction 100. RiceChain’s average is 0.064757, with values ranging from 0.06525077 at Interaction 2 to 0.062771114 at Interaction 100.

The superior throughput of RiceChain-Plus is attributed to its optimized PoA consensus mechanism, efficient data handling, and advanced hashing algorithms. The PoA method reduces computational overhead compared to traditional PoW and PoS methods, resulting in faster transaction processing. The use of SHA-256 optimized hashing algorithms ensures rapid and secure data integrity checks, reducing processing delays and improving overall performance.

Execution time analysis

RiceChain-Plus demonstrates remarkable efficiency with an average execution time of 44.5 milliseconds across all interactions, as shown in Fig. 10. This efficiency is primarily due to the PoA consensus process, which reduce computational expenses and accelerate transaction validation. In contrast, benchmark models exhibit longer execution times: MBRRSM averages 46 milliseconds, KRanTi 45.5 milliseconds, PoTx 45 milliseconds, and RiceChain 45 milliseconds. These models use more intricate or less streamlined procedures, resulting in extended execution durations.

RiceChain-Plus employs effective optimization techniques, including dynamic resource allocation and reduced computational complexity, to ensure faster execution times. The use of efficient hashing algorithms such as SHA-256 speeds up data verification and integrity checks, significantly reducing execution times. Consistent performance is essential in real-world applications, especially in agricultural supply chains where efficiency and dependability are critical.

Transaction time

RiceChain-Plus excels in transaction speed, averaging around 14.045 s per transaction, as depicted in Fig. 11. Short transaction times are crucial for maintaining operational efficiency in the supply chain. Benchmark models exhibit longer transaction times, ranging from 15.2 to 16.0 s, indicating less efficient transaction processing methods.

The superior transaction processing performance of RiceChain-Plus is enhanced by efficient network communication protocols and highly effective encryption algorithms. The PoA consensus mechanism significantly reduces the overhead associated with transaction verification and block formation, accelerating transaction processing. Efficient hashing algorithms ensure rapid data integrity verification, further reducing transaction processing times and enhancing overall efficiency.

Comparative discussion on security and privacy-based performance metrics

RiceChain-Plus demonstrates superior security and privacy measures compared to prior models such as MBRRSM, KRanTi, PoTx, and RiceChain. Unlike these models, which only partially meet essential security and privacy criteria, RiceChain-Plus fully integrates confidentiality, integrity, authentication, authorization, non-repudiation, privacy preservation, and protection against replay attacks.

Table 6 presents a quantitative comparison, replacing qualitative descriptors with actual performance values. A high score corresponds to a metric being fully satisfied using advanced cryptographic techniques and immutable records. A moderate score represents partial fulfilment where the model utilizes standard procedures that lack advanced security measures. A low score signifies minimal or no provisions for the metric.

RiceChain-Plus achieves high confidentiality through the implementation of Zero-Knowledge Proofs and SHA-256 encryption, whereas KRanTi and PoTx achieve moderate confidentiality with traditional cryptographic techniques. Similarly, RiceChain-Plus ensures strong data integrity, authentication, and protection against replay attacks via timestamp-based validations and secure key exchanges, whereas other models rely on less resilient fundamental mechanisms.

Moreover, the framework’s hybrid RBAC-ABAC system enhances authorization, surpassing models that rely solely on role-based systems. RiceChain-Plus also preserves privacy by employing ZKPs, enabling verification without exposing sensitive data—a capability either absent or only partially implemented in other frameworks. These advancements position RiceChain-Plus as the most secure and privacy-conscious solution for blockchain-based rice supply chain management.

Comparative discussion on scalability-based performance metrics

Scalability is a crucial factor in blockchain-based supply chain systems, as it determines the system’s ability to handle increasing data and transaction loads as the network grows. Table 7 provides numerical assessments of key scalability metrics, including transaction throughput, network latency, consensus efficiency, and network adaptation.

Among the analysed models, MBRRSM (2022) exhibits high throughput but suffers from high network latency, leading to an overall moderate scalability. KRanTi (2024) improves on-chain efficiency using IPFS but is limited by Ethereum’s Proof of Stake (PoS), restricting its scalability. PoTx (2023) introduces an optimized consensus mechanism but encounters moderate scalability limitations due to network adaptation constraints. RiceChain (2022) performs moderately but lacks recent advancements for scalability. In contrast, RiceChain-Plus delivers high scalability, supporting elevated throughput, reduced latency, and a highly efficient PoA consensus mechanism, making it the most scalable among the evaluated models. Considering these performance outcomes and design choices, we now present concluding remarks, outline known limitations, and describe future directions aimed at refining and expanding the framework.