A collaborative data storage with incentive mechanism for blockchain-based IoV

Storage optimization techniques for blockchain

In the realm of blockchain storage optimization techniques, three primary approaches are explored: node-dependent optimized storage (Jayabalan & Jeyanthi, 2022), incorporating coding mechanisms (Han et al., 2024), and utilizing cloud storage for backup and offloading (Fu et al., 2024). We survey the recent literature and present a summary, as shown in Table 1.

Enhancing security and privacy in biov through incentive mechanisms

In the Internet of Vehicles (IoV), ensuring the security and reliability of data storage is crucial due to the vast amounts of sensitive and real-time information exchanged among vehicles (Liu et al., 2022a; Liu et al., 2022b), RSUs, and central servers. Traditional IoV data management approaches often suffer from centralization risks, including single points of failure, data tampering, and unauthorized access (Ma et al., 2022). To address these challenges, blockchain technology has emerged as a decentralized solution that enhances data security, integrity, and traceability (Hizal, 2023).

The system model

Adhering to a hierarchical approach, this article presents a data storage model for BIoV (Mathur et al., 2023), as depicted in Fig. 1. The model comprises a four-tier data storage framework: perception, edge, blockchain, and cloud layers. Each layer is detailed as follows:

Perception layer: the primary function of the perception layer is to facilitate communication between vehicles and RSUs regarding road information. This framework assumes that all information, such as V2X data, is trustworthy. To ensure the legitimacy of vehicles within the IoV network, all vehicles must be authorized by a trusted party (TP) edge layer: in this framework, the edge layer refers to the RSUs, which are responsible for communicating with vehicles within a specific range, aggregating messages, implementing consensus mechanisms, generating data blocks, storing data, and offloading data. The blockchain network is deployed on RSU nodes using the proof-of-work (PoW) consensus algorithm. RSUs compete to store data blocks and earn incentives through smart contracts.

Cloud layer: this layer consists of cloud storage that manages data offloading from RSUs based on block access frequency. It secures multiple cloud storage spaces to house infrequently accessed data offloaded by RSUs, thereby ensuring data redundancy. This approach also safeguards against data loss owing to cloud server failures or corruption.

Blockchain layer: in the framework, the blockchain service layer is responsible for selecting RSUs nodes and calculating incentives. It selects RSUs nodes based on a competitiveness matrix calculation, with the results transmitted to the RSUs within the edge layer to facilitate cooperative data-block storage, thereby reducing the storage overhead of the blockchain network system. Furthermore, the blockchain service layer’s incentive mechanism calculates the number of incentives sent by the sender RSUs to each receiver RSUs, as well as the value of the internal incentives spent on data offloading and transmission. Once the incentive calculations are completed, the acquisition and expenditure of incentives are executed via smart contracts.

Within the system, vehicles in the perception layer aggregate the gathered information into data blocks and transmit these to the RSUs nodes in the edge layer within their range. After calculating via the blockchain service layer, the RSU node selects the RSUs node that will receive the data block and provides incentives to the recipient. When an RSU node requires data offloading, it must acquire cloud storage space for this purpose. The meanings represented by the symbols used in the text are shown in Table 2.

The method of incentive collaborative data storage mechanism

This study assumes that for each data block, $⌊num/2-1⌋$ RSUs nodes are utilized for system storage. This approach not only guarantees a decentralized storage mechanism that strengthens the system’s robustness but also effectively minimizes data storage redundancy, optimizing storage efficiency.

In the study, a competitiveness matrix X is defined, where x_ij represents the competitiveness factor of node n_i. The competitiveness factor is categorized into three types: storage capacity, distance, and driving record. The number of evaluation indicators n is set to 3 to reflect these three different aspects of competitiveness. To further optimize the node selection process, the driving record DR _i is introduced to evaluate the historical behavior of the node and its mobility and stability within the network. The calculation formula for the driving record DR _i is as follows: (1)${\displaystyle D{R}_i=a_1\ast \frac{1}{1+V{C}_i}+a_2\ast log\left(M{L}_i+1\right)}$

