Development of a Blockchain-Based Information Protection System with Hybrid R-Snowball Algorithm in a Biofuel Supply Chain

Abstract

The biofuel supply chain is a complex value chain spanning from production to consumption. Manipulating information such as geographical origin, raw material type, and quantity at the production stage can disrupt refinery production plans and cause supply–demand imbalances. Therefore, a transparent traceability system is essential. The existing centralized database architecture poses a high risk of supply chain service suspension due to even a temporary fault in the central server, and it lacks resilience. Furthermore, it is vulnerable to data forgery, making it urgent to secure information integrity. To resolve these issues, this study proposes a blockchain-based biofuel supply chain information protection system. This system utilizes Shamir’s Secret Sharing algorithm to distribute data location information across all nodes and introduces the R-snowball consensus algorithm, which combines the reputation score of nodes with the random sampling of Snowball. The system aims to secure resilience in the event of a failure, achieve reputation-based security, and provide preliminary evidence of robustness against internal and external threats under the tested conditions. Experimental results demonstrated that the proposed system achieved an average recovery time of within 0.03 s, regardless of the load volume. Furthermore, preliminary evidence under the tested conditions suggests that the security and robustness of the system were supported through the exclusion of internal malicious nodes via a reputation-based penalty logic, the defense against main chain takeover attempts in external attack scenarios involving multiple fake nodes (Sybil nodes), and the maintenance of consistent consensus times.

1. Introduction

With the recent advancement of artificial intelligence and the increase in cyberattacks, blockchain security technology—a distributed ledger technology that enables decentralized data synchronization without a central authority—is being utilized to protect product information from potential online threat actors [1,2,3]. Blockchain was developed in the cryptocurrency community as a distributed ledger technology to enable decentralized transactions and verification without the need for third-party financial institutions [4]. However, numerous blockchain networks now exist, supporting various currencies and digital services worldwide. Blockchain is playing an increasingly essential role in our daily lives, spanning banking, healthcare, supply chains, and tracking [5].

Blockchain technology is being utilized in supply chain management because it can enhance visibility and transparency. By sharing information in real time with partners across the entire supply chain, logistics efficiency and stability can be dramatically improved [6]. Blockchain records enable access to information about manufacturers, raw materials, and other aspects of a product, enabling product history tracking at every point in the supply chain [7,8,9,10,11]. Wu et al. proposed a parallel search algorithm based on bipartite graph maximum matching, reducing product tracking time overhead by up to 85.1% in blockchain-based supply chain traceability systems [12].

Like supply chains in other industries, the biofuel supply chain is a complex value chain spanning feedstock production to final biofuel consumption. Due to the dispersed nature and seasonality of feedstocks, establishing a stable supply chain management system is a key operational challenge [13]. Typically, biofuel supply chain data includes the type and quantity of feedstock produced, the production location, the type and volume of fuel produced at refineries, and the raw materials used in production, as well as the type and volume of fuel used at demand sites [14]. Among these, traceability is becoming increasingly important to prevent environmental impacts, such as environmental destruction, caused by raw materials and raw material-based fuels. The EU RED II and RED III directives are strengthening regulations by mandating strict raw material traceability and the establishment of a Union Database to ensure sustainable production traceability [15,16]. These regulations require supply chain participants to report the quantity, geographical origin, and raw material type of biofuels, bioliquids, and biomass fuels to the EU database [16].

The biofuel supply chain considered in this study focuses on the tracking of biofuel feedstock, a key element in the biomass supply chain. Manipulation of feedstock data can lead to quality degradation during refinery refining, failure to execute production plans, and insufficient demand at demand centers. To resolve these issues, this study develops a blockchain-based security system that enables supply chain participants to proactively manage data, ensures resilience by moving away from existing centralized database methods, and establishes data transparency while guaranteeing traceability. The proposed blockchain-based biofuel supply chain consists of the farm registration module for approving and managing farm (node) participation in the blockchain, the data and blockchain composition module for storing Radio Frequency Identification (RFID) data in InterPlanetary File System (IPFS) storage and the blockchain, the data import module for restoring and reading data stored in the blockchain, and the security validation module for verifying the synchronization of the distributed blockchain with the member database. Furthermore, this study develops and integrates a novel consensus algorithm known as R-snowball into the framework, which utilizes the calculated reputation scores of individual nodes during the system consensus process. Finally, experiments are conducted to verify the resilience, security, and robustness of the proposed system. Specifically, the average recovery time under various traffic loads during node failure situations is measured, and the trends in reputation score changes alongside the final success rate of excluding internal malicious nodes—which attempt to take over the internal network with manipulated blockchains—are analyzed. Additionally, the robustness of the system against external threats involving multiple fake nodes (Sybil nodes) is comprehensively evaluated. The contributions of this study are as follows: (1) A system is proposed that prevents unauthorized participants from participating in the blockchain by developing an R-snowball algorithm that calculates the reputation scores of blockchain members; (2) RFID input data is immediately distributed and stored to prevent third parties other than authorized supply chain participants from viewing or modifying the information; (3) Alongside the evaluation of resilience in response to node failures, the security and robustness of the proposed system are quantitatively evaluated through experiments simulating internal threats—assuming the hijacking of refinery node control—and external threat scenarios involving the mobilization of multiple Sybil (fake) nodes.

This study is structured as follows. Section 2 describes the characteristics of the biofuel supply chain and proposes a blockchain-based supply chain security technology. Section 3 presents the experiments conducted to verify the resilience, security, and robustness of the proposed R-snowball-based supply chain system. Section 4 and Section 5 discuss the research results and address the conclusions.

2. Materials and Methods

2.1. Biofuel Supply Chain and Information Protection

The biofuel supply chain is a complex value chain spanning raw material production to final consumption, consisting of biomass production, biomass logistics, biofuel production, biofuel distribution, and biofuel end-users [17]. Figure 1 provides an overview of the general biofuel supply chain. The biomass (or feedstock) production stage aims to minimize supply uncertainty by diversifying raw materials, ranging from agricultural and forestry by-products with distinct geographical and seasonal constraints to dedicated energy crops and aquatic resources that can be mass-produced [18]. The second stage, the biomass logistics system, integrates and manages the collection, preprocessing, storage, and transportation processes, and is key to overcoming the low energy density of raw materials and geographical and seasonal uncertainties [19]. The third stage, the biofuel production system, is the core process of converting raw materials into liquid fuel through physical and chemical processes at a biorefinery facility [20]. The produced fuel is delivered to consumers through the fourth stage, the biofuel distribution system, which varies depending on the characteristics of the fuel. Ethanol and other fuels have limited use in existing oil pipelines due to issues such as corrosiveness and stress corrosion cracking (SCC) [21]. Drop-in fuels, on the other hand, can utilize existing oil infrastructure (pipelines, storage tanks, etc.) without modification [22]. Finally, the final end-user stage for biofuels is where the fuel is actually consumed, such as in aviation, shipping, and road transport [23].

