## 3 System Model
### RSU Cluster Cooperative Storage System Model
By leveraging these immutable and tamper-proof reputation profiles recorded in the blockchain, vehicles dynamically establish social relationships such as trust-based collaborations or resource sharing with other entities, thereby enabling decentralized and credibility-driven interactions within the SIoV. For the block deployment and vehicle access process, taking the system in Figure 1 as an example, we cluster RSUs into three clusters \(C_{1}\), \(C_{2}\), and \(C_{3}\). Assuming that the current blockchain ledger is \(B=\{b_{1},b_{2},\cdots,b_{6}\}\), then in addition to being stored as a backup in the cloud, the blockchain data also need to be deployed within the RSU clusters \(C_{1}\), \(C_{2}\), and \(C_{3}\). For cluster \(C_{1}\), which consists of four RSUs \(r_{1}\)\(\sim\)\(r_{4}\), unlike traditional full nodes that need to store the entire blockchain, each RSU in the cluster only stores a subset of the blockchain blocks, while storing only block headers for the remaining blocks to support basic verification. The cluster must collaboratively ensure that at least one complete copy of the blockchain data is available within the storage cluster. For the RSU node \(r_{3}\) within the collaborative storage cluster, even if it does not store all blockchain blocks locally, it can still provide services to vehicles through RSU collaboration. Considering RSU \(r_{3}\) within the collaborative storage cluster as shown in Figure 1, it stores the full data of block \(b_{6}\) while only keeping the block headers of the remaining blocks. When vehicle \(v_{2}\) requests the data contained in block \(b_{2}\) from \(r_{3}\), the RSU first checks whether it has stored block \(b_{2}\) locally. Upon detecting the absence of this block, \(r_{3}\) sends a request via the R2R (RSU-to-RSU) link to another RSU within the cluster, \(r_{2}\) which has stored block \(b_{2}\). After retrieving the required block data, \(r_{3}\) transmits it to vehicle \(v_{2}\) via the R2V (RSU-to-Vehicle) link. Based on the full-node constraints imposed by blockchain, all RSUs within a cluster \(C_{l}\) must collaboratively store at least one complete copy of the blockchain ledger to support verification and consensus functions. Therefore, the total storage capacity of the RSU cluster must satisfy the following condition:  
\[\sum_{r_{l}\in C_{l}}rc_{i}\geq\eta\sum_{b_{k}\in B}s_{k,}\eta\geq 1 \tag{1}\]  
Figure 1: Collaborative storage system of RSU cluster based on blockchain. where \(\eta\) is an adjustment factor that ensures the cluster meets the fundamental storage constraints while reserving additional storage capacity to accommodate newly generated blocks within the cluster. A larger \(\eta\) value enhances the cluster's fault tolerance against individual node failures but also increases the overall storage resource requirements, potentially necessitating additional nodes to maintain stable cluster operation. Subject to the constraint in Equation (1), any RSU node within the cluster can selectively store the complete data of certain blocks while retaining only block header information for the remaining blocks. This approach optimizes the utilization of storage resources.