where a₁ and a₂ reflect the influence of traffic violation records and driving mileage on the node selection, VC_i represents the number of traffic violations, and ML_i represents the driving mileage. (2)${\displaystyle \mathrm{X}=\left[\begin{array}{ccc}\hfill x_{1,1}\hfill & \hfill \cdots \hfill & \hfill x_{1,num}\hfill \\ \hfill ⋮\hfill & \hfill \ddots \hfill & \hfill ⋮\hfill \\ \hfill x_{n,1}\hfill & \hfill \cdots \hfill & \hfill x_{n.num}\hfill \end{array}\right]==\left[\begin{array}{cccc}\hfill L_1\hfill & \hfill L_2\hfill & \hfill \cdots \hfill & \hfill L_N\hfill \\ \hfill M{u}_1\hfill & \hfill M{u}_2\hfill & \hfill \cdots \hfill & \hfill M{u}_N\hfill \\ \hfill D{R}_1\hfill & \hfill D{R}_2\hfill & \hfill \cdots \hfill & \hfill D{R}_N\hfill \end{array}\right]}$

where L_i represents the path loss of the distance between node i and the sending node. The calculation formula is: (3)${\displaystyle L_i=l+10\theta lo{g}_{10}\left(d/d_0\right)}$

where d₀ is the reference distance, typically 1 meter; l is the path loss at the reference distance d₀. θ is the path loss exponent, reflecting the complexity of the propagation environment; and d represents the distance between two points. Mu_i is the storage utilization, and the formula is (4)${\displaystyle M{u}_i=\frac{M_i}{M_{i,max}}.}$

In addition, this article used the entropy weighting method to determine the weight of each evaluation index, and the weighting coefficient γ_n is defined as: (5)${\displaystyle {\gamma }_n=\frac{1-H_n}{m-\sum _{i=1}^m{H}_n}}$ (6)${\displaystyle {\gamma }_1+{\gamma }_2+{\gamma }_3=1}$

where γ_n represents the weight of the n-th competitiveness factor, such as physical distance, storage capacity, or driving records. The values are dynamically adjusted according to the current network state to ensure that the most important factors are prioritized in different scenarios. k is the adjustment coefficient, which controls the magnitude of the weight adjustment. A higher k indicates that the system is more sensitive to changes in competitiveness factors, while a lower k suggests that the system is more stable. f_ni represents the current state of the i th competitiveness factor, such as a node’s physical distance, storage capacity, or driving records, reflecting the node’s real-time performance in the network. (7)${\displaystyle H_n=-k\ast \sum _{i=1}^{N\sum _{ni}}{f}_{ni}ln}$ (8)${\displaystyle f_{ni}=\frac{x_{ni}}{\sum _{i=1}^N{x}_{ni}}}$

where k is a constant in the entropy weight method, defined as: (9)${\displaystyle k=\frac{1}{\mathit{ln}N}.}$

The final comprehensive competitiveness value ω_i is calculated using the following formula: (10)${\displaystyle {\omega }_i=\frac{{\gamma }_1}{L_i}+{\gamma }_2\ast M{u}_i+\frac{{\gamma }_3}{{\widehat{DR}}_i}}$

where ${\hat{L}}_i$ and ${\widehat{DR}}_i$ are derived from the normalization of the competitiveness factors of the storage node. (11)${\displaystyle {\hat{L}}_i=\frac{L_i-L_{min}}{L_{max}}}$ (12)${\displaystyle {\widehat{DR}}_i=\frac{D{R}_i-D{R}_{min}}{D{R}_{max}}.}$

Algorithm 1:

Incentive mechanism collaborative data storage algorithm

DOI: 10.7717/peerjcs.2849/table-4

In Algorithm 1, the selection process for collaborative storage nodes is demonstrated. In the first step, driving record DR_i, node distance consumption L_i, and storage utilization rate Mu_i are calculated using Eqs. (1), (3), and (4). The results are incorporated into the matrix in Eq. (2), yielding the competitiveness matrix. In the second step, the dynamic weight adjustment coefficients are calculated using Eqs. (5) through (9), and the competitiveness factors of the storage nodes are normalized using Eqs. (11) and (12). These are then substituted into Eq. (10) to obtain the comprehensive competitiveness value ω_i for each storage node. In this study, competitiveness is equivalent to the incentive value obtained by the RSU node, with smaller competitiveness indicating higher priority. In the third step, the values of ω are sorted to identify the $⌊num/2-1⌋$ nodes with the highest priority as recipient nodes.

The method of incentive-based data offloading

In this study, the incentive allocation for nodes is based on three core factors: driving record, storage utilization, and path loss. The initial incentive value is calculated using the following formula: (13)${\displaystyle P_i^{{}^{\prime }}=D{R}_i\ast \beta \left(1-\frac{M_i}{M_{i,max}}\right)\ast L_i.}$