Looking at the data generated in the biofuel supply chain, biomass production involves factors such as raw material type (such as rice straw, corn, or cornstalks), regional availability, and seasonal harvest times. Biomass logistics requires the management of data on capacity constraints for each transportation mode, changes in raw material density through preprocessing, and conversion rates. Biofuel production involves refinery conversion yields and process parameters, inventory holding costs, and byproduct sales costs. Biofuel distribution considers infrastructure compatibility, such as corrosiveness in existing pipelines, and legal mixing restrictions. Finally, biofuel final destinations utilize data on regional demand density, price volatility, and local job creation impacts [17,24].

Biofuel supply chain data is used in a complex manner across multiple facilities, and if this data is compromised, such as through hacking, the entire supply chain could be threatened. Colonial Pipeline, the largest pipeline operator in the United States, suffered a ransomware attack on its central database in May 2021 [25]. While the operating equipment remained intact, the operator was forced to halt pipeline operations due to the loss of information used to record who took how much oil and bill for it. This led to a fuel shortage and an emergency across the eastern United States. This is a prime example of the vulnerability of a supply chain with a centralized database.

Furthermore, the controversy surrounding fake used cooking oil (UCO) is further compromising transparency in the biofuel supply chain. Since the mid-2020s, the US and EU countries have raised suspicions that used cooking oil imported from China may be blended with vegetable oils such as palm oil [26]. The US Congress, in particular, believes China is exploiting this practice to exploit US tax incentives and Renewable Identification Number (RIN) fraud under the Renewable Fuel Standard (RFS). Given these concerns, it is crucial to maintain data transparency and immutability in the supply chain.

As such, securing components within the biofuel supply chain is essential. This also applies to agricultural products, which are the raw materials for biofuels. Hasan et al. [27] argued that if the agricultural supply chain is not properly secured, transparency and data traceability, which allow verification of product origin and authenticity of food labels, are lacking, leaving consumers at risk of greenwashing and deceptive labeling. To address this, the authors utilized an Ethereum-based blockchain network combining real-time IoT sensor monitoring, smart contracts, and IPFS distributed storage. This framework supports transparent and reliable decision-making regarding food authentication from farm to consumer through smart contracts and tamper-proof logs.

2.2. Blockchain-Based Crop Byproduct Information Security System

This study proposes a blockchain-based security system to secure the biofuel supply chain. Specifically, it implements a blockchain-based traceability system for crop byproducts, which are the raw materials for biofuels. Fraudulent claims or data manipulation during the supply of crop byproducts, which are the raw materials for biofuels, can lead to system interruptions and other supply chain disruptions. To prevent malicious intent against data, blockchain technology is introduced. The proposed blockchain-based biofuel supply chain consists of four modules. The farm registration module approves and manages farm (node) participation in the blockchain. The data and blockchain composition module reads RFID data and stores it in IPFS storage and the blockchain. The data import module restores and reads data stored in the blockchain. Finally, the security validation module verifies the synchronization between the distributed blockchain and the member database. Figure 2 shows the overall framework for this, and detailed descriptions of each module are provided in the following sections.

2.2.1. Farm Registration Module

The farm registration module registers and approves new farms on the blockchain for their participation in the supply chain network. For a new farm, a feedstock producer, to join the supply chain network, each farm requires a private key for electronic transaction signatures and a master key share for data access in their local storage [28,29]. Once key generation is complete at the master and private key generation stage, the node derives a corresponding public key from the private key and transmits it to the refinery node, initiating the identity registration process at the node registration request stage. At the authority approval stage, the refinery node manager compares the pre-registration information of a farm with the applicant’s information to approve node registration and sends a verification request to the blockchain registration stage. The request of the refinery is verified through four steps: timestamp verification, hash value comparison, digital signature validity, and role authorization verification. Once access to the farm is approved, the blockchain registration stage mines a block to officially register the new farm on the blockchain. This information is synchronized to each node’s local database, making it verifiable by all users. Information stored in the local database is used later in the member verification process. The registration and authority approval function of the refinery node is activated only upon a new farm registration request and is not continuously operational. In all other functions, including data storage, blockchain composition, and consensus participation, the refinery node operates identically to farm nodes. Figure 3 schematically illustrates the actual farm registration process for refinery managers.

2.2.2. Data and Blockchain Composition Module

The data and blockchain composition module stores actual raw material data stored on RFID in the IPFS repository and distributes related information across the entire blockchain. In the meantime, this module processes raw data collected from RFID tags into a transaction format suitable for blockchain recording and stores it in a local database. RFID configuration information is broadly divided into physical identifiers (unique identifier (UID)), logistics dynamic information (time, quantity, type), and stakeholder information (worker name). In particular, it is combined with the unique identification number (Edge Node ID) of the device that reads data on-site and transmits it to the server to clarify the basis of data generation, and all time data is converted and stored according to the ISO 8601 standard [30].

In the RFID tagging stage, when an RFID tag is tagged to a reader, the key restoration and authority approval stage begins. This stage consists of the master key restoration process and the authority approval process on the refinery node. If the process passes, the data moves to the data sharding and IPFS storage stage, where data is entered into the refinery node. If the process fails, data storage is rejected. The data sharding and IPFS storage stage divides the data into P shards using Shamir’s secret sharing algorithm [28]. The divided shards are stored in the IPFS network storage of each farm and refinery node [31].

In the block mining and data storage stage, the location information values (content identifier (CID) values) of all shards are mined in the blockchain in the form of transactions. The proposed methodology utilizes a hybrid consensus mechanism combining Proof-of-Work (PoW) and reputation-based snowball (R-snowball) during this stage (see Section 2.2.5 for more information). In order to prevent indiscriminate block generation and spam data input, the first operation is to perform a Hashcash-based PoW calculation that requires computation to change the Nonce value and find a valid hash value. The Nonce value increases from 0 to find a valid hash value. If a valid hash value is found (e.g., when the difficulty is $d=4$ and the upper 16 bits are 0), the block generation is completed, and the node’s blockchain is updated. If the hash value is invalid, the block is not generated [32]. The next operation is for the node that created the block to broadcast the updated blockchain to other nodes. At this time, the receiving nodes derive a final consensus by calculating the final reputation score of the blockchain received through the R-snowball. Based on this consensus, each node updates its own blockchain and local database. Figure 4 shows the operation process of the module after RFID tagging.

2.2.3. Data Import Module

The data import module is for retrieving stored data. This module displays data recorded on the RFID when a specific farm is retrieved from the monitoring system. First, the block number of the required data is retrieved from the blockchain. The data shards are retrieved from nodes using the content identifier (CID) values (location information values) of the distributed shards corresponding to the block number. To verify retrieval authority, the master key share for the entire network is retrieved from each node and the master key is restored. If the master key is successfully restored, the data is restored using the data shards. If the restoration is successful, the data is displayed; if the restoration fails, the retrieval is rejected.

2.2.4. Security Validation Module

The security validation module verifies the integrity of the blockchain and member database in real time. First, the blockchain validation begins by retrieving the block index and the corresponding block’s tx_hash from the Records DB in Figure 2. Nodes then recalculate the Merkle root of each block to check for transaction falsification. The Merkle root is the final, top-level hash value obtained by encrypting all transaction data within a block, pairing them in a tree structure, and hashing them. It then uses the hash value of the previous block to verify the connection to the current block. This verifies the continuity of the chain. This verification prevents block tampering by storing the hash value of the previous block in the next block. The PoW is then re-executed for each block from the genesis block (the first block) to the latest block, and the recorded values are compared to verify the mathematical validity of the entire chain. Finally, the tx_hash value stored in the Records DB is compared with the corresponding blockchain transaction hash value. If they match, the integrity of the current block is confirmed. Afterwards, real-time cross-validation with peer nodes indicates that the locally stored blockchains match. If a discrepancy is found, a fork or discrepancy warning is issued through the UI.

