## 5 Spatio-Temporal Big Data Collaborative Storage Mechanism
### Aggregation Proof Protocol
The configuration of the devices used in the experiments is shown in Table 1.

### Communication Overhead

In the collaborative on-chain and off-chain storage scheme, during the setup phase, data owners need to send initial setup information to the off-chain storage server and the blockchain. This information is used later for querying, verification, and updating of the data. The experiment in this chapter compares the scheme proposed in this paper with the schemes referred to as Ref [34] and the Bsmd [35] scheme. In the Ref scheme, the user divides the file into blocks to generate copies and data tags and sends them to the cloud organizer (CO) for verification. After passing, the CO distributes the data and tags it to the cloud server (CS) and records the storage location. The Bsmd scheme is similar to the system storage model of this paper. However, in the setup phase, the data owner generates signatures based on the original data and stores these signatures on the chain after verification by other nodes, while storing the complete data off the chain. Both the Ref and Bsmd schemes need to calculate and submit the corresponding location information for each submitted data, and its size is linear and related to the amount of data submitted. In the scheme proposed in this chapter, it is necessary to compute and submit information about the position of each piece of data submitted, with the size being linear and related to the volume of data submitted. In the scheme proposed in this chapter, we amortize the verification parameters over each upload and update, only calculating and sending \((G,g,PrimeGen)\) during the setup phase, which has a fixed size and is independent of the volume of data submitted. We experimentally compared the parameter overhead during the setup phase of these three schemes, with the results shown in Figure 3. It can be concluded that the scheme proposed in this chapter has a higher communication efficiency and can enhance system performance. ### Off-Chain Overhead

In this section, to better test the aggregation performance of the proposed scheme, we divided the queries into two types: Query1 and Query2. Both are batch queries that require the off-chain storage server to run either a de-aggregation or aggregation algorithm. The distinction lies in that for Query1, when the query location \(Q\cap I=\varnothing\), it necessitates the aggregation of \(S_{i}\) and \(\Lambda_{i}\). In another scenario, Query2, when the query location \(Q\cap I=\varnothing\), a de-aggregation algorithm is needed, where \(I\) represents the proofs that have already been aggregated in the database. Since in practical applications, data owners need to upload \(S_{i}\) at the time of data upload, we will pre-calculate the corresponding \(S_{i}\) at the respective positions. We created a file of 20 MB and partitioned it into 10,000 data blocks, each block being 2 Kb in dimensions. \begin{table}
\begin{tabular}{l c c} \hline \hline
**Parameter** & **Storage Server** & **Data Owner/Verifier** \\ \hline CPU & 3.1 GHz & 2.8 GHz \\ Memory & 16 GB & 8 GB \\ Hard Disk & 1 TB & 128 GB \\ Network Speed & 300 Mb & 100 Mb \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Parameter configuration table. As shown in Figure 4, specifically because we have implemented preprocessing techniques, the time required for our verification operation, Verify, is the lowest among the three operations and does not vary significantly with various quantities of data blocks. This indicates that the verification process is both fast and stable. The time expense of the Query1 operation increases with the number of data blocks, but the overall increase is moderate, showing a certain linear growth trend. The time expense of the Query2 operation also increases with the quantity of data blocks, and it has the highest time expense among all operations. Particularly when the quantity of data blocks is large, its time cost is significantly higher than that of Query1 and the verification operation.