The driving record DR_i evaluates the historical behavior of nodes, with well-performing nodes receiving more incentives. $\left(1-\frac{M_i}{M_{i,max}}\right)$ the storage utilization reflects the remaining storage space; the more ample the storage space, the higher the incentive. The path loss L_i represents the quality of signal transmission; the smaller the loss, the greater the incentive. Through the interaction of these factors, β can balance performance across various dimensions, ensuring fair and reasonable incentive distribution. (14)${\displaystyle P_i=P_i^{{}^{\prime }}\ast \left(1-\frac{a\ast P_i^{{}^{\prime }}}{P_{max}}\right).}$

In this formula, a is the attenuation coefficient, controlling the rate of incentive decay. As the incentive value $P_i^{{}^{\prime }}$ of a node approaches the threshold P_max, the attenuation factor $a\ast P_i^{{}^{\prime }}$ gradually increases, slowing down the rate of incentive growth. This mechanism ensures balanced incentive distribution, preventing excessive concentration of incentives on a few nodes, encouraging more nodes to participate in storage and data transmission, and maintaining system stability and fairness.

While providing incentives, collaborative storage needs to be implemented between nodes. Based on Eq. (15), the remaining storage capacity M_i of the node is obtained after collaborative storage. Here, ${\overline{M}}_i$ represents the node’s remaining capacity before collaborative storage, and S is the size of the collaboratively stored data. (15)${\displaystyle M_i={\overline{M}}_i-S.}$

In this article, the threshold ratio T of competitiveness is defined in Eq. (15), l represents the number of times each RSU appears in the receiving node-set when traversing all RSUs. (16)${\displaystyle T=\frac{l}{N}.}$

In Eq. (10), as the remaining storage capacity of a node decreases, the required incentives for data storage increase. Eventually, when the incentives are insufficient to compete with other nodes, the node may no longer receive incentives, signaling the need for data offloading to alleviate storage pressure (Firdaus, Rahmadika & Rhee, 2021). (17)${\displaystyle {\widehat{M}}_i=M_i+r\ast M_{i,max}.}$

Equation (16) outlines the process for calculating data offloading. Here, $\widehat{M_i}$ represents the remaining storage size in the node after the offloading process, whileM_i denotes the initial remaining storage size before offloading. Additionally, r is the uninstallation ratio, and r∗M_i,max represents an integer multiple of the data block size unloaded from the node. This equation ensures that the unloaded data is a coherent block that aligns with the storage capacity and data block size of the system.

In Eq. (18), the remaining amount Mo_i of a roadside unit node depends on its original amount ${\overline{Mo}}_i$, the reward P_i obtained from receiving data blocks, the amount Sdb_i spent by the node to broadcast data blocks and the amount ${\overline{P}}_i$ used to purchase cloud storage space. (18)${\displaystyle M{o}_i={\overline{Mo}}_i+P_i-Sd{b}_i-{\overline{P}}_i.}$

Algorithm 2:

Data Unloading Algorithm

DOI: 10.7717/peerjcs.2849/table-5

In Algorithm 1, the first step involves calculating the incentive value granted to the collaborative storage nodes and the remaining storage capacities P_i and M_i of the nodes, using Eqs. (13), (14), and (15) based on the collaborative storage nodes obtained from Algorithm 1. In the second step, the algorithm traverses the nodes to calculate their competitiveness T. If a node’s T-value is below the lower threshold of competitiveness, data offloading commences. The offloading process continues, gradually increasing the offloading storage ratio until the node’s T-value reaches the upper threshold of competitiveness. In the third step, Eq. (18) is used to calculate the remaining incentive value of the node. To ensure efficient storage management, the amount of data offloaded must be an integer multiple of the data block size. The maximum amount of data that can be offloaded is equivalent to the total capacity of stored data. The competitiveness threshold limits were determined through testing, with an optimal range identified between 30% and 90%. Test results also indicate that as the number of blocks in the blockchain network increases, the frequency of offloads decreases, demonstrating optimal performance in terms of data management and network efficiency.

Experimental analysis

This section analyzes the performance of the proposed scheme in terms of storage cost and scalability. It then contrasts the scheme with existing work in the field. A comparative evaluation was conducted through simulation, which allowed for a controlled experimental environment to assess the performance metrics and compare them with those of other approaches.