The member DB validation checks the synchronization of the member DB to manage network participant permissions. Each node combines the node identifier (Node ID) and Status information obtained from the member DB to produce a unique status hash value. This hash value is compared with the values produced by peer nodes. If a match is found, the node’s member information is considered valid. If a match is not found, the member information is invalid.

2.2.5. R-Snowball Algorithm

Blockchain technology, which protects information in supply chain networks, relies on a consensus algorithm for updating new blocks when new data is entered during the data recording process. This study proposes a hybrid R-snowball algorithm that combines the probabilistic random subsampling technique of the Snowball protocol proposed by Rocket et al. [33] with a behavior-based reputation model unique to the biofuel supply chain [34,35]. This algorithm achieves the lightweight required for computationally constrained environments, such as RFID tags and IoT devices, while also solidifying finality led by authenticated internal nodes using a mathematical reputation system. The pseudocode of the R-snowball algorithm is presented in Algorithm 1. The algorithm consists of four stages: (1) reputation score calculation, in which the final reputation score for each node is determined by the sum of the identity-verified base score and the accumulated reputation score up to the calculation time; (2) random partial sampling, in which k nodes are randomly selected from the active peer set using a probabilistic subsampling technique to collect and validate candidate chains; (3) consensus weight calculation and chain confirmation, in which the consensus weight for each candidate chain is calculated as the sum of the reputation scores of its supporting nodes, and the canonical ledger is determined based on maliciousness verification results and predefined criteria; and (4) reputation update based on contribution, in which each node’s accumulated reputation score is updated by adding reward or punishment values according to the node’s role in the consensus process.

Algorithm 1. R-snowball consensus algorithm

$\mathbf{Input}:\mathrm{Local}\mathrm{chain}{C}_{local}$$;\mathrm{active}\mathrm{peer}\mathrm{set}\mathsf{\Omega }$$;\mathrm{trigger}\mathrm{node}{n}_{trigger}$$\left(\mathrm{optional}\right);\mathrm{sub}\text{-}\mathrm{sampling}\mathrm{size}K$$;\mathrm{finality}\mathrm{depth}{d}_f$$;\mathrm{participation}\mathrm{threshold}{W}_{PC}$ Output: Updated canonical chain; updated reputation scores Precondition: Proof-of-Work is completed before this algorithm is invoked in every consensus round.

▷ Stage 1: Reputation Score Calculation 1: $\mathbf{for}\mathrm{each}\mathrm{node}{n}_i\in \mathsf{\Omega }$ do 2:     $\mathbf{if}{n}_i\in$$\mathit{MemberDB}\mathbf{then}{a}_i$$\leftarrow W_{member}$ 3:     $\mathbf{else}{a}_i$$\leftarrow W_{guest}$ 4:     $P_{i,l}$$\leftarrow a_i+R_{i,l}$ 5:     $\mathrm{if}{n}_i\notin \mathit{MemberDB}$$\mathbf{then}{P}_{i,l}$$\leftarrow \mathrm{m}\mathrm{i}\mathrm{n}(P_{i,l},W_{guest}^{max})$ 6:     $P_{i,l}$$\leftarrow \mathrm{c}\mathrm{l}\mathrm{a}\mathrm{m}\mathrm{p}(P_{i,l},P_{i,l}^{min},P_{i,l}^{max})$ 7: end for

▷ Stage 2: Random Partial Sampling 8: $S$$\leftarrow \left\{n_{trigger}\right\}$$\mathrm{if}{n}_{trigger}\ne \varnothing$$;\mathbf{else}S$$\leftarrow \varnothing$ 9: $S$$\leftarrow S\cup$$\mathrm{RandomSample}(\mathsf{\Omega }\backslash S,K-|S\left|\right)$ 10: $\mathit{Votes}\left[\mathrm{Hash}\right(C_{local}$$.\mathrm{last}\left)\right]\leftarrow P_{self,l}$$;\mathit{ChainStore}\leftarrow \left\{C_{local}\right\}$$;\mathit{VerifiedPeers}\leftarrow \varnothing$ 11: $\mathbf{for}\mathrm{each}{n}_j\in S$ do 12:   $\mathrm{Fetch}{C}_j$$\mathrm{from}{n}_j$$;\mathbf{if}{C}_j=\varnothing \vee P_{i,l}<W_{PC}$ then continue 13:   $\mathbf{if}\neg \mathrm{ValidChain}(C_j$$)\mathbf{then}{P}_{j,l+1}$$\leftarrow P_{j,l}-5$; continue 14:   $\delta$$\leftarrow \mathrm{FindDivergenceIndex}(C_{local},C_j)$ 15:   $\mathbf{if}(\left|C_{local}\right|-\delta )>$$d_f$$\mathbf{then}\mathit{result}\leftarrow \mathit{Reject},P_{j,l+1}$$\leftarrow P_{j,l}+{\beta }_{punish}$; continue 16:   $\mathit{Votes}\left[\mathrm{Hash}\right(C_j$$.\mathrm{last}\left)\right]\leftarrow \mathit{Votes}\left[\mathrm{Hash}\right(C_j$$.\mathrm{last}\left)\right]+P_{j,l}$$;\mathit{Chainstore}\leftarrow \mathit{Chainstore}\cup \left\{C_j\right\}$$;\mathit{VerifiedPeers}\leftarrow \mathit{VerifiedPeers}\cup \left\{n_j\right\}$; 17: end for

▷ Stage 3: Consensus Weight Calculation and Chain Confirmation 18: $\mathbf{for}\mathrm{each}\mathrm{candidate}\mathrm{chain}{c}_m\in$$\mathrm{ChainStore}:S_{c_m}$$\leftarrow \mathit{Votes}\left[c_m\right]={\sum }_{i\in I}{N_{i,c_m}\times P}_{i,l}$ 19: $c_{final}$$\leftarrow {argmax}_{c_m}(length\left(c_m\right),S_{c_m},\mathrm{H}\mathrm{a}\mathrm{s}\mathrm{h}\left(c_m\right))$ 20: $\mathbf{if}\mathrm{length}\left(c_{final}\right)$$>$$\left|C_{local}\right|\bigwedge C_{final}$ is not history rewriting then result ← Simple Extension 21: $\mathbf{else}\mathbf{if}\mathrm{length}\left(c_{final}\right)$$>$$\left|C_{local}\right|\bigwedge$$\mathrm{Hash}(C_{final}$$.\mathrm{last})\ne$$\mathrm{Hash}(C_{final}$$.\mathrm{last})\bigwedge$$C_{final}$ is not a history rewriting then result ← Fork resolution 22: $\mathbf{if}\mathrm{result}=\mathit{Simple}\mathit{Extension}\vee \mathit{result}=\mathit{Fork}\mathit{Resolution}$$\mathbf{then}{C}_{local}$$\leftarrow c_{final}$$;\mathit{SyncDB}\left(C_{local}\right)$

▷ Stage 4: Reputation Update Based on Contribution 23: $\mathbf{for}\mathrm{each}{n}_i\in$$\mathit{VerifiedPeers}\mathrm{where}{n}_i$$\ne$self do 24:   $\mathbf{if}{n}_i$$\mathrm{voted}\mathrm{for}{c}_{final}\bigwedge$$\mathit{result}=\mathit{Simple}\mathit{Extension}\mathbf{then}\beta$$\leftarrow {\beta }_{fork}$ 25:   $\mathbf{else}\mathbf{if}{n}_i$$\mathrm{voted}\mathrm{for}{c}_{final}\bigwedge$$\mathit{result}=\mathit{Fork}\mathit{Resolution}\mathbf{then}\beta$$\leftarrow {\beta }_{ext}$ 26:   $\mathbf{else}\mathbf{if}{n}_i$$\mathrm{participated}\mathrm{then}\beta$$\leftarrow {\beta }_{pc}$ 27:   $\mathbf{else}\mathbf{if}\mathit{result}=\mathit{Reject}\bigwedge$$n_i$$\mathrm{is}\mathrm{Proposer}\mathbf{then}\beta$$\leftarrow {\beta }_{punish}$ 28:   $R_{i,l+1}$$\leftarrow R_{i,l}+\beta$ 29: end for 30: $\mathbf{return}{C}_{local}$, updated BehaviorDB

In the reputation score calculation stage, the final reputation score $P_{i,l}$ for each node ($n_i$) in each consensus round ($l$) is determined by the sum of the base score ($a_i$) based on identity verification and the accumulated reputation score ($R_{i,l}$) up to the calculation time (see Equation (1)).

$$P_{i,l}=a_i+R_{i,l}(P_{i,l}^{min}\le P_{i,l}\le P_{i,l}^{max})$$

(1)

where $P_{i,l}^{min}$ is the lower bound of the final reputation score that a node can have, and $P_{i,l}^{max}$ is the upper bound of the final reputation score that a node can have.

The base score ($a_i$) represents the difference between the scores of member nodes and guest nodes. This serves to reduce guest nodes’ influence in the consensus process by assigning a lower reputation score to guest nodes, thereby encouraging regular members to lead the consensus. For a sample size k of nodes selected from all nodes, a guest score cap is applied to ensure that a guest node’s score does not exceed the base reputation score of regular member nodes. The score cap $W_{guest}^{max}$ represents the maximum final reputation score a guest can have. It is calculated as shown in Equation (2).

$$W_{guest}^{max}=W_{member}/k$$

(2)

In the consensus weight calculation and chain confirmation stage, the consensus weight for a specific chain is calculated by multiplying the voting power score by the number of supporters, as shown in Equation (3).

$$S\left(c_m\right)=\sum _{i\in I}{N_{i,c_m}\times P}_{i,l}$$

(3)

where $c_m$ is the chain $m$ used for consensus, and $S\left(c_m\right)$ is a function that calculates the sum of the reputation scores supported by nodes for the chain as a consensus weight. $N_{i,c_m}$ is a binary variable that takes the value 1 if node $i$ supports the $c_m$ and 0 otherwise. $P_{i,l}$ is the final reputation score of node $i$ in round $l$.

After selecting the chain with the highest consensus weight ($c_{final}$), a maliciousness verification is performed to confirm that it satisfies the criteria. The Canonical ledger is determined based on the verification results and criteria. The criteria for determining the Canonical ledger are described in

Table 1. Criteria for determining the final ledger.

Result	Criteria
Reject	If the blockchain, except for the most recent n blocks, has been modified, reject a history rewriting.
Fork Resolution	If the length of $c_{final}$ is the same as that of the existing chain and $c_{final}$ is not a history rewriting, update to $c_{final}.$
Simple Extension	If the length of $c_{final}$ is longer than the length of the existing chain and it is not a history rewriting, the existing chain is updated to $c_{final}.$

.

In the reputation update based on contribution, each node updates the reputation scores of consensus nodes other than itself at each consensus round using Equation (4).

$$R_{i,l+1}=R_{i,l}+\beta$$

(4)

where $R_{i,l}$ is the accumulated reputation score up to round $l$, and $\beta$ represents the reward and punishment values according to the node’s role in the consensus process. Nodes that arrive at a correct consensus are given high rewards, while simple participants are given basic rewards. Conversely, nodes that attempt falsification are penalized, preventing them from participating in the consensus process. At this time, the node’s accumulated reputation score is updated by adding the reward and punishment values ($\beta$) according to the node’s role, to the accumulated reputation score up to round $l$. $\beta$ is determined based on Equation (5).