The proposed system architecture was implemented using Python version 3.7.2, as the primary programming language. The smart contracts were developed in Solidity, a script-oriented programming language designed to implement smart contracts in the Ethereum blockchain. This article used Solidity version 0.5.17 for this purpose. Remix IDE, a web-based integrated development environment, was utilized for compiling, debugging, and testing these smart contracts. All experimental procedures were carried out on a single computer equipped with an Intel(R) Core (TM) i5-7300HQ CPU at 2.50 GHz and 16 GB of RAM, running the Windows 10 operating system. The underlying data conditions for the simulation are listed in Table 3.

Storage consumption assessment

This study conducted two sets of experiments to compare storage consumption. In the first series of experiments, the storage consumption of the proposed scheme was benchmarked against that of the conventional blockchain, LayerChain, IoV block secure (G, Jatoth & Doriya, 2024) and GpDB schemes. In the second series, the study investigates how storage consumption is affected by varying the number of RSU nodes and data blocks, providing a comprehensive analysis of the scheme’s performance under different network conditions and data loads.

In the first set of experiments presented in Algorithm 2, this article observes that the remaining storage space of nodes in traditional blockchain configurations decreases as the number of data blocks increases. The results indicate that the proposed scheme (shown by red dashed lines and circles) demonstrates the lowest storage consumption, with a gradual increase as the block number grows. In contrast, the traditional blockchain shows a sharp rise in storage consumption, reaching the highest level at the 100-block mark. The LayerChain model exhibits a moderate increase in storage consumption, while the GpDB and IoV Block Secure models both show lower but steady increases in storage requirements. Overall, the proposed scheme proves to be the most efficient in terms of storage consumption, outperforming the other models as the block number increases.

These experiments varied the number of storage blocks from 10 to 100 and compared the storage consumption of our scheme with that of the traditional blockchain, GpDB, and LayerChain at equivalent block counts. The performance results indicate that our scheme exhibits significantly lower storage consumption owing to the incorporation of storage optimization and data offloading mechanisms under the incentivized framework.

In the second set of experiments depicted in Fig. 3, the study examined the storage consumption behavior in traditional blockchain networks. Because blockchain functions as a distributed ledger, each node must maintain a duplicate of the same data on the public chain. As the number of nodes increases, the total storage capacity required across all nodes escalates linearly for a constant number of data blocks. Similarly, for a fixed number of nodes, the total storage demand increases linearly with the number of data blocks.

This experiment is varied the number of RSUs from 10 to 70 and the number of data blocks from 50 to 150. Owing to the implementation of data offloading, the total storage consumption of RSU nodes was reduced as the amount of data shows that the overall storage consumption of the RSU nodes generally increased with the addition of more RSUs, despite instances of data offloading. When comparing the effects of increasing the number of blocks with a fixed number of RSUs, the total storage consumption typically increased with the block count, except in certain scenarios where data offloading led to a decrease in the total storage across all RSUs nodes.

The threshold value of competitiveness assessments

In this model, blockchain must address the issue of growing data within RSUs over time by optimizing storage through data offloading. Determining the circumstances under which to offload data and the extent of offloading are crucial for managing this challenge. This study uses the data’s competitive ability as the criterion for offloading. The lower limit of the competitiveness threshold is employed to decide when to initiate the offloading of data blocks, whereas the upper limit determines when to cease offloading.

The experiment presented in Fig. 4 compares the offloading folds for different data blocks by varying the number of data blocks from 50 to 175. Lower limits of 30% and 40% and upper limits of 70%, 80%, and 90% were tested. As observed in Fig. 4, the lower limit has a more significant impact on the number of offloads, whereas the upper limit has a relatively minor effect. The data revealed that the lowest average number of offloads occurred at a lower limit of 30% and an upper limit of 90%. Consequently, for the experimental tests in this study, the lower limit of the competitiveness threshold was uniformly set to 30%, and the upper limit was set to 90%.

Furthermore, tests were conducted with the lower limit of the competitiveness threshold set to 20% to investigate the principle that a lower limit results in less offloading. When the lower limit of the competitiveness threshold was too low, the number of offloads from all the RSUs decreased, as did the amount of data offloaded each time. This eventually led to the depletion of the remaining storage in the individual nodes. Conversely, this issue did not arise when the lower competitiveness limit was set to 30%. Therefore, to ensure that RSU nodes always maintained some remaining storage capacity, the lower limit of the competitiveness threshold was established at 30%.

Data reception and offload assessment