$$\beta =\{\begin{array}{c}{\beta }_{ext}if{n}_{i}votedfor{c}_{final}\wedge Final\_chain=SimpleExtension\\ {\beta }_{fork}if{n}_{i}votedfor{c}_{final}\wedge Final\_chain=ForkResolution\\ \begin{array}{c}{\beta }_{pc}if{n}_{i}participated\\ {\beta }_{punish}ifFinal\_chain=Reject\wedge n_{i}isProposer\end{array}\end{array}$$

(5)

where ${\beta }_{ext}$ is the reward received by node $n_i$ if the chain proposed by node $n_i$ is selected as a Simple Extension. ${\beta }_{fork}$ is the reward received by node $n_i$ if the chain proposed by node $n_i$ is selected as Fork Resolution. ${\beta }_{pc}$ is the reward received if the proposed chain is not selected despite participating in consensus. ${\beta }_{punish}$ is the punishment received by node $n_i$ if the proposed chain is rejected.

R-snowball must be performed after the Proof-of-Work (PoW) process in every round of blockchain consensus. This is significant in that it enhances reliability by rewarding nodes that consistently participate in a clear biofuel supply chain, and it punishes malicious behavior by nodes that are unidentified or defective, thereby ensuring blockchain stability.

2.2.6. Statistical Hypothesis Testing

In this study, Welch’s t-test [36] and Mann–Whitney $U$ test [37] are used to ensure statistical significance of the results in the experiment and discussion. To test the difference in mean recovery time between two independent groups, Welch’s t-test is applied, which is robust even in situations where the variances between groups are unequal and the sample sizes differ. The t-statistic for this test is calculated as shown in the following Equation (6).

$$t={\displaystyle \frac{\overline{x_1}-\overline{x_2}}{\sqrt{\frac{s_1^2}{n_1}+\frac{s_2^2}{n_2}}}}$$

(6)

where $\overline{x_i}$, $s_i^2$, and $n_i$ represent the mean, variance, and sample size of the groups, respectively. Here, the degrees of freedom ($\nu$) are approximated by the Welch–Satterthwaite equation, as shown in Equation (7).

$$\nu \approx {\displaystyle \frac{{(\frac{s_1^2}{n_1}+\frac{s_2^2}{n_2})}^2}{\frac{{(s_1^2/n_1)}^2}{n_1-1}+\frac{{(s_2^2/n_2)}^2}{n_2-1}}}$$

(7)

The calculated t-statistic and degrees of freedom ($\nu$) are ultimately used to determine statistical significance. The $\nu$ defines the shape of Student’s t-distribution followed by the test statistic t, and by deriving the p-value corresponding to the observed t-statistic on this distribution, the acceptance or rejection of the hypothesis is determined under the set significance level ($\alpha =0.05$).

In addition, to compensate for the limitations of the normality assumption due to the small sample size of the control group, a rank-based Mann–Whitney $U$ test is performed in parallel. After combining the observations of the two groups and ranking them, the statistic $U$ is calculated as follows using Equation (8):

$$U=n_1{n}_2+{\displaystyle \frac{n_1(n_1+1)}{2}}-R_1$$

(8)

where $R_1$ is the sum of the ranks of the first group observations. Under the null hypothesis, the expected value of $U$ and its variance are given by the following Equations (9) and (10).

$$E[U]={\displaystyle \frac{n_1{n}_2}{2}}$$

(9)

$$Var[U]={\displaystyle \frac{n_1{n}_2(n_1+n_2+1)}{12}}$$

(10)

The normal distribution Z-score is calculated by Equation (11). The Z-score is converted into a probability on the standard normal distribution to derive the p-value, and the decision to accept the hypothesis is made under a set significance level ($\alpha =0.05$).

$$Z={\displaystyle \frac{U-E\left[U\right]}{\sqrt{Var\left[U\right]}}}$$

(11)

Furthermore, to quantify the practical magnitude of the observed difference beyond statistical significance, Cohen’s d is employed as a measure of effect size. Cohen’s d is calculated as the standardized mean difference between two groups, as shown in Equation (12) [38]:

$$d={\displaystyle \frac{|{\overline{x}}_1-{\overline{x}}_2|}{S_{pooled}}}$$

(12)

where $S_{pooled}$ is the pooled standard deviation of the two groups, calculated as shown in Equation (13).

$$S_{pooled}=\sqrt{{\displaystyle \frac{\left(n_1-1\right)s_1^2+(n_2-1)s_2^2}{n_1+n_2-2}}}$$

(13)

Here, $s_i^2$ and $n_i$ represent the variance and sample size of each group, respectively. The resulting $d$ value is interpreted according to the conventional benchmarks proposed by Cohen, where values below 0.2 are considered negligible, values between 0.2 and 0.5 indicate a small effect, values between 0.5 and 0.8 indicate a medium effect, and values of 0.8 or above indicate a large effect. This allows for a complementary assessment of whether a statistically significant result also carries practical significance.

3. Experiments

3.1. Scenario

To evaluate the effectiveness of the proposed R-snowball-based supply chain system, experiments are conducted in terms of two key aspects: (1) system resilience, and (2) security and robustness. The six-node configuration adopted in this study reflects the realistic operational scale of the biofuel supply chain. As demonstrated in an empirical supply chain case study by Kim et al. [20], under the current 4% bioethanol blending policy, only five farms are actively selected as corn stover suppliers based on geographic and transportation cost efficiency, resulting in an effective network of five farms and one centralized facility. Therefore, the experimental environment consisted of a total of six nodes, and the sub-sampling size $\left(K\right)$ required to reach a consensus is set to 3. Specific experimental parameters are detailed in

Table 2. Parameters for experiments.

Category	Parameter Description	Symbol/Variable	Value
Network	Total number of nodes	$N$	6 (1 Refinery, 5 Farms)
Data Storage	Total Data Shards	$P\left(or{N}_{store}\right)$	5
	Data Recovery Threshold	$Q$	3
Master Key	Master Key Shares	-	6
	Master Key Threshold	$T$	4
Blockchain	Sub-sampling size	$K$	3
	PoW Difficulty	$d$	1
	Finality Depth for history check	-	3 Blocks
Reputation (Score)	Maximum Reputation Score	$P_{max}$	120
	Minimum Reputation Score	$P_{min}$	0
	Initial Score (Member)	$W_{member}$	80
	Initial Score (Guest)	$W_{guest}$	20
	Reputation Cap (Guest)	$W_{guest}^{max}$	26.6
	Participation Cap(All)	$W_{PC}$	10
Reputation (Update)	Reward for Simple Extension	${\beta }_{ext}$	1
	Reward for Fork Resolution	${\beta }_{fork}$	1
	Reward for Participation (Non-leader)	${\beta }_{pc}$	0.1
	Penalty for Malicious Act	${\beta }_{punish}$	−100

. The PoW difficulty of the blockchain is set to 1, the minimum level, to focus on the logical verification of the R-snowball algorithm by reducing the resources consumed during the PoW computation process. Additionally, the finality depth for the last blocks is designated as 3 to prevent history rewriting attacks. Regarding the reputation scores, the initial member score $\left(W_{member}\right)$ and initial guest score $(W_{guest}$) are set to 80 and 20, respectively. By setting the reputation cap for guests ${(W}_{guest}^{max})$ to 26.6 as defined in Equation (2), the system ensures that when the sub-sampling size $\left(K\right)$ is 3, the sum of guest node scores does not exceed 80, thereby maintaining the existing blockchain. Finally, the penalty score (${\beta }_{punish})$ is set to −100 to ensure that participation eligibility is not revoked at once, based on the scores accumulated between the maximum reputation score $\left(P_{max}\right)$ of 120 and the participation cap $(W_{PC}$) of 10 for all nodes.

First, the experiments evaluate node failure scenarios that may occur during operation to verify system resilience. The evaluation is divided into two categories: (1) failures of farm nodes (general participant nodes) and (2) failures of the refinery node (the network’s core administrator node). To analyze how quickly the system ensures data availability in such failure events, the system’s stable resilience is examined by generating incremental traffic loads upon failure for each node type and quantitatively measuring the recovery speed.

Second, the system’s state is evaluated regarding internal and external attacks to verify security and robustness. Specifically, this experiment focused on evaluating whether the proposed reputation-based R-snowball algorithm blocks an attacker’s influence and successfully defends the blockchain against attacks. The evaluation considers Byzantine faults, where control of the refinery node—serving as the network’s trust anchor—is hijacked, leading to malicious data manipulation. In this scenario, one refinery node is designated as the malicious node with no prior knowledge of the reputation mechanism, injecting a modified blockchain and repeatedly broadcasting manipulated consensus messages to overwrite the legitimate ledger, and the attack is considered successful if the manipulated blockchain replaces the existing legitimate ledger. In this experiment, the security success rate in defending against and punishing malicious consensus propagated by the hijacked node is assessed, along with the mathematical rigor of the reputation-based penalty logic. Furthermore, a Sybil attack scenario is established, where an attacker generates multiple fake nodes (Sybil nodes) to join the network and propagate malicious consensus [39]. The number of Sybil nodes is incrementally increased from 1 to 40, and each Sybil node is configured to broadcast a manipulated blockchain with a forged transaction history, collectively attempting to accumulate sufficient consensus weight to replace the legitimate chain. Through this, the security success rate of blocking the manipulated blockchain from taking over the existing ledger is calculated, and the system’s robustness is confirmed by measuring changes in consensus duration as the number of nodes increases.

Additionally, the experimental configuration for evaluating the performance of the proposed R-snowball-based blockchain information protection system is detailed in

Table 3. Experimental configuration.

Component	Specification
CPU	Intel Core i7-13700 @ 2.10 GHz
Memory	16 GB DDR4
OS	Windows 11
Network	1 Gbps Ethernet

. The experiments are conducted on a system equipped with an Intel Core i7-13700 processor and 16 GB of memory, running the Windows 11 operating system. The network communication environment is configured based on a 1 Gbps Ethernet connection. The entire blockchain network setup, the implementation of the consensus logic, and the experimental simulations are all developed and executed using Python 3.11.0 and IPFS version 0.38.1.

3.2. Results

Based on the experimental scenarios described in Section 3.1, this section evaluates node failure scenarios that may occur during operation to verify the resilience of the proposed system, and assess the system’s state against internal and external attacks to verify security and robustness. Figure 5 shows the recovery time distribution using a box plot when a failure occurs in a Farm node under various transaction load conditions (Load 0–100).

In Figure 5, examining the overall trend, the system operates stably, with the median recovery time (solid red line) maintaining a range between a minimum of 0.0125 s (Load 10) and a maximum of 0.0367 s (Load 40) across most load intervals. In particular, at Load 30 (IQR of 0.0198 s) and Load 40 (IQR of 0.0292 s), the lengths of the boxes representing the interquartile range (IQR) become significantly longer compared to other intervals, indicating a temporary increase in the variance of recovery times. However, as the load further intensifies in the maximum load intervals of Load 80–100, the medians paradoxically stabilize downward to a range of 0.0159 to 0.0247 s, and the variance also decreases. This demonstrates that even under extreme increases in transaction load, the system’s recovery performance does not continuously degrade within the designed consensus algorithm.

Meanwhile, outliers are observed in several intervals. The most notable examples are a single delayed measurement of 0.1038 s at Load 50 and a recorded value of 0 s at Load 70. However, considering that the overall distribution maintains a normal trajectory (i.e., median 0.0144 s at Load 50, median 0.0155 s at Load 70) and that such extreme values do not occur at the maximum load condition of Load 100, it is clear that this is not due to a structural bottleneck. That is, these outliers are analyzed as exceptional cases resulting from momentary communication delays inherent to distributed network environments or temporary verification errors within individual nodes.

Consequently, this distribution demonstrates that even under the highest transaction load environment (i.e., median 0.0159 s at Load 100), the Farm nodes consistently exhibit recovery speeds comparable to, or even faster than, those in the optimal, no-load state (i.e., median 0.0268 s at Load 0). This indicates a robust system architecture capable of immediately rectifying unexpected faults in certain nodes and maintaining the network without interruption.

Table 4. Statistical values for end-to-end recovery time of farm nodes.

	Criteria	Data Count	Average (s)	Standard Deviation (s)	95% Confidence Interval (s)	Welch’s t-Test	MWU Test	Cohen’s d
Group
Load 0		50	0.0285	0.0154	[0.0241, 0.0329]	p = 0.1820	p = 0.0715	0.2704
Load 10 to 100		49	0.0242	0.0164	[0.0194, 0.0289]

presents the results of measuring the recovery time when a farm node failed. The results were obtained by randomly shutting down farm nodes for 30 min and measuring the recovery time five times based on transactions (Load 0–100) that occurred during that time. For Load 0, 50 data points were collected from farm nodes operating under no-load conditions across the network. For Load 10–100, measurements across 10 load conditions yielded 49 data points in total, with one measurement error at Load 70 excluded. In Table 4, the average recovery time for Load 0 is 0.0285 s, and for Loads 10–100, the average recovery time is 0.0242 s. In Welch’s t-test, considering the difference in sample size and variance between the two groups, the difference in recovery time between the two groups is not statistically significant (p = 0.1820 > 0.05). In addition, as a non-parametric robustness check, there is no significant difference in the Mann–Whitney $U$ test (p = 0.0715 > 0.05). Furthermore, Cohen’s d (=0.2704) indicates a small effect size, confirming that the practical difference between the two groups is negligible. Therefore, it is statistically confirmed that the proposed blockchain maintains the same level of data recovery speed as the optimal state with no load (Load 0), even in a situation with extreme traffic load (Load 100).

Figure 6 shows the recovery time distribution using a box plot when a failure occurs in the Refinery node under various transaction load conditions (Load 0–100). The most prominent feature of this graph is that, regardless of the continuous increase in data load, the median recovery time (solid red line) remains stable within a very narrow range between 0.0154 s and 0.0185 s. In particular, the median for the optimal, no-load state (Load 0) is 0.0177 s, and the median for the maximum transaction load state (Load 100) is 0.0162 s, recording comparable levels. This demonstrates that even during heavy load processing, a failure in some nodes does not disrupt the entire system, and the recovery speed is consistently maintained without degradation.

Furthermore, the variance in the data recovery process is also very low. Excluding the vicinity of Load 70 (IQR of 0.0067 s), the lengths of the boxes representing the interquartile range (IQR) are formed thinly and uniformly around 0.001 to 0.005 s across most load levels. The maximum and minimum distribution of the data, indicated by the top and bottom whiskers, is also mostly concentrated within a narrow boundary of 0.011 to 0.026 s, indicating that the recovery process is not swayed by specific factors.

While the overall distribution shows high stability, minor outliers are observed in certain intervals. The most notable outlier is a measurement of 0.0374 s at Load 40, followed by measurements of 0.0325 s at Load 40 and 0.0285 s at Load 100, which is somewhat higher compared to the median of that interval. However, considering that 50% of the total data at Load 0 is densely concentrated between 0.0158 s and 0.0187 s (the IQR box range), it is evident that, similar to the situation in Figure 5, this is not a performance degradation due to structural bottlenecks or system defects. That is, these outliers are also analyzed as exceptional single cases resulting from momentary communication delays inherent to distributed network environments or temporary computational loads within individual nodes.

Consequently, this distribution demonstrates that even under the highest transaction load environment (Load 100), the Refinery node consistently exhibits recovery speeds comparable to those in the optimal, no-load state (Load 0).

Table 5. End-to-end recovery time of refinery nodes.

Load (Data Count)	0	10	20	30	40	50	60	70	80	90	100
Round 1	0.0172	0.0138	0.0135	0.0133	0.0138	0.0172	0.014	0.015	0.0132	0.0129	0.0131
Round 2	0.0153	0.0139	0.0146	0.0176	0.0325	0.0157	0.014	0.0136	0.0135	0.0172	0.0146
Round 3	0.0175	0.0152	0.0136	0.0146	0.0135	0.0128	0.0139	0.0124	0.0125	0.0139	0.017
Round 4	0.0129	0.0135	0.0135	0.0121	0.0138	0.0138	0.0163	0.0262	0.02	0.0141	0.0169
Round 5	0.014	0.0155	0.0148	0.0151	0.0161	0.016	0.0133	0.019	0.0155	0.0189	0.0113
Round 6	0.018	0.0235	0.02	0.0238	0.02	0.017	0.019	0.0166	0.017	0.0175	0.0245
Round 7	0.0374	0.0176	0.0164	0.019	0.0175	0.02	0.02	0.023	0.016	0.018	0.0211
Round 8	0.0179	0.018	0.0274	0.019	0.0179	0.022	0.0165	0.0245	0.019	0.019	0.0285
Round 9	0.019	0.016	0.0191	0.021	0.017	0.016	0.0161	0.018	0.017	0.015	0.0151
Round 10	0.0273	0.0175	0.016	0.017	0.017	0.016	0.017	0.0195	0.0166	0.016	0.0155
Average	0.0196	0.0165	0.0169	0.0172	0.0179	0.0167	0.016	0.0188	0.016	0.0163	0.0178
		0.017 (s)

evaluates the recovery time at the refinery node, which serves as the administrator node. The average recovery time was measured by randomly stopping operations for 30 min and varying the transaction input volume (Load 0–100). The average recovery time at Load 0 is 0.0196 s, and at Loads 10–100, it is 0.017 s. Welch’s t-test shows that the difference in recovery time between the two groups is not statistically significant (p = 0.2879 > 0.05). Additionally, the Mann–Whitney $U$ test also indicates no significant difference in the distribution between the two groups (p = 0.2335 > 0.05). Cohen’s d is 0.6383 (medium), indicating that the effect size is medium with no significant practical difference. In other words, it can be concluded that there is no statistically significant difference in data recovery speed according to load, including the administrator node.

Table 6. Outcome of malicious consensus for 5 nodes.

Chain Length	First Reputation Score	Final Reputation Score	Length per Consensus Duration (s)	2-Group Consensus Duration (s)	Success Rate
10	−13.37	-	0.0826	0.5363	100%
30	−2.2126	-	0.4584		100%
${50}_{\left(1\right)}$	7.079	-	1.1269		100%
${50}_{\left(2\right)}$	13.57	−84.49	0.5107	0.7118	100%
70	19.948	−79.924	0.3851		100%
100	38.454	−61.4398	1.2193		100%

shows the measurement results for reputation scores and consensus time when the proposed R-snowball punishment logic is applied at different blockchain lengths. To accurately observe the dynamic range of reputation score fluctuations, the experiment was designed with maximum and minimum reputation score limits. Blockchain lengths were set between 10 and 100, and the experiment was conducted 10 times for each length by manipulating the top 5 blocks of the chain to replace them with malicious blocks.

When the blockchain length is 10 or 30, the reputation score drops below the consensus threshold (10 points), and the attack is blocked by the first punishment logic alone. However, as the blockchain length increases, nodes with an initial reputation score exceeding 10 points begin to appear. When the blockchain length is 50, there are cases where the reputation score is below the consensus threshold, but there are also cases where it exceeds 10 points. When the blockchain length is 70 and 100, the consensus threshold is found to exceed 10 points in both cases. For blockchains that exceed the consensus threshold, R-snowball’s punishment logic is executed twice, and the final reputation score drops to 10 points or less, which is below the consensus threshold. Additionally, the consensus time does not show a special correlation with the blockchain length.

That is, if a node that has propagated malicious data maintains a reputation score above the consensus participation threshold of 10 even after the initial application of the penalty logic, it retains the right to participate in the subsequent consensus round, thereby triggering the penalty logic a second time. This demonstrates that even if an attacker attempts continuous attacks by exploiting a high reputation accumulated in the past, the system can robustly defend itself by cumulatively deducting points whenever malicious behavior is detected, in accordance with the R-snowball algorithm’s unique behavior-based evaluation design. Furthermore, the penalty logic demonstrates a 100% defense success rate against the introduction of manipulated blockchains across all chain lengths.

Welch’s t-test shows that the difference in resolution time between the one-punishment and two-punishment situations is not statistically significant (p = 0.3638 > 0.05). The average resolution time for the group punished once is 0.5363 s, and the average resolution time for the group punished twice is 0.7118 s.

Table 7. Sensitivity analysis with penalty score for malicious and maximum reputation score.

Parameter		Chain Length	First Reputation Score	Second Reputation Score	Final Reputation Score	Consensus Duration (s)	Success Rate
${\beta }_{punish}$	−50	${50}_{\left(1\right)}$	56.955	6.9655	-	0.3493	100%
		${50}_{\left(2\right)}$	62.35	12.46	−37.4375	1.0095
	−100	${50}_{\left(1\right)}$	7.079	-		1.1269	100%
		${50}_{\left(2\right)}$	13.57	−84.49	-	0.5107
	−120	50	−41.58	-	-	0.8217	100%
$P_{max}$	100	50	0	-	-	0.7808	100%
	120	${50}_{\left(1\right)}$	7.067	-	-	0.5229	100%
		${50}_{\left(2\right)}$	12.68	0	-	0.9526

presents the sensitivity analysis for ${\beta }_{punish}$ and $P_{max}$ under a fixed transaction load of 50, with all other parameters identical to those in Table 2.

The ${\beta }_{punish}$ analysis is conducted without minimum and maximum reputation bounds, consistent with the condition of Table 6. In the ${50}_{\left(1\right)}$ case, the reputation score of 56.955 drops to 6.9655 following the second penalty, falling below the $W_{PC}$ threshold and resulting in exclusion. In the ${50}_{\left(2\right)}$ case, the reputation score of 62.35 drops to 12.46 following the second penalty, remaining above the $W_{PC}$ threshold and surviving, and further drops to −37.4375 after the third penalty, falling below the $W_{PC}$ threshold and resulting in exclusion. While this renders the configuration vulnerable to persistent attackers, the gradual score reduction offers a lenient policy that allows penalized nodes to remain active and recover. When ${\beta }_{punish}=$ −100, in the ${50}_{\left(1\right)}$ case, a penalty applied at a reputation score of 7.079 upon the first detection results in immediate exclusion. In the ${50}_{\left(2\right)}$ case, the reputation score of 13.57 at the first detection drops to −84.49 following the penalty, falling below the $W_{PC}$ threshold and resulting in exclusion. This configuration satisfies the design condition $P_{max}$(120) − $\left|{\beta }_{punish}\right|$(100) > $W_{PC}$(10), implementing a graduated response while maintaining security. When ${\beta }_{punish}=$ −120, exclusion is enforced upon the first detection, as the reputation score immediately falls below the $W_{PC}$ threshold, offering the strongest attack resistance.

For the $P_{max}$, the minimum and maximum reputation bounds are applied. When $P_{max}=$ 100, the attacker’s maximum achievable reputation score equals the penalty magnitude, resulting in immediate exclusion with no opportunity for recovery. When $P_{max}=$ 120, the attacker retains a residual reputation score of 12.68 after the first penalty in the ${50}_{\left(2\right)}$, exceeding the $W_{PC}$ threshold and granting one additional chance before final exclusion. This indicates that $P_{max}$ directly controls how many times an attacker can be punished before exclusion, and the value of 120 is established to balance security with a single-chance graduated response.

Table 8. Consensus duration and success rate with various Sybil nodes.

Sybil Nodes	Consensus Duration (s)							Success Rate (%)
	Refinery	Farm A	Farm B	Farm C	Farm D	Farm E	Average
1	0.08151	0.1148	0.102	0.0614	0.078	0.1042	0.0909	100%
10	0.0766	0.1138	0.1029	0.0907	0.0849	0.1143	0.0989	100%
20	0.0755	0.1062	0.1001	0.0504	0.0746	0.0839	0.0818	100%
30	0.09	0.1022	0.0846	0.0501	0.0716	0.0758	0.079	100%
40	0.0757	0.1041	0.0904	0.4911	0.0740	0.0699	0.0772	100%

presents the performance evaluation results of the R-snowball algorithm according to the variation in the number of fake nodes (Sybil nodes) and their consensus propagation under a Sybil attack scenario. The experiments were repeated 10 times for each case, increasing the number of fake nodes from 1 to 40 in increments of 10. Key indicators include the consensus time per Sybil node measured by legitimate nodes (Refinery and Farm nodes) and the success rate of defending against the propagation of manipulated blockchains by Sybil nodes.

In Table 8, even if the number of fake nodes disrupting the network increases, the average consensus time of all system nodes remains less than 0.1 s. This means that an increase in malicious forgery nodes did not lead to consensus delays. The system has a 100% defense success rate in all situations, which implies that the consensus logic based on the R-snowball algorithm sampling maintains a constant consensus time regardless of the number of Sybil nodes. Furthermore, even if a fake node intrudes from the outside and propagates a manipulated blockchain, the reputation score of that node does not exceed the preset $W_{member}$ score, so it can be confirmed that the blockchain defense rate of the normal node has reached 100%.

Figure 7 shows the distribution changes in the overall consensus duration using a box plot as the number of malicious Sybil nodes (1, 10, 20, 30, and 40) within the network increases. To analyze the trend of the primary data distribution, outliers have been excluded from this graph.

The most notable aspect of this graph is that even under an extreme Sybil attack scenario where the number of attack nodes continuously increases up to 40, the median consensus duration (solid red line) is maintained within a very narrow range of 0.079 to 0.097 s. When a single Sybil node is injected, the median is 0.091 s, and it exhibits a slight upward trend to 0.097 s when 10 nodes are present. However, in the subsequent intervals where a large number of fake nodes (20–40) are added, the system demonstrates resilience as the median paradoxically stabilizes downward to a level of 0.080 to 0.083 s.

Furthermore, the interquartile range (IQR), which indicates data variability, remains very narrow at 0.015 to 0.025 s across most intervals. The maximum and minimum distribution of the overall data, represented by the top and bottom whiskers, also stably converges within a boundary of 0.05 to 0.115 s. That is, despite a 40-fold increase in attack nodes, the variance in data processing is controlled at a level comparable to the initial state.

Consequently, this distribution demonstrates that the proposed consensus algorithm not only prevents consensus delays and system performance degradation in a Sybil attack environment involving multiple fake nodes but also effectively defends against malicious network disruption attempts, thereby maintaining fast and uniform data processing speeds without system paralysis.

4. Discussion

Through the experiments in Section 3, it can be seen that the proposed blockchain-based security system possesses the capability to defend against anomalies caused by internal and external threats. In particular, the proposed R-snowball algorithm prevents unauthorized modification of data recorded on the blockchain through reputation scores. While existing snowball algorithms focused solely on rapid consensus and carried security risks, the R-snowball algorithm solves this problem by imposing reputation score penalties on nodes attempting to distribute modified data. The biofuel industry faces ongoing risks such as strict environmental regulations (e.g., EU RED II/III), duplicate payments of subsidies and credits, and origin laundering [40], but utilizing the proposed algorithm can prevent data modification within the supply chain.

Furthermore, the proposed blockchain enables recovery through a distributed network even if some blockchain nodes fail. The proposed system can recover data in 0.03 s, even if some nodes are destroyed or disconnected. This means that system recovery does not take a significant amount of time, even if the systems of nodes affected by IT infrastructure failures or ransomware attacks are replaced. Therefore, it is effective to adopt blockchain technology to reduce security threats when establishing a biofuel supply chain.

These contributions are best understood in the context of security threats unique to the biofuel supply chain. Colonial Pipeline suffered a ransomware attack in May 2021 and was forced to halt operations despite intact equipment, which is a prime example of the vulnerability of a centralized database architecture, and the ongoing controversy over fraudulent UCO imports further illustrates that origin data manipulation is an active and financially motivated threat in this domain [25,26]. The original Snowball protocol provides light-weight probabilistic sub-sampling but offers no identity management or defense against internal Byzantine behavior, whereas R-snowball addresses these limitations by introducing identity-differentiated base scoring with a mathematically defined guest score cap, behavior-based cumulative reputation updates that progressively exclude malicious nodes, and a finality depth mechanism that protects confirmed blocks from history-rewriting attempts, constituting an algorithmic advance over existing Snowball-family and general-purpose blockchain traceability frameworks.

The proposed system addressed the data management challenges inherent to the biofuel supply chain, where feedstock data is generated across geographically dispersed farms and must satisfy strict origin traceability requirements. Unlike general supply chain traceability systems, which primarily focus on transparency and immutability, the biofuel supply chain requires identity-based access control to distinguish authenticated feedstock suppliers from unauthorized participants, and tamper-proof distributed storage to ensure that origin data remains verifiable throughout the farm-to-refinery segment. These requirements directly motivate the proposed combination of R-snowball consensus and IPFS-based sharded storage, which together provide a data management framework tailored to the operational and regulatory constraints of the biofuel domain.

5. Conclusions

This study proposes a blockchain-based information protection system designed to ensure data transparency and block security threats within the complex value chains of the biofuel supply chain. In particular, considering the characteristics of real-world agricultural supply chains where the number of participating nodes can rapidly increase due to raw material collection, the R-snowball algorithm was devised and applied to the system. The algorithm is designed so that only sampled nodes participate in the consensus process. A reputation score is defined for each node to numerically assign participation over time, utilizing it for bonus points for consensus participation, equilibrium situations, and defense against malicious consensus propagation. Experimental results showed that the proposed system demonstrated rapid data synchronization and ledger recovery capabilities within 0.03 s, even when some nodes were destroyed or disconnected. The R-snowball consensus algorithm, combined with punishment logic, identified malicious manipulation attempts during Byzantine faults and continuously penalized reputation scores by keeping them below the threshold for consensus participation, thereby suggesting that the integrity of supply chain governance can potentially be maintained under the tested conditions. This implies that the proposed system goes beyond simple data storage functions, providing preliminary evidence of its potential to protect the biofuel supply chain from internal and external security breach attempts through a reputation-based autonomous defense mechanism under the tested conditions. In conclusion, this study provides preliminary proof-of-concept evidence for the feasibility of enabling farms that face difficulties in establishing expensive IT infrastructure to participate in a blockchain network using only standard PCs. This suggests the potential of a blockchain-based traceability system across the entire biofuel supply chain, involving multiple farms serving as raw material suppliers.

However, this study has several limitations that should be addressed in future work. The experiments were conducted under controlled conditions that may not fully reflect real-world deployment environments, and the scope of the security evaluation remains bounded by the experimental design. The proposed system is expected to work effectively in permissioned biofuel supply chain networks comprising a small number of authenticated participants, and future work should address broader validation scenarios, real-world deployment and cost analysis. Furthermore, research should continue to establish a more sophisticated and flexible security response system by introducing a machine learning-based intelligent reputation management model.