This experiment comprises three parts: (1) The first part presents the total number of RSU offloads based on the variation in the number of RSUs. (2) The second part illustrates the change in the overall number of RSU offloads as the block size is altered. (3) The third part presents a comparison graph of the received and sent data for each RSU under the condition that the number of RSUs, block size, and block number remain constant.

In the first set of experiments presented in Fig. 5, the number of RSUs varied from 10 to 70, and the number of data blocks was changed from 50 to 150. The results indicate that the total number of data blocks offloaded by all RSUs increased as the number of RSUs increased while keeping the number of data blocks constant. The figure demonstrates that the increase in the number of RSUs did not affect the offloading process within individual RSU nodes, and multiple RSUs did not interfere with one another during the offloading process.

When the number of RSUs remained constant, an examination of the effects of increasing the number of data blocks revealed that the overall number of offloads for all RSUs continued to increase as the number of data blocks increased.

In the second set of experiments depicted in Fig. 6, the data block size was increased from 10 KB to 60 KB. For a constant number of data blocks, the overall total RSUs unload count increased as the data block size continued to increase. This indicates that the size of the data block affects the number of uninstalls.

In the third set of experiments presented in Fig. 7, this study compared the received and sent data for each RSU under the condition that the number of RSUs, block size, and block number were fixed. The bar chart illustrates the storage occupied by the new data blocks (including the storage occupied by the data blocks generated by the node itself and the received data blocks) and the storage of the unloaded data blocks for each RSU node when the total number of storage blocks reaches 50. The line graph represents the ratio of received storage to unloaded storage for each RSU node when the total number of storage blocks reaches 50.

As depicted in Fig. 8, the ratio remained stable between 1.1 and 1.5. Data blocks within the RSU node were organized in a queue structure and unloaded in a first-in, first-out sequence. Consequently, the size of the unloaded data blocks was smaller than or equal to that of the added data blocks. This ensured that the RSU node retained the most recently added data blocks after offloading, facilitating easy access to the latest data and enabling the node to efficiently manage temporary traffic issues. Moreover, every node actively participates in the storage and offloading of data, thereby ensuring that there are no selfish nodes in the system.

Implementation of ethereum

This study presents an incentive-based collaborative data storage scheme implemented within an Ethereum smart contract. The implementation results are presented in two sections. The first part compares the amount of gas consumed to propagate a fixed number of data blocks within the network using the traditional blockchain. The second part compares the wallet balance of each RSU node after spending and receiving incentives to store and unload the data blocks within this scheme.

The first part is shown in Fig. 9. Transaction cost refers to the amount of gas consumed by smart contracts during transactions in the blockchain. Gas is the “fuel” in Ethereum that ensures the smooth operation of the Ethereum ecosystem and is the unit used to measure the computational work required for specific operations on the Ethereum blockchain. In this context, the cost of gas comprises two primary aspects: the cost required to store data for the receiving node and the cost required to offload data.

When comparing the cost of storing the same data block in this scheme with the traditional blockchain, it is evident that even though this scheme demands additional offload gas, the total cost remains one-third lower than that in the traditional blockchain.

In the second part of the results in Fig. 10, the number of data blocks was set to 30, 90, and 150. After transmitting the specified number of data blocks, the amount remaining for each RSU node after spending and receiving the incentives was calculated. The incentive changes in the figure demonstrate that all RSU nodes within the proposed framework actively participated in sending, receiving, and offloading data. The nodes were evenly distributed to ensure that there were no selfish nodes in the system.

Discussion on the validity of the framework

The dataset was randomly generated in the experiments to minimize dataset-related issues. The results compared data offloading times and storage consumption across varying data block size, block count, and RSU nodes. The analysis confirmed that the proposed incentive mechanism effectively encouraged cooperation among RSU nodes, leading to enhanced system efficiency. The proposed scheme outperformed traditional blockchain, LayerChain, and GpDB in storage consumption, saving over 99% in storage and reducing gas consumption by 35%, especially with more blocks. However, the scheme lacks a comprehensive study on data credibility, which is vital for ensuring network security and performance. Future work should address data verification to maintain trustworthiness in untrusted data scenarios.

Discussion on implementation

The framework relies on collaboration between blockchain and RSU nodes, optimizing storage and data transfer by adjusting storage and incentive strategies. The architecture includes modules for data block management, RSU incentives, and blockchain optimization. Experimental results showed improved storage efficiency and lower gas consumption compared to traditional blockchain technologies, even with more blocks. However, data credibility remains unresolved. Future research should focus on integrating data verification and encryption to enhance security and trustworthiness in real-world deployments.